mirror of
https://github.com/dashpay/dash.git
synced 2024-12-26 04:22:55 +01:00
be5c84f41d
d6d2ab984547be4a9f7ba859a2a4c9ac9bfbf206 test: MiniWallet: fix fee calculation for P2PK and check tx vsize (Sebastian Falbesoner) ce024b1c0ef2dcd307023aaaab40373c8bf17db1 test: MiniWallet: force P2PK signature to have fixed size (71 bytes) (Sebastian Falbesoner) Pull request description: This PR is a follow-up to #21945. It aims to both fix the fee calculation for P2PK mode transactions and enable its vsize check. Currently, the latter assumes a fixed tx length, which is fine for anyone-can-spend txs but doesn't apply to P2PK output spends due to varying DER signature size; the vsize check is therefore disabled for P2PK mode on master branch. Creating one million DER signatures with MiniWallet shows the following distribution of sizes (smart people with better math skills probably could deduce the ratios without trying, but hey): | DER signature size [bytes] | #occurences (ratio) | | ------------- | ------------- | | 71 | 498893 (49.89%) | | 70 | 497244 (49.72%) | | 69 | 3837 (0.38%) | | 68 | 22 (0.0022%) | Note that even smaller signatures are possible (for smaller R and S values with leading zero bytes), it's just that the probability decreases exponentially. Instead of choosing a large vsize check range and hoping that smaller signatures are never created (potentially leading to flaky tests), the proposed solution is ~~to limit the signature size to the two most common sizes 71 and 70 (>99.6% probability) and then accordingly only check for two vsize values; the value to be used for fee calculation is a decimal right between the two possible sizes (167.5 vbytes) and for the vsize check it's rounded down/up integer values are used.~~ to simply grind the signature to a fixed size of 71 bytes (49.89% probability, i.e. on average each call to `sign_tx()`, on average two ECC signing operations are needed). ~~The idea of grinding signatures to a fixed size (similar to https://github.com/bitcoin/bitcoin/pull/13666 which grinds to low-R values) would be counter-productive, as the signature creation in the test suite is quite expensive and this would significantly slow down tests that calculate hundreds of signatures (like e.g. feature_csv_activation.py).~~ For more about transaction sizes on different input/output types, see the following interesting article: https://medium.com/coinmonks/on-bitcoin-transaction-sizes-97e31bc9d816 ACKs for top commit: MarcoFalke: Concept ACK d6d2ab984547be4a9f7ba859a2a4c9ac9bfbf206 Tree-SHA512: 011c70ee0e4adf9ba12902e4b6c411db9ae96bdd8bc810bf1d67713367998e28ea328394503371fc1f5087a819547ddaea56c073b28db893ae1c0031d7927f32 |
||
|---|---|---|
| .. | ||
| crypto | ||
| __init__.py | ||
| address.py | ||
| authproxy.py | ||
| bdb.py | ||
| bip340_test_vectors.csv | ||
| blockfilter.py | ||
| blocktools.py | ||
| coverage.py | ||
| descriptors.py | ||
| governance.py | ||
| key.py | ||
| messages.py | ||
| netutil.py | ||
| p2p.py | ||
| script_util.py | ||
| script.py | ||
| socks5.py | ||
| test_framework.py | ||
| test_node.py | ||
| test_shell.py | ||
| util.py | ||
| wallet_util.py | ||
| wallet.py | ||