💬 TheCharlatan commented on pull request "kernel: Introduce initial C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2326052516)
The handle type is not exposed to the user (other than being defined in the header), so I don't think it matters that much. I think I prefer the current approach though, since the difference between the two is pretty clear. I think there is a decent reason why would not want to copy a `ContextOptions`: We transfer potential ownership of a user-space object to it, which could be a double free if we just copy it to another object. We could make it a shared pointer internally, but then it might als
...
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2326052516)
The handle type is not exposed to the user (other than being defined in the header), so I don't think it matters that much. I think I prefer the current approach though, since the difference between the two is pretty clear. I think there is a decent reason why would not want to copy a `ContextOptions`: We transfer potential ownership of a user-space object to it, which could be a double free if we just copy it to another object. We could make it a shared pointer internally, but then it might als
...
💬 TheCharlatan commented on pull request "kernel: Introduce initial C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#issuecomment-3259751728)
Thank you for the review @stickies-v! Took most of your suggestions and added a few minor additional cleanups.
82c503641a3a848234bba5c9979b9c4df5e53ea7 -> 89f9518af5c92a5daac49b9ed4b8b9ad81c2c354 ([kernelApi_62](https://github.com/TheCharlatan/bitcoin/tree/kernelApi_62) -> [kernelApi_63](https://github.com/TheCharlatan/bitcoin/tree/kernelApi_63), [compare](https://github.com/TheCharlatan/bitcoin/compare/kernelApi_62..kernelApi_63))
* Addressed @stickies-v's [comment](https://github.com/bit
...
(https://github.com/bitcoin/bitcoin/pull/30595#issuecomment-3259751728)
Thank you for the review @stickies-v! Took most of your suggestions and added a few minor additional cleanups.
82c503641a3a848234bba5c9979b9c4df5e53ea7 -> 89f9518af5c92a5daac49b9ed4b8b9ad81c2c354 ([kernelApi_62](https://github.com/TheCharlatan/bitcoin/tree/kernelApi_62) -> [kernelApi_63](https://github.com/TheCharlatan/bitcoin/tree/kernelApi_63), [compare](https://github.com/TheCharlatan/bitcoin/compare/kernelApi_62..kernelApi_63))
* Addressed @stickies-v's [comment](https://github.com/bit
...
💬 davidgumberg commented on pull request "test: fix p2p_leak_tx.py":
(https://github.com/bitcoin/bitcoin/pull/33121#issuecomment-3259772527)
> If `NextInvToInbounds` doesn't fire, we should just get no inv and the `wait_until` should fail (I also used 120s timeout here to make that less likely), but if we receive an inv, shouldn't it always contain the wtxid?
My understanding of [`Peer::TxRelay::m_tx_inventory_known_filter`](https://github.com/bitcoin/bitcoin/blob/e04cb9c1bdf2199127cc8cf9c87f25e46b8cac7b/src/net_processing.cpp#L297-L300) is that it will [occasionally indicate](https://github.com/bitcoin/bitcoin/blob/e04cb9c1bdf219
...
(https://github.com/bitcoin/bitcoin/pull/33121#issuecomment-3259772527)
> If `NextInvToInbounds` doesn't fire, we should just get no inv and the `wait_until` should fail (I also used 120s timeout here to make that less likely), but if we receive an inv, shouldn't it always contain the wtxid?
My understanding of [`Peer::TxRelay::m_tx_inventory_known_filter`](https://github.com/bitcoin/bitcoin/blob/e04cb9c1bdf2199127cc8cf9c87f25e46b8cac7b/src/net_processing.cpp#L297-L300) is that it will [occasionally indicate](https://github.com/bitcoin/bitcoin/blob/e04cb9c1bdf219
...
💬 Crypt-iQ commented on pull request "fuzz: compact block harness":
(https://github.com/bitcoin/bitcoin/pull/33300#issuecomment-3259826186)
I was able to get AFL++ multi-core fuzzing to work by adding a static `FuzzedDirectoryWrapper` instance that deletes the passed path in its destructor as well as using a random element to each statically named datadir. Each instance is in the high 98-99% stability and does not crash after hitting 100,000 iterations (yay). I was not able to use multiple `TestingSetup`s at the same time without causing several panics due to assertions about globals. I will fix the lint, tidy jobs and see if the de
...
(https://github.com/bitcoin/bitcoin/pull/33300#issuecomment-3259826186)
I was able to get AFL++ multi-core fuzzing to work by adding a static `FuzzedDirectoryWrapper` instance that deletes the passed path in its destructor as well as using a random element to each statically named datadir. Each instance is in the high 98-99% stability and does not crash after hitting 100,000 iterations (yay). I was not able to use multiple `TestingSetup`s at the same time without causing several panics due to assertions about globals. I will fix the lint, tidy jobs and see if the de
...
👋 hebasto's pull request is ready for review: "Release: 30.0 translations update"
(https://github.com/bitcoin/bitcoin/pull/33275)
(https://github.com/bitcoin/bitcoin/pull/33275)
💬 hebasto commented on pull request "Release: 30.0 translations update":
(https://github.com/bitcoin/bitcoin/pull/33275#issuecomment-3259983275)
Rebased. Updated.
Ready for review.
(https://github.com/bitcoin/bitcoin/pull/33275#issuecomment-3259983275)
Rebased. Updated.
Ready for review.
💬 hebasto commented on pull request "Avoid pathological QT text/markdown behavior...":
(https://github.com/bitcoin-core/gui/pull/886#issuecomment-3260012080)
Concept ACK.
(https://github.com/bitcoin-core/gui/pull/886#issuecomment-3260012080)
Concept ACK.
🚀 hebasto merged a pull request: "Fix compatibility with `-debuglogfile` command-line option"
(https://github.com/bitcoin-core/gui/pull/884)
(https://github.com/bitcoin-core/gui/pull/884)
⚠️ Bottegatecnologica opened an issue: "Potential systemic risk: OP_RETURN outputs as unintended governance signaling"
(https://github.com/bitcoin/bitcoin/issues/33323)
## Context
In `policy/policy.cpp`, inside `IsStandardTx`, OP_RETURN (NULL_DATA) outputs are limited in size (`nMaxDatacarrierBytes`, default 80 bytes). This effectively prevents arbitrarily large payloads but does not fully eliminate systemic risks from structured misuse.
## Description of risk
Even within the allowed size, OP_RETURN can be systematically repurposed as a signaling channel. For example:
- Each UTXO could embed a short marker in its OP_RETURN.
- These markers could be aggregated
...
(https://github.com/bitcoin/bitcoin/issues/33323)
## Context
In `policy/policy.cpp`, inside `IsStandardTx`, OP_RETURN (NULL_DATA) outputs are limited in size (`nMaxDatacarrierBytes`, default 80 bytes). This effectively prevents arbitrarily large payloads but does not fully eliminate systemic risks from structured misuse.
## Description of risk
Even within the allowed size, OP_RETURN can be systematically repurposed as a signaling channel. For example:
- Each UTXO could embed a short marker in its OP_RETURN.
- These markers could be aggregated
...
📝 l0rinc opened a pull request: "RFC: blocks: add `-reobfuscate-blocks` arg to xor existing blk/rev on startup"
(https://github.com/bitcoin/bitcoin/pull/33324)
### Draft for now - comments are welcome
* Should we repurpose the existing `-blocksxor` arg instead?
* Would multithreading help enough to justify the extra complexity (ordering, extra memory), given the current IO-bound profile?
* Should we split `ObfuscateBlocks` out of init?
* Which additional scenarios would you like covered in testing (resume mid-run, explicit 16-hex key path, large datadirs, pruned)?
* Release notes, translations?
* Given user concern about what they store on disk
...
(https://github.com/bitcoin/bitcoin/pull/33324)
### Draft for now - comments are welcome
* Should we repurpose the existing `-blocksxor` arg instead?
* Would multithreading help enough to justify the extra complexity (ordering, extra memory), given the current IO-bound profile?
* Should we split `ObfuscateBlocks` out of init?
* Which additional scenarios would you like covered in testing (resume mid-run, explicit 16-hex key path, large datadirs, pruned)?
* Release notes, translations?
* Given user concern about what they store on disk
...
💬 BenWestgate commented on pull request "doc: update multisig tutorial to use multipath descriptors":
(https://github.com/bitcoin/bitcoin/pull/33286#discussion_r2326489489)
Good idea. I moved that note to section 1.1, right before our snippet with sed. I'd rather explain it in words before the command.
(https://github.com/bitcoin/bitcoin/pull/33286#discussion_r2326489489)
Good idea. I moved that note to section 1.1, right before our snippet with sed. I'd rather explain it in words before the command.
💬 BenWestgate commented on pull request "doc: update multisig tutorial to use multipath descriptors":
(https://github.com/bitcoin/bitcoin/pull/33286#issuecomment-3260971981)
Thanks for the suggestion @Sjors. I've updated the test to use multi-path descriptors as well.
> Although not directly related to this PR, I have a minor suggestion: it might be helpful to add a loadwallet command for multisig_wallet_01, not just for participant wallets.
I agree it's a flaw to not load multisig_wallet_01 so I added it to this PR, we'll see if that's OK or reviewers want it in a separate commit or PR.
(https://github.com/bitcoin/bitcoin/pull/33286#issuecomment-3260971981)
Thanks for the suggestion @Sjors. I've updated the test to use multi-path descriptors as well.
> Although not directly related to this PR, I have a minor suggestion: it might be helpful to add a loadwallet command for multisig_wallet_01, not just for participant wallets.
I agree it's a flaw to not load multisig_wallet_01 so I added it to this PR, we'll see if that's OK or reviewers want it in a separate commit or PR.
💬 purpleKarrot commented on pull request "stabilize translations by reverting old ids by text content":
(https://github.com/bitcoin/bitcoin/pull/33270#issuecomment-3261215698)
> do we really want to do that :)? I don't...
I would do It, but I am concerned about the bus factor, so I would prefer to train someone else.
05255d5d1ec1852d8d8d7683ccbf28351f57b89e is an example for replacing a sed replacement with cmake code.
(https://github.com/bitcoin/bitcoin/pull/33270#issuecomment-3261215698)
> do we really want to do that :)? I don't...
I would do It, but I am concerned about the bus factor, so I would prefer to train someone else.
05255d5d1ec1852d8d8d7683ccbf28351f57b89e is an example for replacing a sed replacement with cmake code.
🤔 yuvicc reviewed a pull request: "kernel: make blockTip index const"
(https://github.com/bitcoin/bitcoin/pull/33321#pullrequestreview-3191698366)
Code review ACK 75d9b72475708ee0da13fb23ef65dcced805b6af
(https://github.com/bitcoin/bitcoin/pull/33321#pullrequestreview-3191698366)
Code review ACK 75d9b72475708ee0da13fb23ef65dcced805b6af
💬 Sjors commented on pull request "Update libmultiprocess subtree to improve build and logs":
(https://github.com/bitcoin/bitcoin/pull/33322#issuecomment-3261747558)
Windows error seems to be a failing download of one of the previous release binaries, but would be good to re-run it.
(https://github.com/bitcoin/bitcoin/pull/33322#issuecomment-3261747558)
Windows error seems to be a failing download of one of the previous release binaries, but would be good to re-run it.
💬 HowHsu commented on issue "-loadblock doesn't work":
(https://github.com/bitcoin/bitcoin/issues/33280#issuecomment-3261918000)
Some clarification about my steps below:
```
1. I first run bitcoind -prune=1024 -stopatheight=840000 -datadir=empty_dir, then there is some block files in empty_dir/blocks.
2. Then I copy empty_dir to empty_dir2, run bitcoind -prune=1024 -stopatheight=840050 -datadir=empty_dir2
Compare two blocks dir, I now have some blk.dat files relects height 840000 to 840050.
3. At last I copy empty_dir to empty_dir3, and run bitcoind -datadir=empty_dir3 -assumevalid=0 -prune=10240 -stopafterblockimport -n
...
(https://github.com/bitcoin/bitcoin/issues/33280#issuecomment-3261918000)
Some clarification about my steps below:
```
1. I first run bitcoind -prune=1024 -stopatheight=840000 -datadir=empty_dir, then there is some block files in empty_dir/blocks.
2. Then I copy empty_dir to empty_dir2, run bitcoind -prune=1024 -stopatheight=840050 -datadir=empty_dir2
Compare two blocks dir, I now have some blk.dat files relects height 840000 to 840050.
3. At last I copy empty_dir to empty_dir3, and run bitcoind -datadir=empty_dir3 -assumevalid=0 -prune=10240 -stopafterblockimport -n
...
💬 sipa commented on pull request "Add functional test for IPC interface":
(https://github.com/bitcoin/bitcoin/pull/33201#issuecomment-3261975263)
@Sjors Not magic, it needed a `--break-system-packages` instead of `--user` somewhere.
(https://github.com/bitcoin/bitcoin/pull/33201#issuecomment-3261975263)
@Sjors Not magic, it needed a `--break-system-packages` instead of `--user` somewhere.
💬 HowHsu commented on issue "-loadblock doesn't work":
(https://github.com/bitcoin/bitcoin/issues/33280#issuecomment-3262044272)
> Some clarification about my steps below:
>
> ```
>
> 1. I first run bitcoind -prune=1024 -stopatheight=840000 -datadir=empty_dir, then there is some block files in empty_dir/blocks.
> 2. Then I copy empty_dir to empty_dir2, run bitcoind -prune=1024 -stopatheight=840050 -datadir=empty_dir2
> Compare two blocks dir, I now have some blk.dat files relects height 840000 to 840050.
> 3. At last I copy empty_dir to empty_dir3, and run bitcoind -datadir=empty_dir3 -assumevalid=0 -prune=10240 -stopaf
...
(https://github.com/bitcoin/bitcoin/issues/33280#issuecomment-3262044272)
> Some clarification about my steps below:
>
> ```
>
> 1. I first run bitcoind -prune=1024 -stopatheight=840000 -datadir=empty_dir, then there is some block files in empty_dir/blocks.
> 2. Then I copy empty_dir to empty_dir2, run bitcoind -prune=1024 -stopatheight=840050 -datadir=empty_dir2
> Compare two blocks dir, I now have some blk.dat files relects height 840000 to 840050.
> 3. At last I copy empty_dir to empty_dir3, and run bitcoind -datadir=empty_dir3 -assumevalid=0 -prune=10240 -stopaf
...
💬 HowHsu commented on issue "-loadblock doesn't work":
(https://github.com/bitcoin/bitcoin/issues/33280#issuecomment-3262056024)
Reduced block ranges to only one file, run logs attached below.
```
bitcoind -datadir=datatmp -assumevalid=0 -prune=10240 -stopafterblockimport -networkactive=0 -noconnect -listen=0 -dnsseed=0 -dns=0 -loadblock=data840010/blocks/blk04241.dat -loadblock=data840010/blocks/blk04242.dat
2025-09-06T12:24:44Z Bitcoin Core version v29.99.0-unk (release build)
2025-09-06T12:24:44Z parameter interaction: -listen=0 -> setting -natpmp=0
2025-09-06T12:24:44Z parameter interaction: -listen=0 -> setting -disc
...
(https://github.com/bitcoin/bitcoin/issues/33280#issuecomment-3262056024)
Reduced block ranges to only one file, run logs attached below.
```
bitcoind -datadir=datatmp -assumevalid=0 -prune=10240 -stopafterblockimport -networkactive=0 -noconnect -listen=0 -dnsseed=0 -dns=0 -loadblock=data840010/blocks/blk04241.dat -loadblock=data840010/blocks/blk04242.dat
2025-09-06T12:24:44Z Bitcoin Core version v29.99.0-unk (release build)
2025-09-06T12:24:44Z parameter interaction: -listen=0 -> setting -natpmp=0
2025-09-06T12:24:44Z parameter interaction: -listen=0 -> setting -disc
...
💬 sipa commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#issuecomment-3262110826)
And with the addition of `SingletonClusterImpl`, overall mempool usage (determined by loading a `mempool.dat` from a long-running node into both (1) master and (2) #28676 + this PR), the mempool memusage/vsize ratio seems to have dropped ~4.5%, effectively increasing mempool size by that much:
Master:
```
"size": 58610,
"bytes": 28502050,
"usage": 173585008,
"total_fee": 0.05257629,
"maxmempool": 300000000,
```
Cluster mempool + this PR:
```
"size": 58348,
"bytes":
...
(https://github.com/bitcoin/bitcoin/pull/33157#issuecomment-3262110826)
And with the addition of `SingletonClusterImpl`, overall mempool usage (determined by loading a `mempool.dat` from a long-running node into both (1) master and (2) #28676 + this PR), the mempool memusage/vsize ratio seems to have dropped ~4.5%, effectively increasing mempool size by that much:
Master:
```
"size": 58610,
"bytes": 28502050,
"usage": 173585008,
"total_fee": 0.05257629,
"maxmempool": 300000000,
```
Cluster mempool + this PR:
```
"size": 58348,
"bytes":
...