aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-06-22Opportunistically use bech32m change addresses if availableAndrew Chow
If a transaction as a segwit output, use a bech32m change address if they are available. If not, fallback to bech32. If bech32 change addresses are unavailable, fallback to the default address type.
2021-06-22Add OutputType::BECH32MAndrew Chow
Bech32m addresses need their own OutputType We are not ready to create DescriptorScriptPubKeyMans which produce bech32m addresses. So don't allow generating them.
2021-06-22Limit LegacyScriptPubKeyMan address typesAndrew Chow
Make sure that LegacyScriptPubKeyMan can only be used for legacy, p2sh-segwit, and bech32 address types.
2021-06-22Merge bitcoin/bitcoin#22308: wallet: Add missing BlockUntilSyncedToCurrentChainMarcoFalke
fa27baa9c8a13239625e5a7b6c472d236fe5b9fa Revert "test: Add temporary logging to debug #20975" (MarcoFalke) fadb55085a02c9e355617bcb5f84b6335e4f8c9d wallet: Add missing BlockUntilSyncedToCurrentChain (MarcoFalke) Pull request description: Fixes #20975 Also replace the wallet pointer by a reference ACKs for top commit: achow101: ACK fa27baa9c8a13239625e5a7b6c472d236fe5b9fa Tree-SHA512: 79047a30998104a12c2ff84a8e3cc5207151410bbe92b74cfedbe1c1aca3ffa5909391607fc597f3a3cf0725fa827528a4c57edaeacc8360536b1965e166be6a
2021-06-22Merge bitcoin/bitcoin#22309: blockstorage: Add missing atomic includeMarcoFalke
fa2d21fec8e532aa0781211e198ee6098f89350e add missing atomic include (MarcoFalke) Pull request description: `std::atomic` is used in the file, so to avoid compile issues, add the missing include. ACKs for top commit: practicalswift: cr ACK fa2d21fec8e532aa0781211e198ee6098f89350e jamesob: crACK https://github.com/bitcoin/bitcoin/pull/22309/commits/fa2d21fec8e532aa0781211e198ee6098f89350e hebasto: ACK fa2d21fec8e532aa0781211e198ee6098f89350e, I have reviewed the code and it looks OK, I agree it can be merged. prayank23: crACK https://github.com/bitcoin/bitcoin/pull/22309/commits/fa2d21fec8e532aa0781211e198ee6098f89350e Tree-SHA512: 307b15abd62006be4457b2437fb65de517c296bf0417e8acd181904eb6056dba5655dd5bc43b834bf68a087d06637f5e99ba5a6bc8be3e12388cea470dc155d0
2021-06-22add missing atomic includeMarcoFalke
2021-06-22Revert "test: Add temporary logging to debug #20975"MarcoFalke
This reverts commit faa94961d6e38392ba068381726ed4e033367b03.
2021-06-22wallet: Add missing BlockUntilSyncedToCurrentChainMarcoFalke
2021-06-22Merge bitcoin/bitcoin#22201: test: Fix TestShell to allow running in Jupyter ↵MarcoFalke
Notebook 168b6c317ca054c1287c36be532964e861f44266 add dummy file param to fix jupyter (Josiah Baker) Pull request description: this fixes argparse to use `parse_known_args`. previously, if an unknown argument was passed, argparse would fail with an `unrecognized arguments: %s` error. ## why the documentation mentions being able to run `TestShell` in a REPL interpreter or a jupyter notebook. when i tried to run inside a jupyter notebook, i got the following error: ![image](https://user-images.githubusercontent.com/7444140/121382910-57554880-c947-11eb-94f2-49da8679528c.png) this was due to the notebook passing the filename of the notebook as an argument. this is a known problem with notebooks and argparse, documented here: https://stackoverflow.com/questions/48796169/how-to-fix-ipykernel-launcher-py-error-unrecognized-arguments-in-jupyter ## testing to test, make sure you have jupyter notebooks installed. you can do this by running: ``` pip install notebook ``` or following instructions from [here](https://jupyterlab.readthedocs.io/en/stable/getting_started/installation.html). once installed, start a notebook (`jupyter notebook`), launch a python3 kernel and run the following snippet: ```python import sys # make sure this is the path for your system sys.path.insert(0, "/path/to/bitcoin/test/functional") from test_framework.test_shell import TestShell test = TestShell().setup(num_nodes=2, setup_clean_chain=True) ``` you should see the following output, without errors: ![image](https://user-images.githubusercontent.com/7444140/121383301-a307f200-c947-11eb-83b6-6c50b2cada25.png) if you are unfamiliar with notebooks, here is a short guide on using them: https://jupyter.readthedocs.io/en/latest/running.html ACKs for top commit: MarcoFalke: review ACK 168b6c317ca054c1287c36be532964e861f44266 jamesob: crACK https://github.com/bitcoin/bitcoin/pull/22201/commits/168b6c317ca054c1287c36be532964e861f44266 practicalswift: cr ACK 168b6c317ca054c1287c36be532964e861f44266 Tree-SHA512: 4fee1563bf64a1cf9009934182412446cde03badf2f19553b78ad2cb3ceb0e5e085a5db41ed440473494ac047f04641311ecbba3948761c6553d0ca4b54937b4
2021-06-21Merge bitcoin/bitcoin#22296: doc: Final merge of release notes snippets, mv ↵MarcoFalke
to wiki fa09fd1a0986aba918c5740f4c041ff2c7a7bae7 doc: Final merge of release notes snippets (MarcoFalke) Pull request description: None of the remaining pulls tagged for 22.0 have snippets, so merge them and move them to the wiki. Trivial to review with `--color-moved=dimmed-zebra`. ACKs for top commit: laanwj: ACK fa09fd1a0986aba918c5740f4c041ff2c7a7bae7 jonatack: ACK fa09fd1a0986aba918c5740f4c041ff2c7a7bae7 Tree-SHA512: d5d272a9fc2217a87988efa189000cae5330da22f0459dd5e4340a18aba3d67d8fe8661016cb777e2e15f5d137c1c2b3de7d576c942eaf4201dabdc4e9c783f4
2021-06-21add dummy file param to fix jupyterJosiah Baker
testshell in jupyter was failing due to an extra arg. this adds a dummy -f param, which allows TestShell to be used in a command line or jupyter environment
2021-06-21doc: Final merge of release notes snippetsMarcoFalke
2021-06-21Merge bitcoin/bitcoin#22089: test: MiniWallet: fix fee calculation for P2PK ↵MarcoFalke
and check tx vsize d6d2ab984547be4a9f7ba859a2a4c9ac9bfbf206 test: MiniWallet: fix fee calculation for P2PK and check tx vsize (Sebastian Falbesoner) ce024b1c0ef2dcd307023aaaab40373c8bf17db1 test: MiniWallet: force P2PK signature to have fixed size (71 bytes) (Sebastian Falbesoner) Pull request description: This PR is a follow-up to #21945. It aims to both fix the fee calculation for P2PK mode transactions and enable its vsize check. Currently, the latter assumes a fixed tx length, which is fine for anyone-can-spend txs but doesn't apply to P2PK output spends due to varying DER signature size; the vsize check is therefore disabled for P2PK mode on master branch. Creating one million DER signatures with MiniWallet shows the following distribution of sizes (smart people with better math skills probably could deduce the ratios without trying, but hey): | DER signature size [bytes] | #occurences (ratio) | | ------------- | ------------- | | 71 | 498893 (49.89%) | | 70 | 497244 (49.72%) | | 69 | 3837 (0.38%) | | 68 | 22 (0.0022%) | Note that even smaller signatures are possible (for smaller R and S values with leading zero bytes), it's just that the probability decreases exponentially. Instead of choosing a large vsize check range and hoping that smaller signatures are never created (potentially leading to flaky tests), the proposed solution is ~~to limit the signature size to the two most common sizes 71 and 70 (>99.6% probability) and then accordingly only check for two vsize values; the value to be used for fee calculation is a decimal right between the two possible sizes (167.5 vbytes) and for the vsize check it's rounded down/up integer values are used.~~ to simply grind the signature to a fixed size of 71 bytes (49.89% probability, i.e. on average each call to `sign_tx()`, on average two ECC signing operations are needed). ~~The idea of grinding signatures to a fixed size (similar to https://github.com/bitcoin/bitcoin/pull/13666 which grinds to low-R values) would be counter-productive, as the signature creation in the test suite is quite expensive and this would significantly slow down tests that calculate hundreds of signatures (like e.g. feature_csv_activation.py).~~ For more about transaction sizes on different input/output types, see the following interesting article: https://medium.com/coinmonks/on-bitcoin-transaction-sizes-97e31bc9d816 ACKs for top commit: MarcoFalke: Concept ACK d6d2ab984547be4a9f7ba859a2a4c9ac9bfbf206 Tree-SHA512: 011c70ee0e4adf9ba12902e4b6c411db9ae96bdd8bc810bf1d67713367998e28ea328394503371fc1f5087a819547ddaea56c073b28db893ae1c0031d7927f32
2021-06-21Merge bitcoin/bitcoin#21056: rpc: Add a `-rpcwaittimeout` parameter to limit ↵W. J. van der Laan
time spent waiting b9e76f1bf08c52fcd402b2314e00db4ad247ebc8 rpc: Add test for -rpcwaittimeout (Christian Decker) f76cb10d7dc9a7b0c55d28011161606399417664 rpc: Prefix rpcwaittimeout error with details on its nature (Christian Decker) c490e17ef698a1695050f82ef6567b3b87a21861 doc: Add release notes for the `-rpcwaittimeout` cli parameter (Christian Decker) a7fcc8eb59fe51473571661316214156fbdbdcae rpc: Add a `-rpcwaittimeout` parameter to limit time spent waiting (Christian Decker) Pull request description: Adds a new numeric `-rpcwaittimeout` that can be used to limit the time we spend waiting on the RPC server to appear. This is used by downstream projects to provide a bit of slack when `bitcoind`s RPC interface is not available right away. This makes the `-rpcwait` argument more useful, since we can now limit how long we'll ultimately wait, before potentially giving up and reporting an error to the caller. It was discussed in the context of the BTCPayServer wanting to have c-lightning wait for the RPC interface to become available but still have the option of giving up eventually ([4355]). I checked with laanwj whether this is already possible ([comment]), and whether this would be a welcome change. Initially I intended to repurpose the (optional) argument to `-rpcwait`, however I decided against it since it would potentially break existing configurations, using things like `rpcwait=1`, or `rpcwait=true` (the former would have an unintended short timeout, when old behavior was to wait indefinitely). ~Due to its simplicity I didn't implement a test for it yet, but if that's desired I can provide one.~ Test was added during reviews. [4355]: https://github.com/ElementsProject/lightning/issues/4355 [comment]: https://github.com/ElementsProject/lightning/issues/4355#issuecomment-768288261 ACKs for top commit: laanwj: Code review ACK b9e76f1bf08c52fcd402b2314e00db4ad247ebc8 promag: ACK b9e76f1bf08c52fcd402b2314e00db4ad247ebc8. Tree-SHA512: 3cd6728038ec7ca7c35c2e7ccb213bfbe963f99a49bb48bbc1e511c4dd23d9957c04f9af1f8ec57120e47b26eaf580b46817b099d5fc5083c98da7aa92db8638
2021-06-21Merge bitcoin/bitcoin#19033: http: Release work queue after event base finishW. J. van der Laan
4e353cb618745cdb5d98e58e7dcd400ded01299a http: Release work queue after event base finish (João Barbosa) Pull request description: This fixes a race between `http_request_cb` and `StopHTTPServer` where the work queue is used after release. Fixes #18856. ACKs for top commit: fjahr: Code review ACK 4e353cb618745cdb5d98e58e7dcd400ded01299a achow101: ACK 4e353cb618745cdb5d98e58e7dcd400ded01299a LarryRuane: ACK 4e353cb618745cdb5d98e58e7dcd400ded01299a hebasto: ACK 4e353cb618745cdb5d98e58e7dcd400ded01299a, tested (rebased on top of master 9313c4e6aa4b707c06a86b33d5d2753cd8383340) on Linux Mint 20.1 (x86_64) using MarcoFalke's [patch](https://github.com/bitcoin/bitcoin/pull/19033#issuecomment-640106647), including different `-rpcthreads`/`-rpcworkqueue` cases. The bug is fixed. The code is correct. Tree-SHA512: 185d2a9744d0d5134d782bf321ac9958ba17b11a5b3d70b4897c8243e6b146dfd3f23c57aef8e10ae9484374120b64389c1949a9cf0a21dccc47ffc934c20930
2021-06-21Merge bitcoin/bitcoin#22147: p2p: Protect last outbound HB compact block peerW. J. van der Laan
30aee2dfe671b347438c1c327c6f79edfacff1ce tests: Add test for compact block HB selection (Pieter Wuille) 6efbcec4ded6116a42d2783c96c60ef0f255a1b2 Protect last outbound HB compact block peer (Suhas Daftuar) Pull request description: If all our high-bandwidth compact block serving peers (BIP 152) stall block download, then we can be denied a block for (potentially) a long time. As inbound connections are much more likely to be adversarial than outbound connections, mitigate this risk by never removing our last outbound HB peer if it would be replaced by an inbound. ACKs for top commit: achow101: ACK 30aee2dfe671b347438c1c327c6f79edfacff1ce ariard: Code ACK 30aee2dfe jonatack: ACK 30aee2dfe671b347438c1c327c6f79edfacff1ce Tree-SHA512: 5c6c9326e3667b97e0864c371ae2174d2be9054dad479f4366127b9cd3ac60ffa01ec9707b16ef29cac122db6916cf56fd9985733390017134ace483278921d5
2021-06-21Merge bitcoin/bitcoin#22244: devtools: Correctly extract symbol versions in ↵W. J. van der Laan
symbol-check e8cd3700eeb27437f5ea435869c9d61214285fdd devtools: Integrate ARCH_MIN_GLIBC_VER table into MAX_VERSIONS in symbol-check.py (W. J. van der Laan) a33381acf5ae2b43616fffaf26b1c8962e8ef0bb devtools: Add xkb version to symbol-check (W. J. van der Laan) 19e598bab0a1cb5ad93321eb9fa25d1a58d5e276 devtools: Fix verneed section parsing in pixie (W. J. van der Laan) Pull request description: I misunderstood the ELF specification for version symbols (verneed): The `vn_aux` pointer is relative to the main verneed record, not the start of the section. This caused many symbols to not be versioned properly in the return value of `elf.dyn_symbols`. This was discovered in #21454. Fix it by correcting the offset computation. - xkb versions symbols (using the prefix `V`), as this library is used by bitcoin-qt, add it to the valid versions in `symbol-check.py` This unfortunately brings to light some symbols that have been introduced since and weren't caught (from a gitian compile of master): ``` bitcoin-cli: symbol getrandom from unsupported version GLIBC_2.25 bitcoin-cli: failed IMPORTED_SYMBOLS bitcoind: symbol getrandom from unsupported version GLIBC_2.25 bitcoind: symbol log from unsupported version GLIBC_2.29 bitcoind: symbol fcntl64 from unsupported version GLIBC_2.28 bitcoind: symbol pow from unsupported version GLIBC_2.29 bitcoind: symbol exp from unsupported version GLIBC_2.29 bitcoind: failed IMPORTED_SYMBOLS bitcoin-qt: symbol exp from unsupported version GLIBC_2.29 bitcoin-qt: symbol fcntl64 from unsupported version GLIBC_2.28 bitcoin-qt: symbol log from unsupported version GLIBC_2.29 bitcoin-qt: symbol pow from unsupported version GLIBC_2.29 bitcoin-qt: symbol statx from unsupported version GLIBC_2.28 bitcoin-qt: symbol getrandom from unsupported version GLIBC_2.25 bitcoin-qt: symbol renameat2 from unsupported version GLIBC_2.28 bitcoin-qt: symbol getentropy from unsupported version GLIBC_2.25 bitcoin-qt: failed IMPORTED_SYMBOLS bitcoin-wallet: symbol exp from unsupported version GLIBC_2.29 bitcoin-wallet: symbol log from unsupported version GLIBC_2.29 bitcoin-wallet: symbol fcntl64 from unsupported version GLIBC_2.28 bitcoin-wallet: failed IMPORTED_SYMBOLS test_bitcoin: symbol getrandom from unsupported version GLIBC_2.25 test_bitcoin: symbol log from unsupported version GLIBC_2.29 test_bitcoin: symbol fcntl64 from unsupported version GLIBC_2.28 test_bitcoin: symbol pow from unsupported version GLIBC_2.29 test_bitcoin: symbol exp from unsupported version GLIBC_2.29 test_bitcoin: failed IMPORTED_SYMBOLS ``` ACKs for top commit: hebasto: ACK e8cd3700eeb27437f5ea435869c9d61214285fdd Tree-SHA512: 8c15e3478eb642f01a1ddaadef03f80583f088f9fa8e3bf171ce16b0ec05ffb4675ec147d7ffc6a4360637ed47fca517c6ca2bac7bb30d794c03783cfb964b79
2021-06-19Merge bitcoin/bitcoin#22279: fuzz: add missing ECCVerifyHandle to ↵MarcoFalke
base_encode_decode 906d7913117c8f10934b37afa27ae8ac565da042 fuzz: add missing ECCVerifyHandle to base_encode_decode (Andrew Poelstra) Pull request description: It is possible to trigger a fuzztest failure in the `base_encode_decode` by asking it to decode any PSBT that has HD keypaths in it. For example, this one ``` cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoEBBUdSIQOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RiED3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg71SriIGA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GELSmumcAAACAAAAAgAQAAIAiBgPeVdHh2sgF4/iljB+/m5TALz26r+En/vykmV8m+CCDvRC0prpnAAAAgAAAAIAFAACAAAA= ``` which I took straight from the PSBT test vectors. The reason is that in src/psbt.h we call `DeserializeHDKeypaths`, which in turn calls `CPubKey::IsFullyValid`, which in turn asserts that a secp context has been created. The error appears to be masked on many systems by the definition of `instance_of_eccryptoclosure` in src/script/bitcoinconsensus.cpp, which defines a static object which contains an `ECCVerifyHandle`. If you just comment out that line you can reliably trigger the fuzz test failure, e.g. by creating a file `crash` with the above PSBT, and runnnig ``` ASAN_OPTIONS=symbolize=0:detect_stack_use_after_return=1:check_initialization_order=1:strict_init_order=1 UBSAN_OPTIONS=suppressions=./test/sanitizer_suppressions/ubsan:print_stacktrace=1:halt_on_error=1:report_error_type=1 FUZZ=base_encode_decode ./src/test/fuzz/fuzz -seed_inputs=crash ``` ACKs for top commit: practicalswift: cr ACK 906d7913117c8f10934b37afa27ae8ac565da042 Tree-SHA512: b98b60573c21efe28503fe351883c6f0d9ac99d0dd6f100537b16ac53476617b8a3f899faf0c23d893d34a01b3bbe4a784499ec6f9c7000292e850bed449bd85
2021-06-19Merge bitcoin/bitcoin#22210: test: Use MiniWallet in ↵MarcoFalke
test_no_inherited_signaling RBF test fa7d71f270b89c9d06230d4ff262646f9ea29f4a test: Run pep-8 on touched test (MarcoFalke) fab7e99c2a4b02a41b7448b45f0e6cdfdbb53ac3 test: Use MiniWallet in test_no_inherited_signaling RBF test (MarcoFalke) fab871f649e3da4a5a5f6cffac3fc748bb1ca900 test: Remove unused generate() from test (MarcoFalke) faff3f35b778d9af3d649b303d7edab49bfe40b4 test: Add txin.sequence option to MiniWallet (MarcoFalke) Pull request description: This comes with nice benefits: * Less code and complexity * Test can be run without wallet compiled in Also add some additional checks for `getmempoolentry` (#22209) and other cleanups :art: ACKs for top commit: mjdietzx: Tested ACK fa7d71f270b89c9d06230d4ff262646f9ea29f4a thanks for the explanations, nicely done theStack: ACK fa7d71f270b89c9d06230d4ff262646f9ea29f4a 🍷 Tree-SHA512: 0e9b8fe985779d8d7034d256deed627125bb374b6ae2972c461b3a220739a51061c6147ad69339bee16282f82716c7f3f8a7a89c693ceb1e47ea50709272332a
2021-06-18fuzz: add missing ECCVerifyHandle to base_encode_decodeAndrew Poelstra
2021-06-18Merge bitcoin/bitcoin#20923: signet miner followupsW. J. van der Laan
b3c712cb2871e0034898b37454fb6a4e1fc78f84 contrib/signet/miner: remove debug code (Anthony Towns) 297e35159f99d4caa995de29d419aefa4b87630c bitcoin-util: use AddCommand / GetCommand (Anthony Towns) b6d493fd4d602a67d16d2566466e18091e272fa0 contrib/signet/README.md: Update miner description (Anthony Towns) e66543827cd4ae9b76ff4c5c6e414c1942c7d727 contrib/signet/miner: Automatic timestamp for first block (Anthony Towns) a383ce5b4add6cdf4e9974527b609a1147a0d972 contrib/signet/miner: --grind-cmd is required for calibrate (Anthony Towns) 1a45cd2e51214f81442a5f9bf16612100adaf5b8 contrib/signet: Fix typos (Anthony Towns) Pull request description: Followups from #19937 ACKs for top commit: laanwj: Code review ACK b3c712cb2871e0034898b37454fb6a4e1fc78f84 Tree-SHA512: a1003f9ee3697438114b60872b50f4300c8b52f0d58551566eb61c421d787525807ae75be205dcab2c24358cd568f53260120880109a9d728773405ff987596f
2021-06-18Merge bitcoin/bitcoin#14604: tests: Add test and refactor feature_block.pyMarcoFalke
55311197c483477b79883da5da09f2bc71acc7cf Added new test for future blocks reacceptance (sanket1729) 511a5af4622915c236cfb11df5234232c2983e45 Fixed inconsistencies between code and comments (sanket1729) Pull request description: This Commit does 3 things: 1) Adds a test case for checking reacceptance a previously rejected block which was too far in the future. ~~2) clean up uses of rehash or calc_sha256 where it was not needed~~ 3) While constructing block 44, this commit makes the code consistent with the expected figure in the comment just above it by adding a transaction to the block. 4) Fix comment describing `sign_tx()` function ACKs for top commit: duncandean: reACK 5531119 brunoerg: reACK 55311197c483477b79883da5da09f2bc71acc7cf Tree-SHA512: d40c72fcdbb0b2a0715adc58441eeea08147ee2ec5e371a4ccc824ebfdc6450698bd40aaeecb7ea7bfdb3cd1b264dd821b890276fff8b8d89b7225cdd9d6b546
2021-06-18Merge bitcoin/bitcoin#22249: test: kill process group to avoid dangling ↵MarcoFalke
processes when using `--failfast` 451b96f7d2796d00eabaec56d831f9e9b1a569cc test: kill process group to avoid dangling processes (S3RK) Pull request description: This is an alternative to #19281 This PR fixes a problem when after test failure with `--failfast` option there could be dangling nodes. The nodes will continue to occupy rpc/p2p ports on the machine and will cause further test failures. If there are any dangling nodes left at the end of the test run we kill the whole process group. Pros: the operations is immediate and won't lead to CI timeout Cons: the test_runner process is also killed and exit code is 137 Example output: ``` ... Early exiting after test failure TEST | STATUS | DURATION rpc_decodescript.py | ✓ Passed | 2 s rpc_deprecated.py | ✓ Passed | 2 s rpc_deriveaddresses.py | ✓ Passed | 2 s rpc_dumptxoutset.py | ✖ Failed | 2 s ALL | ✖ Failed | 8 s (accumulated) Runtime: 4 s Killed: 9 > echo $? 137 ``` ACKs for top commit: MarcoFalke: review ACK 451b96f7d2796d00eabaec56d831f9e9b1a569cc aitorjs: ACK 451b96f7d2796d00eabaec56d831f9e9b1a569cc. Manual testing with and without **--failfast**. Tree-SHA512: 87e510a1411b9e7571e63cf7ffc8b9a8935daf9112ffc0f069d6c406ba87743ec439808181f7e13cb97bb200fad528589786c47f0b43cf3a2ef0d06a23cb86dd
2021-06-18devtools: Integrate ARCH_MIN_GLIBC_VER table into MAX_VERSIONS in ↵W. J. van der Laan
symbol-check.py The (ancient) versions specified here were deceptive. Entries older than MAX_VERSIONS['GLIBC'], which is 2.17, are ignored here. So reorganize the code to avoid confusion for other people reading this code.
2021-06-18Merge bitcoin/bitcoin#21871: scripts: add checks for minimum required OS ↵fanquake
versions aa80b5759dfa613780a99801641519dd78bb3eca scripts: check macOS SDK version is set (fanquake) c972345bacd0cb01371b3f00941e81dce16278e1 scripts: check minimum required Windows version is set (fanquake) 29615aef52d7f1a29a87a29dfe4d39bf0e9867f3 scripts: check minimum required macOS vesion is set (fanquake) 8732f7b6c92f9dcf37f3ab618e9daab0c52fc781 scripts: LIEF 0.11.5 (fanquake) Pull request description: macOS: We use a compile flag ([-mmacosx-version-min=10.14](https://github.com/bitcoin/bitcoin/blob/master/depends/hosts/darwin.mk#L96)) to set the minimum required version of macOS needed to run our binaries. This adds a sanity check that the version is being set as expected. Clangs Darwin driver should infer the SDK version used during compilation, and forward that through to the linker. Add a check that this has been done, and the expected SDK version is set. Should help prevent issues like #21771 in future. Windows: We use linker flags ([-Wl,--major/minor-subsystem-version](https://github.com/bitcoin/bitcoin/blob/master/configure.ac#L683)) to set the minimum required version of Windows needed to run our binaries. This adds a sanity check that the version is being set as expected. Gitian builds: ```bash # macOS: 8b6fcd61d75001c37b2af3fceb5ae09f5d2fe85e97d361f684214bd91c27954a bitcoin-f015e1c2cac9-osx-unsigned.dmg 3c1e412bc7f5a7a5d0f78e2cd84b7096831414e1304c1307211aa3e135d89bbf bitcoin-f015e1c2cac9-osx-unsigned.tar.gz 50b7b2804e8481f63c69c78e3e8a71c0d811bf2db8895dd6d3edae9c46a738ae bitcoin-f015e1c2cac9-osx64.tar.gz fe6b5c0a550096b76b6727efee30e85b60163a41c83f21868c849fdd9876b675 src/bitcoin-f015e1c2cac9.tar.gz 8a20f21b20673dfc8c23e22b20ae0839bcaf65bf0e02f62381cdf5e7922936f0 bitcoin-core-osx-22-res.yml # Windows: b01fcdc2a5673387050d6c6c4f96f1d350976a121155fde3f76c2af309111f9d bitcoin-f015e1c2cac9-win-unsigned.tar.gz b95bdcbef638804030671d2332d58011f8c4ed4c1db87d6ffd211515c32c9d02 bitcoin-f015e1c2cac9-win64-debug.zip 350bf180252d24a3d40f05e22398fec7bb00e06d812204eb5a421100a8e10638 bitcoin-f015e1c2cac9-win64-setup-unsigned.exe 2730ddabe246d99913c9a779e97edcadb2d55309933d46f1dffd0d23ecf9aae5 bitcoin-f015e1c2cac9-win64.zip fe6b5c0a550096b76b6727efee30e85b60163a41c83f21868c849fdd9876b675 src/bitcoin-f015e1c2cac9.tar.gz aa60d7a753e8cb2d4323cfbbf4d964ad3645e74c918cccd66862888f8646d80f bitcoin-core-win-22-res.yml ``` ACKs for top commit: hebasto: ACK aa80b5759dfa613780a99801641519dd78bb3eca, tested by breaking tests: Tree-SHA512: 10150219910e8131715fbfe20edaa15778387616ef3bfe1a5152c7acd3958fe8f88c74961c3d3641074eb72824680c22764bb1dc01a19e92e946c2d4962a8d2c
2021-06-18Merge bitcoin/bitcoin#22238: build: improve detection of eBPF supportfanquake
8f7704d0321a71c1691837a6bd3b4e05f84d3031 build: improve detection of eBPF support (fanquake) Pull request description: Just checking for the `sys/sdt.h` header isn't enough, as systems like macOS have the header, but it doesn't actually have the `DTRACE_PROBE*` probes, which leads to [compile failures](https://github.com/bitcoin/bitcoin/pull/22006#issuecomment-859559004). The contents of `sys/sdt.h` in the macOS SDK is: ```bash #ifndef _SYS_SDT_H #define _SYS_SDT_H /* * This is a wrapper header that wraps the mach visible sdt.h header so that * the header file ends up visible where software expects it to be. We also * do the C/C++ symbol wrapping here, since Mach headers are technically C * interfaces. * * Note: The process of adding USDT probes to code is slightly different * than documented in the "Solaris Dynamic Tracing Guide". * The DTRACE_PROBE*() macros are not supported on Mac OS X -- instead see * "BUILDING CODE CONTAINING USDT PROBES" in the dtrace(1) manpage * */ #include <sys/cdefs.h> __BEGIN_DECLS #include <mach/sdt.h> __END_DECLS #endif /* _SYS_SDT_H */ ``` The `BUILDING CODE CONTAINING USDT PROBES` section from the dtrace manpage is available [here](https://gist.github.com/fanquake/e56c9866d53b326646d04ab43a8df9e2), and outlines the more involved process of using USDT probes on macOS. ACKs for top commit: jb55: utACK 8f7704d0321a71c1691837a6bd3b4e05f84d3031 practicalswift: cr ACK 8f7704d0321a71c1691837a6bd3b4e05f84d3031 hebasto: ACK 8f7704d0321a71c1691837a6bd3b4e05f84d3031, tested on macOS Big Sur 11.4 (20F71) and on Linux Mint 20.1 (x86_64) with depends. Tree-SHA512: 5f1351d0ac2e655fccb22a5454f415906404fdaa336fd89b54ef49ca50a442c44ab92d063cba3f161cb8ea0679c92ae3cd6cfbbcb19728cac21116247a017df5
2021-06-18Merge bitcoin/bitcoin#21365: Basic Taproot signing support for descriptor ↵Samuel Dobson
wallets 458a345b0590fd2fa04c7d8d70beb8d57e34bbc8 Add support for SIGHASH_DEFAULT in RPCs, and make it default (Pieter Wuille) c0f0c8eccb04f90940007e0c6aaff56bf2ab35b5 tests: check spending of P2TR (Pieter Wuille) a2380127e905e5849f90acc7c69832859d8336aa Basic Taproot signing logic in script/sign.cpp (Pieter Wuille) 49487bc3b6038393c1b9c2dbdc04a78ae1178f1a Make GetInputUTXO safer: verify non-witness UTXO match (Pieter Wuille) fd3f6890f3dfd683f6f13db912caf5c4288adf08 Construct and use PrecomputedTransactionData in PSBT signing (Pieter Wuille) 5cb6502ac5730ea453edbec4c46027ac2ada97e0 Construct and use PrecomputedTransactionData in SignTransaction (Pieter Wuille) 5d2e22437b22e7465ae4be64069443bcc1769dc9 Don't nuke witness data when signing fails (Pieter Wuille) ce9353164bdb6215a62b2b6dcb2121d331796f60 Permit full precomputation in PrecomputedTransactionData (Pieter Wuille) e841fb503d7a662bde01ec2e4794faa989265950 Add precomputed txdata support to MutableTransactionSignatureCreator (Pieter Wuille) a91d532338ecb66ec5bed164929d878dd55d63a4 Add CKey::SignSchnorr function for BIP 340/341 signing (Pieter Wuille) e77a2839b54fa2039bba468e8c09dbbbf19b150a Use HandleMissingData also in CheckSchnorrSignature (Pieter Wuille) dbb0ce9fbff01ffe4dd29da465f43ecaddc2854c Add TaprootSpendData data structure, equivalent to script map for P2[W]SH (Pieter Wuille) Pull request description: Builds on top of #22051, adding signing support after derivation support. Nothing is changed in descriptor features. Signing works for key path and script path spending, through the normal sending functions, and PSBT-based RPCs. However, PSBT usability is rather low as no extensions have been defined to convey Taproot-specific information, so all script information must be known to the signing wallet. ACKs for top commit: achow101: re-ACK 458a345b0590fd2fa04c7d8d70beb8d57e34bbc8 fjahr: Code review ACK 458a345b0590fd2fa04c7d8d70beb8d57e34bbc8 Sjors: ACK 458a345b0590fd2fa04c7d8d70beb8d57e34bbc8 Tree-SHA512: 30ed212cf7754763a4a81624ebc084c51727b8322711ac0b390369213c1a891d367ed8b123882ac08c99595320c11ec57ee42304ff22a69afdc3d1a0d55cc711
2021-06-17Merge bitcoin/bitcoin#22271: fuzz: Assert roundtrip equality for `CPubKey`MarcoFalke
9550dffa0c61df6d1591c62d09629b4c5731e1b7 fuzz: Assert roundtrip equality for `CPubKey` (Sebastian Falbesoner) Pull request description: This PR is a (quite late) follow-up to #19237 (https://github.com/bitcoin/bitcoin/pull/19237#issuecomment-642203251). Looking at `CPubKey::Serialize` and `CPubKey::Unserialize` I can't think of a scenario where the roundtrip (serialization/deserialization) equality wouldn't hold. ACKs for top commit: jamesob: crACK https://github.com/bitcoin/bitcoin/pull/22271/commits/9550dffa0c61df6d1591c62d09629b4c5731e1b7 pending CI Tree-SHA512: 640fb9e777d249769b22ee52c0b15a68ff0645b16c986e1c0bce9742155d14f1be601e591833e1dc8dcffebf271966c6b861b90888a44aae1feae2e0248e2c55
2021-06-17Merge bitcoin/bitcoin#20516: Well-defined CAddress disk serialization, and ↵W. J. van der Laan
addrv2 anchors.dat f8866e8c324be3322fa507c2ceb1de35d148d0f1 Add roundtrip fuzz tests for CAddress serialization (Pieter Wuille) e2f0548b52a4b2ba3edf77e3f21365f1e8f270a4 Use addrv2 serialization in anchors.dat (Pieter Wuille) 8cd8f37dfe3ffb73a09f3ad773603d9d89452245 Introduce well-defined CAddress disk serialization (Pieter Wuille) Pull request description: Alternative to #20509. This makes the `CAddress` disk serialization format well defined, and uses it to enable addrv2 support in anchors.dat (in a way that's compatible with older software). The new format is: - The first 4 bytes store a format version number. Its low 19 bits are ignored (as those historically stored the `CLIENT_VERSION`), but its high 13 bits specify the actual serialization: - 0x00000000: LE64 encoding for `nServices`, V1 encoding for `CService` (like pre-BIP155 network serialization). - 0x20000000: CompactSize encoding for `nServices`, V2 encoding for `CService` (like BIP155 network serialization). - Any other value triggers an unsupported format error on deserialization, and can be used for future format changes. - The `ADDRV2_FORMAT` flag in the stream's version does not determine the actual serialization format; it only sets whether or not V2 encoding is permitted. ACKs for top commit: achow101: ACK f8866e8c324be3322fa507c2ceb1de35d148d0f1 laanwj: Code review ACK f8866e8c324be3322fa507c2ceb1de35d148d0f1 vasild: ACK f8866e8c324be3322fa507c2ceb1de35d148d0f1 jonatack: ACK f8866e8c324be3322fa507c2ceb1de35d148d0f1 tested rebased to master and built/run/restarted with DEBUG_ADDRMAN, peers.dat and anchors ser/deser seems fine hebasto: ACK f8866e8c324be3322fa507c2ceb1de35d148d0f1, tested on Linux Mint 20.1 (x86_64). Tree-SHA512: 3898f8a8c51783a46dd0aae03fa10060521f5dd6e79315fe95ba807689e78f202388ffa28c40bf156c6f7b1fc2ce806b155dcbe56027df73d039a55331723796
2021-06-17fuzz: Assert roundtrip equality for `CPubKey`Sebastian Falbesoner
2021-06-17Merge bitcoin/bitcoin#22268: fuzz: Add temporary debug assert for oss-fuzz issueMarcoFalke
faf1af58f85da74f94c6b5f6910c7faf7b47cc88 fuzz: Add Temporary debug assert for oss-fuzz issue (MarcoFalke) Pull request description: oss-fuzz is acting weird, so add an earlier assert to help troubleshooting ACKs for top commit: practicalswift: cr ACK faf1af58f85da74f94c6b5f6910c7faf7b47cc88 Tree-SHA512: 85830d7d47cf6b4edfe91a07bd5aa8f7110db0bade8df93868cf276ed04d5dd17e671f769e6a0fb5092012b86aa82bb411fb171411f15746981104ce634c88c1
2021-06-17Merge bitcoin/bitcoin#22267: fuzz: Speed up crypto fuzz targetMarcoFalke
fa483e9f68b8b4171dabb25cc88dc2eada454a99 fuzz: Speed up crypto fuzz target (MarcoFalke) Pull request description: May fix https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=34962 Similar solution to https://github.com/bitcoin/bitcoin/pull/22005 ACKs for top commit: practicalswift: cr ACK fa483e9f68b8b4171dabb25cc88dc2eada454a99: patch looks correct and rationale makes sense Tree-SHA512: 3788cf9f6ba0f7a0a217cd3a6a825839689425e99e4d6d657981d291a001b0da7c5abb50a68b4ee1c2a8300b87fb92e4e3ccc1171907792b40251e467c33bd53
2021-06-17fuzz: Add Temporary debug assert for oss-fuzz issueMarcoFalke
2021-06-17fuzz: Speed up crypto fuzz targetMarcoFalke
2021-06-17Merge bitcoin/bitcoin#22120: test: p2p_invalid_block: Check that a block ↵MarcoFalke
rejected due to too-new tim… 754e802274e9373ad7e1dccb710acf74ded6e7fb test: check rejected future block later accepted (Luke Dashjr) Pull request description: (Luke) was unsure if the code sufficiently avoided caching a time-too-new rejection, so wrote this test to check it. It looks like despite only exempting BLOCK_MUTATED, it is still okay because header failures never cache block invalidity. This test will help ensure that if this ever changes, BLOCK_TIME_FUTURE gets excluded at the same time. This PR re-opens https://github.com/bitcoin/bitcoin/pull/17872 which went stale and addresses the nits raised by reviewers there. ACKs for top commit: MarcoFalke: review ACK 754e802274e9373ad7e1dccb710acf74ded6e7fb Tree-SHA512: a2bbc8fffb523cf2831e1ecb05f20868e30106a38cc2e369e4973fa549cca06675a668df16f76c49cc4ce3a22925404255e5c53c4232d63ba1b9fca878509aa0
2021-06-17Merge bitcoin/bitcoin#22182: guix: Overhaul how guix-{attest,verify} works ↵fanquake
and hierarchy e2c40a4ed5272d72fea997bd936fba28bb753226 guix-attest: Error out if SHA256SUMS is unexpected (Carl Dong) 4cc35daed557f38b080360a89036b2e97a6f78c2 Rewrite guix-{attest,verify} for new hier (Carl Dong) 28a9c9b83924f585b397f0f3b8e9e73780ac0ad6 Make SHA256SUMS fragment right after build (Carl Dong) Pull request description: Based on: #22075 Code reviewers: I recommend reading the new `guix-{attest,verify}` files instead of trying to read the diff The following changes resolve many usability improvements which were pointed out to me: 1. Some maintainers like to extract their "uncodesigned tarball" inside the `output/` directory, resulting in the older `guix-attest` mistakenly attesting to the extracted contents 2. Maintainers whose GPG keys reside on an external smartcard often need to physically interact with the smartcard as a way to approve the signing operation, having one signature per platform means a lot of fidgeting 3. Maintainers wishing to sign on a separate machine now has the option of transferring only a subtree of `output/`, namely `output/*/SHA256SUMS.part`, in order to perform a signature (you may need to specify an `$OUTDIR_BASE` env var) 4. An `all.SHA256SUMS` file should be usable as the base `SHA256SUMS` in bitcoin core torrents and on the release server. For those who sign on an separate machine than the one you do builds on, the following steps will work: 1. `env GUIX_SIGS_REPO=/home/achow101/guix.sigs SIGNER=achow101 NO_SIGN=1 ./contrib/guix/guix-attest` 2. Copy `/home/achow101/guix.sigs/<tag>/achow101` (which does not yet have signatures) to signing machine 3. Sign the `SHA256SUMS` files: ```bash for i in "<path-to-achow101>/*.SHA256SUMS"; do gpg --detach-sign --local-user "<your-key-here>" --armor --output "$i"{.asc,} done ``` 5. Upload `<path-to-achow101>` (now with signatures) to `guix.sigs` ----- After this change, output directories will now include a `SHA256SUMS.part` fragment, created immediately after a successful build: ``` output └── x86_64-w64-mingw32 ├── bitcoin-4e069f7589da-win64-debug.zip ├── bitcoin-4e069f7589da-win64-setup-unsigned.exe ├── bitcoin-4e069f7589da-win64.zip ├── bitcoin-4e069f7589da-win-unsigned.tar.gz └── SHA256SUMS.part ``` These `SHA256SUMS.part` fragments look something like: ``` 3ebd7262b1a0a5bb757fef1f70e7e14033c70f98c059bc4dbfee5d1992b25825 dist-archive/bitcoin-4e069f7589da.tar.gz def2e7d3de5ab3e3f955344e75151df4f33713f9101f5295bd13c9375bdf633b x86_64-w64-mingw32/bitcoin-4e069f7589da-win64-debug.zip 643049fe3ee4a4e83a1739607e67b11b7c9b1a66208a6f35a9ff634ba795500e x86_64-w64-mingw32/bitcoin-4e069f7589da-win64-setup-unsigned.exe a247a1ccec0ccc2e138c648284bd01f6a761f2d8d6d07d91b5b4a6670ec3f288 x86_64-w64-mingw32/bitcoin-4e069f7589da-win-unsigned.tar.gz fab76a836dcc592e39c04fd2396696633fb6eb56e39ecbf6c909bd173ed4280c x86_64-w64-mingw32/bitcoin-4e069f7589da-win64.zip ``` Meaning that they are valid `SHA256SUMS` files when `sha256sum --check`'d at the `guix-build-*/output` directory level When `guix-attest` is invoked, these `SHA256SUMS.part` files are combined and sorted (by `-k2`, `LC_ALL=C`) to create: 1. `noncodesigned.SHA256SUMS` for a manifest of all non-codesigned outputs, and 3. `all.SHA256SUMS` for a manifest of all outputs including non-codesigned outputs Then both files are signed, resulting in the following `guix.sigs` hierarchy: ``` 4e069f7589da/ └── dongcarl ├── all.SHA256SUMS ├── all.SHA256SUMS.asc ├── noncodesigned.SHA256SUMS └── noncodesigned.SHA256SUMS.asc ``` ACKs for top commit: achow101: ACK e2c40a4ed5272d72fea997bd936fba28bb753226 hebasto: ACK e2c40a4ed5272d72fea997bd936fba28bb753226, tested on Linux Mint 20.1 (x86_64) with and w/o `NO_SIGN=1`. Changes in `contrib/guix/libexec/codesign.sh` and `contrib/guix/guix-verify` are reviewed only. Tree-SHA512: 618aacefb0eb6595735a9ab6a98ea6598fce65f9ccf33fa1e7ef93bf140c0f6cfc16e34870c6aa3e4777dd3f004b92a82a994141879870141742df948ec59c1f
2021-06-17Merge bitcoin/bitcoin#21935: Enable external signer support by default, ↵fanquake
reduce #ifdef 2f5bdcbc31a2eeb7c11226a9e51c56f02ac807dd gui: misc external signer fixes and translation hints (Sjors Provoost) d672404466204444a1d9f2d3498de4448f53d2be refactor: make ExternalSigner NetworkArg() and m_chain private (Sjors Provoost) 4455145e266450397b45acd7286686966edd072b refactor: reduce #ifdef ENABLE_EXTERNAL_SIGNER usage (Sjors Provoost) 5be90c907eba0a38019c7d9826623d5d5f567c66 build: enable external signer by default (Sjors Provoost) 7d9453041b827bafbdfc1ac0b01c7b7e1ee2bd4f refactor: clean up external_signer.h includes (Sjors Provoost) fc0eca31b33f87882e2aa329a3746d4e08af1985 fuzz: fix fuzz binary linking order (Sjors Provoost) Pull request description: This follows the introduction of GUI support in https://github.com/bitcoin-core/gui/pull/4 I don't think we should expect GUI users to self compile. This also enables external signer support by default for RPC users. In addition this PR reduces the number of `#ifdef ENABLE_EXTERNAL_SIGNER`, which also fixes #21919. When compiled with `--disable-external-signer` such wallets can't be created in RPC or GUI, but they can be loaded. Attempting any action that calls HWI will trigger an error. Side-note: this PR may or may not (currently) break CI for the GUI repository, as explained here: https://github.com/bitcoin-core/gui/pull/4#issuecomment-769859001 ACKs for top commit: achow101: ACK 2f5bdcbc31a2eeb7c11226a9e51c56f02ac807dd hebasto: re-ACK 2f5bdcbc31a2eeb7c11226a9e51c56f02ac807dd Tree-SHA512: 1b71c5a8bea2be077ee9fa33a01130c957a0cf90951d4b7b04d3d0ef826bb77e474c3963abddfef2e2c1ea99d9c72cd2302d1eb9b5fcb7ba0bd2a625f006aa05
2021-06-17Merge bitcoin/bitcoin#22258: build: Disable deprecated-copy warning only ↵fanquake
when external warnings are enabled 1111457d7433c2cca1d7e98946f6954e3a0280ef build: Disable deprecated-copy warning only when external warnings are enabled (MarcoFalke) Pull request description: Fixes https://github.com/bitcoin/bitcoin/issues/18967 Alternative to https://github.com/bitcoin/bitcoin/pull/22240 ACKs for top commit: fanquake: tACK 1111457d7433c2cca1d7e98946f6954e3a0280ef Tree-SHA512: 0fc826f26ebbeab662fa7eed2a5cc1630c6c4e612deb91734885fc8bae0352be657ec48ae94ff55a984ac36d27b95cea8d947cc5cf408231d56addecf79db83f
2021-06-16Added new test for future blocks reacceptancesanket1729
Adds a test case for checking reacceptance a previously rejected block that was too far in the future.
2021-06-16Fixed inconsistencies between code and commentssanket1729
1) Makes the code for block 44 consistent with the expected figure in the comment above it by adding a transaction to the block 2) Fixed comment describing sign_tx() function
2021-06-16build: Disable deprecated-copy warning only when external warnings are enabledMarcoFalke
2021-06-16gui: misc external signer fixes and translation hintsSjors Provoost
2021-06-16refactor: make ExternalSigner NetworkArg() and m_chain privateSjors Provoost
2021-06-16refactor: reduce #ifdef ENABLE_EXTERNAL_SIGNER usageSjors Provoost
In particular this make the node interface independent on whether external signer support is compiled.
2021-06-16build: enable external signer by defaultSjors Provoost
2021-06-16refactor: clean up external_signer.h includesSjors Provoost
Co-Authored-By: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>
2021-06-16fuzz: fix fuzz binary linking orderSjors Provoost
We encountered a linking error when attempting to include external_signer_scriptpubkeyman.cpp when configured with --disable-external-signer. Everywhere else we have LIBBITCOIN_WALLET, it is always before LIBBITCOIN_COMMON. But if you go up to where FUZZ_SUITE_LD_COMMON is first set, you see that we will end up having LIBBITCOIN_COMMON set before LIBBITCOIN_WALLET which means that the linker will have problems linking things common things that the wallet uses. Because the order is correct for the other targets, we only see a linker error for test/fuzz/fuzz. In this diff, LIBTEST_UTIL and LIBTEST_FUZZ are moved to the top because they include LIBBITCOIN_SERVER and LIBBITCOIN_COMMON. LIBBITCOIN_SERVER always needs to be the first item in the linker order since it has the most dependencies. The makefiles for making the fuzz and test binaries should be revisited so that the linking order is made consistent with the rest of the code and to avoid other linker order issues that may crop up in the future. Co-Authored-By: Andrew Chow <achow101-github@achow101.com>
2021-06-16Merge bitcoin/bitcoin#22144: Randomize message processing peer orderfanquake
79c02c88b347f1408a2db307db2654917f9b0bcc Randomize message processing peer order (Pieter Wuille) Pull request description: Right now, the message handling loop iterates the list of nodes always in the same order: the order they were connected in (see the `vNodes` vector). For some parts of the net processing logic, this order matters. Transaction requests are assigned explicitly to peers since #19988, but many other parts of processing work on a "first-served-by-loop-first" basis, such as block downloading. If peers can predict this ordering, it may be exploited to cause delays. As there isn't anything particularly optimal about the current ordering, just make it unpredictable by randomizing. Reported by Crypt-iQ. ACKs for top commit: jnewbery: ACK 79c02c88b3 Crypt-iQ: ACK 79c02c88b347f1408a2db307db2654917f9b0bcc sdaftuar: utACK 79c02c88b347f1408a2db307db2654917f9b0bcc achow101: Code Review ACK 79c02c88b347f1408a2db307db2654917f9b0bcc jamesob: crACK https://github.com/bitcoin/bitcoin/pull/22144/commits/79c02c88b347f1408a2db307db2654917f9b0bcc jonatack: ACK 79c02c88b347f1408a2db307db2654917f9b0bcc vasild: ACK 79c02c88b347f1408a2db307db2654917f9b0bcc theStack: ACK 79c02c88b347f1408a2db307db2654917f9b0bcc Tree-SHA512: 9a87c4dcad47c2d61b76c4f37f59674876b78f33f45943089bf159902a23e12de7a5feae1a73b17cbc3f2e37c980ecf0f7fd86af9e6fa3a68099537a3c82c106
2021-06-16build: improve detection of eBPF supportfanquake
Just checking for the `sys/sdt.h` header isn't enough, as systems like macOS have the header, but it doesn't actually have the dtrace probes, which leads to compile failures.
2021-06-15test: check rejected future block later acceptedLuke Dashjr
(Luke) was unsure if the code sufficiently avoided caching a time-too-new rejection, so wrote this test to check it. It looks like despite only exempting BLOCK_MUTATED, it is still okay because header failures never cache block invalidity. This test will help ensure that if this ever changes, BLOCK_TIME_FUTURE gets excluded at the same time. Co-authored-by: Will Clark <will8clark@gmail.com>
generated by cgit v1.2.3 (git 2.26.2) at 2024-11-12 22:03:32 +0000