💬 theStack commented on pull request "test: add functional test for `TestShell` (matching doc example)":
(https://github.com/bitcoin/bitcoin/pull/33546#discussion_r2417135650)
Thanks, done.
(https://github.com/bitcoin/bitcoin/pull/33546#discussion_r2417135650)
Thanks, done.
💬 glozow commented on pull request "depends: Update URL for `qrencode` package source tarball":
(https://github.com/bitcoin/bitcoin/pull/33494#issuecomment-3386227576)
> It's also been pointed out that this has also (effectively) broken the Guix build on the release branches.
I've been testing for 29.2 and hitting this problem. After the old tarball was restored yesterday I was able to do a fresh guix build, but it's now failing again (the fukuchi.org one doesn't exist and the fallback depends-source has re-pulled the new tarball with a different hash, as described above).
```
Fetching qrencode-4.1.1.tar.gz from https://fukuchi.org/works/qrencode/
%
...
(https://github.com/bitcoin/bitcoin/pull/33494#issuecomment-3386227576)
> It's also been pointed out that this has also (effectively) broken the Guix build on the release branches.
I've been testing for 29.2 and hitting this problem. After the old tarball was restored yesterday I was able to do a fresh guix build, but it's now failing again (the fukuchi.org one doesn't exist and the fallback depends-source has re-pulled the new tarball with a different hash, as described above).
```
Fetching qrencode-4.1.1.tar.gz from https://fukuchi.org/works/qrencode/
%
...
💬 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
...