aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-05-14tests, fuzz: use new NUMS_H constjosibake
2024-05-14[log] updates in TxOrphanageglozow
- Add elapsed time in "remove orphan" log - Add size in "stored orphan" log - grammar edit
2024-05-14[functional test] attackers sending mutated orphansglozow
2024-05-14[unit test] TxOrphanage handling of same-txid-different-witness txnsglozow
2024-05-14[p2p] allow entries with the same txid in TxOrphanageglozow
Index by wtxid instead of txid to allow entries with the same txid but different witnesses in orphanage. This prevents an attacker from blocking a transaction from entering the orphanage by sending a mutated version of it.
2024-05-14[refactor] TxOrphanage::EraseTx by wtxidglozow
No behavior change right now, as transactions in the orphanage are unique by txid. This makes the next commit easier to review.
2024-05-14[refactor] TxOrphanage::HaveTx only by wtxidglozow
2024-05-14[p2p] don't query orphanage by txidglozow
2024-05-14kernel: Remove batchpriority from kernel libraryTheCharlatan
The current usage of ScheduleBatchPriority is not transparent. Once the thread scheduling is changed, it remains unchanged for the remainder of the thread's lifetime. So move the call from `ImportBlocks` to the init code where it is clearer that its effect lasts for the entire lifetime of the thread. Users of the kernel library might not expect `ImportBlocks` to have an influence on the thread it is called in. Particularly since it is only a compile time option and cannot be controlled at runtime. With this patch users of the kernel library can now choose their own scheduling policy.
2024-05-14crypto: add NUMS_H constjosibake
2024-05-14Merge bitcoin/bitcoin#30078: depends: set AR & RANLIB for CMakemerge-script
019ad7327c397094d7648b55503bf5373b108a57 depends: set RANLIB for CMake (fanquake) 43cfb428cba04b8db98d4d0d56ffe28ad686e58c depends: set NM for CMake (fanquake) 1e4412b317f74dd64069309544fe73c95e2c10e7 depends: set AR for CMake (fanquake) Pull request description: Needed for #21778. Should be more correct in any case. ACKs for top commit: theuni: utACK 019ad7327c397094d7648b55503bf5373b108a57. I didn't test, but I tried this approach on a few deps and it seemed to work as expected. TheCharlatan: ACK 019ad7327c397094d7648b55503bf5373b108a57 Tree-SHA512: 78cc8981456f7476cafca0e40fcc569e474b92004c8024d1c4268b6aab53175074a06ab17ebded8d706bf0a7f77401642dd38bb7ce2e4b04abdcd149d3d69969
2024-05-13wallet: implement BerkeleyRODatabase::BackupAva Chow
2024-05-13wallet: implement BerkeleyROBatchAva Chow
Implement ReadKey and HasKey of BerkeleyROBatch, and Next of BerkeleyROCursor. Also adds the containers for records to BerkeleyRODatabase so that BerkeleyROBatch will be able to access the records.
2024-05-13wallet: add dummy BerkeleyRODatabase and BerkeleyROBatch classesAva Chow
BerkeleyRODatabase and BerkeleyROBatch will be used to access a BDB file without the use of BDB. For now, these are dummy classes.
2024-05-13refactor: simplify `FormatSubVersion` using strprintf/JoinSebastian Falbesoner
Rather than using std::ostringstream and manually joining the comments, use strprintf and our own `Join` helper.
2024-05-13Merge bitcoin/bitcoin#28233: validation: don't clear cache on periodic ↵Ava Chow
flush: >2x block connection speed 4a6d1d1e3bc3d559cd13d134b4b827f22635ac4b validation: don't clear cache on periodic flush (Andrew Toth) Pull request description: Since https://github.com/bitcoin/bitcoin/pull/17487 we no longer need to clear the coins cache when syncing to disk. A warm coins cache significantly speeds up block connection, and only needs to be fully flushed when nearing the `dbcache` limit. Periodic flushes occur every 24 hours, which empties the cache and causes block connection to slow down. By keeping the cache through periodic flushes a node can run for several days with an increasingly hotter cache and connect blocks much more quickly. Now not only can setting a higher `dbcache` value be beneficial for IBD, it can also be beneficial for connecting blocks faster. To benchmark in real world usage, I spun up 6 identical `t2.small` AWS EC2 instances, all running in the same region in the same VPC. I configured 2 instances to run master, 2 instances to run the change in this PR, and 2 instances to run the change in this PR but with `dbcache=1000`. All instances had `prune=5000` and a 20 GB `gp2` `EBS` volume. A 7th EC2 instance in the same VPC ran master and connected only to some trusted nodes in the outside network. Each of the 6 nodes under test only connected directly to this 7th instance. I manually pruned as much as possible and uploaded the same `blocks`, `chainstate` and `mempool.dat` to all instances. I started all 6 peers simultaneously at block height `835245` and ran them for over a week until block `836534`. The results were much faster block connection times for this branch compared to master, and much faster for this branch with `dbcache=1000` compared to default `dbcache`. | branch |speed | |-----------:|----------:| | master 1 | 1995.49ms/blk | | master 2 | 2129.78ms/blk | | branch default dbcache 1 | 1189.65ms/blk | | branch default dbcache 2 | 1037.74ms/blk | | branch dbcache=1000 1 | 393.69ms/blk | | branch dbcache=1000 2 | 427.77ms/blk | The log files of all 6 instances are [here](https://gist.github.com/andrewtoth/03c95033e7581d5dbc5be028639a1a91). There is a lot of noise with the exact times of blocks being connected, so I plotted the rolling 20 block connect time averages. The large dots are the times where the cache is emptied. For the red master nodes, this happens every 24 hours. The blue branch nodes with default `dbcache` only filled up and emptied the caches once, which is seen in the middle. The green branch nodes with 1000 `dbcache` never emptied the cache. It is very clear from the chart that whenever the cache is emptied, connect block speed degrades significantly. ![plot](https://github.com/bitcoin/bitcoin/assets/237213/802cb28d-1ad4-47c3-a886-c5366b423eca) Also note that this still clears the cache for pruning flushes. Having frequent pruning flushes with a large cache that doesn't clear is less performant than the status quo https://github.com/bitcoin/bitcoin/pull/15265#issuecomment-458657451. See https://github.com/bitcoin/bitcoin/pull/28280. ACKs for top commit: sipa: utACK 4a6d1d1e3bc3d559cd13d134b4b827f22635ac4b achow101: ACK 4a6d1d1e3bc3d559cd13d134b4b827f22635ac4b brunoerg: crACK 4a6d1d1e3bc3d559cd13d134b4b827f22635ac4b Tree-SHA512: 05dbc677bc309bbcf89c52a6c5e853e2816b0ef0b5ee3719b30696df315a0427e244bb82da9ad828ec0e7ea8764552f8affe14c0184b52adf1909f5d8c1b4f9e
2024-05-13Merge bitcoin/bitcoin#30094: rpc: move UniValue in blockToJSONRyan Ofsky
b77bad309e92f176f340598eec056eb7bff86f5f rpc: move UniValue in blockToJSON (willcl-ark) Pull request description: Fixes: #24542 Fixes: #30052 Without explicitly declaring the move, these `UniValues` get copied, causing increased memory usage. Fix this by explicitly moving the `UniValue` objects. Used by `rest_block` and `getblock` RPC. ACKs for top commit: maflcko: review ACK b77bad309e92f176f340598eec056eb7bff86f5f ismaelsadeeq: ACK b77bad309e92f176f340598eec056eb7bff86f5f TheCharlatan: ACK b77bad309e92f176f340598eec056eb7bff86f5f theuni: utACK b77bad309e92f176f340598eec056eb7bff86f5f hebasto: ACK b77bad309e92f176f340598eec056eb7bff86f5f, I have reviewed the code and it looks OK. BrandonOdiwuor: ACK b77bad309e92f176f340598eec056eb7bff86f5f Tree-SHA512: 767608331040f9cfe5c3568ed0e3c338920633472a1a50d4bbb47d1dc69d2bb11466d611f050ac8ad1a894b47fe1ea4d968cf34cbd44d4bb8d479fc5c7475f6d
2024-05-13Merge bitcoin/bitcoin#29974: fuzz: txorphan tests fixupsglozow
58594c7040241f2312b0b8735a8baf0412674613 fuzz: txorphan tests fixups (Sergi Delgado Segura) Pull request description: Motivated by https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1576401327 Adds the following fixups in txorphan fuzz tests: - Don't bond the output count of the created orphans to the number of available coins - Allow duplicate inputs but don't store duplicate outpoints Most significantly, this gets rid of the `duplicate_input` flag altogether, making the test easier to reason about. Notice how, under normal conditions, duplicate inputs would be caught by `MemPoolAccept::PreChecks`, however, no validations checks are run on the test before adding data to the orphanage (neither were they before this patch) ## Rationale The way the test is currently written, duplicate inputs are allowed based on a random flag (`duplicate_input`). If the flag is unset, upon selecting an outpoint as input for a new transaction, the input is popped to prevent re-selection and later re-added to the collection (once all inputs have been picked). However, the re-addition to the collection is performed independently of whether the flag was set or not. This means that, if the flag is set, the selected inputs are duplicated which in turn makes these inputs more likely to be re-picked in the following iteration of the loop. Additionally, both the input and output count of the transaction are bonded to the number of available outpoints. This makes sense for the former, but the latter shouldn't be. ACKs for top commit: maflcko: utACK 58594c7040241f2312b0b8735a8baf0412674613 glozow: ACK 58594c7 instagibbs: ACK 58594c7040241f2312b0b8735a8baf0412674613 Tree-SHA512: e97cc2a43e388f87b64d2e4e45f929dd5b0dd85d668dd693b75e4c9ceea734cd7645952385d428208d07b70e1aafbec84cc2ec264a2e07d36fc8ba3e97885a8d
2024-05-13Merge bitcoin/bitcoin#29994: doc: removed help text saying that peers may ↵glozow
not connect automatically 95897ff181c0757e445f0e066a2a590a0a0120d2 doc: removed help text saying that peers may not connect automatically (kevkevin) Pull request description: Introduced in https://github.com/bitcoin/bitcoin/pull/23542 and released in version 23.0 there has been significant time since this change (2 years). This should be removed as it is no longer relevant ACKs for top commit: stickies-v: ACK 95897ff181c0757e445f0e066a2a590a0a0120d2 tdb3: ACK for 95897ff181c0757e445f0e066a2a590a0a0120d2. vasild: ACK 95897ff181c0757e445f0e066a2a590a0a0120d2 jonatack: ACK 95897ff181c0757e445f0e066a2a590a0a0120d2 kristapsk: ACK 95897ff181c0757e445f0e066a2a590a0a0120d2. According to https://bitnodes.io/dashboard/#user-agents stats, most nodes on the network are v23+. Tree-SHA512: 9e35194f8a1e06f1447450af2ea30cdc43722665c2d2e4b7aa9a52afac5c1e83fed744742c836743a555cc180c90f9eebdc6637eba6190010d693eef9c5834f7
2024-05-13rpc: move UniValue in blockToJSONwillcl-ark
Without explicitly declaring the move, these UniValues get copied, causing increased memory usage. Fix this by explicitly moving the UniValue objects. Used by `rest_block` and `getblock` RPC.
2024-05-13depends: set RANLIB for CMakefanquake
2024-05-13depends: set NM for CMakefanquake
2024-05-13depends: set AR for CMakefanquake
2024-05-12Merge bitcoin-core/gui#812: Fix create unsigned transaction fee bumpmerge-script
671b7a32516d62e1e79393ded4b45910bd08010a gui: fix create unsigned transaction fee bump (furszy) Pull request description: Fixes #810. Not much to explain; we were requiring the wallet to be unlocked for the unsigned transaction creation process. Fix this by moving the unlock wallet request to the signed transaction creation process. ACKs for top commit: pablomartin4btc: tACK 671b7a32516d62e1e79393ded4b45910bd08010a hebasto: ACK 671b7a32516d62e1e79393ded4b45910bd08010a, tested on Ubuntu 24.04. Tree-SHA512: 5b9ec5a1b91c014c05c83c63daaa8ba33f9dc1bfa930442315a0913db710df17a1b6bb4ad39f1419a7054f37ebedb7ad52e1c5d3d2fb444b1676162e89a4efd2
2024-05-12Merge bitcoin/bitcoin#29658: Bugfix: GUI: Help messages already have a ↵merge-script
trailing newline, so don't add an extra one d1ed09a7643b567e021b2ecb756bc925c48fc708 Bugfix: GUI: Help messages already have a trailing newline, so don't add an extra one (Luke Dashjr) Pull request description: Reviewing #29585, I noticed that `bitcoin-qt` adds an extra newline for `-help` and `-version` beyond the other binaries'. ACKs for top commit: hebasto: ACK d1ed09a7643b567e021b2ecb756bc925c48fc708, tested on Ubuntu 24.04. Tree-SHA512: 15ee9d1060c2492bb3b04a0ac4cb53f7b959bbe32bce415793da0c221f1c963c8f2bb3996ea07d1a7c192bfc2e23be2cd7d4e5649c592eb3fc03906c2763f1aa
2024-05-11Merge bitcoin-core/gui#813: Don't permit port in proxy IP optionmerge-script
10c5275ba4532fb1bf54057d2f61fc35b51f1e85 gui: don't permit port in proxy IP option (willcl-ark) Pull request description: Fixes: https://github.com/bitcoin-core/gui/issues/809 Previously it was possible through the GUI to enter an IP address:port into the "Proxy IP" configuration box. After the node was restarted the errant setting would prevent the node starting back up until manually removed from settings.json. Prevent this with a simple check for ":" in the string. This is acceptable here in the GUI setting because we already fail on a hostname such as "http://x.x.x.x", so it won't cause false positives. ACKs for top commit: furszy: utACK 10c5275ba45 hebasto: ACK 10c5275ba4532fb1bf54057d2f61fc35b51f1e85, tested on Ubuntu 24.04. Tree-SHA512: ed83590630cf693680a3221f701ecd18dd08710a17b726dc4978a3a6e330a34fb77d73a4f710c01bcb3faf88b6604ff37bcdbb191ce1623348ca5b92fd6fe9a7
2024-05-11Merge bitcoin-core/gui#788: debugwindow: update session ID tooltipmerge-script
3bf00e13609eefa6ddb11353519bb1aec2342513 gui: debugwindow: update session ID tooltip (Marnix) Pull request description: When you have a v2 connection, there is always a session ID. the _if any_ is a leftover from https://github.com/bitcoin-core/gui/pull/754, where the session ID property initially would always be displayed (transport v1 and v2). So the session ID could be empty when you have a v1 connection. As now the _Session ID_ property only is displayed for v2 connection, there will always be a session ID. master ![sessionIDifany](https://github.com/bitcoin-core/gui/assets/93143998/d4d7df43-8281-4b1e-83fc-5a3788d7724e) PR ![sessionID](https://github.com/bitcoin-core/gui/assets/93143998/221f6831-7d12-4913-be76-325a87baad2e) Session ID not shown when transport v1 ![transportv1](https://github.com/bitcoin-core/gui/assets/93143998/6c067a08-4be4-4ce1-b514-80654ca5cd43) <!-- *** Please remove the following help text before submitting: *** Pull requests without a rationale and clear improvement may be closed immediately. GUI-related pull requests should be opened against https://github.com/bitcoin-core/gui first. See CONTRIBUTING.md --> <!-- Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly: * Any test improvements or new tests that improve coverage are always welcome. * All other changes should have accompanying unit tests (see `src/test/`) or functional tests (see `test/`). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change. * Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed. * Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible. * Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they *significantly* improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the [developer notes](/doc/developer-notes.md), stylistic code changes are usually rejected. --> <!-- Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. --> ACKs for top commit: vostrnad: ACK 3bf00e13609eefa6ddb11353519bb1aec2342513 kristapsk: ACK 3bf00e13609eefa6ddb11353519bb1aec2342513 jarolrod: ACK 3bf00e13609eefa6ddb11353519bb1aec2342513 pablomartin4btc: tACK 3bf00e13609eefa6ddb11353519bb1aec2342513 hebasto: ACK 3bf00e13609eefa6ddb11353519bb1aec2342513. Tree-SHA512: 4de0c56c070dc5d1cee73b629bdf3d1778c6d90d512337aa6cfd3eed4ce95cbcfbe5713e2942f6fc22907b2c4d9df7979ba8e9f91f7cc173b42699ea35113f96
2024-05-11Merge bitcoin/bitcoin#30081: refactor: Remove unused code from ↵merge-script
`subprocess.h` header 5a11d3023f7d0cde777f3496c0f3aa381823d749 refactor, subprocess: Remove unused stream API calls (Hennadii Stepanov) 05b6f8793c6d5f17d1cb413e2884f1fb0f367ad8 refactor, subprocess: Remove unused `Popen::child_created_` data member (Hennadii Stepanov) 9e1ccf55e178144804e30cfe94757b6da2a6ca28 refactor, subprocess: Remove unused `Popen::poll()` (Hennadii Stepanov) 24b53fc84af301fff592e06723b980e29aa68289 refactor, subprocess: Remove `Popen::pid()` (Hennadii Stepanov) Pull request description: This PR continues https://github.com/bitcoin/bitcoin/pull/29961. Please note that `Popen::poll()` is not required for https://github.com/bitcoin/bitcoin/pull/29868 anymore. ACKs for top commit: theuni: Easy code review ACK 5a11d3023f7d0cde777f3496c0f3aa381823d749 since it's all removals :) theStack: Code-review ACK 5a11d3023f7d0cde777f3496c0f3aa381823d749 Tree-SHA512: 11f984f8384c337782d058afa80011e88087a1b5a3ed6e4678d492e6c232b706a26312463c5dd8c529aa477497c8afca9f54574e0e36e3edd5675bd5d8424bbb
2024-05-11Merge bitcoin/bitcoin#29739: build: swap cctools otool for llvm-objdumpmerge-script
7f5ac4520d1553170b1053a9ffcd58179386a6d2 build: swap otool for (llvm-)objdump (fanquake) Pull request description: This tool is used in GUI packaging on macOS, and also somewhat of a blocker for #21778. The main issue is that some distros don't really ship this tool in a standard ways, i.e Ubuntu only ships `llvm-otool` with a version suffix, i.e `llvm-otool-17`, which makes it hard to find and use. Rather than trying to deal with that mess, switch to using the equivalent LLVM tool (objdump), which is a drop-in replacement. ACKs for top commit: TheCharlatan: ACK 7f5ac4520d1553170b1053a9ffcd58179386a6d2 theuni: ACK 7f5ac4520d1553170b1053a9ffcd58179386a6d2. Tested `make deploy` on native macOS. Looks good. hebasto: ACK 7f5ac4520d1553170b1053a9ffcd58179386a6d2. Tree-SHA512: ac978043f14fb448010542a4a7ce8c6c74b4cbd90f83b4cb4d0bff55974010f10a70b5354f65b239a8bd961d7a3aca22ca165b42954ca87879b9e0524db5f879
2024-05-10test: add GetAddedNodeInfo() CJDNS regression unit testJon Atack
2024-05-10p2p, bugfix: detect addnode cjdns peers in GetAddedNodeInfo()Jon Atack
Addnode (manual) peers connected to us via the cjdns network are currently not detected by CConnman::GetAddedNodeInfo(), i.e. fConnected is always false. This causes the following issues: - RPC `getaddednodeinfo` incorrectly shows them as not connected - CConnman::ThreadOpenAddedConnections() continually retries to connect them
2024-05-10Merge bitcoin/bitcoin#29252: kernel: Remove key module from kernel libraryAva Chow
96378fe734e5fb6167eb20036d7170572a647edb Refactor: Remove ECC_Start and ECC_Stop from key header (TheCharlatan) 41eba5bd716bea47c8731d156d053afee92a7f12 kernel: Remove key module from kernel library (TheCharlatan) a08d2b3cb971c68e9a50b991b2953fa4541cf48a tools: Use ECC_Context helper in bitcoin-tx and bitcoin-wallet tools (Ryan Ofsky) 28905c1a64a87a56f16aea8a4d23dea7eec9ca59 test: Use ECC_Context helper in bench and fuzz tests (Ryan Ofsky) 538fedde1d9c96a2bbe06cacc0cd6903135fbc83 common: Add ECC_Context RAII wrapper for ECC_Start/ECC_Stop (Ryan Ofsky) Pull request description: The key module's functionality is not used by the kernel library, but currently kernel users are still required to initialize the key module's `secp256k1_context_sign` global as part of the `kernel::Context` through `ECC_Start`. So move the `ECC_Start` call to the `NodeContext` ctor instead to completely remove the key module from the kernel library. The gui tests currently keep multiple `NodeContext` objects in memory, so call `ECC_Stop` manually to avoid triggering an assertion on `ECC_Start`. --- This PR is part of the [libbitcoinkernel project](https://github.com/bitcoin/bitcoin/issues/27587). It removes a module from the kernel library. ACKs for top commit: achow101: ACK 96378fe734e5fb6167eb20036d7170572a647edb ryanofsky: Code review ACK 96378fe734e5fb6167eb20036d7170572a647edb. Just suggested comment changes since last review. theuni: utACK 96378fe734e5fb6167eb20036d7170572a647edb Tree-SHA512: 40be427e8e2c920c0e3ce64a9bdd90551be27a89af11440bfb6ab0dd3a1d1ccb7cf1f82383cd782818cd1bb44d5ae5d2161cf4d78d3127ce4987342007090bab
2024-05-10Merge bitcoin/bitcoin#29948: test: add missing comparison of node1's mempool ↵Ava Chow
in MempoolPackagesTest e912717ff63f111d8f1cd7ed1fcf054e28f36409 test: add missing comparison of node1's mempool in MempoolPackagesTest (umiumi) Pull request description: #29941 Recreated a pull request because there was a conflict. Trying to resolve the conflict but the old one automatically closed. Add missing comparison for TODO comments in `mempool_packages.py` Also, notice that the ancestor size limits and descendant size limits actually implemented in #21800 , so I removed the todo for those two size limits. ACKs for top commit: kevkevinpal: ACK [e912717](https://github.com/bitcoin/bitcoin/pull/29948/commits/e912717ff63f111d8f1cd7ed1fcf054e28f36409) achow101: ACK e912717ff63f111d8f1cd7ed1fcf054e28f36409 alfonsoromanz: Tested ACK e912717ff63f111d8f1cd7ed1fcf054e28f36409. The code looks good to me and the test execution is successful. rkrux: tACK [e912717](https://github.com/bitcoin/bitcoin/pull/29948/commits/e912717ff63f111d8f1cd7ed1fcf054e28f36409) Tree-SHA512: 8cb51746b0547369344c9ceef59599bfe9c91d424687af5e24dc6641f9e99fb433515d79c724e71fd3d5e02994f0cef623d3674367b8296b05c3c6fcdde282ef
2024-05-10refactor, subprocess: Remove unused stream API callsHennadii Stepanov
2024-05-10refactor, subprocess: Remove unused `Popen::child_created_` data memberHennadii Stepanov
2024-05-10refactor, subprocess: Remove unused `Popen::poll()`Hennadii Stepanov
2024-05-10refactor, subprocess: Remove `Popen::pid()`Hennadii Stepanov
2024-05-09Merge bitcoin/bitcoin#30006: test: use sleepy wait-for-log in reindex readonlyAva Chow
fd6a7d3a13d89d74e161095b0e9bd3570210a40c test: use sleepy wait-for-log in reindex readonly (Matthew Zipkin) Pull request description: Also rename the busy wait-for-log method to prevent recurrence. See https://github.com/bitcoin/bitcoin/pull/27039#discussion_r1532578152 ACKs for top commit: maflcko: utACK fd6a7d3a13d89d74e161095b0e9bd3570210a40c achow101: ACK fd6a7d3a13d89d74e161095b0e9bd3570210a40c tdb3: ACK for fd6a7d3a13d89d74e161095b0e9bd3570210a40c rkrux: ACK [fd6a7d3](https://github.com/bitcoin/bitcoin/pull/30006/commits/fd6a7d3a13d89d74e161095b0e9bd3570210a40c) Tree-SHA512: 7ff0574833df1ec843159b35ee88b8bb345a513ac13ed0b72abd1bf330c454a3f9df4d927871b9e3d37bfcc07542b06ef63acef8e822cd18499adae8cbb0cda8
2024-05-09Merge bitcoin/bitcoin#29939: test: add MiniWallet tagging support to avoid ↵Ava Chow
UTXO mixing, use in `fill_mempool` dd8fa861939d5b8bdd844ad7cab015d08533a91a test: use tagged ephemeral MiniWallet instance in fill_mempool (Sebastian Falbesoner) b2037ad4aeb4e16c7eb1e5756d0d1ee20172344b test: add MiniWallet tagging support to avoid UTXO mixing (Sebastian Falbesoner) c8e6d08236ff225db445009bf513d6d25def8eb2 test: refactor: eliminate COINBASE_MATURITY magic number in fill_mempool (Sebastian Falbesoner) 4f347140b1a31237597dd1821adcde8bd5761edc test: refactor: move fill_mempool to new module mempool_util (Sebastian Falbesoner) Pull request description: Different MiniWallet instances using the same mode (either ADDRESS_OP_TRUE, RAW_OP_TRUE or RAW_P2PK) currently always create and spend UTXOs with identical output scripts, which can cause unintentional tx dependencies (see e.g. the discussion in https://github.com/bitcoin/bitcoin/pull/29827#discussion_r1565443465). In order to avoid mixing of UTXOs between instances, this PR introduces the possibility to provide a MiniWallet tag name, that is used to derive a different internal key for the taproot construction, leading to a different P2TR output script. Note that since we use script-path spending and only the key-path is changed here, no changes in the MiniWallet spending logic are needed. The new tagging option is then used in the `fill_mempool` helper to create an ephemeral wallet for the filling txs, as suggested in https://github.com/bitcoin/bitcoin/pull/29827#discussion_r1565964264. To avoid circular dependencies, `fill_mempool` is moved to a new module `mempool_util.py` first. I'm still not sure if a generic word like "tag" is the right term for what this tries to achieve, happy to pick up better suggestions. Also, maybe passing a tag name is overkill and a boolean flag like "random_output_script" is sufficient? ACKs for top commit: glozow: ACK dd8fa861939 achow101: ACK dd8fa861939d5b8bdd844ad7cab015d08533a91a rkrux: tACK [dd8fa86](https://github.com/bitcoin/bitcoin/pull/29939/commits/dd8fa861939d5b8bdd844ad7cab015d08533a91a) brunoerg: utACK dd8fa861939d5b8bdd844ad7cab015d08533a91a Tree-SHA512: 5ef3558c3ef5ac32cfa79c8f751972ca6bceaa332cd7daac7e93412a88e30dec472cb041c0845b04abf8a317036d31ebddfc3234e609ed442417894c2bdeeac9
2024-05-09Merge bitcoin/bitcoin#29122: test: adds outbound eviction functional tests, ↵Ava Chow
updates comment in ConsiderEviction d53d84834747c37f4060a9ef379e0a6b50155246 test: adds outbound eviction tests for non outbound-full-relay peers (Sergi Delgado Segura) a8d9a0edc7cef2c31a557ef53eb45520976b0d65 test: adds outbound eviction functional tests, updates comment in ConsiderEviction (Sergi Delgado Segura) Pull request description: ## Motivation While checking the outbound eviction code I realized a case was not considered within the comments, which in turn made me realize we had no functional tests for the outbound eviction case (when I went to check/add the test case). This PR updates the aforementioned comment and adds functional tests to cover the outbound eviction logic, in addition to the existing unit tests found at `src/test/denialofservice_tests.cpp`. ACKs for top commit: davidgumberg: reACK https://github.com/bitcoin/bitcoin/commit/d53d84834747c37f4060a9ef379e0a6b50155246 tdb3: Re ACK for d53d84834747c37f4060a9ef379e0a6b50155246 achow101: ACK d53d84834747c37f4060a9ef379e0a6b50155246 cbergqvist: ACK d53d84834747c37f4060a9ef379e0a6b50155246 Tree-SHA512: 633b84bb1229fe21e2f650c1beada33ca7f190b64eafd64df2266516d21175e5d652e019ff7114f00cb8bd19f5817dc19e65adf75767a88e24dc0842ce40c63e
2024-05-10contrib: drop dead get_machine from test sym checkfanquake
2024-05-10contrib: use env_flags in get_archfanquake
Otherwise we fail to link when trying to use lld.
2024-05-09Merge bitcoin/bitcoin#28793: contrib: Add asmap-toolAva Chow
6abe772a17e09fe96e68cd3311280d5a30f6378b contrib: Add asmap-tool (Fabian Jahr) Pull request description: This adds `asmap.py` and `asmap-tool.py` from sipa's `nextgen` branch: https://github.com/sipa/asmap/tree/nextgen The motivation is that we should maintain the tooling for de- and encoding asmap files within the bitcoin core repository because it is not possible to use an asmap file that is not encoded. We already had an earlier version of `asmap.py` within the seeds contrib tools. The newer version only had a small amount of changes and is still compatible, so the old version is removed from contrib/seeds and the new version is made available to `makeseeds.py`. ACKs for top commit: virtu: ACK [6abe772](https://github.com/bitcoin/bitcoin/commit/6abe772a17e09fe96e68cd3311280d5a30f6378b) 0xB10C: ACK 6abe772a17e09fe96e68cd3311280d5a30f6378b achow101: ACK 6abe772a17e09fe96e68cd3311280d5a30f6378b brunoerg: ACK 6abe772a17e09fe96e68cd3311280d5a30f6378b Tree-SHA512: cc2a82ffa4eb46fa0ce4ca769dd82f8d0d2f37fc3652aa748eeb060e1142f9da4035008fe89433e2fd524a4dc153b7b9c085748944b49137b37009b0c0be8afb
2024-05-09Merge bitcoin/bitcoin#29973: test: Assumeutxo: ensure failure when importing ↵Ava Chow
a snapshot twice b259b0e8d360726b062c4b0453d1cf5a68e1933f [Test] Assumeutxo: ensure failure when importing a snapshot twice (Alfonso Roman Zubeldia) Pull request description: I am getting familiar with the `assume_utxo` tests and I found that the scenario of trying to activate a snapshot twice is not covered. This test is to ensure failure when loading a snapshot if there is already a snapshot-based chainstate. ACKs for top commit: fjahr: Code review ACK b259b0e8d360726b062c4b0453d1cf5a68e1933f kevkevinpal: tACK [b259b0e](https://github.com/bitcoin/bitcoin/pull/29973/commits/b259b0e8d360726b062c4b0453d1cf5a68e1933f) achow101: ACK b259b0e8d360726b062c4b0453d1cf5a68e1933f rkrux: tACK [b259b0e](https://github.com/bitcoin/bitcoin/pull/29973/commits/b259b0e8d360726b062c4b0453d1cf5a68e1933f) Tree-SHA512: 3510861390d0e40cdad6861b728df04827a1b63e642f3d956aee66ed2770b1cb7e3aa3eb00c62eb9da0544703c943cc5296936c9ebfcac18c719741c354421bb
2024-05-09Refactor: Remove ECC_Start and ECC_Stop from key headerTheCharlatan
They are unused outside of the key module now.
2024-05-09kernel: Remove key module from kernel libraryTheCharlatan
The key module's functionality is not used by the kernel library, but currently kernel users are still required to initialize the key module's `secp256k1_context_sign` global as part of the `kernel::Context` through `ECC_Start`.
2024-05-09tools: Use ECC_Context helper in bitcoin-tx and bitcoin-wallet toolsRyan Ofsky
2024-05-09test: Use ECC_Context helper in bench and fuzz testsRyan Ofsky
2024-05-09common: Add ECC_Context RAII wrapper for ECC_Start/ECC_StopRyan Ofsky
2024-05-09Merge bitcoin/bitcoin#30063: build, test: Remove unused `TIMEOUT` ↵merge-script
environment variable 189d0da3f6f561c808fdd9fbd4dfd34ccfa23fe1 build, test: Remove unused `TIMEOUT` environment variable (Hennadii Stepanov) Pull request description: Setting the `TIMEOUT` environment variable has been a noop in both cases since its introduction. It seems to have been inadvertently copy-pasted from existed code. For example, in commit d80e3cbece857b293a4903ef49c4d543bb2cfb7f, it was needlessly copied from a valid case a few lines above for the `qa/pull-tester/run-bitcoind-for-test.sh` script. ACKs for top commit: maflcko: utACK 189d0da3f6f561c808fdd9fbd4dfd34ccfa23fe1 edilmedeiros: ACK 189d0da3f6f561c808fdd9fbd4dfd34ccfa23fe1 Tree-SHA512: 61111eba30e0c82a0220bea48eba451cd9caa68785b48ec8a91059ca5aadfaff2f6d2ccdc5aa737c5cefa33579cb735431bb9e94bda8fa047825d7bd28d542fb