| Age | Commit message (Collapse) | Author |
|---|
|
This makes it more generalistic than just having the miniscripts since
we are going to have Taproot descriptors with (multiple) miniscripts in
them too.
|
|
We make the Satisfier a base in which to store the common methods
between the Tapscript and P2WSH satisfier, and from which they both
inherit.
A field is added to SignatureData to be able to satisfy pkh() under
Tapscript context (to get the pubkey hash preimage) without wallet data.
For instance in `finalizepsbt` RPC. See also the next commits for a
functional test that exercises this.
|
|
We'll need the Miniscript satisfier for Tapscript too.
|
|
|
|
|
|
64-hex-characters public keys are valid in Miniscript key expressions
within a Tapscript context.
Keys under a Tapscript context always serialize as 32-bytes x-only
public keys (and that's what get hashed by OP_HASH160 on the stack too).
|
|
In order to exacerbate a mistake in the stack size tracking logic,
sometimes pad the witness to make the script execute at the brink of the
stack size limit. This way if the stack size is underestimated for a
script it would immediately fail `VerifyScript`.
|
|
|
|
Under Tapscript, due to the lifting of some standardness and consensus
limits, scripts can now run into the maximum stack size during
execution. Any Miniscript that may hit the limit on any of its spending
paths must be marked as unsafe.
Co-Authored-By: Pieter Wuille <pieter@wuille.net>
|
|
We introduce another global that dictates the script context under which
to operate when running the target.
For miniscript_script, just consume another byte to set the context.
This should only affect existing seeds to the extent they contain a
CHECKMULTISIG. However it would not invalidate them entirely as they may
contain a NUMEQUAL or a CHECKSIGADD, and this still exercises a bit of
the parser.
For miniscript_string, reduce the string size by one byte and use the
last byte to determine the context. This is the change that i think
would invalidate the lowest number of existing seeds.
For miniscript_stable, we don't want to invalidate any seed. Instead of
creating a new miniscript_stable_tapscript, simply run the target once
for P2WSH and once for Tapscript (with the same seed).
For miniscript_smart, consume one byte before generating a pseudo-random
node to set the context. We have less regard for seed stability for this
target anyways.
|
|
Adapt the test data and the parsing context to support x-only keys.
Adapt the Test() helper to test existing cases under both Tapscript and
P2WSH context, asserting what needs to be valid or not in each.
Finally, add more cases that exercise the logic that was added in the
previous commits (multi_a, different resource checks and keys
serialization under Tapscript, different properties for 'd:' fragment,
..).
|
|
We'll need to get a compressed key out of an x-only one in other places.
Avoid duplicating the code.
|
|
|
|
Under Tapscript, there is:
- No limit on the number of OPs
- No limit on the script size, it's implicitly limited by the maximum
(standard) transaction size.
- No standardness limit on the number of stack items, it's limited by
the consensus MAX_STACK_SIZE. This requires tracking the maximum stack
size at all times during script execution, which will be tackled in
its own commit.
In order to avoid any Miniscript that would not be spendable by a
standard transaction because of the size of the witness, we limit the
script size under Tapscript to the maximum standard transaction size
minus the maximum possible witness and Taproot control block sizes. Note
this is a conservative limit but it still allows for scripts more than a
hundred times larger than under P2WSH.
|
|
|
|
|
|
In Tapscript MINIMALIF is a consensus rule, so we can rely on the fact
that the `DUP IF [X] ENDIF` will always put an exact 1 on the stack upon
satisfaction.
|
|
It is the equivalent of multi() but for Tapscript, using CHECKSIGADD
instead of CHECKMULTISIG.
It shares the same properties as multi() but for 'n', since a threshold
multi_a() may have an empty vector as the top element of its
satisfaction. It could also have the 'o' property when it only has a
single key, but in this case a 'pk()' is always preferable anyways.
|
|
CHECKMULTISIG is disabled for Tapscript. Instead, we'll introduce
a multi_a() fragment with the same semantic as multi().
|
|
Some checks will be different depending on the script context (for
instance the maximum script size).
|
|
We are going to introduce Tapscript support in Miniscript, for which
some of Miniscript rules and properties change (new or modified
fragments, different typing rules, different resources consumption, ..).
|
|
It's true that for any public key there'll be a signature check in a
valid Miniscript. The code would previously, when computing the size of
a satisfaction, account for the signature when it sees a public key
push. Instead, account for it when it is required (ie when encountering
the `c:` wrapper). This has two benefits:
- Allows to accurately compute the net effect of a fragment on the stack
size. This is necessary to track the size of the stack during the
execution of a Script.
- It also just makes more sense, making the code more accessible to
future contributors.
|
|
This was calling the wrong constructor.
|
|
b442580ed2a6173f0cfb86f265887d783dde3ff8 gui: remove legacy wallet creation (furszy)
Pull request description:
Fixes #763
Preventing users from creating a legacy wallet prior to its deprecation in the upcoming releases.
Note:
This is still available using the `createwallet` RPC command.
Future Note:
Would be nice to re-write this modal as a wizard. And improve the design.
<details><summary> Pre-Changes Screenshot </summary>
<img width="611" alt="Screenshot 2023-10-06 at 11 30 14" src="https://github.com/bitcoin-core/gui/assets/5377650/ca10c97d-46e8-4aed-82da-068f2afbe25c">
</details>
<details><summary> Post-Changes Screenshot </summary>
<img width="729" alt="Screenshot 2023-10-06 at 11 32 58" src="https://github.com/bitcoin-core/gui/assets/5377650/f6bdcb57-646a-43d8-86a7-476e3cca683f">
</details>
ACKs for top commit:
achow101:
ACK b442580ed2a6173f0cfb86f265887d783dde3ff8
hebasto:
re-ACK b442580ed2a6173f0cfb86f265887d783dde3ff8
pablomartin4btc:
tACK b442580ed2a6173f0cfb86f265887d783dde3ff8
Tree-SHA512: f5d26ffbb0962648b9edf273b325e89425a318e136df26a26acb21b88730fd7d6499c68a705680539dc1b40862fbf413a1e0c8572436a0cfc665e2d08a3cf97d
|
|
5d227a68627614efa8618d360efee22a47afa88b rpc: Use Ensure(Any)Chainman in assumeutxo related RPCs (Fabian Jahr)
710e5db61bf7b303fa425f8dcbdce536281fa7f3 doc: Drop references to assumevalid in assumeutxo docs (Fabian Jahr)
1ff1c34656d49d60a93066a886dc1bfad9baccf4 test: Rename wait_until_helper to wait_until_helper_internal (Fabian Jahr)
a482f86779a6182d87004b463c0eaf21038181c3 chain: Rename HaveTxsDownloaded to HaveNumChainTxs (Fabian Jahr)
82e48d20f1243fb7733e872a29661b151ab5d523 blockstorage: Let FlushChainstateBlockFile return true in case of missing cursor (Fabian Jahr)
73700fb554d6abad705d8f48aed4840fedb36c79 validation, test: Improve and document nChainTx check for testability (Fabian Jahr)
2c9354facb27a6c394bb0c64f85fc4e3a33f4aed doc: Add snapshot chainstate removal warning to reindexing documentation (Fabian Jahr)
4e915e926bccbc9bdd61933ce44e87f2b4173b30 test: Improvements of feature_assumeutxo (Fabian Jahr)
a47fbe7d49e8921214ac159c558ff4ca19f98dce doc: Add and edit some comments around assumeutxo (Fabian Jahr)
0a39b8cbd88e9a496823b36feed77d137ccd894c validation: remove unused mempool param in DetectSnapshotChainstate (Fabian Jahr)
Pull request description:
Addressing what I consider to be non- or not-too-controversial comments from #27596.
Let me know if I missed anything among the many comments that can be easily included here.
ACKs for top commit:
ryanofsky:
Code review ACK 5d227a68627614efa8618d360efee22a47afa88b. Just suggested doc change and new EnsureChainman RPC cleanup commit since last review.
Tree-SHA512: 6f7c762100e18f82946b881676db23e67da7dc3a8bf04e4999a183e90b4f150a0b1202bcb95920ba937a358867bbf2eca300bd84b9b1776c7c490410e707c267
|
|
|
|
|
|
|
|
Co-authored-by: MarcoFalke <falke.marco@gmail.com>
|
|
Co-authored-by: MarcoFalke <falke.marco@gmail.com>
|
|
Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
|
|
Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
|
|
|
|
- Remove usage of the internal wait_until_helper function
- Use framework self.no_op instead of new no_sync function
co-authored-by: Andrew Chow <github@achow101.com>
|
|
Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
|
|
|
|
output
0f83ab407ec5aa0591c54c03bcf408c7f2f0a192 test: display abrupt shutdown errors in console output (furszy)
Pull request description:
Making it easier to debug errors in the CI environment,
particularly in scenarios where it's not immediately clear
what happened nor which node crashed (or shutdown abruptly).
A bit of context:
Currently, the test framework redirects each node's stderr output
stream to a different temporary file inside each node's data directory.
While this is sufficient for storing the error, it isn't very helpful for
understanding what happened just by reading the CI console output.
Most of the time, reading the stderr file in the CI environment is not
possible, because people don't have access to it.
Testing Note:
The displayed error difference can be observed by cherry-picking this
commit https://github.com/furszy/bitcoin-core/commit/9cc5393c0f24c774b4a59706fc7c7873a59573e7 on top of this branch and running any
functional test.
ACKs for top commit:
maflcko:
lgtm ACK 0f83ab407ec5aa0591c54c03bcf408c7f2f0a192
theStack:
ACK 0f83ab407ec5aa0591c54c03bcf408c7f2f0a192
Tree-SHA512: 83ce4d21d5316e8cb16a17d3fbe77b8649fced9e09410861d9674c233f6e9c34bcf573504e387e4f439c2841b2ee9855d0d35607fa13aa89eafe0080c45ee82d
|
|
f0cebbdb2a1a3c2f0facd88963484ad6fd5851db qt: enable -ltcg for windows HOST (fanquake)
Pull request description:
Patch around multiple definition issues in Qt, and enable `-ltcg` when using `LTO=1`.
Split from #25391.
ACKs for top commit:
hebasto:
ACK f0cebbdb2a1a3c2f0facd88963484ad6fd5851db
Tree-SHA512: 2d6e34779f360bf6dfea4f70fc9004a16e95da79716fcb3046afbf2b01317b7e16965cb51b967b7b5fb64549306c5f48cf59082884289c52016bc1e86949e062
|
|
of regtest
5b878be742dbfcd232d949d2df1fff4743aec3d8 [doc] add release note for submitpackage (glozow)
7a9bb2a2a59ba49f80519c8435229abec2432486 [rpc] allow submitpackage to be called outside of regtest (glozow)
5b9087a9a7da2602485e85e0b163dc3cbd2daf31 [rpc] require package to be a tree in submitpackage (glozow)
e32ba1599c599e75b1da3393f71f633de860505f [txpackages] IsChildWithParentsTree() (glozow)
b4f28cc345ef9c5261c4a8d743654a44784c7802 [doc] parent pay for child in aggregate CheckFeeRate (glozow)
Pull request description:
Permit (restricted topology) submitpackage RPC outside of regtest. Suggested in https://github.com/bitcoin/bitcoin/pull/26933#issuecomment-1510851570
This RPC should be safe but still experimental - interface may change, not all features (e.g. package RBF) are implemented, etc. If a miner wants to expose this to people, they can effectively use "package relay" before the p2p changes are implemented. However, please note **this is not package relay**; transactions submitted this way will not relay to other nodes if the feerates are below their mempool min fee. Users should put this behind some kind of rate limit or permissions.
ACKs for top commit:
instagibbs:
ACK 5b878be742dbfcd232d949d2df1fff4743aec3d8
achow101:
ACK 5b878be742dbfcd232d949d2df1fff4743aec3d8
dergoegge:
Code review ACK 5b878be742dbfcd232d949d2df1fff4743aec3d8
ajtowns:
ACK 5b878be742dbfcd232d949d2df1fff4743aec3d8
ariard:
Code Review ACK 5b878be742. Though didn’t manually test the PR.
Tree-SHA512: 610365c0b2ffcccd55dedd1151879c82de1027e3319712bcb11d54f2467afaae4d05dca5f4b25f03354c80845fef538d3938b958174dda8b14c10670537a6524
|
|
-deprecatedrpc=create_bdb
fa071aeb61dcc42cd122d3fb1abe4b9c238f8010 wallet: No BDB creation, unless -deprecatedrpc=create_bdb (MarcoFalke)
Pull request description:
With BDB being removed soon, it seems confusing and harmful to allow users to create fresh BDB wallets going forward, as it would load them with an additional burden of having to migrate them soon after.
Also, it would be good to allow for one release for test (and external) scripts to adapt.
Fix all issues by introducing the `-deprecatedrpc=create_bdb` setting.
ACKs for top commit:
Sjors:
tACK fa071aeb61dcc42cd122d3fb1abe4b9c238f8010
achow101:
ACK fa071aeb61dcc42cd122d3fb1abe4b9c238f8010
furszy:
utACK fa071aeb
Tree-SHA512: 37a4c3e4ba659e0ebe2382e71d9c80e42a895d9ad743f5dda7c110fbbb7d2a36f46769982552a9ac0c3a57203379ef164be97aa8033eb7674d6b4da030ba8f9b
|
|
a list of chainstates
a9ef702a877a964bac724a56e2c0b5bee4ea7586 assumeutxo: change getchainstates RPC to return a list of chainstates (Ryan Ofsky)
Pull request description:
Current `getchainstates` RPC returns "normal" and "snapshot" fields which are not ideal because it requires new "normal" and "snapshot" terms to be defined, and the definitions are not really consistent with internal code. (In the RPC interface, the "snapshot" chainstate becomes the "normal" chainstate after it is validated, while in internal code there is no "normal chainstate" and the "snapshot chainstate" is still called that temporarily after it is validated).
The current `getchainstates` RPC is also awkward to use if you to want information about the most-work chainstate, because you have to look at the "snapshot" field if it exists, and otherwise fall back to the "normal" field.
Fix these issues by having `getchainstates` just return a flat list of chainstates ordered by work, and adding a new chainstate "validated" field alongside the existing "snapshot_blockhash" field so it is explicit if a chainstate was originally loaded from a snapshot, and whether the snapshot has been validated.
This change was motivated by comment thread in https://github.com/bitcoin/bitcoin/pull/28562#discussion_r1344154808
ACKs for top commit:
Sjors:
re-ACK a9ef702a877a964bac724a56e2c0b5bee4ea7586
jamesob:
re-ACK a9ef702
achow101:
ACK a9ef702a877a964bac724a56e2c0b5bee4ea7586
Tree-SHA512: b364e2e96675fb7beaaee60c4dff4b69e6bc2d8a30dea1ba094265633d1cddf9dbf1c5ce20c07d6e23222cf1e92a195acf6227e4901f3962e81a1e53a43490aa
|
|
c1e6c542af6d89a499e2a65465865aec651c4d67 descriptors: disallow hybrid public keys (Pieter Wuille)
Pull request description:
Fixes #28511
The descriptor documentation (`doc/descriptors.md`) and [BIP380](https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki) explicitly require that hex-encoded public keys start with 02 or 03 (compressed) or 04 (uncompressed). However, the current parsing/inference code permit 06 and 07 (hybrid) encoding as well. Fix this.
ACKs for top commit:
darosior:
ACK c1e6c542af6d89a499e2a65465865aec651c4d67
achow101:
ACK c1e6c542af6d89a499e2a65465865aec651c4d67
Tree-SHA512: 23b674fb420619b2536d12da10008bb87cf7bc0333ec59e618c0d02c3574b468cc71248475ece37f76658d743ef51e68566948e903bca79fda5f7d75416fea4d
|
|
wallet_backwards_compatibility.py for 25.0 and descriptor wallets
afd9a673c458e97305da49a70a1ddbf60e651876 test: roundtrip wallet backwards compat downgrade (Andrew Chow)
bbf43c63b9472a79462e625a1f0592973c22b47c test: Add 25.0 to wallet backwards compatibiilty test (Andrew Chow)
538939ec39e146bedffb80cf84849a450ea8fead test: Run upgrade test on all nodes (Andrew Chow)
6d4699028b17cb33953f7d11764e06069dd58915 test: Run downgrade test on descriptor wallets (Andrew Chow)
f158573be12746991b75587cc9e41a74a5e986eb test: Add 0.21 tr() incompatibility test (Andrew Chow)
f41215c3f08f99d1bfa524f2da8055b6a4458bbb test: add logging 0.17 incompatibilities in wallet back compat (Andrew Chow)
71c03aeff7e1c63c21fa72d119311230f0b30e73 test: Refactor v19 addmultisigaddress test to be distinct (Andrew Chow)
53f35d02cb7b67ddecc9514559083f85093b6ce5 test: Remove w1_v18 from wallet backwards compatibility (Andrew Chow)
313d665437079ce8426916a41a11972e97c73d6d test: Fix 0.16 wallet paths and downgrade test (Andrew Chow)
5d8469362acfb7a03e0f767dbb7166830355bead test: Add helper functions for checking node versions (Andrew Chow)
Pull request description:
It was somewhat surprising to me that wallet_backwards_compatibility.py did not catch #27915 since the purpose of the test is to find downgrade issues such as that. It turns out the test was deficient in several places when it came to testing descriptor wallets, as well as deficient in addition to failing to correctly test some releases.
This PR fixes these test cases, adds more informative logging, slightly refactors the entire test in order to better test future versions, and adds a 25.0 node to the test.
Notable changes:
* The compatibility test with 0.16 should not have been passing. The wallets were being copied incorrectly for 0.16 and resulting in 0.16 creating new wallets rather than testing the target wallets.
* The downgrade test will actually be run on descriptor wallets and it will test that downgrades are successful, and a subsequent upgrade is also successful. This catches #27915.
* The upgrade and downgrade test will be run on all versions up to master, rather than just 0.16, 0.17, and 0.19.
ACKs for top commit:
Sjors:
re-ACK afd9a673c458e97305da49a70a1ddbf60e651876
furszy:
ACK afd9a67
Tree-SHA512: dd2d85cab29a636da93020681c533534af4a9cda18d8550c9db9d8937719b3a225025966981c5d4d2f30486448a772b760f0e723a25ea6bc49df80387dc7b8b0
|
|
intermittent issues
fa28f5a3819a4bb69b046529e05932016273170b test: Bump walletpassphrase timeouts to avoid intermittent issues (MarcoFalke)
Pull request description:
This bumps all timeouts for all `walletpassphrase` to avoid intermittent issues in `valgrind` (or other sanitizers).
As an idea for a follow-up, `walletpassphrase` could be changed to treat `0` as "no timeout" instead of "instant timeout".
Example failure:
```
node0 2023-09-03T22:44:38.374955Z [httpworker.3] [rpc/server.cpp:594] [RPCRunLater] [rpc] queue run of timer lockwallet(w6) in 60 seconds (using HTTP)
test 2023-09-03T22:44:40.173000Z TestFramework.bitcoincli (DEBUG): Running bitcoin-cli ['-rpcwallet=w6', 'getnewaddress', '', 'legacy']
node0 2023-09-03T22:44:59.810893Z [http] [httpserver.cpp:255] [http_request_cb] [http] Received a POST request for /wallet/w6 from 127.0.0.1:48928
node0 2023-09-03T22:44:59.813132Z [httpworker.1] [rpc/request.cpp:181] [parse] [rpc] ThreadRPCServer method=getnewaddress user=__cookie__
node0 2023-09-03T22:44:59.837183Z [httpworker.1] [wallet/sqlite.cpp:53] [TraceSqlCallback] [/ci_container_base/ci/scratch/test_runner/test_runner_₿_🏃_20230903_183350/wallet_createwallet_171/node0/regtest/w6/wallet.dat] SQLite Statement: INSERT or REPLACE into main values(?, ?)
node0 2023-09-03T22:44:59.929735Z [httpworker.1] [wallet/sqlite.cpp:53] [TraceSqlCallback] [/ci_container_base/ci/scratch/test_runner/test_runner_₿_🏃_20230903_183350/wallet_createwallet_171/node0/regtest/w6/wallet.dat] SQLite Statement: INSERT or REPLACE into main values(?, ?)
node0 2023-09-03T22:44:59.934484Z [httpworker.1] [wallet/sqlite.cpp:53] [TraceSqlCallback] [/ci_container_base/ci/scratch/test_runner/test_runner_₿_🏃_20230903_183350/wallet_createwallet_171/node0/regtest/w6/wallet.dat] SQLite Statement: INSERT or REPLACE into main values(?, ?)
node0 2023-09-03T22:44:59.935467Z [httpworker.1] [wallet/sqlite.cpp:53] [TraceSqlCallback] [/ci_container_base/ci/scratch/test_runner/test_runner_₿_🏃_20230903_183350/wallet_createwallet_171/node0/regtest/w6/wallet.dat] SQLite Statement: INSERT or REPLACE into main values(?, ?)
test 2023-09-03T22:45:02.328000Z TestFramework.bitcoincli (DEBUG): Running bitcoin-cli ['-rpcwallet=w6', 'signmessage', 'mqatqH4VQmrZ81nxUfrnfcLnxgbzhZb4PC', 'test']
node0 2023-09-03T22:45:20.269375Z [http] [httpserver.cpp:255] [http_request_cb] [http] Received a POST request for /wallet/w6 from 127.0.0.1:44618
node0 2023-09-03T22:45:20.270670Z [httpworker.2] [rpc/request.cpp:181] [parse] [rpc] ThreadRPCServer method=signmessage user=__cookie__
test 2023-09-03T22:45:23.490000Z TestFramework.bitcoincli (DEBUG): Running bitcoin-cli ['-rpcwallet=w6', 'keypoolrefill', '1']
node0 2023-09-03T22:45:40.244603Z [http] [httpserver.cpp:255] [http_request_cb] [http] Received a POST request for /wallet/w6 from 127.0.0.1:32854
node0 2023-09-03T22:45:40.293021Z [httpworker.0] [rpc/request.cpp:181] [parse] [rpc] ThreadRPCServer method=keypoolrefill user=__cookie__
test 2023-09-03T22:45:41.852000Z TestFramework (ERROR): JSONRPC error
Traceback (most recent call last):
File "/ci_container_base/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/test/functional/test_framework/test_framework.py", line 131, in main
self.run_test()
File "/ci_container_base/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/test/functional/wallet_createwallet.py", line 156, in run_test
w6.keypoolrefill(1)
File "/ci_container_base/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/test/functional/test_framework/test_node.py", line 732, in __call__
return self.cli.send_cli(self.command, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/ci_container_base/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/test/functional/test_framework/test_node.py", line 795, in send_cli
raise JSONRPCException(dict(code=int(code), message=message))
test_framework.authproxy.JSONRPCException: Error: Please enter the wallet passphrase with walletpassphrase first. (-13)
ACKs for top commit:
achow101:
ACK fa28f5a3819a4bb69b046529e05932016273170b
Tree-SHA512: 58caa569cec39acc121d4cc038a4190937af34e85d2696272ed4f2792fd386469b0cfefd2cb564438fedded97b21b23d8bf46ba27b5633671a277ed4679f0d5d
|
|
|
|
Current getchainstates RPC returns "normal" and "snapshot" fields which are not
ideal because it requires new "normal" and "snapshot" terms to be defined, and
the definitions are not really consistent with internal code. (In the RPC
interface, the "snapshot" chainstate becomes the "normal" chainstate after it
is validated, while in internal code there is no "normal chainstate" and the
"snapshot chainstate" is still called that temporarily after it is validated).
The current getchainstatees RPC is also awkward to use if you to want
information about the most-work chainstate because you have to look at the
"snapshot" field if it exists, and otherwise fall back to the "normal" field.
Fix these issues by having getchainstates just return a flat list of
chainstates ordered by work, and adding new chainstate "validated" field
alongside the existing "snapshot_blockhash" so it is explicit if a chainstate
was originally loaded from a snapshot, and whether the snapshot has been
validated.
|
|
4cafe9f176e93ebb6c38abb12140e8d8be005cbf [test] Make PeerManager's rng deterministic in tests (dergoegge)
fecec3e1c661ba273470ecc5ef12d4c070b53050 [net processing] FeeFilterRounder doesn't own a FastRandomContext (dergoegge)
47520ed209d9341702a0fb6006bee6f63f7da42e [net processing] Make fee filter rounder non-global (dergoegge)
77506f4ac6b3a3d7396a3a6101345019e05b3b10 [net processing] Addr shuffle uses PeerManager's rng (dergoegge)
a648dd79e5ebfdb627d0221b1207862efb664dfc [net processing] PushAddress uses PeerManager's rng (dergoegge)
87c706713e5d1c78bad943a42bf7c69047d28ea5 [net processing] PeerManager holds a FastRandomContext (dergoegge)
Pull request description:
This lets us avoid some non-determinism in tests (also see #28537).
ACKs for top commit:
MarcoFalke:
re-ACK 4cafe9f176e93ebb6c38abb12140e8d8be005cbf 🕗
glozow:
concept && light code review ACK 4cafe9f176e93ebb6c38abb12140e8d8be005cbf
Tree-SHA512: 3c18700773d0bc547ccb6442c41567e6f26b0b50fab5b79620da417ec91b9c0ae1395d15258da3aa4a91447b8ce560145dd135e39fbbd0610749e528e665b111
|
|
Making it easier to debug errors in the CI environment,
particularly in scenarios where it's not immediately clear
what happened nor which node crashed (or shutdown abruptly).
|
|
/ wrong network magic detection
e1308967e1a7e0ab275ab4c6f2f94c4ca0ee517b test: BIP324: add checks for v1 prefix matching / wrong network magic detection (Sebastian Falbesoner)
Pull request description:
This PR adds missing test coverage for the detection of incoming v1 connections and wrong network magic on BIP324-enabled (i.e. running with `-v2transport=1`) nodes. Both checks are using prefix sizes of 16 bytes (previously only 12 bytes were used for the v1 prefix matching, which was fixed by PR #28577).
ACKs for top commit:
Sjors:
utACK e1308967e1a7e0ab275ab4c6f2f94c4ca0ee517b
MarcoFalke:
lgtm ACK e1308967e1a7e0ab275ab4c6f2f94c4ca0ee517b
Tree-SHA512: d4d1567277297f42c543b9638a6c64d14b17ff0ddbf85a7efff22f45c619478139dbedcb9dc4f449b4814b00856ee43644f15df1aa20c8931d5496a607ca2fd4
|
|
|
