da2bc865d644f6be748c305556bdd02f02d1b161 [wallet] don't create long chains by default (glozow)
Pull request description:
Default mempool policy doesn't let you have chains longer than 25 transactions. This is locally configurable of course, but it's not really safe to assume that a chain longer than 25 transactions will propagate. Thus, the wallet should probably avoid creating such transactions by default; set `DEFAULT_WALLET_REJECT_LONG_CHAINS` to true.
Closes#9752Closes#10004
ACKs for top commit:
MarcoFalke:
re-ACK da2bc865d644f6be748c305556bdd02f02d1b161 only change is fixing typos in tests 🎏
Tree-SHA512: 65d8e4ec437fe928adf554aa7e819a52e0599b403d5310895f4e371e99bbc838219b3097c4d2f775bc870ac617ef6b4227b94291f2b376f824f14e8f2b152f31
0000ff0d6b2442706a588fd906ebf1adf8ff8226 test: move-only: Move all generate* tests to a single file (MarcoFalke)
Pull request description:
Seems a bit overkill to spread tests for the `generate*` methods over several files. Combining them into a single file has also a nice side-effect of requiring less node (re)starts, which are expensive in valgrind.
ACKs for top commit:
glozow:
utACK 0000ff0d6b2442706a588fd906ebf1adf8ff8226
Tree-SHA512: 8269eb05649a871011bbfbd1838d0f7d1dac4a35b3b198fc43fe85131fda8a53803b75da78cbf422eabf086006dee4421e622fbe706f6781a3848b989024001b
1066d10f71e6800c78012d789ff6ae19df0243fe scripted-diff: rename TxRelay members (John Newbery)
575bbd0dea6d12510fdf3220d0f0e47d969da6e9 [net processing] Move tx relay data to Peer (John Newbery)
785f55f7eeab0dedbeb8e0d0b459f3bdc538b621 [net processing] Move m_wtxid_relay to Peer (John Newbery)
36346703f8558d6781c079c29ddece5a97477beb [net] Add CNode.m_relays_txs and CNode.m_bloom_filter_loaded (John Newbery)
Pull request description:
This continues the work of moving application layer data into net_processing, by moving all tx data into the new Peer object added in #19607.
For motivation, see #19398.
ACKs for top commit:
dergoegge:
ACK 1066d10f71e6800c78012d789ff6ae19df0243fe - This is a good layer separation improvement with no behavior changes.
glozow:
utACK 1066d10f71e6800c78012d789ff6ae19df0243fe
Tree-SHA512: 0c9d6b8a0a05e2d816b6d6588b7df133842ec960ae67667813422aa7bd8eb5308599c714f3822a98ddbdf364ffab9050b055079277ba4aff24092557ff99ebcc
cccc1e70b8a14430cc94143da97936a60d6c83d3 Enforce Taproot script flags whenever WITNESS is set (MarcoFalke)
fa422994116a7a053789304d56159760081479eb Remove nullptr check in GetBlockScriptFlags (MarcoFalke)
faadc606c7644f2934de390e261d9d65a81a7592 refactor: Pass const reference instead of pointer to GetBlockScriptFlags (MarcoFalke)
Pull request description:
Now that Taproot is active, it makes sense to enforce its rules on all blocks, even historic ones, regardless of the deployment status.
### Benefits:
(With "script flags" I mean "taproot script verification flags".)
* Script flags are known ahead for all blocks (even blocks not yet created) and do not change. This may benefit static analysis, code review, and development of new script features that build on Taproot.
* Any future bugs introduced in the deployment code won't have any effect on the script flags, as they are independent of deployment.
* Enforcing the taproot rules regardless of the deployment status makes testing easier because invalid blocks after activation are also invalid before activation. So there is no need to differentiate the two cases.
* It gives belt-and-suspenders protection against a practically expensive and theoretically impossible IBD reorg attack where the node is eclipsed. While `nMinimumChainWork` already protects against this, the cost for a few months worth of POW might be lowered until a major version release of Bitcoin Core reaches EOL. The needed work for the attack is the difference between `nMinimumChainWork` and the work at block 709632.
For reference, previously the same was done for P2SH and WITNESS in commit 0a8b7b4b33c9d78574627fc606267e2d8955cd1c.
### Implementation:
I found one block which fails verification with the flags applied, so I added a `TaprootException`, similar to the `BIP16Exception`.
For reference, the debug log:
```
ERROR: ConnectBlock(): CheckInputScripts on b10c007c60e14f9d087e0291d4d0c7869697c6681d979c6639dbd960792b4d41 failed with non-mandatory-script-verify-flag (Witness program was passed an empty witness)
BlockChecked: block hash=0000000000000000000f14c35b2d841e986ab5441de8c585d5ffe55ea1e395ad state=non-mandatory-script-verify-flag (Witness program was passed an empty witness)
InvalidChainFound: invalid block=0000000000000000000f14c35b2d841e986ab5441de8c585d5ffe55ea1e395ad height=692261 log2_work=92.988459 date=2021-07-23T08:24:20Z
InvalidChainFound: current best=0000000000000000000067b17a4c0ffd77c29941b15ad356ca8f980af137a25d height=692260 log2_work=92.988450 date=2021-07-23T07:47:31Z
ERROR: ConnectTip: ConnectBlock 0000000000000000000f14c35b2d841e986ab5441de8c585d5ffe55ea1e395ad failed, non-mandatory-script-verify-flag (Witness program was passed an empty witness)
```
Hint for testing, make sure to set `-noassumevalid`.
### Considerations
Obviously this change can lead to consensus splits on the network in light of massive reorgs. Currently the last block before Taproot activation, that is the last block without the Taproot script flags set, is only buried by a few days of POW. However, when and if this patch is included in the next major release, it will be buried by a few months of POW. BIP90 considerations apply when looking at reorgs this large.
ACKs for top commit:
Sjors:
tACK cccc1e70b8a14430cc94143da97936a60d6c83d3
achow101:
ACK cccc1e70b8a14430cc94143da97936a60d6c83d3
laanwj:
Code review ACK cccc1e70b8a14430cc94143da97936a60d6c83d3
ajtowns:
ACK cccc1e70b8a14430cc94143da97936a60d6c83d3 ; code review; wrote a "getblockscriptflags" rpc to quickly check that blocks just had bit 17 (taproot) added; review of earlier revisions had established non-exception blocks do validate with taproot rules enabled.
jamesob:
ACK cccc1e70b8a14430cc94143da97936a60d6c83d3 ([`jamesob/ackr/23536.1.MarcoFalke.enforce_taproot_script_f`](https://github.com/jamesob/bitcoin/tree/ackr/23536.1.MarcoFalke.enforce_taproot_script_f))
Tree-SHA512: 00044de68939caef6420ffd588c1291c041a8b397c80a3df1e3e3487fbeae1821d23975c51c95e44e774558db76f943b00b4e27cbd0213f64a9253116dc6edde
58a14795b89a6bd812e0b71cb8b3088b8ab55c11 test: passing -onlynet=onion with -onion=0/-noonion raises expected init error (Jon Atack)
7000f66d367123d1de303fc15ce2ce60df379c11 test: passing -onlynet=onion without -proxy/-onion raises expected init error (Jon Atack)
8332e6e4cf45455fea0bf1f7527256cdb7bb1e6d test: passing invalid -onion raises expected init error (Jon Atack)
d5edb087082a50e6f7d413c3b43fdf1e6a20d29b test: passing invalid -proxy raises expected init error (Jon Atack)
bd57dcbaf2b5e5f50833912c894a1f1239ceb25b test: hoist proxy out of 2 network loops in feature_proxy.py (Jon Atack)
afdf2de28296660fd0284453a241aece8494eea8 test: add CJDNS to LimitedAndReachable_Network unit tests (Jon Atack)
2b7a8180a94738c2fcb21232a2eca07a7b27656d net, init: assert each network reachability is true by default (Jon Atack)
Pull request description:
Adds missing network reachability test coverage and an assertion during init, noticed while reviewing #22834:
- assert during init that each network reachability is true by default
- add CJDNS to the `LimitedAndReachable_Network` unit tests
- hoist proxy out of two network loops in feature_proxy.py
- test that passing invalid `-proxy` raises expected init error
- test that passing invalid `-onion` raises expected init error
- test that passing `-onlynet=onion` without `-proxy` and `-onion` raises expected init error
- test that passing `-onlynet=onion` with `-onion=0` and with `-noonion` raises expected init error
ACKs for top commit:
vasild:
ACK 58a14795b89a6bd812e0b71cb8b3088b8ab55c11
brunoerg:
ACK 58a14795b89a6bd812e0b71cb8b3088b8ab55c11
dongcarl:
Code Review ACK 58a14795b89a6bd812e0b71cb8b3088b8ab55c11
Tree-SHA512: bdee6dd0c12bb63591ce7c9321fe77b509ab1265123054e774adc38a187746dddafe1627cbe89e990bcc78b45e194bfef8dc782710d5b217e2e2106ab0158827
bc90b8d86916d43867762a391633664676550bd8 [move only] remove `is_wallet_compiled` checks (josibake)
0bfbf7fb2488753d795ffc1c63a8977e4fe4a3bc test: use MiniWallet in `interfaces_zmq` (josibake)
Pull request description:
While working on #24584 , `interface_zmq` started failing due to coin selection not running deterministically. The test doesn't actually need the wallet, so this PR migrates it to use MiniWallet
_Note for reviewers:_ the second commit moves large chunks of code out of an if block, so it may be helpful to review with something that ignores whitespace, e.g `git diff -w master`
ACKs for top commit:
vincenzopalazzo:
ACK bc90b8d869
Tree-SHA512: c618e23d00635d72dafdef28e68cbc88b9cc2030d4898fc5b7eac926fd621684c1958c075ed167192716b18308da5a0c1f1393396e31b99d0d3bde78b78fefc5
b2813980b81034ff9b40bd45080fa67dea475d39 init: disallow reindex-chainstate when pruning (Martin Zumsande)
Pull request description:
The combination of `-reindex-chainstate` and `-prune` currently makes the node stuck in an endless loop:
- `LoadChainstate()` will wipe the existing chainstate (so we have no genesis block anymore). It won't clean up unusable block files by calling `CleanupBlockRevFiles()` as for full `-reindex`.
- `ThreadImport()` has [logic](91d12344b1/src/node/blockstorage.cpp (L855)) of reloading Genesis after reindexing. This is what makes full `-reindex` work with `-prune` but it's not executed for `-reindex-chainstate`.
- Since we still don't have a genesis block, init will wait for it forever in an endless loop ([code](91d12344b1/src/init.cpp (L1630-L1640))).
Fix this by disallowing `-reindex-chainstate` together with `-prune`. This is discouraged in the help for `-reindex-chainstate` anyway ("When in pruning mode or if blocks on disk might be corrupted, use full -reindex instead.") but wasn't enforced.
Fixes#24242
ACKs for top commit:
MarcoFalke:
cr ACK b2813980b81034ff9b40bd45080fa67dea475d39
Tree-SHA512: 7220842daaf9a4f972d82b13b81fdeac2833bf5e665c5b0f8eaf6a4bcd0725c8e97d19ec956ca4b730065a983475bb3a2732713d338f4caf8666ccbf63d4d988
fa76d8d4d71d844e217686881d4f630eac3a8e10 test: Actually print TSan tracebacks (MarcoFalke)
Pull request description:
Commit 5e5138a721738f47053d915e4c65f925838ad5b4 made the TSan logs to be printed before returning an error from the ci script.
However, it seems that on Cirrus CI, the `--failfast` option will kill not only all python process and bitcoind child process, but also the parent CI bash script, rendering the `trap` inefficient. I believe this bug was introduced in commit 451b96f7d2796d00eabaec56d831f9e9b1a569cc.
ACKs for top commit:
fanquake:
utACK fa76d8d4d71d844e217686881d4f630eac3a8e10
Tree-SHA512: 686f889d38a343882cb62ad6e0c2080196330e7cc7086891a7ff66d9443b455c82ba8d7e4a5cc42daa0513b0ad2743055bfe90e2f6ac88a910ee3b663fabddcd
2b6dd4e75b3ad2daff553fde018fe4c8f1187878 test: use MiniWallet for mempool_package_onemore.py (Sebastian Falbesoner)
eb3c5c4ef2eeb1d37d729d4487ed067a24cf81c8 test: MiniWallet: add helper methods `{send,create}_self_transfer_multi` (Sebastian Falbesoner)
Pull request description:
This PR enables one more of the non-wallet functional tests (mempool_package_onemore.py) to be run even with the Bitcoin Core wallet disabled by using the MiniWallet instead, as proposed in https://github.com/bitcoin/bitcoin/issues/20078. For this purpose helper methods `MiniWallet.{create,send}_self_transfer_multi` are introduced which serve as a replacement for `chain_transaction`. With this, it should be also quite straight-forward to change the larger related test `mempool_packages.py` to use MiniWallet.
ACKs for top commit:
MarcoFalke:
ACK 2b6dd4e75b3ad2daff553fde018fe4c8f1187878 💾
Tree-SHA512: 0c97fa0519ca5eaa6df8953a04678aa8a6a66905a82db6ff40042a675d0c0682aee829a48db84e4e7983d8f766875021f0d39d65e12889342610b8861bc29cd5
2726b60a3ac098b44f2970bed21147b70e12a1c2 test: use MiniWallet for rpc_createmultisig.py (Ayush Sharma)
Pull request description:
This PR enables one of the non-wallet functional tests (rpc_createmultisig.py) to be run even with the Bitcoin Core wallet disabled by using the MiniWallet instead, as proposed in #20078 .
ACKs for top commit:
danielabrozzoni:
re-ACK 2726b60a3ac098b44f2970bed21147b70e12a1c2
Tree-SHA512: fb0ef22d3f1c161ca5963cb19ce76533ac3941f15102fc0aa2286ef3bec48f219e5934d504b41976f9f295fb6ca582b737e0fea896df4eb964cdaba1b2c91650
fa7a576391ad5d61af937dd62496ded44105c671 test: Run non-wallet tests only once (MarcoFalke)
Pull request description:
I don't see why non-wallet tests should run for two wallet configs, even though they never use a wallet.
ACKs for top commit:
achow101:
ACK fa7a576391ad5d61af937dd62496ded44105c671
Tree-SHA512: 2a135acf3c3c83a2704ae11f40c72882b23a676828647be1a066653c4d00e4523704f377eb8745c6386829601cc5d643abdce376831c1db91a07e999e1d5e01f
fa8593f89892ddb09b64a7740087b725b3d7b5eb test: Fix generate calls and comments in feature_segwit (MarcoFalke)
Pull request description:
There are currently a few incorrect comments: Block `432` is mined "twice" (The second one is actually 433).
There isn't any need to mine this many blocks anyway, so remove a few calls.
ACKs for top commit:
theStack:
Tested ACK fa8593f89892ddb09b64a7740087b725b3d7b5eb
Tree-SHA512: b034077b85e6c978a80aa4de493797b4ae451d686cfb3e4fe40f37a38f41f7cb886f8e00a1c245a284be3502164b17414097fcb0bef66d155a1c1db5cfbe9e8f
fa48ea3067698954dd6630748964429686d8eaba Use MiniWallet in feature_coinstatsindex (MarcoFalke)
fab61437f68d2fa9c791f09ab6d53e3c7be535e0 test: Refactor MiniWallet get_utxo helper (MarcoFalke)
Pull request description:
Allows the test to be run even without a wallet compiled
ACKs for top commit:
josibake:
ACK fa48ea3067
ayush933:
tACK fa48ea3 . The test runs successfully with the wallet disabled.
willcl-ark:
tACK fa48ea3067 both with and without wallet compiled in.
Tree-SHA512: e04e04ea0f236c062d6be68909ece2770130ce1d5343823893073d95aebc6eedb1ad1dc5bc41e5b0cb0bf2cd9018bb1d668f0e7f5f1101ed4e0b007ed6b00f69
61152183ab18960c8b42cf22ff7168762946678e wallet: Add a deprecation warning for newly created legacy wallets (Andrew Chow)
Pull request description:
As we slowly deprecate legacy wallets, we need to warn users that are making new legacy wallets that their wallet type is going to be unsupported in the future.
ACKs for top commit:
jonatack:
ACK 61152183ab18960c8b42cf22ff7168762946678e
S3RK:
reACK 61152183ab18960c8b42cf22ff7168762946678e
theStack:
ACK 61152183ab18960c8b42cf22ff7168762946678e
Tree-SHA512: e89bfb8168869542498958f0c9a2ab302dfd43287f8a49e7d9e09f60438a567bb8b7219a4e569797ee819b30b624f532fcc0b70c6aa0edcb392a301b8ce8b541
5d7c69b8871aad747969247c7a047b439c5ca59e rpc: rename getdeploymentinfo status-next to status_next (Jon Atack)
Pull request description:
Rename the `status-next` field to `status_next` in getdeploymentinfo before the RPC is released in v23.
Before
```
Result:
{ (json object)
"hash" : "str", (string) requested block hash (or tip)
"height" : n, (numeric) requested block height (or tip)
"deployments" : { (json object)
"xxxx" : { (json object) name of the deployment
"type" : "str", (string) one of "buried", "bip9"
"height" : n, (numeric, optional) height of the first block which the rules are or will be enforced (only for "buried" type, or "bip9" type with "active" status)
"active" : true|false, (boolean) true if the rules are enforced for the mempool and the next block
"bip9" : { (json object, optional) status of bip9 softforks (only for "bip9" type)
"bit" : n, (numeric, optional) the bit (0-28) in the block version field used to signal this softfork (only for "started" and "locked_in" status)
"start_time" : xxx, (numeric) the minimum median time past of a block at which the bit gains its meaning
"timeout" : xxx, (numeric) the median time past of a block at which the deployment is considered failed if not yet locked in
"min_activation_height" : n, (numeric) minimum height of blocks for which the rules may be enforced
"status" : "str", (string) status of deployment at specified block (one of "defined", "started", "locked_in", "active", "failed")
"since" : n, (numeric) height of the first block to which the status applies
"status-next" : "str", (string) status of deployment at the next block
"statistics" : { (json object, optional) numeric statistics about signalling for a softfork (only for "started" and "locked_in" status)
"period" : n, (numeric) the length in blocks of the signalling period
"threshold" : n, (numeric, optional) the number of blocks with the version bit set required to activate the feature (only for "started" status)
"elapsed" : n, (numeric) the number of blocks elapsed since the beginning of the current period
"count" : n, (numeric) the number of blocks with the version bit set in the current period
"possible" : true|false (boolean, optional) returns false if there are not enough blocks left in this period to pass activation threshold (only for "started" status)
},
"signalling" : "str" (string) indicates blocks that signalled with a # and blocks that did not with a -
}
}
}
}
```
After
```
Result:
{ (json object)
"hash" : "str", (string) requested block hash (or tip)
"height" : n, (numeric) requested block height (or tip)
"deployments" : { (json object)
"xxxx" : { (json object) name of the deployment
"type" : "str", (string) one of "buried", "bip9"
"height" : n, (numeric, optional) height of the first block which the rules are or will be enforced (only for "buried" type, or "bip9" type with "active" status)
"active" : true|false, (boolean) true if the rules are enforced for the mempool and the next block
"bip9" : { (json object, optional) status of bip9 softforks (only for "bip9" type)
"bit" : n, (numeric, optional) the bit (0-28) in the block version field used to signal this softfork (only for "started" and "locked_in" status)
"start_time" : xxx, (numeric) the minimum median time past of a block at which the bit gains its meaning
"timeout" : xxx, (numeric) the median time past of a block at which the deployment is considered failed if not yet locked in
"min_activation_height" : n, (numeric) minimum height of blocks for which the rules may be enforced
"status" : "str", (string) status of deployment at specified block (one of "defined", "started", "locked_in", "active", "failed")
"since" : n, (numeric) height of the first block to which the status applies
"status_next" : "str", (string) status of deployment at the next block
"statistics" : { (json object, optional) numeric statistics about signalling for a softfork (only for "started" and "locked_in" status)
"period" : n, (numeric) the length in blocks of the signalling period
"threshold" : n, (numeric, optional) the number of blocks with the version bit set required to activate the feature (only for "started" status)
"elapsed" : n, (numeric) the number of blocks elapsed since the beginning of the current period
"count" : n, (numeric) the number of blocks with the version bit set in the current period
"possible" : true|false (boolean, optional) returns false if there are not enough blocks left in this period to pass activation threshold (only for "started" status)
},
"signalling" : "str" (string) indicates blocks that signalled with a # and blocks that did not with a -
}
}
}
}
```
Top commit has no ACKs.
Tree-SHA512: 4facfd7af3cfb7b6f5495758c4387602802f5e39d9270b162d17350a7f954eab0b74d895f17f0d8dfbc7814d36db7cff56d08c42728432885ea6f4e37aea4aa8
40e871d9b4e55f5b5f7ce2a89157cd3d9f152037 [miner] always assume we can create witness blocks (glozow)
Pull request description:
Given the low possibility of a reorg reverting the segwit soft fork, there is no longer a need to check whether segwit is active to see if it's okay to add to the block template (see also #23512, #21009, etc). `TestBlockValidity()` is also run on the block template at the end of `CreateNewBlock()`, so any invalid block would be caught there.
ACKs for top commit:
gruve-p:
ACK 40e871d9b4
jnewbery:
utACK 40e871d9b4, although I disagree about changing the test for segwit transaction in mempool before activagtion, instead of just removing it: https://github.com/bitcoin/bitcoin/pull/24421#discussion_r822933721.
achow101:
ACK 40e871d9b4e55f5b5f7ce2a89157cd3d9f152037
theStack:
Code-review ACK 40e871d9b4e55f5b5f7ce2a89157cd3d9f152037
Tree-SHA512: bf4860bf2bed8339622d05228d11d60286edb0c32a9a3c434b8d154913c07ea56e50649f4af7009c2a1c6a58a81d2299ab43b41a6f16dee7d08cc89cc1603019
db27ac935480aeec40a1cfc9d5f10a48be55d61b tests: Ensure sorted/multi_a descriptors always generate different addrs (Andrew Chow)
Pull request description:
Sometimes the multi_a and sortedmulti_a descriptors will produce some of the same addresses in the tests. This causes the wallets to start generating addresses at a different index as they detect that one of the addresses is used. This subsequently causes a test failure.
To avoid this problem, use descriptors that will produce unique addresses by putting one of the multi_a in a different branch.
ACKs for top commit:
ajtowns:
ACK db27ac935480aeec40a1cfc9d5f10a48be55d61b
theStack:
Tested ACK db27ac935480aeec40a1cfc9d5f10a48be55d61b
Tree-SHA512: 0f57822bf4c7c79da304f092d7d43d6118e78a087cbeb0766fbbf634dc27911ae723d5d41350884d3b63a24d3b3817944f7e5fa534afb849161dd008a1e4a62f
7abd8b21ba34f6a42db2cd2d59a4c0e08561f609 doc: include wtxid in TransactionDescriptionString (brunoerg)
2d596bce6fefeff6033b21b391e81f1dda846937 doc: add wtxid info in release-notes (brunoerg)
a5b66738f19a0ad46d7bc287e0db08552c5a1fec test: add wtxid in expected_fields for wallet_basic (brunoerg)
e8c659a2970ec8855de3e1dbf91c6b614b8e5644 wallet: add wtxid in WalletTxToJSON (brunoerg)
7482b6f89500d9783cc6af0dccab7a08d0128206 wallet: add GetWitnessHash() (brunoerg)
Pull request description:
This PR add `wtxid` in `WalletTxToJSON` which allows to return this field in `listsinceblock`, `listtransactions` and `gettransaction` (RPCs).
ACKs for top commit:
achow101:
re-ACK 7abd8b21ba34f6a42db2cd2d59a4c0e08561f609
w0xlt:
crACK 7abd8b2
luke-jr:
re-utACK 7abd8b21ba34f6a42db2cd2d59a4c0e08561f609
Tree-SHA512: f86f2dbb5e38e7b19932006121802f47b759d31bdbffe3263d1db464f6a3a30fddd68416f886a44f6d3a9fd570f7bd4f8d999737ad95c189e7ae5e8ec1ffbdaa
fa097d074bc1afcc2a52976796bb618f7c6a68b3 addrman: Log too low compat value (MarcoFalke)
Pull request description:
Before this patch, when writing a negative `lowest_compatible` value, it would be read as a positive value. For example `-32` will be read as `224`. There is generally nothing wrong with that. Though, similarly there shouldn't be anything wrong with refusing to read a negative value. I find the code after this patch more logical than before. Also, this allows dropping a file-wide sanitizer suppression.
In practice none of this should ever happen. Bitcoin Core would never write a negative `lowest_compatible` in normal operation, unless the file storage is later corrupted by external influence.
ACKs for top commit:
mzumsande:
re-ACK fa097d074bc1afcc2a52976796bb618f7c6a68b3
Tree-SHA512: 9aae7b8fe666f52f667f149667025e0160cef1a793cc4d392e36608f65c2bee8096da429235118f40a3368f327aabe30f3732ae78c5874648ea6f423f2687b65
Sometimes the multi_a and sortedmulti_a descriptors will produce some of
the same addresses in the tests. This causes the wallets to start
generating addresses at a different index as they detect that one of
the addresses is used. This subsequently causes a test failure.
To avoid this problem, use descriptors that will produce unique
addresses by putting one of the multi_a in a different branch.
4828d53eccd52a67631c64cef0ba7df90dff138d Add (sorted)multi_a descriptors to doc/descriptors.md (Pieter Wuille)
b5f33ac1f82aea290b4653af36ac2ad1bf1cce7b Simplify wallet_taproot.py functional test (Pieter Wuille)
eb0667ea96d52db9135514a5e95ab943f6abd8a6 Add tests for (sorted)multi_a derivation/signing (Pieter Wuille)
c17c6aa08df81aa0086d80b50187c8cd60ecc222 Add signing support for (sorted)multi_a scripts (Pieter Wuille)
3eed6fca57d1fa7544f372e6e7de0a9ae1b5715a Add multi_a descriptor inference (Pieter Wuille)
79728c4a3d8a74f276daf1e72abbdecdab85a5d8 Add (sorted)multi_a descriptor and script derivation (Pieter Wuille)
25e95f9ff89a97b87ce218f28274c3c821b2d54d Merge/generalize IsValidMultisigKeyCount/GetMultisigKeyCount (Pieter Wuille)
Pull request description:
This adds a new `multi_a(k,key_1,key_2,...,key_n)` (and corresponding `sortedmulti_a`) descriptor for k-of-n policies inside `tr()`. Semantically it is very similar to the existing `multi()` descriptor, but with the following changes:
* The corresponding script is `<key1> OP_CHECKSIG <key2> OP_CHECKSIGADD <key3> OP_CHECKSIGADD ... <key_n> OP_CHECKSIGADD <k> OP_NUMEQUAL`, rather than the traditional `OP_CHECKMULTISIG`-based script, making it usable inside the `tr()` descriptor.
* The keys can optionally be specified in x-only notation.
* Both the number of keys and the threshold can be as high as 999; this is the limit due to the consensus stacksize=1000 limit
I expect that this functionality will later be replaced with a miniscript-based implementation, but I don't think it's necessary to wait for that.
Limitations:
* The wallet code will for not estimate witness size incorrectly for script path spends, which may result in a (dramatic) fee underpayment with large multi_a scripts.
* The multi_a script construction is (slightly) suboptimal for n-of-n (where a `<key1> OP_CHECKSIGVERIFY ... <key_n-1> OP_CHECKSIGVERIFY <key_n> OP_CHECKSIG` would be better). Such a construction is not included here.
ACKs for top commit:
achow101:
ACK 4828d53eccd52a67631c64cef0ba7df90dff138d
gruve-p:
ACK 4828d53ecc
sanket1729:
code review ACK 4828d53eccd52a67631c64cef0ba7df90dff138d
darosior:
Code review ACK 4828d53eccd52a67631c64cef0ba7df90dff138d
Tree-SHA512: 5dcd434b79585f0ff830f7d501d27df5e346f5749f47a3109ec309ebf2cbbad0e1da541eec654026d911ab67fd7cf7793fab0f765628d68d81b96ef2a4d234ce
If `-bind=` is provided then we would bind only to a particular address
and should not add all the other addresses of the machine to the list of
local addresses.
Fixes https://github.com/bitcoin/bitcoin/issues/20184 (case 4.)
`GetListenPort()` uses a simple logic: "if `-port=P` is given, then we
must be listening on `P`, otherwise we must be listening on `8333`".
This is however not true if `-bind=` has been provided with `:port` part
or if `-whitebind=` has been provided. Thus, extend `GetListenPort()` to
return the port from `-bind=` or `-whitebind=`, if any.
Fixes https://github.com/bitcoin/bitcoin/issues/20184 (cases 1. 2. 3. 5.)
Rename `CaptureMessage()` to `CaptureMessageToFile()` and introduce a
`std::function` variable called `CaptureMessage` whose value can be
changed by unit tests, should they need to inspect message contents.
c4d76c6faa3adf06f192649e169ca860ce420d30 tests: Tests for inactive HD chains (Andrew Chow)
8077862c5e8a3ed501f0baabc33536eb16922ceb wallet: Refactor TopUp to be able to top up inactive chains too (Andrew Chow)
70134eb34f58f0c572e7c3775e292d408f03b5ab wallet: Properly set hd chain counters when loading (Andrew Chow)
961b9e4e40019a87eaa11c8a9c3305870f7a6d75 wallet: Parse hdKeypath if key_origin is not available (Andrew Chow)
0652ee73ec880a66ec88bde007ee03c0b9d1b074 Add size check on meta.key_origin.path (Rob Fielding)
Pull request description:
Currently inactive HD chains are only derived from at the time a key in that chain is found to have been used. However, at that time, the wallet may not be able to derive keys (e.g. it is locked). Currently we would just move on and not derive any new keys, however this could result in missing funds.
This PR resolves this problem by adding memory only variables to `CHDChain` which track the highest known index. `TopUp` is modified to always try to top up the inactive HD chains, and this process will use the new variables to determine how much to top up. In this way, after an encrypted wallet is unlocked, the inactive HD chains will be topped up and hopefully funds will not be missed.
Note that because these variables are not persisted to disk (because `CHDChain`s for inactive HD chains are not written to disk), if an encrypted wallet is not unlocked in the same session as a key from an inactive chain is found to be used, then it will not be topped up later unless more keys are found.
Additionally, wallets which do not have upgraded key metadata will not derive any keys from inactive HD chains. This is resolved by using the derivation path string in `CKeyMetadata.hdKeypath` to determine what indexes to derive.
ACKs for top commit:
laanwj:
Code review ACK c4d76c6faa3adf06f192649e169ca860ce420d30
Tree-SHA512: b2b572ad7f1b1b2847edece09f7583543d63997e18ae32764e5a27ad608dd64b9bdb2d84ea27137894e986a8e82f047a3dba9c8015b74f5f179961911f0c4095
