💬 fanquake commented on pull request "ci: use Mold linker for asan-lsan-ubsan-integer-no-depends-usdt workflow":
(https://github.com/bitcoin/bitcoin/pull/33370#issuecomment-3284429177)
These changes should be in `00_setup_env_native_asan.sh`.
(https://github.com/bitcoin/bitcoin/pull/33370#issuecomment-3284429177)
These changes should be in `00_setup_env_native_asan.sh`.
💬 nervana21 commented on issue "RFC: Formal description of the RPC API":
(https://github.com/bitcoin/bitcoin/issues/29912#issuecomment-3284438240)
I’m using the output from @casey’s `schema` RPC in a [project](https://github.com/nervana21/bitcoin-rpc-codegen) that generates Rust clients across versions of Core.
Because my project depends upon it, I'm maintaining a [branch](https://github.com/nervana21/bitcoin/tree/2025-07-schema-generation) with casey's patch applied.
If there’s interest in reviving this, I can help keep the output in sync with Core.
(https://github.com/bitcoin/bitcoin/issues/29912#issuecomment-3284438240)
I’m using the output from @casey’s `schema` RPC in a [project](https://github.com/nervana21/bitcoin-rpc-codegen) that generates Rust clients across versions of Core.
Because my project depends upon it, I'm maintaining a [branch](https://github.com/nervana21/bitcoin/tree/2025-07-schema-generation) with casey's patch applied.
If there’s interest in reviving this, I can help keep the output in sync with Core.
📝 Sjors opened a pull request: "mining: log failed blocks in submitSolution()"
(https://github.com/bitcoin/bitcoin/pull/33372)
Unlike the submitblock RPC which takes a fully serialized block, when a block solution is received via IPC the client only provides the nonce, coinbase and a few other fields to `submitSolution()`. It may not have all the information it needs to reconstruct the block. This makes debugging difficult when the block is invalid.
This commit therefore logs the fully serialized block if it's rejected. This is in addition to the failure reason logged by `ProcessNewBlock()`.
Example on a custom si
...
(https://github.com/bitcoin/bitcoin/pull/33372)
Unlike the submitblock RPC which takes a fully serialized block, when a block solution is received via IPC the client only provides the nonce, coinbase and a few other fields to `submitSolution()`. It may not have all the information it needs to reconstruct the block. This makes debugging difficult when the block is invalid.
This commit therefore logs the fully serialized block if it's rejected. This is in addition to the failure reason logged by `ProcessNewBlock()`.
Example on a custom si
...
💬 fanquake commented on issue "oss-fuzz: build failing":
(https://github.com/bitcoin/bitcoin/issues/33366#issuecomment-3284518541)
https://github.com/google/oss-fuzz/pull/13987
(https://github.com/bitcoin/bitcoin/issues/33366#issuecomment-3284518541)
https://github.com/google/oss-fuzz/pull/13987
💬 fanquake commented on pull request "ci: Skip Centos job on GHA runners":
(https://github.com/bitcoin/bitcoin/pull/33365#issuecomment-3284546897)
To be clear, this will start skipping the job in https://github.com/bitcoin-core/gui ?
(https://github.com/bitcoin/bitcoin/pull/33365#issuecomment-3284546897)
To be clear, this will start skipping the job in https://github.com/bitcoin-core/gui ?
💬 ajtowns commented on pull request "mining: log failed blocks in submitSolution()":
(https://github.com/bitcoin/bitcoin/pull/33372#issuecomment-3284604377)
> On mainnet this would be a huge message, but the IPC connection is trusted.
If this is for IPC, wouldn't it make more sense to return the value over IPC as part of an error response? Otherwise, having it be a LogDebug or even LogTrace seems more sensible?
(https://github.com/bitcoin/bitcoin/pull/33372#issuecomment-3284604377)
> On mainnet this would be a huge message, but the IPC connection is trusted.
If this is for IPC, wouldn't it make more sense to return the value over IPC as part of an error response? Otherwise, having it be a LogDebug or even LogTrace seems more sensible?
💬 Sjors commented on pull request "mining: log failed blocks in submitSolution()":
(https://github.com/bitcoin/bitcoin/pull/33372#issuecomment-3284678151)
@ajtowns currently the return value is a boolean. I could indeed change it to return both a boolean and a string. But ideally I'd like to back port this to v30, so keeping it as simple as possible without changing the interface.
I picked `LogInfo` because, especially on mainnet, the information seems critical enough to log by default.
(https://github.com/bitcoin/bitcoin/pull/33372#issuecomment-3284678151)
@ajtowns currently the return value is a boolean. I could indeed change it to return both a boolean and a string. But ideally I'd like to back port this to v30, so keeping it as simple as possible without changing the interface.
I picked `LogInfo` because, especially on mainnet, the information seems critical enough to log by default.
💬 stickies-v commented on pull request "rpc: refactor: use string_view in Arg/MaybeArg":
(https://github.com/bitcoin/bitcoin/pull/32983#discussion_r2343793451)
Will do if I force-push, but they are aliases so there should be no safety difference, and afaik the project also hasn't stated a preference to phase one out, although I personally tend to use and prefer `tfm::format`.
(https://github.com/bitcoin/bitcoin/pull/32983#discussion_r2343793451)
Will do if I force-push, but they are aliases so there should be no safety difference, and afaik the project also hasn't stated a preference to phase one out, although I personally tend to use and prefer `tfm::format`.
💬 stickies-v commented on pull request "rpc: refactor: use string_view in Arg/MaybeArg":
(https://github.com/bitcoin/bitcoin/pull/32983#discussion_r2343800487)
Yeah you're probably right, will change if I force push, but I feel like this is close to merge and the PR has been open for a while so gonna minimize nit force pushes. Thanks for your review!
(https://github.com/bitcoin/bitcoin/pull/32983#discussion_r2343800487)
Yeah you're probably right, will change if I force push, but I feel like this is close to merge and the PR has been open for a while so gonna minimize nit force pushes. Thanks for your review!
🚀 fanquake merged a pull request: "trace: Workaround GCC bug compiling with old systemtap"
(https://github.com/bitcoin/bitcoin/pull/33310)
(https://github.com/bitcoin/bitcoin/pull/33310)
💬 fanquake commented on pull request "trace: Workaround GCC bug compiling with old systemtap":
(https://github.com/bitcoin/bitcoin/pull/33310#issuecomment-3284792505)
Backported to 30.x in #33356.
(https://github.com/bitcoin/bitcoin/pull/33310#issuecomment-3284792505)
Backported to 30.x in #33356.
💬 fanquake commented on pull request "trace: Workaround GCC bug compiling with old systemtap":
(https://github.com/bitcoin/bitcoin/pull/33310#issuecomment-3284796811)
Backported to 29.x in #33344.
(https://github.com/bitcoin/bitcoin/pull/33310#issuecomment-3284796811)
Backported to 29.x in #33344.
📝 fanquake opened a pull request: "depends: systemtap 5.3"
(https://github.com/bitcoin/bitcoin/pull/33373)
The diff in the copied header is:
```diff
< #if __STDC_VERSION__ >= 199901L
---
> #if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
```
From
https://sourceware.org/git/?p=systemtap.git;a=commit;h=b8345d8e07b725a943a97b19aa4866e74baadd98.
(https://github.com/bitcoin/bitcoin/pull/33373)
The diff in the copied header is:
```diff
< #if __STDC_VERSION__ >= 199901L
---
> #if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
```
From
https://sourceware.org/git/?p=systemtap.git;a=commit;h=b8345d8e07b725a943a97b19aa4866e74baadd98.
📝 Sjors opened a pull request: "mining: add applySolution() to interface"
(https://github.com/bitcoin/bitcoin/pull/33374)
Unlike the submitblock RPC which takes a fully serialized block, when a block solution is received via IPC the client only provides the nonce, coinbase and a few other fields. It may not have all the information it needs to reconstruct the block. This makes debugging difficult when the block is invalid.
This commit adds `applySolution()` which returns the reconstructed block and can be used by the client for debugging. It's assigned `@11` in the `.cap` file, and will not break existing client
...
(https://github.com/bitcoin/bitcoin/pull/33374)
Unlike the submitblock RPC which takes a fully serialized block, when a block solution is received via IPC the client only provides the nonce, coinbase and a few other fields. It may not have all the information it needs to reconstruct the block. This makes debugging difficult when the block is invalid.
This commit adds `applySolution()` which returns the reconstructed block and can be used by the client for debugging. It's assigned `@11` in the `.cap` file, and will not break existing client
...
💬 Sjors commented on pull request "mining: log failed blocks in submitSolution()":
(https://github.com/bitcoin/bitcoin/pull/33372#issuecomment-3284967478)
I opened #33374 as an alternative or complimentary approach.
(https://github.com/bitcoin/bitcoin/pull/33372#issuecomment-3284967478)
I opened #33374 as an alternative or complimentary approach.
💬 fanquake commented on pull request "depends: systemtap 5.3":
(https://github.com/bitcoin/bitcoin/pull/33373#issuecomment-3285067079)
Guix Build:
```bash
860c39a3db7eb7e8aaf8165cd6834d2fd87afc69b82b20203a013c7ad7e7b057 guix-build-28efd724b478/output/aarch64-linux-gnu/SHA256SUMS.part
841aea1c04fd996bc437ae0d7a59f4e7feb52a21c0d810489aa87654c38d7b55 guix-build-28efd724b478/output/aarch64-linux-gnu/bitcoin-28efd724b478-aarch64-linux-gnu-debug.tar.gz
1b5fee5de6da1981518dd6c04542e0194a810abe9911ee4844f9c8c546279b6a guix-build-28efd724b478/output/aarch64-linux-gnu/bitcoin-28efd724b478-aarch64-linux-gnu.tar.gz
43d8427e5b93fb90
...
(https://github.com/bitcoin/bitcoin/pull/33373#issuecomment-3285067079)
Guix Build:
```bash
860c39a3db7eb7e8aaf8165cd6834d2fd87afc69b82b20203a013c7ad7e7b057 guix-build-28efd724b478/output/aarch64-linux-gnu/SHA256SUMS.part
841aea1c04fd996bc437ae0d7a59f4e7feb52a21c0d810489aa87654c38d7b55 guix-build-28efd724b478/output/aarch64-linux-gnu/bitcoin-28efd724b478-aarch64-linux-gnu-debug.tar.gz
1b5fee5de6da1981518dd6c04542e0194a810abe9911ee4844f9c8c546279b6a guix-build-28efd724b478/output/aarch64-linux-gnu/bitcoin-28efd724b478-aarch64-linux-gnu.tar.gz
43d8427e5b93fb90
...
💬 willcl-ark commented on pull request "coins: warn on oversized `-dbcache`":
(https://github.com/bitcoin/bitcoin/pull/33333#issuecomment-3285116096)
> You mean that the uxto size is less than 48 GiB therefore the warning isn't relevant?
What I mean is, we are warning when system ram is below <various_sizes> with the %-based scheme. Why should <1.5GB free emit a warning on some systems, and < 16GB free emit a warning on others? I get that it's a best-effort algorithm approach, but just not convinced that it makes the most sense.
For example, did you consider just warning if it would leave <1.5GB free on all systems, and if so why choose
...
(https://github.com/bitcoin/bitcoin/pull/33333#issuecomment-3285116096)
> You mean that the uxto size is less than 48 GiB therefore the warning isn't relevant?
What I mean is, we are warning when system ram is below <various_sizes> with the %-based scheme. Why should <1.5GB free emit a warning on some systems, and < 16GB free emit a warning on others? I get that it's a best-effort algorithm approach, but just not convinced that it makes the most sense.
For example, did you consider just warning if it would leave <1.5GB free on all systems, and if so why choose
...
💬 ajtowns commented on pull request "RFC: blocks: add `-reobfuscate-blocks` arg to xor existing blk/rev on startup":
(https://github.com/bitcoin/bitcoin/pull/33324#discussion_r2344113580)
Loading a large file entirely into memory when it's not necessary is just bad practice. What if we changed to .blk files of 1GB each? What if we're running on a node that's memory constrained and configured dbcache down to 4MB?
If we're worried about speed, then doing it in parallel helps on my system since obfuscation ends up CPU bound when single-threaded -- with the current code, it takes 238s (4min); with 8 threads it's 65s; with 16 threads it's 47s. Using 16MB chunks (BLOCKFILE_CHUNK_SIZ
...
(https://github.com/bitcoin/bitcoin/pull/33324#discussion_r2344113580)
Loading a large file entirely into memory when it's not necessary is just bad practice. What if we changed to .blk files of 1GB each? What if we're running on a node that's memory constrained and configured dbcache down to 4MB?
If we're worried about speed, then doing it in parallel helps on my system since obfuscation ends up CPU bound when single-threaded -- with the current code, it takes 238s (4min); with 8 threads it's 65s; with 16 threads it's 47s. Using 16MB chunks (BLOCKFILE_CHUNK_SIZ
...
💬 vasild commented on pull request "p2p: Advance pindexLastCommonBlock early after connecting blocks":
(https://github.com/bitcoin/bitcoin/pull/32180#discussion_r2344157017)
Looks like, according to `git range-diff b7ff6a611a...3bdff9a154`, this and the suggestion above were reverted in the latest push? If that was not intentional, then maybe amend this change in the latest commit:
```diff
--- i/test/functional/p2p_ibd_stalling.py
+++ w/test/functional/p2p_ibd_stalling.py
@@ -63,29 +63,30 @@ class P2PIBDStallingTest(BitcoinTestFramework):
blocks.append(create_block(tip, create_coinbase(height), block_time))
blocks[-1].solve()
...
(https://github.com/bitcoin/bitcoin/pull/32180#discussion_r2344157017)
Looks like, according to `git range-diff b7ff6a611a...3bdff9a154`, this and the suggestion above were reverted in the latest push? If that was not intentional, then maybe amend this change in the latest commit:
```diff
--- i/test/functional/p2p_ibd_stalling.py
+++ w/test/functional/p2p_ibd_stalling.py
@@ -63,29 +63,30 @@ class P2PIBDStallingTest(BitcoinTestFramework):
blocks.append(create_block(tip, create_coinbase(height), block_time))
blocks[-1].solve()
...
⚠️ Raimo33 opened an issue: "bench: unrealistic ConnectBlock benchmarks"
(https://github.com/bitcoin/bitcoin/issues/33375)
The current `ConnectBlock` benchmarks in `bench/connectblock.cpp` do not reflect realistic mainnet workloads due to three key issues:
#### 1. Unrealistic block composition
Every benchmarked block is constructed with a highly artificial transaction pattern:
```c
/*
* - Each transaction has the same number of inputs and outputs
* - All Taproot inputs use simple key path spends (no script path spends)
* - All signatures use SIGHASH_ALL (default sighash)
* - Each transaction spends all output
...
(https://github.com/bitcoin/bitcoin/issues/33375)
The current `ConnectBlock` benchmarks in `bench/connectblock.cpp` do not reflect realistic mainnet workloads due to three key issues:
#### 1. Unrealistic block composition
Every benchmarked block is constructed with a highly artificial transaction pattern:
```c
/*
* - Each transaction has the same number of inputs and outputs
* - All Taproot inputs use simple key path spends (no script path spends)
* - All signatures use SIGHASH_ALL (default sighash)
* - Each transaction spends all output
...