💬 glozow commented on pull request "net_processing: rename RelayTransaction to better describe what it does":
(https://github.com/bitcoin/bitcoin/pull/33565#discussion_r2417108700)
The transaction isn't really scheduled; its broadcast time hasn't been decided. Apologies for the pedantry but given this PR aims to rename something for clarity, I point out that all other `schedule`s in net_processing involve deciding on the time at which something will happen.
My suggestion: here, we `QueueAnnouncement`. Later, depending on what's in the queue and what else we receive, might inv it. "Announce" is more specific than "Broadcast" for tx relay.
(https://github.com/bitcoin/bitcoin/pull/33565#discussion_r2417108700)
The transaction isn't really scheduled; its broadcast time hasn't been decided. Apologies for the pedantry but given this PR aims to rename something for clarity, I point out that all other `schedule`s in net_processing involve deciding on the time at which something will happen.
My suggestion: here, we `QueueAnnouncement`. Later, depending on what's in the queue and what else we receive, might inv it. "Announce" is more specific than "Broadcast" for tx relay.
🚀 fanquake merged a pull request: "ci: upgrade GitHub Action to download-artifact@v5"
(https://github.com/bitcoin/bitcoin/pull/33584)
(https://github.com/bitcoin/bitcoin/pull/33584)
🚀 fanquake merged a pull request: "ci: Properly include $FILE_ENV in DEPENDS_HASH"
(https://github.com/bitcoin/bitcoin/pull/33581)
(https://github.com/bitcoin/bitcoin/pull/33581)
📝 purpleKarrot opened a pull request: "cmake: Use builtin support for .manifest files"
(https://github.com/bitcoin/bitcoin/pull/33585)
Remove some redundant logic from the CMake code:
* The `WIN32_EXECUTABLE` target property only has an effect when building for `WIN32`. Checking `WIN32` is redundant.
* CMake has builtin support for `.rc` and `.manifest` files. Both may be added to sources unconditionally. They only have an effect when building for `WIN32`.
(https://github.com/bitcoin/bitcoin/pull/33585)
Remove some redundant logic from the CMake code:
* The `WIN32_EXECUTABLE` target property only has an effect when building for `WIN32`. Checking `WIN32` is redundant.
* CMake has builtin support for `.rc` and `.manifest` files. Both may be added to sources unconditionally. They only have an effect when building for `WIN32`.
💬 plebhash commented on issue "RFC: Cancelling waitNext calls in the IPC mining interface":
(https://github.com/bitcoin/bitcoin/issues/33575#issuecomment-3386438916)
the current implementation has two concurrent loops:
- one that monitors for incoming Sv2 messages
- one that monitors `waitNext` (which is restarted upon arrival of `CoinbaseOutputConstraints`)
I guess in theory they could be unified into a single one, however `interruptWait` would have to be called whenever **some** incoming Sv2 message arrived, not only if that was a `CoinbaseOutputConstraints`.
that's because under a single unified loop, the futures for incoming messages now would be "comp
...
(https://github.com/bitcoin/bitcoin/issues/33575#issuecomment-3386438916)
the current implementation has two concurrent loops:
- one that monitors for incoming Sv2 messages
- one that monitors `waitNext` (which is restarted upon arrival of `CoinbaseOutputConstraints`)
I guess in theory they could be unified into a single one, however `interruptWait` would have to be called whenever **some** incoming Sv2 message arrived, not only if that was a `CoinbaseOutputConstraints`.
that's because under a single unified loop, the futures for incoming messages now would be "comp
...
💬 stringintech commented on pull request "fuzz: compact block harness":
(https://github.com/bitcoin/bitcoin/pull/33300#discussion_r2417231848)
Since the crash I explained wasn't observed by others, I doubted whether it was actually coming from multiple child processes running simultaneously or from missed data dir cleanup. So I added a bunch of logs (including pid and parent pid in each) to investigate this further and found this after reading the logs for multiple runs:
I observed that AFL++ ran one worker process at a time, not multiple workers in parallel. Each worker created a static cached directory once, then ran multiple fuzz
...
(https://github.com/bitcoin/bitcoin/pull/33300#discussion_r2417231848)
Since the crash I explained wasn't observed by others, I doubted whether it was actually coming from multiple child processes running simultaneously or from missed data dir cleanup. So I added a bunch of logs (including pid and parent pid in each) to investigate this further and found this after reading the logs for multiple runs:
I observed that AFL++ ran one worker process at a time, not multiple workers in parallel. Each worker created a static cached directory once, then ran multiple fuzz
...
📝 waketraindev reopened a pull request: "rpc: add optional peer_ids param to filter getpeerinfo"
(https://github.com/bitcoin/bitcoin/pull/32741)
Adds an optional `peer_ids` parameter to `getpeerinfo` to filter results by peer IDs.
This is useful when using bitcoin-cli or the console to inspect specific peers referenced in debug.log.
(https://github.com/bitcoin/bitcoin/pull/32741)
Adds an optional `peer_ids` parameter to `getpeerinfo` to filter results by peer IDs.
This is useful when using bitcoin-cli or the console to inspect specific peers referenced in debug.log.
💬 glozow commented on pull request "Revert "depends: Update URL for `qrencode` package source tarball"":
(https://github.com/bitcoin/bitcoin/pull/33577#issuecomment-3386475009)
> Just checking someone has the original tarball? Otherwise I'm assuming this revert will not work.
Yes. This was done yesterday, but the server auto-updated this morning.
(https://github.com/bitcoin/bitcoin/pull/33577#issuecomment-3386475009)
> Just checking someone has the original tarball? Otherwise I'm assuming this revert will not work.
Yes. This was done yesterday, but the server auto-updated this morning.
💬 plebhash commented on issue "RFC: Cancelling waitNext calls in the IPC mining interface":
(https://github.com/bitcoin/bitcoin/issues/33575#issuecomment-3386476128)
although I wonder about potentially undesirable round-trips that could be avoided by having separate loops?
for example, every time there's a new template, we send a `NewTemplate` message
and for most Sv2 implementations that are on the receiving and of this message, we expect to get a `RequestTransactionData` right afterwards
so every time there's a new template, we're essentially creating one "useless" `waitNext` request that's bound to be discarded right afterwards (with the extra round-tr
...
(https://github.com/bitcoin/bitcoin/issues/33575#issuecomment-3386476128)
although I wonder about potentially undesirable round-trips that could be avoided by having separate loops?
for example, every time there's a new template, we send a `NewTemplate` message
and for most Sv2 implementations that are on the receiving and of this message, we expect to get a `RequestTransactionData` right afterwards
so every time there's a new template, we're essentially creating one "useless" `waitNext` request that's bound to be discarded right afterwards (with the extra round-tr
...
💬 achow101 commented on pull request "Revert "depends: Update URL for `qrencode` package source tarball"":
(https://github.com/bitcoin/bitcoin/pull/33577#issuecomment-3386476933)
> Just checking someone has the original tarball?
Yes. The original has already been uploaded to the server as `qrencode-4.1.1-fukuchi.org.tar.gz` and it only needs to be renamed to match.
(https://github.com/bitcoin/bitcoin/pull/33577#issuecomment-3386476933)
> Just checking someone has the original tarball?
Yes. The original has already been uploaded to the server as `qrencode-4.1.1-fukuchi.org.tar.gz` and it only needs to be renamed to match.
💬 fanquake commented on pull request "cmake: Use builtin support for .manifest files":
(https://github.com/bitcoin/bitcoin/pull/33585#issuecomment-3386480246)
This doesn't Guix build:
```bash
[100%] Built target bitcoin-qt
Running symbol and dynamic library checks...
/distsrc-base/distsrc-3277798895d9-x86_64-w64-mingw32/build/bin/bitcoin.exe: failed APPLICATION_MANIFEST
/distsrc-base/distsrc-3277798895d9-x86_64-w64-mingw32/build/bin/bitcoind.exe: failed APPLICATION_MANIFEST
/distsrc-base/distsrc-3277798895d9-x86_64-w64-mingw32/build/bin/bitcoin-qt.exe: failed APPLICATION_MANIFEST
/distsrc-base/distsrc-3277798895d9-x86_64-w64-mingw32/build/bin/b
...
(https://github.com/bitcoin/bitcoin/pull/33585#issuecomment-3386480246)
This doesn't Guix build:
```bash
[100%] Built target bitcoin-qt
Running symbol and dynamic library checks...
/distsrc-base/distsrc-3277798895d9-x86_64-w64-mingw32/build/bin/bitcoin.exe: failed APPLICATION_MANIFEST
/distsrc-base/distsrc-3277798895d9-x86_64-w64-mingw32/build/bin/bitcoind.exe: failed APPLICATION_MANIFEST
/distsrc-base/distsrc-3277798895d9-x86_64-w64-mingw32/build/bin/bitcoin-qt.exe: failed APPLICATION_MANIFEST
/distsrc-base/distsrc-3277798895d9-x86_64-w64-mingw32/build/bin/b
...
💬 stringintech commented on pull request "fuzz: compact block harness":
(https://github.com/bitcoin/bitcoin/pull/33300#discussion_r2417263019)
> I'm confused why fuzzing on debian didn't bring this up.
While my case wasn't exactly a multi-process execution issue, it seems a true multi-process execution should observe the same crash because of the same `g_rng_temp_path`.
(https://github.com/bitcoin/bitcoin/pull/33300#discussion_r2417263019)
> I'm confused why fuzzing on debian didn't bring this up.
While my case wasn't exactly a multi-process execution issue, it seems a true multi-process execution should observe the same crash because of the same `g_rng_temp_path`.
💬 sipa commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417268131)
I don't think that's worth the slowdown.
My thinking around this is that whenever the fuzzer hits a particular level of complication, it's reasonable to assume it has already explored most less-complicated cases too, through other runs of the harness. That applies to prefixes of the same seed too.
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417268131)
I don't think that's worth the slowdown.
My thinking around this is that whenever the fuzzer hits a particular level of complication, it's reasonable to assume it has already explored most less-complicated cases too, through other runs of the harness. That applies to prefixes of the same seed too.
💬 saxxi commented on issue "Set default datacarriersize to 160 bytes":
(https://github.com/bitcoin/bitcoin/issues/33543#issuecomment-3386505733)
Conveniently and "mysteriously" is not possible to login into the platform 👏
<img width="723" height="447" alt="Image" src="https://github.com/user-attachments/assets/97a13c80-bbb4-454c-8b00-a82f83d17443" />
(https://github.com/bitcoin/bitcoin/issues/33543#issuecomment-3386505733)
Conveniently and "mysteriously" is not possible to login into the platform 👏
<img width="723" height="447" alt="Image" src="https://github.com/user-attachments/assets/97a13c80-bbb4-454c-8b00-a82f83d17443" />
💬 purpleKarrot commented on pull request "[wip] A more static bitcoin-qt":
(https://github.com/bitcoin/bitcoin/pull/33537#issuecomment-3386517719)
@fanquake, what is the motivation for a statically built bitcoin-qt? Is the performance or the package size a concern?
Or is it to simplify deployment, like being able to provide a single binary that can be run on any Linux machine?
If the latter is the case, [AppImage](https://appimage.org/) might be an alternative approach. CMake version 4.2 introduces a [CPack AppImage Generator](https://cmake.org/cmake/help/git-master/cpack_gen/appimage.html).
(https://github.com/bitcoin/bitcoin/pull/33537#issuecomment-3386517719)
@fanquake, what is the motivation for a statically built bitcoin-qt? Is the performance or the package size a concern?
Or is it to simplify deployment, like being able to provide a single binary that can be run on any Linux machine?
If the latter is the case, [AppImage](https://appimage.org/) might be an alternative approach. CMake version 4.2 introduces a [CPack AppImage Generator](https://cmake.org/cmake/help/git-master/cpack_gen/appimage.html).
🤔 mzumsande reviewed a pull request: "p2p: Mitigate GETADDR fingerprinting by setting address timestamps to a fixed value"
(https://github.com/bitcoin/bitcoin/pull/33498#pullrequestreview-3319680730)
I wonder if this could lead to addrs of nodes that have left the network never getting removed:
The scenario is a well-connected node that is present in most other nodes' addrmans, but that suddenly leaves the network or changes its IP.
Currently what happens is that 1) It won't self-advertise anymore and 2) [after 30 days](https://github.com/bitcoin/bitcoin/blob/b510893d00760083ac36948747aa6ebd84656192/src/addrman.cpp#L34), the addr gets Terrible and won't be part of `GetAddr` interaction
...
(https://github.com/bitcoin/bitcoin/pull/33498#pullrequestreview-3319680730)
I wonder if this could lead to addrs of nodes that have left the network never getting removed:
The scenario is a well-connected node that is present in most other nodes' addrmans, but that suddenly leaves the network or changes its IP.
Currently what happens is that 1) It won't self-advertise anymore and 2) [after 30 days](https://github.com/bitcoin/bitcoin/blob/b510893d00760083ac36948747aa6ebd84656192/src/addrman.cpp#L34), the addr gets Terrible and won't be part of `GetAddr` interaction
...
👋 fanquake's pull request is ready for review: "[30.x] Finalise v30.0"
(https://github.com/bitcoin/bitcoin/pull/33559)
(https://github.com/bitcoin/bitcoin/pull/33559)
💬 m3dwards commented on pull request "Revert "depends: Update URL for `qrencode` package source tarball"":
(https://github.com/bitcoin/bitcoin/pull/33577#issuecomment-3386567933)
utACK e4335a31920cd390d936cd51cc4478a234db1276
Got a failure with:
```shell
make -C depends clean-all
make -C depends qrencode
/bin/sh: command -v llvm-ranlib: No such file or directory
/bin/sh: command -v llvm-strip: No such file or directory
/bin/sh: command -v llvm-nm: No such file or directory
/bin/sh: command -v llvm-objcopy: No such file or directory
/bin/sh: command -v llvm-objdump: No such file or directory
/bin/sh: command -v dsymutil: No such file or directory
Fetching q
...
(https://github.com/bitcoin/bitcoin/pull/33577#issuecomment-3386567933)
utACK e4335a31920cd390d936cd51cc4478a234db1276
Got a failure with:
```shell
make -C depends clean-all
make -C depends qrencode
/bin/sh: command -v llvm-ranlib: No such file or directory
/bin/sh: command -v llvm-strip: No such file or directory
/bin/sh: command -v llvm-nm: No such file or directory
/bin/sh: command -v llvm-objcopy: No such file or directory
/bin/sh: command -v llvm-objdump: No such file or directory
/bin/sh: command -v dsymutil: No such file or directory
Fetching q
...
💬 sipa commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417305579)
Seems unrelated to this PR.
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417305579)
Seems unrelated to this PR.
💬 earonesty commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-3386603198)
- agreed that it must evolve to "settlement", but disagree that lowering
blocksize won't help. aggregate fee per block will strictly increase as
block space is limited.
- maturing is lovely, but bitcoin's goal is decentralization and
censorship resistant p2p electronic cash
- we don't need an "ecosystem of shitcoins". but we do need a way to
batch enter and unilaterally exit a vtxo for us to get a robust layer 2
that anyone can safely use
On Wed, Oct 8, 2025 at 5:04 PM Wycli
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-3386603198)
- agreed that it must evolve to "settlement", but disagree that lowering
blocksize won't help. aggregate fee per block will strictly increase as
block space is limited.
- maturing is lovely, but bitcoin's goal is decentralization and
censorship resistant p2p electronic cash
- we don't need an "ecosystem of shitcoins". but we do need a way to
batch enter and unilaterally exit a vtxo for us to get a robust layer 2
that anyone can safely use
On Wed, Oct 8, 2025 at 5:04 PM Wycli
...