💬 ryanofsky commented on pull request "init: verify blocks data existence only once for all the indexers":
(https://github.com/bitcoin/bitcoin/pull/27607#discussion_r1191383733)
In commit "index: verify blocks data existence only once" (86752e0cc5bc48f3d4ac1cd07835c37daf078d6a)
In the case where the bitcoind datadir is being newly created and the `LoadChainState` call above doesn't set a chain tip, `pindex` will be null here and this line will segfault. It should be possible to handle this with `if (!pindex) return`. This is causing CI errors (https://cirrus-ci.com/task/4539645451567104) currently
(https://github.com/bitcoin/bitcoin/pull/27607#discussion_r1191383733)
In commit "index: verify blocks data existence only once" (86752e0cc5bc48f3d4ac1cd07835c37daf078d6a)
In the case where the bitcoind datadir is being newly created and the `LoadChainState` call above doesn't set a chain tip, `pindex` will be null here and this line will segfault. It should be possible to handle this with `if (!pindex) return`. This is causing CI errors (https://cirrus-ci.com/task/4539645451567104) currently
💬 ryanofsky commented on pull request "init: verify blocks data existence only once for all the indexers":
(https://github.com/bitcoin/bitcoin/pull/27607#discussion_r1191329811)
In commit "index: verify blocks data existence only once" (86752e0cc5bc48f3d4ac1cd07835c37daf078d6a)
Not important in practice, but since `m_best_block_index` is an atomic variable, it would look a little better to retrieve it atomically with:
```
if (const CBlockIndex* pindex = m_best_block_index.load()) {
```
(https://github.com/bitcoin/bitcoin/pull/27607#discussion_r1191329811)
In commit "index: verify blocks data existence only once" (86752e0cc5bc48f3d4ac1cd07835c37daf078d6a)
Not important in practice, but since `m_best_block_index` is an atomic variable, it would look a little better to retrieve it atomically with:
```
if (const CBlockIndex* pindex = m_best_block_index.load()) {
```
💬 ryanofsky commented on pull request "init: verify blocks data existence only once for all the indexers":
(https://github.com/bitcoin/bitcoin/pull/27607#discussion_r1191396717)
In commit "indexes, refactor: Remove index prune_violation code" (1341793b928ba81205b1cea11fdbd52fe6c3e869)
It would probably make more sense to make this method into a standalone function `bool ChainDataFromTipDown(ChainstateManager& chainman, const CBlockIndex& start_block)` function in someplace like `src/node/chainstate.cpp` than to add it to interfaces::Chain if it won't be called by chain clients like wallets or indexes.
(https://github.com/bitcoin/bitcoin/pull/27607#discussion_r1191396717)
In commit "indexes, refactor: Remove index prune_violation code" (1341793b928ba81205b1cea11fdbd52fe6c3e869)
It would probably make more sense to make this method into a standalone function `bool ChainDataFromTipDown(ChainstateManager& chainman, const CBlockIndex& start_block)` function in someplace like `src/node/chainstate.cpp` than to add it to interfaces::Chain if it won't be called by chain clients like wallets or indexes.
💬 hebasto commented on pull request "wallet: fix deadlock in bdb read write operation":
(https://github.com/bitcoin/bitcoin/pull/27556#issuecomment-1544286558)
Concept ACK.
(https://github.com/bitcoin/bitcoin/pull/27556#issuecomment-1544286558)
Concept ACK.
💬 instagibbs commented on pull request "Parallel compact block downloads, take 3":
(https://github.com/bitcoin/bitcoin/pull/27626#discussion_r1191418745)
sounds right, I'll sit on this for a bit
(https://github.com/bitcoin/bitcoin/pull/27626#discussion_r1191418745)
sounds right, I'll sit on this for a bit
💬 dergoegge commented on pull request "Parallel compact block downloads, take 3":
(https://github.com/bitcoin/bitcoin/pull/27626#discussion_r1191426977)
Could use `pfrom.m_bip152_highbandwidth_to`?
(https://github.com/bitcoin/bitcoin/pull/27626#discussion_r1191426977)
Could use `pfrom.m_bip152_highbandwidth_to`?
💬 hebasto commented on pull request "wallet: fix deadlock in bdb read write operation":
(https://github.com/bitcoin/bitcoin/pull/27556#discussion_r1191433122)
Does this comment remain true?
(https://github.com/bitcoin/bitcoin/pull/27556#discussion_r1191433122)
Does this comment remain true?
💬 instagibbs commented on pull request "Parallel compact block downloads, take 3":
(https://github.com/bitcoin/bitcoin/pull/27626#discussion_r1191435827)
what if we just removed the limit, since it's not much of a protection, especially if the missing 10 txns are *nscriptions
(https://github.com/bitcoin/bitcoin/pull/27626#discussion_r1191435827)
what if we just removed the limit, since it's not much of a protection, especially if the missing 10 txns are *nscriptions
💬 ajtowns commented on pull request "Parallel compact block downloads, take 3":
(https://github.com/bitcoin/bitcoin/pull/27626#discussion_r1191441529)
Probably better to defer it as an unrelated change anyway?
(https://github.com/bitcoin/bitcoin/pull/27626#discussion_r1191441529)
Probably better to defer it as an unrelated change anyway?
📝 theuni opened a pull request: "build: Fix shared lib linking for darwin with lld"
(https://github.com/bitcoin/bitcoin/pull/27628)
Solves one of the last remaining blockers for #21778. Fixes lld linking shared libs for macos via libtool.
lld fails one of libtool's earliest checks [because it happens to output a warning that contains a specific string](https://git.savannah.gnu.org/cgit/libtool.git/tree/m4/libtool.m4#n999):
> # If there is a non-empty error log, and "single_module"
> # appears in it, assume the flag caused a linker warning
And here is the test being run:
> x86_64-apple-darwin-ld: warning:
...
(https://github.com/bitcoin/bitcoin/pull/27628)
Solves one of the last remaining blockers for #21778. Fixes lld linking shared libs for macos via libtool.
lld fails one of libtool's earliest checks [because it happens to output a warning that contains a specific string](https://git.savannah.gnu.org/cgit/libtool.git/tree/m4/libtool.m4#n999):
> # If there is a non-empty error log, and "single_module"
> # appears in it, assume the flag caused a linker warning
And here is the test being run:
> x86_64-apple-darwin-ld: warning:
...
💬 theuni commented on pull request "build: Fix shared lib linking for darwin with lld":
(https://github.com/bitcoin/bitcoin/pull/27628#issuecomment-1544323444)
Ping @fanquake
And @hebasto, because I know you love libtool hacks ;)
(https://github.com/bitcoin/bitcoin/pull/27628#issuecomment-1544323444)
Ping @fanquake
And @hebasto, because I know you love libtool hacks ;)
👍 hernanmarino approved a pull request: "refactor: Add util::Result failure values, multiple error and warning messages"
(https://github.com/bitcoin/bitcoin/pull/25665#pullrequestreview-1423032563)
re ACK 28a954c7034077ac3a45083dd5e2b5cdb4d4cdde
(https://github.com/bitcoin/bitcoin/pull/25665#pullrequestreview-1423032563)
re ACK 28a954c7034077ac3a45083dd5e2b5cdb4d4cdde
💬 fanquake commented on pull request "build: Fix shared lib linking for darwin with lld":
(https://github.com/bitcoin/bitcoin/pull/27628#issuecomment-1544326369)
Concept ACK. Note that this is also shown to be working in #21778, as the build there is succeeding.
(https://github.com/bitcoin/bitcoin/pull/27628#issuecomment-1544326369)
Concept ACK. Note that this is also shown to be working in #21778, as the build there is succeeding.
💬 fanquake commented on pull request "[23.2] Backports for rc1":
(https://github.com/bitcoin/bitcoin/pull/27624#issuecomment-1544329711)
Added #27610, as well as all other changes required to cut an rc1.
> Are you going to add https://github.com/bitcoin/bitcoin/pull/27610 to this?
Yes. Note that the second commit from that PR is not a clean cherry-pick.
(https://github.com/bitcoin/bitcoin/pull/27624#issuecomment-1544329711)
Added #27610, as well as all other changes required to cut an rc1.
> Are you going to add https://github.com/bitcoin/bitcoin/pull/27610 to this?
Yes. Note that the second commit from that PR is not a clean cherry-pick.
💬 instagibbs commented on pull request "Parallel compact block downloads, take 3":
(https://github.com/bitcoin/bitcoin/pull/27626#discussion_r1191449571)
don't love your name suggestion; changed the initialization though
(https://github.com/bitcoin/bitcoin/pull/27626#discussion_r1191449571)
don't love your name suggestion; changed the initialization though
💬 ajtowns commented on pull request "Parallel compact block downloads, take 3":
(https://github.com/bitcoin/bitcoin/pull/27626#discussion_r1191449589)
I think the limit's fine; when you start up with an empty mempool, you'll be requesting most of the transactions in the block because your mempool's empty, and there's no need to do that three times in parallel. Could perhaps have the limit work the other way: if you've already got N txs and need K txs, and `0 < K <= N/4 + 10`; then if the block just has ten 100kvB txs, you won't request them multiple times.
(https://github.com/bitcoin/bitcoin/pull/27626#discussion_r1191449589)
I think the limit's fine; when you start up with an empty mempool, you'll be requesting most of the transactions in the block because your mempool's empty, and there's no need to do that three times in parallel. Could perhaps have the limit work the other way: if you've already got N txs and need K txs, and `0 < K <= N/4 + 10`; then if the block just has ten 100kvB txs, you won't request them multiple times.
💬 hebasto commented on pull request "build: Fix shared lib linking for darwin with lld":
(https://github.com/bitcoin/bitcoin/pull/27628#issuecomment-1544334336)
> Solves one of the last remaining blockers for #21778.
Concept ACK on that.
> And @hebasto, because I know you love libtool hacks ;)
I believe we'll manage to switch to CMake earlier :)
(https://github.com/bitcoin/bitcoin/pull/27628#issuecomment-1544334336)
> Solves one of the last remaining blockers for #21778.
Concept ACK on that.
> And @hebasto, because I know you love libtool hacks ;)
I believe we'll manage to switch to CMake earlier :)
💬 hebasto commented on pull request "wallet: fix deadlock in bdb read write operation":
(https://github.com/bitcoin/bitcoin/pull/27556#discussion_r1191456854)
A note for myself: Seems unfortunate to `reset` a `std::unique_ptr` instance explicitly instead of using its RAII capabilities.
(https://github.com/bitcoin/bitcoin/pull/27556#discussion_r1191456854)
A note for myself: Seems unfortunate to `reset` a `std::unique_ptr` instance explicitly instead of using its RAII capabilities.
💬 theuni commented on pull request "build: Fix shared lib linking for darwin with lld":
(https://github.com/bitcoin/bitcoin/pull/27628#issuecomment-1544340008)
> > And @hebasto, because I know you love libtool hacks ;)
>
> I believe we'll manage to switch to CMake earlier :)
Hahaha, you're probably right about that. But at least this way there's no "well it didn't work with autotools so it doesn't have to work with CMake" excuse :p
(https://github.com/bitcoin/bitcoin/pull/27628#issuecomment-1544340008)
> > And @hebasto, because I know you love libtool hacks ;)
>
> I believe we'll manage to switch to CMake earlier :)
Hahaha, you're probably right about that. But at least this way there's no "well it didn't work with autotools so it doesn't have to work with CMake" excuse :p
📝 fanquake opened a pull request: "doc: remove version number from bips.md"
(https://github.com/bitcoin/bitcoin/pull/27629)
This always just needs "bumping" (see previous rc type pulls), and the version number is already whichever version of the code you acquired bips.md with.
(https://github.com/bitcoin/bitcoin/pull/27629)
This always just needs "bumping" (see previous rc type pulls), and the version number is already whichever version of the code you acquired bips.md with.