👍 stickies-v approved a pull request: "[26.x] backports and final changes for 26.2rc1"
(https://github.com/bitcoin/bitcoin/pull/30260#pullrequestreview-2107948460)
ACK 7ca424f8e651707effe1380aaf72d9ad0e97aa18
I checked that:
- backport is clean
- manpages are identical to mine
- translations are identical to mine, except for the removal of the languages mentioned in the commit message, which appears to be vandalism
- release notes are correct
(https://github.com/bitcoin/bitcoin/pull/30260#pullrequestreview-2107948460)
ACK 7ca424f8e651707effe1380aaf72d9ad0e97aa18
I checked that:
- backport is clean
- manpages are identical to mine
- translations are identical to mine, except for the removal of the languages mentioned in the commit message, which appears to be vandalism
- release notes are correct
👍 brunoerg approved a pull request: "test: Remove redundant verack check"
(https://github.com/bitcoin/bitcoin/pull/30252#pullrequestreview-2107960087)
ACK 0000276b31cea5e443a59d94a98c569293ada951
(https://github.com/bitcoin/bitcoin/pull/30252#pullrequestreview-2107960087)
ACK 0000276b31cea5e443a59d94a98c569293ada951
👍 ryanofsky approved a pull request: "Introduce Mining interface"
(https://github.com/bitcoin/bitcoin/pull/30200#pullrequestreview-2107880187)
Code review ACK febd3d1c3d41cf6083baf990fb2a3a69cade364a
(https://github.com/bitcoin/bitcoin/pull/30200#pullrequestreview-2107880187)
Code review ACK febd3d1c3d41cf6083baf990fb2a3a69cade364a
💬 ryanofsky commented on pull request "Introduce Mining interface":
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1633297880)
In commit "rpc: getblocktemplate getTip() via Miner interface" (9c226c5c3818ef157fc50a5f6ecc534a612ac1d0)
Commit message could be updated since this now called getTipHash
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1633297880)
In commit "rpc: getblocktemplate getTip() via Miner interface" (9c226c5c3818ef157fc50a5f6ecc534a612ac1d0)
Commit message could be updated since this now called getTipHash
💬 ryanofsky commented on pull request "Introduce Mining interface":
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1633296276)
In commit "rpc: call TestBlockValidity via miner interface" (8589e6c44726d6b5760095d72c37934e4be3315c)
Why is the `testBlockValidity` check being moved before the block.hashPrevBlock != tip check? The previous ordering seemed more straightforward and consistent with "TestBlockValidity only supports blocks built on the current Tip" comment
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1633296276)
In commit "rpc: call TestBlockValidity via miner interface" (8589e6c44726d6b5760095d72c37934e4be3315c)
Why is the `testBlockValidity` check being moved before the block.hashPrevBlock != tip check? The previous ordering seemed more straightforward and consistent with "TestBlockValidity only supports blocks built on the current Tip" comment
💬 ryanofsky commented on pull request "Introduce Mining interface":
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1633318785)
In commit "rpc: call CreateNewBlock via miner interface" (f375fb9a0dff7ccead80626f4aee853db7799e6f)
It might be good to keep this ApplyArgsManOptions function for more consistency with other options parsing code. The node/interfaces.cpp createNewBlock function could call ApplyArgsManOptions instead of parsing options itself. The current approach also seems ok though if you prefer it.
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1633318785)
In commit "rpc: call CreateNewBlock via miner interface" (f375fb9a0dff7ccead80626f4aee853db7799e6f)
It might be good to keep this ApplyArgsManOptions function for more consistency with other options parsing code. The node/interfaces.cpp createNewBlock function could call ApplyArgsManOptions instead of parsing options itself. The current approach also seems ok though if you prefer it.
💬 ryanofsky commented on pull request "Introduce Mining interface":
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1633363110)
In commit "rpc: call CreateNewBlock via miner interface" (f375fb9a0dff7ccead80626f4aee853db7799e6f)
I'm not clear how this implementation lines up with the commit description which says "the pool communicates how many extra bytes it needs for its own outputs (payouts, extra commitments, etc). This needs to be substracted from what the user set as -blockmaxweight."
Is the commit description just saying that this implementation is not complete and it will need to be extended in the future? W
...
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1633363110)
In commit "rpc: call CreateNewBlock via miner interface" (f375fb9a0dff7ccead80626f4aee853db7799e6f)
I'm not clear how this implementation lines up with the commit description which says "the pool communicates how many extra bytes it needs for its own outputs (payouts, extra commitments, etc). This needs to be substracted from what the user set as -blockmaxweight."
Is the commit description just saying that this implementation is not complete and it will need to be extended in the future? W
...
👍 ryanofsky approved a pull request: "validation: improve performance of CheckBlockIndex"
(https://github.com/bitcoin/bitcoin/pull/28339#pullrequestreview-2108028986)
Code review ACK 5bc2077e8f592442b089affdf0b5795fbc053bb8. Just added suggested assert and simplification since last review
(https://github.com/bitcoin/bitcoin/pull/28339#pullrequestreview-2108028986)
Code review ACK 5bc2077e8f592442b089affdf0b5795fbc053bb8. Just added suggested assert and simplification since last review
💬 Sjors commented on pull request "Introduce Mining interface":
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1633391557)
Yes, this is a reference to the future change in sv2. I'll see if I can reword it.
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1633391557)
Yes, this is a reference to the future change in sv2. I'll see if I can reword it.
💬 maflcko commented on pull request "log: use error level for critical log messages":
(https://github.com/bitcoin/bitcoin/pull/30255#discussion_r1633421463)
I think it is fine to have this log, but happy to review a separate pull removing it :)
(https://github.com/bitcoin/bitcoin/pull/30255#discussion_r1633421463)
I think it is fine to have this log, but happy to review a separate pull removing it :)
💬 maflcko commented on pull request "log: use error level for critical log messages":
(https://github.com/bitcoin/bitcoin/pull/30255#discussion_r1633423562)
This reminded me to change the two other log lines before `fatalError` to use the error level. So I pushed that other change in the last push.
(https://github.com/bitcoin/bitcoin/pull/30255#discussion_r1633423562)
This reminded me to change the two other log lines before `fatalError` to use the error level. So I pushed that other change in the last push.
💬 mzumsande commented on pull request "refactor: move m_is_inbound out of CNodeState":
(https://github.com/bitcoin/bitcoin/pull/30233#discussion_r1633424948)
The primary source of that information is `CNode::m_conn_type`. Is it necessary to have a partial copy of that in `Peer`?
If not, an alternative approach might be to use that, as is done for various other spots in net_processing that call `IsInboundConn()`. We might need also need helper functions similar to `GetExtraBlockRelayCount` but for inbounds. I haven't tried it or looked into it in depth, but just wanted to bring up where you've considered that option.
(https://github.com/bitcoin/bitcoin/pull/30233#discussion_r1633424948)
The primary source of that information is `CNode::m_conn_type`. Is it necessary to have a partial copy of that in `Peer`?
If not, an alternative approach might be to use that, as is done for various other spots in net_processing that call `IsInboundConn()`. We might need also need helper functions similar to `GetExtraBlockRelayCount` but for inbounds. I haven't tried it or looked into it in depth, but just wanted to bring up where you've considered that option.
⚠️ Sjors opened an issue: "Add bitcoind and bitcoin-cli to macOS release"
(https://github.com/bitcoin/bitcoin/issues/30262)
### Please describe the feature you'd like to see added.
Currently the macOS downloads only contain bitcoin-qt.
It would be nice to have the other binaries as well, especially `bitcoin-cli`. Currently the user has to compile these themselves.
### Is your feature related to a problem, if so please describe it.
E.g. for a Stratum v2 workshop the instructions for macOS have to completely different than for Linux, because the latter can use the command-line. https://github.com/plebhash/sv2-wor
...
(https://github.com/bitcoin/bitcoin/issues/30262)
### Please describe the feature you'd like to see added.
Currently the macOS downloads only contain bitcoin-qt.
It would be nice to have the other binaries as well, especially `bitcoin-cli`. Currently the user has to compile these themselves.
### Is your feature related to a problem, if so please describe it.
E.g. for a Stratum v2 workshop the instructions for macOS have to completely different than for Linux, because the latter can use the command-line. https://github.com/plebhash/sv2-wor
...
💬 Sjors commented on pull request "Introduce Mining interface":
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1633492530)
I split f375fb9a0dff7ccead80626f4aee853db7799e6f in two parts:
1. 6d6ddcb759465c7375ff772faa960cf92805468a simply adds and uses the interface
2. 6b7c8c3e27ae529306d18019e7bd94b4ae5b9a21 drops the `BlockAssembler` constructor without `options` argument
I changed this second commit to keep `ApplyArgsManOptions`.
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1633492530)
I split f375fb9a0dff7ccead80626f4aee853db7799e6f in two parts:
1. 6d6ddcb759465c7375ff772faa960cf92805468a simply adds and uses the interface
2. 6b7c8c3e27ae529306d18019e7bd94b4ae5b9a21 drops the `BlockAssembler` constructor without `options` argument
I changed this second commit to keep `ApplyArgsManOptions`.
💬 Sjors commented on pull request "Introduce Mining interface":
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1633492626)
Done
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1633492626)
Done
💬 Sjors commented on pull request "Introduce Mining interface":
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1633492703)
I think that was by accident. Moved it back.
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1633492703)
I think that was by accident. Moved it back.
👍 tdb3 approved a pull request: "test: Remove redundant verack check"
(https://github.com/bitcoin/bitcoin/pull/30252#pullrequestreview-2108210705)
ACK 0000276b31cea5e443a59d94a98c569293ada951
(https://github.com/bitcoin/bitcoin/pull/30252#pullrequestreview-2108210705)
ACK 0000276b31cea5e443a59d94a98c569293ada951
👍 theStack approved a pull request: "util: add BitSet"
(https://github.com/bitcoin/bitcoin/pull/30160#pullrequestreview-2108226640)
Code-review ACK 47f705b33fc1381d96c99038e2110e6fe2b2f883
(https://github.com/bitcoin/bitcoin/pull/30160#pullrequestreview-2108226640)
Code-review ACK 47f705b33fc1381d96c99038e2110e6fe2b2f883
💬 paplorinc commented on pull request "refactor: reserve memory allocation for transaction outputs":
(https://github.com/bitcoin/bitcoin/pull/30093#issuecomment-2158816952)
Thanks for the review @josibake, I've added the conclusions of the benchmarks to the commit message (but copied it to the PR description as well now), can you please check if https://github.com/bitcoin/bitcoin/pull/30093/commits/ebf8667f634653a2eebe404469bfb62c5bb3add2 answers your questions?
@theuni, appreciate your previous reviews and insights, please take a look at the changes I did since.
(https://github.com/bitcoin/bitcoin/pull/30093#issuecomment-2158816952)
Thanks for the review @josibake, I've added the conclusions of the benchmarks to the commit message (but copied it to the PR description as well now), can you please check if https://github.com/bitcoin/bitcoin/pull/30093/commits/ebf8667f634653a2eebe404469bfb62c5bb3add2 answers your questions?
@theuni, appreciate your previous reviews and insights, please take a look at the changes I did since.
📝 maflcko opened a pull request: "build: Bump clang minimum supported version to 16"
(https://github.com/bitcoin/bitcoin/pull/30263)
Most supported operating systems ship with clang-16 (or later), so bump the minimum to that and allow new code to drop workarounds for previous clang bugs.
For reference:
* https://packages.debian.org/bookworm/clang-16
* https://packages.ubuntu.com/noble/clang (clang-18)
* CentOS-like 8/9 Stream: All Clang versions from 15 to 17
* FreeBSD 12/13: All Clang versions from 15 to 16
* OpenSuse Tumbleweed ships with https://software.opensuse.org/package/clang (`clang18`); No idea about OpenSus
...
(https://github.com/bitcoin/bitcoin/pull/30263)
Most supported operating systems ship with clang-16 (or later), so bump the minimum to that and allow new code to drop workarounds for previous clang bugs.
For reference:
* https://packages.debian.org/bookworm/clang-16
* https://packages.ubuntu.com/noble/clang (clang-18)
* CentOS-like 8/9 Stream: All Clang versions from 15 to 17
* FreeBSD 12/13: All Clang versions from 15 to 16
* OpenSuse Tumbleweed ships with https://software.opensuse.org/package/clang (`clang18`); No idea about OpenSus
...