π 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
...
π¬ Crypt-iQ commented on pull request "fuzz: compact block harness":
(https://github.com/bitcoin/bitcoin/pull/33300#discussion_r2417331534)
Some signals are not caught by the fuzzer, so if it creates a datadir (i.e. `process_messages`) and you Ctrl-C, it will leave it around instead of deleting it in `~BasicTestingSetup`. In any case, not using `g_rng_temp_path` seems like the right choice.
(https://github.com/bitcoin/bitcoin/pull/33300#discussion_r2417331534)
Some signals are not caught by the fuzzer, so if it creates a datadir (i.e. `process_messages`) and you Ctrl-C, it will leave it around instead of deleting it in `~BasicTestingSetup`. In any case, not using `g_rng_temp_path` seems like the right choice.
π¬ hebasto commented on pull request "Revert "depends: Update URL for `qrencode` package source tarball"":
(https://github.com/bitcoin/bitcoin/pull/33577#issuecomment-3386621614)
> Just checking someone has the original tarball?
I have:
```
$ sha256sum sources/qrencode-4.1.1.tar.gz
da448ed4f52aba6bcb0cd48cac0dd51b8692bccc4cd127431402fca6f8171e8e sources/qrencode-4.1.1.tar.gz
```
(https://github.com/bitcoin/bitcoin/pull/33577#issuecomment-3386621614)
> Just checking someone has the original tarball?
I have:
```
$ sha256sum sources/qrencode-4.1.1.tar.gz
da448ed4f52aba6bcb0cd48cac0dd51b8692bccc4cd127431402fca6f8171e8e sources/qrencode-4.1.1.tar.gz
```
β οΈ glozow opened an issue: "Minor Release 29.2"
(https://github.com/bitcoin/bitcoin/issues/33586)
Backports
- #33344
- #33474
- #33403
RC 1:
- [x] final changes #33344
- [x] tag
- [x] upload binaries
RC 2:
- [x] final changes #33534
- [x] tag
- [x] upload binaries
- [x] announcements
Final version:
- [ ] final changes
- [ ] tag
- [ ] upload binaries
- [ ] announcements
- [ ] archive release notes
- [ ] github release
See [release process docs](https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md) for more details. This issue can be used to track status updates. Please fe
...
(https://github.com/bitcoin/bitcoin/issues/33586)
Backports
- #33344
- #33474
- #33403
RC 1:
- [x] final changes #33344
- [x] tag
- [x] upload binaries
RC 2:
- [x] final changes #33534
- [x] tag
- [x] upload binaries
- [x] announcements
Final version:
- [ ] final changes
- [ ] tag
- [ ] upload binaries
- [ ] announcements
- [ ] archive release notes
- [ ] github release
See [release process docs](https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md) for more details. This issue can be used to track status updates. Please fe
...
π¬ glozow commented on issue "Minor Release 29.2":
(https://github.com/bitcoin/bitcoin/issues/33586#issuecomment-3386635593)
rc1 bins: https://bitcoincore.org/bin/bitcoin-core-29.2/test.rc1/
rc2 bins: https://bitcoincore.org/bin/bitcoin-core-29.2/test.rc2/
announcements for release candidates:
https://delvingbitcoin.org/t/bitcoin-core-v29-2-release-candidate-available/2036
https://groups.google.com/g/bitcoindev/c/FAebgCmXOKs
(https://github.com/bitcoin/bitcoin/issues/33586#issuecomment-3386635593)
rc1 bins: https://bitcoincore.org/bin/bitcoin-core-29.2/test.rc1/
rc2 bins: https://bitcoincore.org/bin/bitcoin-core-29.2/test.rc2/
announcements for release candidates:
https://delvingbitcoin.org/t/bitcoin-core-v29-2-release-candidate-available/2036
https://groups.google.com/g/bitcoindev/c/FAebgCmXOKs
π¬ TheCharlatan commented on pull request "kernel: Introduce initial C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#issuecomment-3386641151)
Updated 2a80cd9f1db45dfc1775ded6698b034691e7bf2d -> 81cec737e68b91f5edf90179b81aa620a5a68677 ([kernelApi_72](https://github.com/TheCharlatan/bitcoin/tree/kernelApi_72) -> [kernelApi_73](https://github.com/TheCharlatan/bitcoin/tree/kernelApi_73), [compare](https://github.com/TheCharlatan/bitcoin/compare/kernelApi_72..kernelApi_73))
* Addressed @ismaelsadeeq's [comment](https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2416004410), removed confusing notice in message printed by bitcoin-
...
(https://github.com/bitcoin/bitcoin/pull/30595#issuecomment-3386641151)
Updated 2a80cd9f1db45dfc1775ded6698b034691e7bf2d -> 81cec737e68b91f5edf90179b81aa620a5a68677 ([kernelApi_72](https://github.com/TheCharlatan/bitcoin/tree/kernelApi_72) -> [kernelApi_73](https://github.com/TheCharlatan/bitcoin/tree/kernelApi_73), [compare](https://github.com/TheCharlatan/bitcoin/compare/kernelApi_72..kernelApi_73))
* Addressed @ismaelsadeeq's [comment](https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2416004410), removed confusing notice in message printed by bitcoin-
...
π bavani-2024-aia opened a pull request: "No remote repository configured (fatal: 'origin' does not appear to be a git repository)Add files via upload"
(https://github.com/bitcoin/bitcoin/pull/33587)
While trying to push local commits to GitHub using git push -u origin master, Git returned the error:
fatal: 'origin' does not appear to be a git repository
fatal: Could not read from remote repository.
This happens because the local repository is not linked to any remote repository. Git cannot find a remote named origin, so it doesnβt know where to push the commits.
Cause:
The repository was initialized locally using git init.
No remote repository (on GitHub or other Git hosti
...
(https://github.com/bitcoin/bitcoin/pull/33587)
While trying to push local commits to GitHub using git push -u origin master, Git returned the error:
fatal: 'origin' does not appear to be a git repository
fatal: Could not read from remote repository.
This happens because the local repository is not linked to any remote repository. Git cannot find a remote named origin, so it doesnβt know where to push the commits.
Cause:
The repository was initialized locally using git init.
No remote repository (on GitHub or other Git hosti
...