💬 sipa commented on pull request "cluster mempool: add TxGraph reorg functionality":
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110817020)
Done.
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110817020)
Done.
💬 sipa commented on pull request "cluster mempool: add TxGraph reorg functionality":
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110822058)
Added a commit with a test like this, with some changes. LMK what you think.
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110822058)
Added a commit with a test like this, with some changes. LMK what you think.
💬 sipa commented on pull request "cluster mempool: add TxGraph reorg functionality":
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110821680)
Done. Also organized the fields of `struct TrimTxData` a bit more logically, into "Populated by Cluster::AppendTxData" and "Only used internally in TxGraphImpl::Trim" sections.
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110821680)
Done. Also organized the fields of `struct TrimTxData` a bit more logically, into "Populated by Cluster::AppendTxData" and "Only used internally in TxGraphImpl::Trim" sections.
💬 sipa commented on pull request "cluster mempool: add TxGraph reorg functionality":
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110821096)
Done.
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110821096)
Done.
💬 sipa commented on pull request "cluster mempool: add TxGraph reorg functionality":
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110821027)
Done.
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110821027)
Done.
💬 sipa commented on pull request "cluster mempool: add TxGraph reorg functionality":
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110820886)
Done.
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110820886)
Done.
💬 sipa commented on pull request "cluster mempool: add TxGraph reorg functionality":
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110820614)
Forgot to take this. Will leave open for now.
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110820614)
Forgot to take this. Will leave open for now.
💬 sipa commented on pull request "cluster mempool: add TxGraph reorg functionality":
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110820827)
Done.
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110820827)
Done.
💬 sipa commented on pull request "cluster mempool: add TxGraph reorg functionality":
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110819198)
Done.
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110819198)
Done.
💬 sipa commented on pull request "cluster mempool: add TxGraph reorg functionality":
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110820744)
Done.
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110820744)
Done.
💬 sipa commented on pull request "cluster mempool: add TxGraph reorg functionality":
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110820382)
I've written a test based on this, which randomly adds dependencies but in a "directed" sense that never introduces cycles (rather than just has 2 specific scenarios).
(https://github.com/bitcoin/bitcoin/pull/31553#discussion_r2110820382)
I've written a test based on this, which randomly adds dependencies but in a "directed" sense that never introduces cycles (rather than just has 2 specific scenarios).
💬 saikiran57 commented on pull request "Added rescan option for import descriptors":
(https://github.com/bitcoin/bitcoin/pull/31668#issuecomment-2915121835)
Hi @achow101 @maflcko @davidrobinsonau can you please check this once and merge it everything is fine.
(https://github.com/bitcoin/bitcoin/pull/31668#issuecomment-2915121835)
Hi @achow101 @maflcko @davidrobinsonau can you please check this once and merge it everything is fine.
💬 Sjors commented on pull request "Add bitcoin-{node,gui} to release binaries for IPC":
(https://github.com/bitcoin/bitcoin/pull/31802#issuecomment-2915387816)
#31375 landed!
Still in draft waiting for https://github.com/bitcoin-core/libmultiprocess/pull/172
(https://github.com/bitcoin/bitcoin/pull/31802#issuecomment-2915387816)
#31375 landed!
Still in draft waiting for https://github.com/bitcoin-core/libmultiprocess/pull/172
💬 Sjors commented on issue "Stratum v2 via IPC Mining Interface tracking issue":
(https://github.com/bitcoin/bitcoin/issues/31098#issuecomment-2915399359)
The wrapper binary PR #31375 just landed, which is great progress!
The only big change left is to add bitcoin-node (aka `bitcoin -m`) to the release binaries, which is what #31802 does.
(https://github.com/bitcoin/bitcoin/issues/31098#issuecomment-2915399359)
The wrapper binary PR #31375 just landed, which is great progress!
The only big change left is to add bitcoin-node (aka `bitcoin -m`) to the release binaries, which is what #31802 does.
💬 i-am-yuvi commented on pull request "p2p: protect addnode peers during IBD":
(https://github.com/bitcoin/bitcoin/pull/32051#issuecomment-2915403993)
Code Review ACK 93b07997e9a38523f5ab850aa32ca57983fd2552
I've made a review notes for this pr -> [here](https://github.com/i-am-yuvi/bitcoin-ibd/blob/master/30251.md)
(https://github.com/bitcoin/bitcoin/pull/32051#issuecomment-2915403993)
Code Review ACK 93b07997e9a38523f5ab850aa32ca57983fd2552
I've made a review notes for this pr -> [here](https://github.com/i-am-yuvi/bitcoin-ibd/blob/master/30251.md)
💬 maflcko commented on pull request "test: add MAX_DISCONNECTED_TX_POOL_BYTES, chainlimits coverage":
(https://github.com/bitcoin/bitcoin/pull/32516#issuecomment-2915446066)
re-ACK 84aa484d45e2fb3c1149941ef23779e4adb983d9 🚋
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: re-ACK 84aa484d45e2fb3c1149
...
(https://github.com/bitcoin/bitcoin/pull/32516#issuecomment-2915446066)
re-ACK 84aa484d45e2fb3c1149941ef23779e4adb983d9 🚋
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: re-ACK 84aa484d45e2fb3c1149
...
💬 hebasto commented on issue "build: use UCRT runtime for Windows (release) binaries":
(https://github.com/bitcoin/bitcoin/issues/30210#issuecomment-2915451888)
@jeandudey
> I've sent a patchset a while ago when working on cross-base updating MinGW to 12.0.0: https://issues.guix.gnu.org/71630.
>
> Using `UCRT` will likely need a new target triplet for Guix though like MSYS2 does, e.g. `x86_64-w64-ucrt-mingw32`.
Trying to build `mingw-w64` with the deleted [`--with-default-msvcrt=msvcrt`](https://codeberg.org/guix/guix/src/commit/d1ec5be63e2d8521a6bad61e5c478319280623c6/gnu/packages/mingw.scm#L90) configure option results in a linker error:
```
x86_6
...
(https://github.com/bitcoin/bitcoin/issues/30210#issuecomment-2915451888)
@jeandudey
> I've sent a patchset a while ago when working on cross-base updating MinGW to 12.0.0: https://issues.guix.gnu.org/71630.
>
> Using `UCRT` will likely need a new target triplet for Guix though like MSYS2 does, e.g. `x86_64-w64-ucrt-mingw32`.
Trying to build `mingw-w64` with the deleted [`--with-default-msvcrt=msvcrt`](https://codeberg.org/guix/guix/src/commit/d1ec5be63e2d8521a6bad61e5c478319280623c6/gnu/packages/mingw.scm#L90) configure option results in a linker error:
```
x86_6
...
💬 maflcko commented on pull request "rest: fetch spent transaction outputs by blockhash":
(https://github.com/bitcoin/bitcoin/pull/32540#discussion_r2111303331)
> Reading the undo data directly from storage (i.e. without re-serialization) results in ~3.2x requests per second, and even a bit less data sent over the network:
Hmm. I am not sure if this is representative of the end-to-end performance. Simply fetching the raw (compressed) data is missing the decompression overhead. The end product can probably not do much with the compressed data by itself, so the benchmark should include the decompression as well.
(https://github.com/bitcoin/bitcoin/pull/32540#discussion_r2111303331)
> Reading the undo data directly from storage (i.e. without re-serialization) results in ~3.2x requests per second, and even a bit less data sent over the network:
Hmm. I am not sure if this is representative of the end-to-end performance. Simply fetching the raw (compressed) data is missing the decompression overhead. The end product can probably not do much with the compressed data by itself, so the benchmark should include the decompression as well.
💬 fanquake commented on pull request "guix: accomodate migration to codeberg":
(https://github.com/bitcoin/bitcoin/pull/32439#issuecomment-2915516389)
Backported to `29.x` in #32589.
(https://github.com/bitcoin/bitcoin/pull/32439#issuecomment-2915516389)
Backported to `29.x` in #32589.
💬 stringintech commented on pull request "p2p: protect addnode peers during IBD":
(https://github.com/bitcoin/bitcoin/pull/32051#issuecomment-2915572044)
> An alternative would be to not give these peers unlimited time but clear their block requests (so that these blocks can be requested from other peers) so that they wouldn't be disconnected but also wouldn't be able to stall us indefinitely.
This makes sense, as the PR tries to achieve a similar goal with initial headers sync timeouts in commit 64b956f.
(https://github.com/bitcoin/bitcoin/pull/32051#issuecomment-2915572044)
> An alternative would be to not give these peers unlimited time but clear their block requests (so that these blocks can be requested from other peers) so that they wouldn't be disconnected but also wouldn't be able to stall us indefinitely.
This makes sense, as the PR tries to achieve a similar goal with initial headers sync timeouts in commit 64b956f.