refactor: reenable shift-base sanitizer for InsecureRandomContext::rand64
#7
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The only example present earlier was one that creates an OP_RETURN output. This lack of examples has discouraged me earlier to use this RPC. Adding an example that creates PSBT sending bitcoin to address, a scenario that is much more common.
Update get_permissions function to remove unnecessary replace() and improve password for strangedude6. Change all string concatenation to f-strings.
Replace test_rpcwhitelistdefault_0_no_permissions and test_rpcwhitelistdefault_1_no_permissions with a single test_rpcwhitelistdefault_permissions function.
This affects docs of the following RPCs: `bumpfee`, `psbtbumpfee`, `send`, `walletcreatefundedpsbt`, `createpsbt`, and `createrawtransaction` It was not evident to me that this field creates an `OP_RETURN` output until I read the code and tried it out. Thus, making the doc explicitly mention it.
Update the example wherein the PSBT sends bitcoin to an address instead of creating an OP_RETURN output. Also, update the RPC description to reflect the fact that the created transaction is unsigned.
This change stresses that all ZMQ messages share the same structure and that they differ only in the format of the bodies. Previously this was not clear. Further it removes the notion of endianness of 32-byte hashes, as it was misleading, and replaces it with the term 'reversed byte order' (as opposed to natural or normal byte order produced by hashing functions). Additionally, it states that ZMQ 32-byte hashes are in the same format as in RPC. Previously it incorrectly stated that the two were in different formats.
The benchmark was referencing the old name of the method
This hardware feature is - rarely supported on SoCs (and broken on like half of the chips that support it in the first place) (bitcoin#31817) - apparently not compiled into the release binary (bitcoin#31817 (comment)) - hard to test in CI, due to unavailable of hardware Better to remove it. This reverts commit aee5404. Closes bitcoin#31817.
According to https://wiki.debian.org/DebianReleases#Production_Releases, the current image will be EOL in about one year, so it seems fine to slowly bump it to something more recent.
Currently, the lint_test_runner is built and installed into the lint CI image. This is problematic, because it triggers a full image build on every change to its source code. Doing a build of the lint test_runner on every run is easier and faster.
Reorganized error handling in block-related operations by grouping related operations together within the same scope. In `ReadBlockUndo()` and `ReadBlock()`, moved all deserialization operations, comments and checksum verification inside a single try/catch block for cleaner error handling. In `WriteBlockUndo()`, consolidated hash calculation and data writing operations within a common block to better express their logical relationship.
…issue
`AutoFile{OpenUndoFile(pos)}` was still in scope when `FlushUndoFile(pos.nFile)` was called, which could lead to file handle conflicts or other unexpected behavior.
Co-authored-by: Hodlinator <[email protected]>
Co-authored-by: maflcko <[email protected]>
Renames the constant to be less verbose and better reflect its purpose: it represents the size of the storage header that precedes serialized block data on disk, not to be confused with a block's own header. -BEGIN VERIFY SCRIPT- git grep -q "STORAGE_HEADER_BYTES" $(git ls-files) && echo "Error: Target name STORAGE_HEADER_BYTES already exists in the codebase" && exit 1 sed -i 's/BLOCK_SERIALIZATION_HEADER_SIZE/STORAGE_HEADER_BYTES/g' $(git grep -l 'BLOCK_SERIALIZATION_HEADER_SIZE') -END VERIFY SCRIPT-
Co-authored-by: maflcko <[email protected]>
Made every OpenBlockFile#fReadOnly value explicit. Replaced hard-coded values in ReadRawBlock with STORAGE_HEADER_BYTES. Changed `STORAGE_HEADER_BYTES` and `UNDO_DATA_DISK_OVERHEAD` to `uint32_t` to avoid casts. Also added `LIFETIMEBOUND` to the `AutoFile` parameter of `BufferedFile`, which stores a reference to the underlying `AutoFile`, allowing Clang to emit warnings if the referenced `AutoFile` might be destroyed while `BufferedFile` still exists. Without this attribute, code with lifetime violations wouldn't trigger compiler warnings. Co-authored-by: maflcko <[email protected]>
The obfuscation (XOR) operations are currently done byte-by-byte during serialization. Buffering the reads will enable batching the obfuscation operations later. Different operating systems handle file caching differently, so reading larger batches (and processing them from memory) is measurably faster, likely because of fewer native fread calls and reduced lock contention. Note that `ReadRawBlock` doesn't need buffering since it already reads the whole block directly. Unlike `ReadBlockUndo`, the new `ReadBlock` implementation delegates to `ReadRawBlock`, which uses more memory than a buffered alternative but results in slightly simpler code and a small performance increase (~0.4%). This approach also clearly documents that `ReadRawBlock` is a logical subset of `ReadBlock` functionality. The current implementation, which iterates over a fixed-size buffer, provides a more general alternative to Cory Fields' solution of reading the entire block size in advance. Buffer sizes were selected based on benchmarking to ensure the buffered reader produces performance similar to reading the whole block into memory. Smaller buffers were slower, while larger ones showed diminishing returns. ------ > macOS Sequoia 15.3.1 > C++ compiler .......................... Clang 19.1.7 > cmake -B build -DBUILD_BENCH=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ && cmake --build build -j$(nproc) && build/bin/bench_bitcoin -filter='ReadBlockBench' -min-time=10000 Before: | ns/op | op/s | err% | total | benchmark |--------------------:|--------------------:|--------:|----------:|:---------- | 2,271,441.67 | 440.25 | 0.1% | 11.00 | `ReadBlockBench` After: | ns/op | op/s | err% | total | benchmark |--------------------:|--------------------:|--------:|----------:|:---------- | 1,738,971.29 | 575.05 | 0.2% | 10.97 | `ReadBlockBench` ------ > Ubuntu 24.04.2 LTS > C++ compiler .......................... GNU 13.3.0 > cmake -B build -DBUILD_BENCH=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ && cmake --build build -j$(nproc) && build/bin/bench_bitcoin -filter='ReadBlockBench' -min-time=20000 Before: | ns/op | op/s | err% | ins/op | cyc/op | IPC | bra/op | miss% | total | benchmark |--------------------:|--------------------:|--------:|----------------:|----------------:|-------:|---------------:|--------:|----------:|:---------- | 6,895,987.11 | 145.01 | 0.0% | 71,055,269.86 | 23,977,374.37 | 2.963 | 5,074,828.78 | 0.4% | 22.00 | `ReadBlockBench` After: | ns/op | op/s | err% | ins/op | cyc/op | IPC | bra/op | miss% | total | benchmark |--------------------:|--------------------:|--------:|----------------:|----------------:|-------:|---------------:|--------:|----------:|:---------- | 5,771,882.71 | 173.25 | 0.0% | 65,741,889.82 | 20,453,232.33 | 3.214 | 3,971,321.75 | 0.3% | 22.01 | `ReadBlockBench` Co-authored-by: maflcko <[email protected]> Co-authored-by: Ryan Ofsky <[email protected]> Co-authored-by: Martin Leitner-Ankerl <[email protected]> Co-authored-by: Cory Fields <[email protected]>
…eBlock` Similarly to the serialization reads optimization, buffered writes will enable batched XOR calculations. This is especially beneficial since the current implementation requires copying the write input's `std::span` to perform obfuscation. Batching allows us to apply XOR operations on the internal buffer instead, reducing unnecessary data copying and improving performance. ------ > macOS Sequoia 15.3.1 > C++ compiler .......................... Clang 19.1.7 > cmake -B build -DBUILD_BENCH=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ && cmake --build build -j$(nproc) && build/bin/bench_bitcoin -filter='WriteBlockBench' -min-time=10000 Before: | ns/op | op/s | err% | total | benchmark |--------------------:|--------------------:|--------:|----------:|:---------- | 5,149,564.31 | 194.19 | 0.8% | 10.95 | `WriteBlockBench` After: | ns/op | op/s | err% | total | benchmark |--------------------:|--------------------:|--------:|----------:|:---------- | 2,990,564.63 | 334.39 | 1.5% | 11.27 | `WriteBlockBench` ------ > Ubuntu 24.04.2 LTS > C++ compiler .......................... GNU 13.3.0 > cmake -B build -DBUILD_BENCH=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ && cmake --build build -j$(nproc) && build/bin/bench_bitcoin -filter='WriteBlockBench' -min-time=20000 Before: | ns/op | op/s | err% | ins/op | cyc/op | IPC | bra/op | miss% | total | benchmark |--------------------:|--------------------:|--------:|----------------:|----------------:|-------:|---------------:|--------:|----------:|:---------- | 5,152,973.58 | 194.06 | 2.2% | 19,350,886.41 | 8,784,539.75 | 2.203 | 3,079,335.21 | 0.4% | 23.18 | `WriteBlockBench` After: | ns/op | op/s | err% | ins/op | cyc/op | IPC | bra/op | miss% | total | benchmark |--------------------:|--------------------:|--------:|----------------:|----------------:|-------:|---------------:|--------:|----------:|:---------- | 4,145,681.13 | 241.21 | 4.0% | 15,337,596.85 | 5,732,186.47 | 2.676 | 2,239,662.64 | 0.1% | 23.94 | `WriteBlockBench` Co-authored-by: Ryan Ofsky <[email protected]> Co-authored-by: Cory Fields <[email protected]>
This includes a cmake documentation change suggested bitcoin#31741 (comment) and another change to mention the option in markdown documentation Co-authored-by: Cory Fields <[email protected]>
Also, remove the minor version from the comment, because it does not matter and may even change at any time.
l0rinc
force-pushed
the
detached96
branch
7 times, most recently
from
5adc7f9 to
39b6ee1
Compare
l0rinc
force-pushed
the
detached96
branch
2 times, most recently
from
1cdddee to
ab27b41
Compare
The keys and scripts created for the Legacy Wallet needed to be persisted in order for the migration to work properly.
7749d92 Remove support for RNDR/RNDRRS for aarch64 on Linux (laanwj) Pull request description: This hardware feature is - Rarely supported on SoCs (and broken on like half of the chips that support it in the first place) (bitcoin#31817). It is not clear if, or how, the brokenness will be worked around in the kernel, but working around it in user space seems the wrong thing to do, this is not the place to maintain special workarounds for specific hardware (which despite that, was attempted in bitcoin#31826, but had to be reverted in bitcoin#31908 due to other problems). - Apparently not compiled into the release binary anymore (bitcoin#31817 (comment)). Did check this at the time, but a build system change must have caused this, and went undetected. - Hard to test in CI (as well as manually), due to unavailability of hardware. Better to remove it. This reverts commit aee5404 from bitcoin#26839. Closes bitcoin#31817. ACKs for top commit: sipa: utACK 7749d92 davidgumberg: utACK bitcoin@7749d92 achow101: ACK 7749d92 w0xlt: utACK bitcoin@7749d92 Tree-SHA512: d243ad7f745fb46f711f24b6983d9ea1d94e5d8ee60959229bafdba5caa210a60801a1c2cb5b558a0e72f365371b32285aee9a8d0cd24a60589adc7b03dd6a44
32dcec2 rpc: update RPC help of `createpsbt` (rkrux) 931117a rpc: update the doc for `data` field in `outputs` argument (rkrux) 8134a6b rpc: add cli example for `walletcreatefundedpsbt` RPC (rkrux) Pull request description: ### add cli example for `walletcreatefundedpsbt` and `createpsbt` RPCs The only example present earlier was one that creates an OP_RETURN output. This lack of examples has discouraged me earlier to use this RPC. Adding an example that creates PSBT sending bitcoin to address, a scenario that is much more common. ### rpc: update the doc for `data` field in `outputs` argument It was not evident to me that this field creates an `OP_RETURN` output until I read the code and tried it out. Thus, making the doc explicitly mention it. This affects docs of the following RPCs: `bumpfee`, `psbtbumpfee`, `send`, `walletcreatefundedpsbt`, `createpsbt`, and `createrawtransaction` ACKs for top commit: sipa: utACK 32dcec2 1440000bytes: utACK bitcoin@32dcec2 achow101: ACK 32dcec2 ryanofsky: Concept ACK 32dcec2. These seem like helpful clarifications, but I did not look into the details Tree-SHA512: f994488ba7d52d00960fc52064bb419cf548e29822fe23d6ee0452fdf514dd93f089145eddb32b8086a7918cf8cf33a4c3f16bfcb7948f3c9d5afd95e8d3a1cb
… serialization 8d801e3 optimization: bulk serialization writes in `WriteBlockUndo` and `WriteBlock` (Lőrinc) 520965e optimization: bulk serialization reads in `UndoRead`, `ReadBlock` (Lőrinc) 056cb3c refactor: clear up blockstorage/streams in preparation for optimization (Lőrinc) 67fcc64 log: unify error messages for (read/write)[undo]block (Lőrinc) a4de160 scripted-diff: shorten BLOCK_SERIALIZATION_HEADER_SIZE constant (Lőrinc) 6640dd5 Narrow scope of undofile write to avoid possible resource management issue (Lőrinc) 3197155 refactor: collect block read operations into try block (Lőrinc) c77e310 refactor: rename leftover WriteBlockBench (Lőrinc) Pull request description: This change is part of [[IBD] - Tracking PR for speeding up Initial Block Download](bitcoin#32043) ### Summary We can serialize the blocks and undos to any `Stream` which implements the appropriate read/write methods. `AutoFile` is one of these, writing the results "directly" to disk (through the OS file cache). Batching these in memory first and reading/writing these to disk is measurably faster (likely because of fewer native fread calls or less locking, as [observed](bitcoin#28226 (comment)) by Martinus in a similar change). ### Unlocking new optimization opportunities Buffered writes will also enable batched obfuscation calculations (implemented in bitcoin#31144) - especially since currently we need to copy the write input's std::span to do the obfuscation on it, and batching enables doing the operations on the internal buffer directly. ### Measurements (micro benchmarks, full IBDs and reindexes) Microbenchmarks for `[Read|Write]BlockBench` show a ~**30%**/**168%** speedup with `macOS/Clang`, and ~**19%**/**24%** with `Linux/GCC` (the follow-up XOR batching improves these further): <details> <summary>macOS Sequoia - Clang 19.1.7</summary> > Before: | ns/op | op/s | err% | total | benchmark |--------------------:|--------------------:|--------:|----------:|:---------- | 2,271,441.67 | 440.25 | 0.1% | 11.00 | `ReadBlockBench` | 5,149,564.31 | 194.19 | 0.8% | 10.95 | `WriteBlockBench` > After: | ns/op | op/s | err% | total | benchmark |--------------------:|--------------------:|--------:|----------:|:---------- | 1,738,683.04 | 575.15 | 0.2% | 11.04 | `ReadBlockBench` | 3,052,658.88 | 327.58 | 1.0% | 10.91 | `WriteBlockBench` </details> <details> <summary>Ubuntu 24 - GNU 13.3.0</summary> > Before: | ns/op | op/s | err% | ins/op | cyc/op | IPC | bra/op | miss% | total | benchmark |--------------------:|--------------------:|--------:|----------------:|----------------:|-------:|---------------:|--------:|----------:|:---------- | 6,895,987.11 | 145.01 | 0.0% | 71,055,269.86 | 23,977,374.37 | 2.963 | 5,074,828.78 | 0.4% | 22.00 | `ReadBlockBench` | 5,152,973.58 | 194.06 | 2.2% | 19,350,886.41 | 8,784,539.75 | 2.203 | 3,079,335.21 | 0.4% | 23.18 | `WriteBlockBench` > After: | ns/op | op/s | err% | ins/op | cyc/op | IPC | bra/op | miss% | total | benchmark |--------------------:|--------------------:|--------:|----------------:|----------------:|-------:|---------------:|--------:|----------:|:---------- | 5,771,882.71 | 173.25 | 0.0% | 65,741,889.82 | 20,453,232.33 | 3.214 | 3,971,321.75 | 0.3% | 22.01 | `ReadBlockBench` | 4,145,681.13 | 241.21 | 4.0% | 15,337,596.85 | 5,732,186.47 | 2.676 | 2,239,662.64 | 0.1% | 23.94 | `WriteBlockBench` </details> 2 full IBD runs against master (compiled with GCC where the gains seem more modest) for **888888** blocks (seeded from real nodes) indicates a ~**7%** total speedup. <details> <summary>Details</summary> ```bash COMMITS="d2b72b13699cf460ffbcb1028bcf5f3b07d3b73a 652b4e3"; \ STOP_HEIGHT=888888; DBCACHE=1000; \ C_COMPILER=gcc; CXX_COMPILER=g++; \ BASE_DIR="/mnt/my_storage"; DATA_DIR="$BASE_DIR/BitcoinData"; LOG_DIR="$BASE_DIR/logs"; \ (for c in $COMMITS; do git fetch origin $c -q && git log -1 --pretty=format:'%h %s' $c || exit 1; done) && \ hyperfine \ --sort 'command' \ --runs 2 \ --export-json "$BASE_DIR/ibd-${COMMITS// /-}-$STOP_HEIGHT-$DBCACHE-$C_COMPILER.json" \ --parameter-list COMMIT ${COMMITS// /,} \ --prepare "killall bitcoind; rm -rf $DATA_DIR/*; git checkout {COMMIT}; git clean -fxd; git reset --hard; \ cmake -B build -DCMAKE_BUILD_TYPE=Release -DENABLE_WALLET=OFF -DCMAKE_C_COMPILER=$C_COMPILER -DCMAKE_CXX_COMPILER=$CXX_COMPILER && \ cmake --build build -j$(nproc) --target bitcoind && \ ./build/bin/bitcoind -datadir=$DATA_DIR -stopatheight=1 -printtoconsole=0; sleep 100" \ --cleanup "cp $DATA_DIR/debug.log $LOG_DIR/debug-{COMMIT}-$(date +%s).log" \ "COMPILER=$C_COMPILER COMMIT=${COMMIT:0:10} ./build/bin/bitcoind -datadir=$DATA_DIR -stopatheight=$STOP_HEIGHT -dbcache=$DBCACHE -blocksonly -printtoconsole=0" d2b72b1 refactor: rename leftover WriteBlockBench 652b4e3 optimization: Bulk serialization writes in `WriteBlockUndo` and `WriteBlock` Benchmark 1: COMPILER=gcc ./build/bin/bitcoind -datadir=/mnt/my_storage/BitcoinData -stopatheight=888888 -dbcache=1000 -blocksonly -printtoconsole=0 (COMMIT = d2b72b1) Time (mean ± σ): 41528.104 s ± 354.003 s [User: 44324.407 s, System: 3074.829 s] Range (min … max): 41277.786 s … 41778.421 s 2 runs Benchmark 2: COMPILER=gcc ./build/bin/bitcoind -datadir=/mnt/my_storage/BitcoinData -stopatheight=888888 -dbcache=1000 -blocksonly -printtoconsole=0 (COMMIT = 652b4e3) Time (mean ± σ): 38771.457 s ± 441.941 s [User: 41930.651 s, System: 3222.664 s] Range (min … max): 38458.957 s … 39083.957 s 2 runs Relative speed comparison 1.07 ± 0.02 COMPILER=gcc ./build/bin/bitcoind -datadir=/mnt/my_storage/BitcoinData -stopatheight=888888 -dbcache=1000 -blocksonly -printtoconsole=0 (COMMIT = d2b72b1) 1.00 COMPILER=gcc ./build/bin/bitcoind -datadir=/mnt/my_storage/BitcoinData -stopatheight=888888 -dbcache=1000 -blocksonly -printtoconsole=0 (COMMIT = 652b4e3) ``` </details> ACKs for top commit: maflcko: re-ACK 8d801e3 🐦 achow101: ACK 8d801e3 ryanofsky: Code review ACK 8d801e3. Most notable change is switching from BufferedReader to ReadRawBlock for block reads, which makes sense, and there are also various cleanups in blockstorage and test code. hodlinator: re-ACK 8d801e3 Tree-SHA512: 24e1dee653b927b760c0ba3c69d1aba15fa5d9c4536ad11cfc2d70196ae16b9228ecc3056eef70923364257d72dc929882e73e69c6c426e28139d31299d08adc
…e in RPC tests a4041c7 test: Handle empty string returned by CLI as None in RPC tests (Brandon Odiwuor) Pull request description: Partially Fixes bitcoin#32264 Some tests are failing when `bitcoin-cli` returns an empty string. This change treats an empty response as `None`. See bitcoin#32264 (comment) This fixes the error for: - feature_bip68_sequence.py - feature_nulldummy.py - feature_signet.py - mining_mainnet.py - rpc_scanblocks.py - rpc_scantxoutset.py - wallet_descriptor.py --descriptors ACKs for top commit: maflcko: lgtm ACK a4041c7 achow101: ACK a4041c7 pablomartin4btc: ACK a4041c7 mzumsande: ACK a4041c7 Tree-SHA512: 2f1a416a18e0b3eebdb014c2e2e8dadf1d46b15c231cb61f577d47f5e551994ab0e2aeb7c179c01be7c1f07ebc03476236d29cf2d04c358ffb1fae985aa385c9
…when unset 2929da1 test: Add coverage for rpcwhitelistdefault when unset (naiyoma) 535b874 test: Combine rpcwhitelistdefault functions (naiyoma) 2b6ce92 test: Update permissions and string formatting (naiyoma) Pull request description: This is a follow-up PR to address review feedback from [https://github.com/bitcoin/bitcoin/pull/29858](https://github.com/bitcoin/bitcoin/pull/29858) - [x] add case where rpcwhitelistdefault setting is [unset](bitcoin#29858 (review)) - [x] Code [cleanup](bitcoin#29858 (comment)) , change password and f-string formatting - [x] [Combine](bitcoin#29858 (comment)) rpcwhitelistdefault tests into `test_rpcwhitelistdefault_permissions` I am not sure if my approach of adding` test_rpcwhitelistdefault_unset` is better or if I should just include the assertions in the existing `test_rpcwhitelistdefault_permissions` ACKs for top commit: w0xlt: Code review ACK bitcoin@2929da1 achow101: ACK 2929da1 ryanofsky: Code review ACK 2929da1. Only change since last review was simplifying the last commit as suggested Tree-SHA512: 6750dd3e6abaca3a09ad1fd5d07c64767bc59188ff953cbc26aa7796071774cb92745ac82cf91e479632d682fd450bc00d53032454b65b22654a3e770ec68e89
…format 7a93544 doc: Fix and clarify description of ZMQ message format (Jiri Jakes) Pull request description: This change stresses that all ZMQ messages share the same structure and that they differ only in the format of the bodies. Previously this was not clear. Further it removes the notion of endianness of 32-byte hashes, as it was misleading, and replaces it with the term 'reversed byte order' (as opposed to natural or normal byte order produced by hashing functions). Additionally, it states that ZMQ 32-byte hashes are in the same format as in RPC. Previously it incorrectly stated that the two were in different formats. [Rendered](https://github.com/jirijakes/bitcoin/blob/zmq-doc/doc/zmq.md). Fixes bitcoin#31856. ACKs for top commit: w0xlt: Code review ACK bitcoin@7a93544 achow101: ACK 7a93544 ryanofsky: Code review ACK 7a93544. Nice changes. Documentation seems less repetitive and easier to understand now Tree-SHA512: 8c5ab047c5fd9b5b6910d691b725886d7743dfd01510735b46e43d01c2d0d25ec52d79d71ec75dbeb142e96a88ad503d69ee14b971e3cdaeb8fd85e5292a8c21
7912cd4 bench: Fix WalletMigration benchmark (pablomartin4btc) Pull request description: The keys and scripts created for the Legacy Wallet needed to be persisted in order for the migration to work properly. Fixes bitcoin#32277. ACKs for top commit: achow101: ACK 7912cd4 davidgumberg: Tested ACK 7912cd4 furszy: utACK 7912cd4 Tree-SHA512: fe7b8e0a80d4d030ad3fd6446717ee09a260ab2bd6140bc817bdca52d233e3af8a8fed2d754743ca2ba022f7d2c8615a36b5070991d12942c13835e8f72e359f
So there's at least one CI sanity checking all benchmarks. Related to bitcoin#32277.
faeb1ba ci: refactor: Use version id over version codename consistently (MarcoFalke) fae322a ci: Slim down lint image (MarcoFalke) 3333273 ci: Bump lint imagefile FROM base (MarcoFalke) Pull request description: Currently, the lint_test_runner is built and installed into the lint CI image. This is problematic, because it triggers a full image build on every change to its source code. Doing a build of the lint test_runner on every run is easier and faster. ACKs for top commit: l0rinc: ACK faeb1ba janb84: Re- ACK [faeb1ba](bitcoin@faeb1ba) Tree-SHA512: 39103e61ec2587096213bc1ce55b80087f6f03775592827d8c96a366453b798570d912690bf96fde4685798e5fc8ee2695ce851f473b4c8782d1a4c50c65a594
27f1121 ci: drop -priority-level from bench in win cross CI (fanquake) Pull request description: So there's at least one CI sanity checking all benchmarks. Related to bitcoin#32277. ACKs for top commit: l0rinc: utACK 27f1121 hebasto: ACK 27f1121. mabu44: utACK 27f1121 Tree-SHA512: 4853584bf9db418f6e31aa0f558d08bc45479d672b193e1d25a25907f82fb225bc4388321f8f23286cd9fd9168c7546c713829607eb0cf5e3c62b98e88f8e68b
…d option better 9ccee9c doc: Document WITH_EXTERNAL_LIBMULTIPROCESS build option better (Ryan Ofsky) Pull request description: This includes a cmake documentation change suggested bitcoin#31741 (comment) and another change to mention the option in markdown documentation ACKs for top commit: hebasto: ACK 9ccee9c, changes look good. TheCharlatan: ACK 9ccee9c Tree-SHA512: c9103b001b970ac57afedc6dc384091f5661975d569573e93003cbd7df1891c54cefb06d7296eac5b9a5c57251803dcab2bd3b26c9d81aa476c62f211dcb3d6e
…_estimator target fa6a007 fuzz: Avoid integer sanitizer warnings in policy_estimator target (MarcoFalke) Pull request description: It seems odd to write a fuzz target to trigger integer sanitizer warnings in `CBlockPolicyEstimator::processBlockTx` and then suppress them. If the scenario can happen in reality, the code should be properly fixed to handle the cases. If not, it seems better to fix the fuzz target to not trigger meaningless traces. Do that here by keeping track of the current height and limiting mempool entries to at most this entry height. ACKs for top commit: brunoerg: ACK fa6a007 dergoegge: utACK fa6a007 Tree-SHA512: 2092017dc309fb095fe5d43cfb76efb691795f303d567ee919be2b5cac19a944293636229903dc4d1e8b9fe5daf9dc3058544321eff1735f91f804c3baa36cd0
l0rinc
force-pushed
the
detached96
branch
3 times, most recently
from
e6c6393 to
425a23c
Compare
Serialization casts back and forth between signed and unsigned - let's make it explicit and reenable the sanitizers
l0rinc
changed the title
InsecureRandomContext::rand64
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.