a51d7abf1e13c532c7acf437c3a65a9511b44987 guix: Specify symbols in modules explicitly (Hennadii Stepanov)
47d51fb048f892db843e765beb4ff03f982ff0b5 guix: Drop unneeded modules (Hennadii Stepanov)
57fdedd0e9269888c9a3c0ec76521dc66924299c guix: Unify fetch methods (Hennadii Stepanov)
Pull request description:
This PR cleans up the `contrib/guix/manifest.scm` in the following way:
- Unneeded for a successful build modules have be dropped.
- Some modules have been enhanced with `#:select` clauses, which improves maintainability (see the commit message for details).
ACKs for top commit:
TheCharlatan:
ACK a51d7abf1e13c532c7acf437c3a65a9511b44987
Tree-SHA512: 380a36d03ec303ff8700893cfaad75ca09d84a77fd08d6c6a1679ac96409014b36f0698eb071e09af25ad36f1bc62aec0eec1092146d879251c6a8cce586169b
8d9b90a61e3a2a451abfce25328d13aa1e8f749b Remove now-unnecessary poll, fcntl includes from net(base).cpp (Ben Woosley)
Pull request description:
As far as I can tell, the code calling for these includes was removed in:
6e68ccbefea6509c61fc4405a391a517c6057bb0 #24356
82d360b5a88d9057b6c09b61cd69e426c7a2412d #21387
ACKs for top commit:
fanquake:
ACK 8d9b90a61e3a2a451abfce25328d13aa1e8f749b
Tree-SHA512: e536d60f4cf204a10a5b461eca20c8329aa6b0fd3b27651ac9490ed42d3e22e31d652cd991ddc84c96e4758df15aefa7e7f84c710f2feb6d2e0fcfbda9ad4356
aaaa3aefbdfca1c9243057eeefdc19940e60bf18 test: Use TestNode *_path properties where possible (MarcoFalke)
dddd89962b26b5593860d016586ee8feb5aeea24 test: Allow pathlib.Path as RPC argument via authproxy (MarcoFalke)
fa41614a0abc05cbfbf76d6af3a186ab8d79c3f2 scripted-diff: Use wallets_path and chain_path where possible (MarcoFalke)
fa493fadfb0ac73b7c0ee308f6623213702ae6f4 test: Use wallet_dir lambda in wallet_multiwallet test where possible (MarcoFalke)
Pull request description:
It seems inconsistent, fragile and verbose to:
* Call `get_datadir_path` to recreate the path that already exists as field in TestNode
* Call `os.path.join` with the hardcoded chain name or `self.chain` to recreate the TestNode `chain_path` property
* Sometimes even use the hardcoded node dir name (`"node0"`)
Fix all issues by using the TestNode properties.
ACKs for top commit:
willcl-ark:
re-ACK aaaa3aefbdfca1c9243057eeefdc19940e60bf18
theStack:
Code-review ACK aaaa3aefbdfca1c9243057eeefdc19940e60bf18 🌊
Tree-SHA512: e4720278085beb8164e1fe6c1aa18f601558a9263494ce69a83764c1487007de63ebb51d1b1151862dc4d5b49ded6162a5c1553cd30ea1c28627d447db4d8e72
As far as I can tell, the code calling for these includes was removed in:
6e68ccbefea6509c61fc4405a391a517c6057bb0 #24356
82d360b5a88d9057b6c09b61cd69e426c7a2412d #21387
d4fb58ae8ae9772d025ead184ef8f2c0ea50df3e test: EC: optimize scalar multiplication of G by using lookup table (Sebastian Falbesoner)
1830dd8820fb90bac9aea32000e47d7eb1a99e1b test: add secp256k1 module with FE (field element) and GE (group element) classes (Pieter Wuille)
Pull request description:
This PR rewrites a portion of `test_framework/key.py`, in a compatible way, by introducing classes that encapsulate field element and group element logic, in an attempt to be more readable and reusable.
To maximize readability, the group element logic does not use Jacobian coordinates. Instead, group elements just store (affine) X and Y coordinates directly. To compensate for the performance loss this causes, field elements are represented as fractions. This undoes most, but not all, of the performance loss, and there is a few % slowdown (as measured in `feature_taproot.py`, which heavily uses this).
The upside is that the implementation for group laws (point doubling, addition, subtraction, ...) is very close to the mathematical description of elliptic curves, and this extends to potential future extensions (e.g. ElligatorSwift as needed by #27479).
ACKs for top commit:
achow101:
ACK d4fb58ae8ae9772d025ead184ef8f2c0ea50df3e
theStack:
re-ACK d4fb58ae8ae9772d025ead184ef8f2c0ea50df3e
stratospher:
tested ACK d4fb58a. really liked how this PR makes the secp256k1 code in the tests more intuitive and easier to follow!
Tree-SHA512: 9e0d65d7de0d4fb35ad19a1c19da7f41e5e1db33631df898c6d18ea227258a8ba80c893dab862b0fa9b0fb2efd0406ad4a72229ee26d7d8d733dee1d56947f18
fa38d862358b87219b12bf31236c52f28d9fc5d6 Use only Span{} constructor for byte-like types where possible (MarcoFalke)
fa257bc8312b91c2d281f48ca2500d9cba353cc5 util: Allow std::byte and char Span serialization (MarcoFalke)
Pull request description:
Seems odd to require developers to cast all byte-like spans passed to serialization to `unsigned char`-spans. Fix that by passing and accepting byte-like spans as-is. Finally, add tests and update the code to use just `Span` where possible.
ACKs for top commit:
sipa:
utACK fa38d862358b87219b12bf31236c52f28d9fc5d6
achow101:
ACK fa38d862358b87219b12bf31236c52f28d9fc5d6
ryanofsky:
Code review ACK fa38d862358b87219b12bf31236c52f28d9fc5d6. This looks great. The second commit really removes a lot of boilerplate and shows why the first commit is useful.
Tree-SHA512: 788592d9ff515c3ebe73d48f9ecbb8d239f5b985af86f09974e508cafb0ca6d73a959350295246b4dfb496149bc56330a0b5d659fc434ba6723dbaba0b7a49e5
248a17addf3cb519cb5e0fb91b9f25ce8d003d85 ci: remove duplicate python3 from CI configs (fanquake)
b50767fdde68d289f2bab0757d1e337277584405 ci: remove duplicate bsdmainutils from CI configs (fanquake)
Pull request description:
`bsdmainutils` and `python3` are included in `CI_BASE_PACKAGES`.
ACKs for top commit:
hebasto:
ACK 248a17addf3cb519cb5e0fb91b9f25ce8d003d85
Tree-SHA512: 1e5cddd8a37128690ef3110891549cb9a4c69c6bca558137c97031bc0e494e1053063923d3ccee8b1d9f05d3432765ee10f9ce872e88959b802ba64b6e2d300c
This change improves the maintainability of the manifest:
(1) It allows to remove the module when the specified symbols are no
longer used.
(2) It prevents accidental use of other symbols, such as `bash`
instead of `bash-minimal`.
79d343a642f985801da463b03a0627a59a095238 http: update libevent workaround to correct version (stickies-v)
Pull request description:
The libevent bug described in 5ff8eb2637 was already patched in [release-2.1.9-beta](https://github.com/libevent/libevent/releases/tag/release-2.1.9-beta), with cherry-picked commits [5b40744d1581447f5b4496ee8d4807383e468e7a](5b40744d15) and [b25813800f97179b2355a7b4b3557e6a7f568df2](b25813800f).
There should be no side-effects by re-applying the workaround on an already patched version of libevent (as is currently done in master for people running libevent between 2.1.9 and 2.1.12), but it is best to just set the correct version number to avoid confusion.
This will prevent situations like e.g. in https://github.com/bitcoin/bitcoin/pull/27909#discussion_r1238858604, where a reverse workaround was incorrectly applied to the wrong version range.
ACKs for top commit:
fanquake:
ACK 79d343a642f985801da463b03a0627a59a095238
Tree-SHA512: 56d2576411cf38e56d0976523fec951e032a48e35af293ed1ef3af820af940b26f779b9197baaed6d8b79bd1c7f7334646b9d73f80610d63cffbc955958ca8a0
529c92e837b28169b501562efe7b5b7120a2ebbb guix: Update `python-lief` package to 0.13.2 (Hennadii Stepanov)
Pull request description:
The Guix's `python-lief` package is going to move to using external deps, rather than the bundled ones (https://lists.gnu.org/archive/html/guix-patches/2023-05/msg01302.html). We want to continue using our own package indefinitely, to keep the build simpler, and allow for easier updating.
Changes in `contrib/devtools/security-check.py` are caused by 6357c6370b.
Also see: https://github.com/bitcoin/bitcoin/pull/27507.
ACKs for top commit:
fanquake:
ACK 529c92e837b28169b501562efe7b5b7120a2ebbb
Tree-SHA512: ad81111b090a39b380fe25bb27b54a339e78a158f462c7adda25d5ee55f0d654107b1486b29b9687ad0808e27b01e04f53a0e8ffc6600b79103d6bd0dfec64ef
3c83b1d884b419adece95b335b6e956e7459a7ef doc: Add release note for wallet loading changes (Andrew Chow)
2636844f5353797a0b8e40a879652a0d345172ad walletdb: Remove loading code where the database is iterated (Andrew Chow)
cd211b3b9965b5070d68adc1a03043d82d904d5b walletdb: refactor decryption key loading (Andrew Chow)
31c033e5ca3b65f4f5345d5aa17aafedd637ef4f walletdb: refactor defaultkey and wkey loading (Andrew Chow)
c978c6d39cdeb78fc4720767b943d03d6a9a36d8 walletdb: refactor active spkm loading (Andrew Chow)
6fabb7fc99e60584d5f3a2cb01d39f761769a25d walletdb: refactor tx loading (Andrew Chow)
abcc13dd24889bc1c6af7b10da1da96d86aeafed walletdb: refactor address book loading (Andrew Chow)
405b4d914712b5de3b230a0e2960e89f6a0a2b2a walletdb: Refactor descriptor wallet records loading (Andrew Chow)
30ab11c49793d5d55d66c4dedfa576ae8fd6129c walletdb: Refactor legacy wallet record loading into its own function (Andrew Chow)
9e077d9b422ac3c371fe0f63da40e5092171a25e salvage: Remove use of ReadKeyValue in salvage (Andrew Chow)
ad779e9ece9829677c1735d8865f14b23459da80 walletdb: Refactor hd chain loading to its own function (Andrew Chow)
72c2a54ebb99fa3d91d7d15bd8a38a8d16e0ea6c walletdb: Refactor encryption key loading to its own function (Andrew Chow)
3ccde4599b5150577400c4fa9029f4146617f751 walletdb: Refactor crypted key loading to its own function (Andrew Chow)
7be10adff36c0dc49ae56ac571bb033cba7a565b walletdb: Refactor key reading and loading to its own function (Andrew Chow)
52932c5adb29bb9ec5f0bcde9a31b74113a20651 walletdb: Refactor wallet flags loading (Andrew Chow)
01b35b55a119dc7ac915fc621ecebcd5c50ccb55 walletdb: Refactor minversion loading (Andrew Chow)
Pull request description:
Currently when we load a wallet, we just iterate through all of the records in the database and add them completely statelessly. However we have some records which do rely on other records being loaded before they are. To deal with this, we use `CWalletScanState` to hold things temporarily until all of the records have been read and then we load the stateful things.
However this can be slow, and with some future improvements, can cause some pretty drastic slowdowns to retain this pattern. So this PR changes the way we load records by choosing to load the records in a particular order. This lets us do things such as loading a descriptor record, then finding and loading that descriptor's cache and key records. In the future, this will also let us use `IsMine` when loading transactions as then `IsMine` will actually be working as we now always load keys and descriptors before transactions.
In order to get records of a specific type, this PR includes some refactors to how we do database cursors. Functionality is also added to retrieve a cursor that will give us records beginning with a specified prefix.
Lastly, one thing that iterating the entire database let us do was to find unknown records. However even if unknown records were found, we would not do anything with this information except output a number in a log line. With this PR, we would no longer be aware of any unknown records. This does not change functionality as we don't do anything with unknown records, and having unknown records is not an error. Now we would just not be aware that unknown records even exist.
ACKs for top commit:
MarcoFalke:
re-ACK 3c83b1d884b419adece95b335b6e956e7459a7ef 🍤
furszy:
reACK 3c83b1d8
ryanofsky:
Code review ACK 3c83b1d884b419adece95b335b6e956e7459a7ef. Just Marco's suggested error handling fixes since last review
Tree-SHA512: 15fa56332fb2ce4371db468a0c674ee7a3a8889c8cee9f428d06a7d1385d17a9bf54bcb0ba885c87736841fe6a5c934594bcf4476a473616510ee47862ef30b4
32e2ffc39374f61bb2435da507f285459985df9e Remove the syscall sandbox (fanquake)
Pull request description:
After initially being merged in #20487, it's no-longer clear that an internal syscall sandboxing mechanism is something that Bitcoin Core should have/maintain, especially when compared to better maintained/supported alterantives, i.e [firejail](https://github.com/netblue30/firejail).
There is more related discussion in #24771.
Note that given where it's used, the sandbox also gets dragged into the kernel.
If it's removed, this should not require any sort of deprecation, as this was only ever an opt-in, experimental feature.
Closes#24771.
ACKs for top commit:
davidgumberg:
crACK 32e2ffc393
achow101:
ACK 32e2ffc39374f61bb2435da507f285459985df9e
dergoegge:
ACK 32e2ffc39374f61bb2435da507f285459985df9e
Tree-SHA512: 8cf71c5623bb642cb515531d4a2545d806e503b9d57bfc15a996597632b06103d60d985fd7f843a3c1da6528bc38d0298d6b8bcf0be6f851795a8040d71faf16
Instead of iterating the database to load the wallet, we now load
particular kinds of records in an order that we want them to be loaded.
So it is no longer necessary to iterate the entire database to load the
wallet.
Instead of dealing with these records when iterating the entire
database, find and handle them explicitly.
Loading of OLD_KEY records is bumped up to a LOAD_FAIL error as we will
not be able to use these types of keys which can lead to users missing
funds.
Instead of loading active spkm records as we come across them when
iterating the database, load them explicitly.
Due to exception handling changes, deserialization errors are now
treated as critical.
Instead of loading address book records as we come across them when
iterating the database, load them explicitly
Due to exception handling changes, deserialization errors are now
treated as critical.
The error message for noncritical errors has also been updated to
reflect that there's more data that could be missing than just address
book entries and tx data.
Instead of loading descriptor wallet records as we come across them when
iterating the database, loading them explicitly.
Exception handling for these records changes to a per-record type basis,
rather than globally. This results in some records now failing with a
critical error rather than a non-critical one.
Instead of loading legacy wallet records as we come across them when
iterating the database, load them explicitly.
Exception handling for these records changes to a per-record type basis,
rather than globally. This results in some records now failing with a
critical error rather than a non-critical one.
On my machine, this speeds up the functional test feature_taproot.py by
a factor of >1.66x (runtime decrease from 1m16.587s to 45.334s).
Co-authored-by: Pieter Wuille <pieter@wuille.net>
5fc4939e17509534eb36727b27ac0afb941e44f7 Added static_assert to check that base_blob is using whole bytes. (Brotcrunsher)
Pull request description:
Prior to this commit it was possible to create base_blobs with any arbitrary amount of bits, like base_blob<9>. One could assume that this would be a valid way to create a bit field that guarantees to have at least 9 bits. However, in such a case, base_blob would not behave as expected because the WIDTH is rounded down to the closest whole byte (simple integer division by 8). This commit makes sure that this oddity is detected and blocked by the compiler.
ACKs for top commit:
MarcoFalke:
lgtm ACK 5fc4939e17509534eb36727b27ac0afb941e44f7
theStack:
ACK 5fc4939e17509534eb36727b27ac0afb941e44f7
stickies-v:
ACK 5fc4939e17509534eb36727b27ac0afb941e44f7
Tree-SHA512: 6a06760f09d4a9e6f0b9338d4dddd4091f2ac59a843a443d9302959936d72c55f7cccd55a51ec3a5a799921f68be1b87968ef3c9c11d3389cbd369b5045bb50a
3df60704661cdb5e61ea2b999f468f3a1d16105f contrib: remove macOS lazy_bind check (fanquake)
9bc357e205abc78524eae8906e6d231d6eb9f059 build: explicitly opt-in to new fixup_chains functionality for darwin (Cory Fields)
fb61bc0c022cc0fff290b94ee4f9cf9f4160efe2 depends: Bump MacOS minimum runtime requirement to 11.0 (Cory Fields)
c2cd47280cf5db5645917574dd95e9ec6036319e depends: bump darwin clang to 11.1 (Cory Fields)
Pull request description:
This (I believe) resolves the last of the blockers for [switching us away from cctools and instead using out-of-the-box llvm and lld](https://github.com/bitcoin/bitcoin/pull/21778) for building Darwin binaries.
For now, we continue building with a pre-packaged llvm and cctools, but after this PR the clang+lld combo should just work for anyone trying it. Additionally after this PR, the new runtime `fixup_chains` behavior will be in-use, as ld64 uses it as well.
The commits may seem unrelated, so in detail:
lld (llvm's linker) has been a work-in-progress for Darwin for years. Recently though, it has gained nearly all of the features we require. The last missing feature from ld64, `-Wl,-bind_at_load`, is not implemented in lld; as far as I can tell [lazy loading has conceptually been replaced by fixup chains](https://www.emergetools.com/blog/posts/iOS15LaunchTime).
So that means we don't need ld64's `bind_at_load` as long as lld can handle `-Wl,-fixup_chains` (which it can). I've added it to our configure as a linker option mostly so that we can see it in the logs; it's default-on as long as the minimum version is >11.0.
About that: the runtime functionality required for `-Wl,-fixup_chains` [requires macOS >=11.0](https://github.com/llvm/llvm-project/blob/release/16.x/lld/MachO/Driver.cpp#L1021). Hence the commit that bumps the minimum version. Our current min runtime of `10.15` has been unsupported since September 2022, so I don't expect this bump to be controversial.
Lastly, with the minimum runtime version bumped to 11.0, our current version of pre-compiled clang we use for macOS is too old to understand `-mmacosx-version-min=11.0` because it expects `=10.x`. So I've made the smallest possible bump (from 10.0.1 to 11.1.0) to a version that understands. This bump is arbitrary and unfortunate, but likely to be short-lived as we may end up replacing it with llvm+lld for v26 anyway. I've held off on bumping the SDK as I think that makes sense to do as part of the lld switch instead.
ACKs for top commit:
hebasto:
ACK 3df60704661cdb5e61ea2b999f468f3a1d16105f
gruve-p:
ACK 3df6070466
fanquake:
ACK 3df60704661cdb5e61ea2b999f468f3a1d16105f
TheCharlatan:
ACK 3df60704661cdb5e61ea2b999f468f3a1d16105f
Tree-SHA512: 0200ec4a3b88df33877ae82c15b5c04d745852550923f491a354b391cac65f88e4df116a40055c23a8cbcfcdfb9a376c6ae8fdd0e898e7b966bc213dcb5857cf
3168b08043546cd248a81563e21ff096019f1521 Bench test for EllSwift ECDH (Pieter Wuille)
42d759f239d1842ec0c662f8fa9ac0a9ff18a2cb Bench tests for CKey->EllSwift (dhruv)
2e5a8a437cf9ac78548891e61797b394571e27ae Fuzz test for Ellswift ECDH (dhruv)
c3ac9f5cf413e263803aac668a90a4ddd7316924 Fuzz test for CKey->EllSwift->CPubKey creation/decoding (dhruv)
aae432a764e4ceb7eac305458e585726225c7189 Unit test for ellswift creation/decoding roundtrip (dhruv)
eff72a0dff8fa83af873ad9b15dbac50b8d4eca3 Add ElligatorSwift key creation and ECDH logic (Pieter Wuille)
42239f839081bba9a426ebb9f1b7a56e35a2d428 Enable ellswift module in libsecp256k1 (dhruv)
901336eee751de088465e313dd8b500dfaf462b2 Squashed 'src/secp256k1/' changes from 4258c54f4e..705ce7ed8c (Pieter Wuille)
Pull request description:
This replaces #23432 and part of #23561.
This PR introduces all of the ElligatorSwift-related changes (libsecp256k1 updates, generation, decoding, ECDH, tests, fuzzing, benchmarks) needed for BIP324.
ElligatorSwift is a special 64-byte encoding format for public keys introduced in libsecp256k1 in https://github.com/bitcoin-core/secp256k1/pull/1129. It has the property that *every* 64-byte array is a valid encoding for some public key, and every key has approximately $2^{256}$ encodings. Furthermore, it is possible to efficiently generate a uniformly random encoding for a given public key or private key. This is used for the key exchange phase in BIP324, to achieve a byte stream that is entirely pseudorandom, even before the shared encryption key is established.
ACKs for top commit:
instagibbs:
reACK 3168b08043
achow101:
ACK 3168b08043546cd248a81563e21ff096019f1521
theStack:
re-ACK 3168b08043546cd248a81563e21ff096019f1521
Tree-SHA512: 308ac3d33e9a2deecb65826cbf0390480a38de201918429c35c796f3421cdf94c5501d027a043ae8f012cfaa0584656da1de6393bfba3532ab4c20f9533f06a6
11d650060aed25273d860baa4e03168a778832bb feerate: For GetFeePerK() return nSatoshisPerK instead of round trip through GetFee (Andrew Chow)
Pull request description:
Returning the sats/kvb does not need to round trip through GetFee(1000) since the feerate is already stored as sats/kvb.
Fixes#27913, although this does bring up a larger question of how we should handle such large feerates in fuzzing.
ACKs for top commit:
furszy:
Code ACK 11d65006
Tree-SHA512: bec1a0d4b572a0c810cf7eb4e97d729d67e96835c2d576a909f755b053a9707c2f1b3df9adb8f08a9c4d310cdbb8b1e1b42b9c004bd1ade02a07d8ce9e902138
54877253c807dac7a3720b2c3d1d989c410259a7 test: avoid sporadic MINIMALDATA failure in feature_taproot.py (fixes#27595) (Sebastian Falbesoner)
Pull request description:
The functional test feature_taproot.py fails in some rare cases on the execution of the following `"branched_codesep"` spending script (can be reproduced via `$ ./test/functional/feature_taproot.py --randomseed 9048710178866422833` on master / 137a98c5a22e058ed7a7997a0a4dbd75301de51e):
9d85c03620/test/functional/feature_taproot.py (L741)
The problem occurs if the first data-push (having random content with a random length in the range [0, 510]) has a length of 1 and the single byte has value of [1...16] or [-1]; in this case, the data-push is not minimally encoded by test framework's CScript class (i.e. doesn't use the special op-codes OP_1...OP_16 or OP_1NEGATE) and the script interpreter throws an SCRIPT_ERR_MINIMALDATA error:
```
test_framework.authproxy.JSONRPCException: non-mandatory-script-verify-flag (Data push larger than necessary) (-26)
```
Background: the functional test framework's CScript class translates passed bytes/bytearrays always to data pushes using OP_PUSHx/OP_PUSHDATA{1,2,4} op-codes (see `CScript.__coerce_instance(...)`). E.g. the expression `CScript(bytes([1]))` yields `bytes([OP_PUSH1, 1])` instead of the minimal-encoded `bytes([OP_1])`.
Fix this by adapting the random-size range to [2,...], i.e. never pass byte-arrays below length two to be pushed.
Closes#27595.
ACKs for top commit:
instagibbs:
ACK 54877253c8
sipa:
utACK 54877253c807dac7a3720b2c3d1d989c410259a7
achow101:
ACK 54877253c807dac7a3720b2c3d1d989c410259a7
Tree-SHA512: 3ffad89b2c3985c20702242192e744c9b10188bff880efaf3c38424a00fa07bd4608d8c948678ff9cdbb4e1e5b06696c7f55407ee10bb05edbb3ee03aa599cdc
77d6d89d43cc5969c98d9b4b56a1e877b473e731 net: net_processing, add `ProcessCompactBlockTxns` (brunoerg)
Pull request description:
When processing `CMPCTBLOCK` message, at some moments we can need to process compact block txns / `BLOCKTXN`, since all messages are handled by `ProcessMessage`, so we call `ProcessMessage` all over again.
ab98673f05/src/net_processing.cpp (L4331-L4348)
This PR creates a function called `ProcessCompactBlockTxns` to process it to avoid calling `ProcessMessage` for it - this function is also called when processing `BLOCKTXN` msg.
ACKs for top commit:
instagibbs:
reACK 77d6d89d43cc5969c98d9b4b56a1e877b473e731
ajtowns:
utACK 77d6d89d43cc5969c98d9b4b56a1e877b473e731
achow101:
ACK 77d6d89d43cc5969c98d9b4b56a1e877b473e731
Tree-SHA512: 4b73c189487b999a04a8f15608a2ac1966d0f5c6db3ae0782641e68b9e95cb0807bd065d124c1f316b25b04d522a765addcd7d82c541702695113d4e54db4fda
30778124b82791abdc6e930373460ef1dd587cb2 net: Give seednodes time before falling back to fixed seeds (Martin Zumsande)
Pull request description:
`-seednode` is an alternative bootstrap mechanism - when choosing it, we make a `AddrFetch` connection to the specified peer, gather addresses from them, and then disconnect. Presumably, if users specify a seednode they prefer addresses from that node over fixed seeds.
However, when disabling dns seeds and specifiying `-seednode`, `CConnman::ProcessAddrFetch()` immediately removes the entry from `m_addr_fetches` (before the seednode could give us addresses) - and once `m_addr_fetches` is empty, `ThreadOpenConnections` will add fixed seeds, resulting in a "race" between the fixed seeds and seednodes filling up AddrMan.
This PR suggests to check for any provided `-seednode` arg instead of using the size of `m_addr_fetches`, thus delaying the querying of fixed seeds for 1 minute when specifying any seednode (as we already do for `addnode` peers).
That way, we actually give the seednodes a chance for to provide us with addresses before falling back to fixed seeds.
This can be tested with `bitcoind -debug=net -dnsseed=0 -seednode=(...)` on a node without `peers.dat` and observing the debug log.
ACKs for top commit:
ajtowns:
utACK 30778124b82791abdc6e930373460ef1dd587cb2
achow101:
ACK 30778124b82791abdc6e930373460ef1dd587cb2
dergoegge:
Code review ACK 30778124b82791abdc6e930373460ef1dd587cb2
sr-gi:
ACK [3077812](30778124b8) with a tiny nit, feel free to ignore it
Tree-SHA512: 96446eb34c0805f10ee158a00a3001a07029e795ac40ad5638228d426e30e9bb836c64ac05d145f2f9ab23ec5a528f3a416e3d52ecfdfb0b813bd4b1ebab3c01
1771daa815ec014276cfcb30c934b0eaff4d72bf [fuzz] Show that SRD budgets for non-dust change (Murch)
941b8c6539d72890fd4e36fc900be9c300e1d737 [bug] Increase SRD target by change_fee (Murch)
Pull request description:
I discovered via fuzzing of another coin selection approach that at extremely high feerates SRD may find input sets that lead to transactions without change outputs. This is an unintended outcome since SRD is meant to always produce a transaction with a change output—we use other algorithms to specifically search for changeless solutions.
The issue occurs when the flat allowance of 50,000 ṩ for change is insufficient to pay for the creation of a change output with a non-dust amount, at and above 1,613 ṩ/vB. Increasing the change budget by `change_fee` makes SRD behave as expected at any feerates.
Note: The intermittent failures of `test/functional/interface_usdt_mempool.py` are a known issue: https://github.com/bitcoin/bitcoin/issues/27380
ACKs for top commit:
achow101:
ACK 1771daa815ec014276cfcb30c934b0eaff4d72bf
S3RK:
ACK 1771daa815ec014276cfcb30c934b0eaff4d72bf
Tree-SHA512: 3f36a3e317ef0a711d0e409069c05032bff1d45403023f3728bf73dfd55ddd9e0dc2a9969d4d69fe0a426807ebb0bed1f54abfc05581409bfe42c327acf766d4
0e21b56a44d53cec9080edb04410a692717f1ddc assumeutxo: catch and log fs::remove error instead of two exist checks (Andrew Toth)
Pull request description:
Fixes a block of code which seems to be incorrectly performing two existence checks instead of catching and logging errors. `fs::remove` returns `false` only if the file being removed does not exist, so it is redundant with the `fs::exists` check. If an error does occur when trying to remove an existing file, `fs::remove` will throw. See https://en.cppreference.com/w/cpp/filesystem/remove.
Also see https://github.com/bitcoin/bitcoin/blob/master/src/init.cpp#L326-L332 for a similar pattern.
ACKs for top commit:
MarcoFalke:
lgtm ACK 0e21b56a44d53cec9080edb04410a692717f1ddc
jamesob:
ACK 0e21b56a44
achow101:
ACK 0e21b56a44d53cec9080edb04410a692717f1ddc
Tree-SHA512: 137d0be5266cfd947e5e50ec93b895ac659adadf9413bef3468744bfdacee8dbe7d9bdfaf91784c45708610325d2241a114f4be4e622a108a639b3672b618fd2
