💬 Sjors commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1937839814)
It would require a second thread, because the main thread of the unit test is waiting on `waitNext()`.
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1937839814)
It would require a second thread, because the main thread of the unit test is waiting on `waitNext()`.
💬 achow101 commented on pull request "rpc: have getblocktemplate mintime account for timewarp":
(https://github.com/bitcoin/bitcoin/pull/31600#issuecomment-2628184000)
ACK e1676b08f7b0b9a6c8ed76e31f24faa03a3facc9
(https://github.com/bitcoin/bitcoin/pull/31600#issuecomment-2628184000)
ACK e1676b08f7b0b9a6c8ed76e31f24faa03a3facc9
💬 achow101 commented on pull request "test: Added coverage to the waitfornewblock rpc":
(https://github.com/bitcoin/bitcoin/pull/31746#issuecomment-2628229678)
ACK 93747d934b8a5a1732732a958c0d7e2f5dd0b8c2
(https://github.com/bitcoin/bitcoin/pull/31746#issuecomment-2628229678)
ACK 93747d934b8a5a1732732a958c0d7e2f5dd0b8c2
🚀 achow101 merged a pull request: "rpc: have getblocktemplate mintime account for timewarp"
(https://github.com/bitcoin/bitcoin/pull/31600)
(https://github.com/bitcoin/bitcoin/pull/31600)
🚀 achow101 merged a pull request: "test: Added coverage to the waitfornewblock rpc"
(https://github.com/bitcoin/bitcoin/pull/31746)
(https://github.com/bitcoin/bitcoin/pull/31746)
👍 pinheadmz approved a pull request: "mining: bugfix: Fix duplicate coinbase tx weight reservation"
(https://github.com/bitcoin/bitcoin/pull/31384#pullrequestreview-2587643094)
ACK fd4af64d58901334d907dd0bd38efd303a21374a
This patch consolidates two 4000 WU reservations into one constant, and adjusts configuration parameters to maintain existing behavior. It allows more fine tuned control of block template creation and in particular will allow some mining pools to squeeze an extra 4000 WU of transaction data into new blocks.
Reviewed each commit (again). Built and ran unit and functional tests on macos/arm.
I left a few if-you-touch nits below to improve clarity
...
(https://github.com/bitcoin/bitcoin/pull/31384#pullrequestreview-2587643094)
ACK fd4af64d58901334d907dd0bd38efd303a21374a
This patch consolidates two 4000 WU reservations into one constant, and adjusts configuration parameters to maintain existing behavior. It allows more fine tuned control of block template creation and in particular will allow some mining pools to squeeze an extra 4000 WU of transaction data into new blocks.
Reviewed each commit (again). Built and ran unit and functional tests on macos/arm.
I left a few if-you-touch nits below to improve clarity
...
💬 pinheadmz commented on pull request "mining: bugfix: Fix duplicate coinbase tx weight reservation":
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1937881476)
c39ad81353d89cd60eabd6343263afed91d9060d
same thought here about using policy constant but describing consensus constant in the message
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1937881476)
c39ad81353d89cd60eabd6343263afed91d9060d
same thought here about using policy constant but describing consensus constant in the message
💬 pinheadmz commented on pull request "mining: bugfix: Fix duplicate coinbase tx weight reservation":
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1937875968)
c39ad81353d89cd60eabd6343263afed91d9060d
another nit-if-you-touch:
I think "...and the block header" is a little confusing in this sentence. Does `blockreseredweight` include the header or not?
If it does I think this is more clear:
> "Reserve space to account for the largest coinbase transaction and block header that mining software may add to the block"
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1937875968)
c39ad81353d89cd60eabd6343263afed91d9060d
another nit-if-you-touch:
I think "...and the block header" is a little confusing in this sentence. Does `blockreseredweight` include the header or not?
If it does I think this is more clear:
> "Reserve space to account for the largest coinbase transaction and block header that mining software may add to the block"
💬 pinheadmz commented on pull request "mining: bugfix: Fix duplicate coinbase tx weight reservation":
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1937828541)
b7ec4bf672425c71211415c2ea83e05a246ea66d
nit only if you touch, I think it would make more sense to use the consensus value `MAX_BLOCK_WEIGHT` of course that is equal to the default policy value anyway (for now) but the error message specifically refers to the consensus limit
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1937828541)
b7ec4bf672425c71211415c2ea83e05a246ea66d
nit only if you touch, I think it would make more sense to use the consensus value `MAX_BLOCK_WEIGHT` of course that is equal to the default policy value anyway (for now) but the error message specifically refers to the consensus limit
💬 pinheadmz commented on pull request "mining: bugfix: Fix duplicate coinbase tx weight reservation":
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1937885553)
c39ad81353d89cd60eabd6343263afed91d9060d
nit: Doesn't really matter but I'm just noticing you are instantiating an object just to get a constant from it. Feels like a cleaner option would be to define `DEFAULT_BLOCK_RESERVED_WEIGHT`
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1937885553)
c39ad81353d89cd60eabd6343263afed91d9060d
nit: Doesn't really matter but I'm just noticing you are instantiating an object just to get a constant from it. Feels like a cleaner option would be to define `DEFAULT_BLOCK_RESERVED_WEIGHT`
🤔 fjahr reviewed a pull request: "mining: bugfix: Fix duplicate coinbase tx weight reservation"
(https://github.com/bitcoin/bitcoin/pull/31384#pullrequestreview-2587690660)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/31384#pullrequestreview-2587690660)
Concept ACK
💬 fjahr commented on pull request "mining: bugfix: Fix duplicate coinbase tx weight reservation":
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1937862071)
Couldn't you use `send_self_transfer_multi` instead?
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1937862071)
Couldn't you use `send_self_transfer_multi` instead?
💬 fjahr commented on pull request "mining: bugfix: Fix duplicate coinbase tx weight reservation":
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1937893671)
nit: not sure if this will need to be reformatted later. Usually there is just one bullet per PR/change and it seems like this could be just one block of text. Just to take some editing headache from whoever manages the release...
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1937893671)
nit: not sure if this will need to be reformatted later. Usually there is just one bullet per PR/change and it seems like this could be just one block of text. Just to take some editing headache from whoever manages the release...
💬 fjahr commented on pull request "mining: bugfix: Fix duplicate coinbase tx weight reservation":
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1937931886)
Why not check this against `max_block_weight` instead? The current behavior isn't catastrophic I guess because the clamping later silently fixes this. But it seems like the user is doing something wrong and in the case below we are throwing an error too instead of silently fixing it. Seems a little inconsistent at least.
```suggestion
if (block_reserved_weight > max_block_weight) {
```
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1937931886)
Why not check this against `max_block_weight` instead? The current behavior isn't catastrophic I guess because the clamping later silently fixes this. But it seems like the user is doing something wrong and in the case below we are throwing an error too instead of silently fixing it. Seems a little inconsistent at least.
```suggestion
if (block_reserved_weight > max_block_weight) {
```
📝 davidgumberg opened a pull request: "crypto: Use secure_allocator for `AES256_ctx`"
(https://github.com/bitcoin/bitcoin/pull/31774)
Fixes #31744
Reuse `secure_allocator` for `AES256_ctx` in the aes 256 encrypters and decrypters and the `iv` of `AES256CBC` encrypters and decrypters. These classes are relevant to `CCrypter`, used for encrypting wallets, and my understanding is that if an attacker knows some or all of the contents of these data structures (`AES256_ctx` & `iv`) they might be able to decrypt a user's wallet.
Presently the `secure_allocator` tries to protect sensitive data with `mlock()` on POSIX systems a
...
(https://github.com/bitcoin/bitcoin/pull/31774)
Fixes #31744
Reuse `secure_allocator` for `AES256_ctx` in the aes 256 encrypters and decrypters and the `iv` of `AES256CBC` encrypters and decrypters. These classes are relevant to `CCrypter`, used for encrypting wallets, and my understanding is that if an attacker knows some or all of the contents of these data structures (`AES256_ctx` & `iv`) they might be able to decrypt a user's wallet.
Presently the `secure_allocator` tries to protect sensitive data with `mlock()` on POSIX systems a
...
💬 achow101 commented on pull request "kernel: Move block tree db open to block manager":
(https://github.com/bitcoin/bitcoin/pull/30965#issuecomment-2628328237)
ACK 0cdddeb2240d1f33c8b2dd28bb0c9d84d9420e3d
(https://github.com/bitcoin/bitcoin/pull/30965#issuecomment-2628328237)
ACK 0cdddeb2240d1f33c8b2dd28bb0c9d84d9420e3d
💬 fjahr commented on pull request "mining: bugfix: Fix duplicate coinbase tx weight reservation":
(https://github.com/bitcoin/bitcoin/pull/31384#issuecomment-2628344352)
> This patch consolidates two 4000 WU reservations into one constant, and adjusts configuration parameters to maintain existing behavior. It allows more fine tuned control of block template creation and in particular will allow some mining pools to squeeze an extra 4000 WU of transaction data into new blocks.
Only an extra 2000 WU, right? Before the change setting setting blockmaxheight to max led to the actual minimum reserved 4000 WU. After the change there is the explicit minimum of 2000 W
...
(https://github.com/bitcoin/bitcoin/pull/31384#issuecomment-2628344352)
> This patch consolidates two 4000 WU reservations into one constant, and adjusts configuration parameters to maintain existing behavior. It allows more fine tuned control of block template creation and in particular will allow some mining pools to squeeze an extra 4000 WU of transaction data into new blocks.
Only an extra 2000 WU, right? Before the change setting setting blockmaxheight to max led to the actual minimum reserved 4000 WU. After the change there is the explicit minimum of 2000 W
...
🚀 achow101 merged a pull request: "kernel: Move block tree db open to block manager"
(https://github.com/bitcoin/bitcoin/pull/30965)
(https://github.com/bitcoin/bitcoin/pull/30965)
💬 ismaelsadeeq commented on pull request "mining: bugfix: Fix duplicate coinbase tx weight reservation":
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1937951204)
My plan is to eventually remove the blockmaxweight option in a follow-up. See last sentence in [this comment](https://github.com/bitcoin/bitcoin/pull/31384#issuecomment-2567472713). The behavior you describe is an edge case that is possible, but as you said, the clamping fixes it.
I think it is consistent to compare using `DEFAULT_BLOCK_MAX_WEIGHT` because, eventually, the block-reserved weight will be passed through the mining interface.
See the previous discussion on this [here](https:/
...
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1937951204)
My plan is to eventually remove the blockmaxweight option in a follow-up. See last sentence in [this comment](https://github.com/bitcoin/bitcoin/pull/31384#issuecomment-2567472713). The behavior you describe is an edge case that is possible, but as you said, the clamping fixes it.
I think it is consistent to compare using `DEFAULT_BLOCK_MAX_WEIGHT` because, eventually, the block-reserved weight will be passed through the mining interface.
See the previous discussion on this [here](https:/
...
💬 ismaelsadeeq commented on pull request "mining: bugfix: Fix duplicate coinbase tx weight reservation":
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1937940475)
IIUC `send_self_transfer_multi` is creating and broadcasting a single transaction spending multiple UTXO's, in this case I want to create multiple transactions each spending a single UTXO.
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1937940475)
IIUC `send_self_transfer_multi` is creating and broadcasting a single transaction spending multiple UTXO's, in this case I want to create multiple transactions each spending a single UTXO.
💬 achow101 commented on pull request "wallet, assumeutxo: Don't Assume m_chain_tx_count, Improve wallet RPC errors":
(https://github.com/bitcoin/bitcoin/pull/30909#issuecomment-2628359009)
ACK 9d2d9f7ce29636f08322df70cf6abec8e0ca3727
(https://github.com/bitcoin/bitcoin/pull/30909#issuecomment-2628359009)
ACK 9d2d9f7ce29636f08322df70cf6abec8e0ca3727