💬 josibake commented on pull request "Silent Payments: sending":
(https://github.com/bitcoin/bitcoin/pull/28201#discussion_r2228447040)
This is fine, actually. What we are doing here is making sure to _never_ include a taproot with script path spend or a witness unknown spend. We can include Pay2Pubkey inputs, so long as there is at least one silent payments eligible input.
In the `CreateSilentPaymentsOutputs` function, we check for at least one eligible input here: https://github.com/bitcoin/bitcoin/blob/4225ebc65595b5ef0f661b4f41e3e21266b93575/src/wallet/spend.cpp#L1116, by calling the `IsInputForSharedSecretDerivation` fun
...
(https://github.com/bitcoin/bitcoin/pull/28201#discussion_r2228447040)
This is fine, actually. What we are doing here is making sure to _never_ include a taproot with script path spend or a witness unknown spend. We can include Pay2Pubkey inputs, so long as there is at least one silent payments eligible input.
In the `CreateSilentPaymentsOutputs` function, we check for at least one eligible input here: https://github.com/bitcoin/bitcoin/blob/4225ebc65595b5ef0f661b4f41e3e21266b93575/src/wallet/spend.cpp#L1116, by calling the `IsInputForSharedSecretDerivation` fun
...
💬 b-l-u-e commented on pull request "rpc: Fix internal bug in descriptorprocesspsbt when encountering invalid signatures":
(https://github.com/bitcoin/bitcoin/pull/33014#issuecomment-3113382620)
@achow101...You were right, my initial approach was incorrect. I now understand that CHECK_NONFATAL is correctly protecting the invariant that a PSBT marked as complete must be finalizable.
The actual bug, as you pointed out, was that the completeness check was too lenient, only checking for the presence of a signature rather than its cryptographic validity.
After ensuring that the logic first verifies the existing signatures before declaring the PSBT complete (the approach you suggested w
...
(https://github.com/bitcoin/bitcoin/pull/33014#issuecomment-3113382620)
@achow101...You were right, my initial approach was incorrect. I now understand that CHECK_NONFATAL is correctly protecting the invariant that a PSBT marked as complete must be finalizable.
The actual bug, as you pointed out, was that the completeness check was too lenient, only checking for the presence of a signature rather than its cryptographic validity.
After ensuring that the logic first verifies the existing signatures before declaring the PSBT complete (the approach you suggested w
...
🤔 darosior reviewed a pull request: "net, validation: don't punish peers for consensus-invalid txs"
(https://github.com/bitcoin/bitcoin/pull/33050#pullrequestreview-3051560671)
Concept ACK.
(https://github.com/bitcoin/bitcoin/pull/33050#pullrequestreview-3051560671)
Concept ACK.
💬 darosior commented on pull request "net, validation: don't punish peers for consensus-invalid txs":
(https://github.com/bitcoin/bitcoin/pull/33050#discussion_r2228448364)
You might as well drop `expect_disconnect` in the templates then, instead of setting it to False both there and here? Also the reconnect logic just below here is now dead code.
(https://github.com/bitcoin/bitcoin/pull/33050#discussion_r2228448364)
You might as well drop `expect_disconnect` in the templates then, instead of setting it to False both there and here? Also the reconnect logic just below here is now dead code.
💬 darosior commented on pull request "net, validation: don't punish peers for consensus-invalid txs":
(https://github.com/bitcoin/bitcoin/pull/33050#discussion_r2228460217)
This could make a non-standard transaction error with "non-mandatory-script-verify-flag", which would be confusing. I think we can just drop the mandatoriness language.
```diff
- return state.Invalid(TxValidationResult::TX_NOT_STANDARD, strprintf("non-mandatory-script-verify-flag (%s)", ScriptErrorString(result->first)), result->second);
+ return state.Invalid(TxValidationResult::TX_NOT_STANDARD, strprintf("script validation failed (%s)", ScriptErrorString(result->first)), result->second);
...
(https://github.com/bitcoin/bitcoin/pull/33050#discussion_r2228460217)
This could make a non-standard transaction error with "non-mandatory-script-verify-flag", which would be confusing. I think we can just drop the mandatoriness language.
```diff
- return state.Invalid(TxValidationResult::TX_NOT_STANDARD, strprintf("non-mandatory-script-verify-flag (%s)", ScriptErrorString(result->first)), result->second);
+ return state.Invalid(TxValidationResult::TX_NOT_STANDARD, strprintf("script validation failed (%s)", ScriptErrorString(result->first)), result->second);
...
💬 darosior commented on pull request "script: return verification flag responsible for error upon validation failure":
(https://github.com/bitcoin/bitcoin/pull/33012#issuecomment-3113410847)
> Someone recently made the point that we already have a lot of code to maintain in bitcoin core
A wise man! More seriously, i was merely pointing out the tradeoff here. Not saying this PR is the better alternative to #33050. I am out of rationalization for the existing behaviour anyways, so might as well take a red diff over a green one.
(https://github.com/bitcoin/bitcoin/pull/33012#issuecomment-3113410847)
> Someone recently made the point that we already have a lot of code to maintain in bitcoin core
A wise man! More seriously, i was merely pointing out the tradeoff here. Not saying this PR is the better alternative to #33050. I am out of rationalization for the existing behaviour anyways, so might as well take a red diff over a green one.
💬 marcofleon commented on pull request "[29.x] Backport #32521":
(https://github.com/bitcoin/bitcoin/pull/33013#issuecomment-3113414394)
reACK f25dc84b2892e6bdbbd0471add9fcb2757700981
(https://github.com/bitcoin/bitcoin/pull/33013#issuecomment-3113414394)
reACK f25dc84b2892e6bdbbd0471add9fcb2757700981
💬 Sjors commented on pull request "Add bitcoin-{node,gui} to release binaries for IPC":
(https://github.com/bitcoin/bitcoin/pull/31802#issuecomment-3113414578)
Rebased after #32888. I ended up indenting the list of apt installed packages for the `test-each-commit` job, which might reduce future conflicts.
(https://github.com/bitcoin/bitcoin/pull/31802#issuecomment-3113414578)
Rebased after #32888. I ended up indenting the list of apt installed packages for the `test-each-commit` job, which might reduce future conflicts.
💬 fanquake commented on pull request "ci: Use optimized Debug build type in test-each-commit":
(https://github.com/bitcoin/bitcoin/pull/32888#issuecomment-3113467932)
A run of the new job / flags here: https://github.com/bitcoin/bitcoin/actions/runs/16495974354/job/46641652091?pr=33044.
(https://github.com/bitcoin/bitcoin/pull/32888#issuecomment-3113467932)
A run of the new job / flags here: https://github.com/bitcoin/bitcoin/actions/runs/16495974354/job/46641652091?pr=33044.
💬 fjahr commented on pull request "test, refactor: Embedded ASmap selected preparatory work":
(https://github.com/bitcoin/bitcoin/pull/33026#discussion_r2228533987)
I can drop this is other reviewers agree that it's confusing. I personally think this is the more intuitive behavior for path args independently of asmap because our bool args all work with both `-foo` and `-foo=1` afaik. If the user wants to use `-asmap` (or any path arg) as a bool then I think they would expect it to work the same as the other bool params. Fwiw, I discovered this because I wrote a functional test that covered `-asmap=1` and I actually expected it work, only after it didn't I a
...
(https://github.com/bitcoin/bitcoin/pull/33026#discussion_r2228533987)
I can drop this is other reviewers agree that it's confusing. I personally think this is the more intuitive behavior for path args independently of asmap because our bool args all work with both `-foo` and `-foo=1` afaik. If the user wants to use `-asmap` (or any path arg) as a bool then I think they would expect it to work the same as the other bool params. Fwiw, I discovered this because I wrote a functional test that covered `-asmap=1` and I actually expected it work, only after it didn't I a
...
💬 ryanofsky commented on pull request "cmake: Move internal binaries from bin/ to libexec/":
(https://github.com/bitcoin/bitcoin/pull/31679#issuecomment-3113495899)
This PR has several acks, but it would be helpful if someone familiar with the build system could review the first commit here cd97905ebc564b8b095099a28d1d5437951927c4 and provide feedback. The other commits are all documentation commits, so less critical. @hebasto @fanquake @theuni @maflcko @purpleKarrot might bit good candidates according to git log (sorry if I forgot anyone).
Related PR #31802 switching on the `ENABLE_IPC` option is a similar state, and could use some build system review.
...
(https://github.com/bitcoin/bitcoin/pull/31679#issuecomment-3113495899)
This PR has several acks, but it would be helpful if someone familiar with the build system could review the first commit here cd97905ebc564b8b095099a28d1d5437951927c4 and provide feedback. The other commits are all documentation commits, so less critical. @hebasto @fanquake @theuni @maflcko @purpleKarrot might bit good candidates according to git log (sorry if I forgot anyone).
Related PR #31802 switching on the `ENABLE_IPC` option is a similar state, and could use some build system review.
...
📝 darosior opened a pull request: "[29.x] backport #32069"
(https://github.com/bitcoin/bitcoin/pull/33052)
Backport https://github.com/bitcoin/bitcoin/pull/32069 to 29. This is a test flakiness fix for https://github.com/bitcoin/bitcoin/pull/31757, which was backported to 29 in https://github.com/bitcoin/bitcoin/pull/32589.
(https://github.com/bitcoin/bitcoin/pull/33052)
Backport https://github.com/bitcoin/bitcoin/pull/32069 to 29. This is a test flakiness fix for https://github.com/bitcoin/bitcoin/pull/31757, which was backported to 29 in https://github.com/bitcoin/bitcoin/pull/32589.
💬 darosior commented on pull request "[29.x] Backport #32521":
(https://github.com/bitcoin/bitcoin/pull/33013#issuecomment-3113500474)
Opened a separate backport PR for the flakiness fix: https://github.com/bitcoin/bitcoin/pull/33052
(https://github.com/bitcoin/bitcoin/pull/33013#issuecomment-3113500474)
Opened a separate backport PR for the flakiness fix: https://github.com/bitcoin/bitcoin/pull/33052
💬 fanquake commented on pull request "test: fix intermittent failure in wallet_reorgsrestore.py":
(https://github.com/bitcoin/bitcoin/pull/32069#issuecomment-3113519822)
Backported to `29.x` in #33052.
(https://github.com/bitcoin/bitcoin/pull/32069#issuecomment-3113519822)
Backported to `29.x` in #33052.
👍 ryanofsky approved a pull request: "Add bitcoin-{node,gui} to release binaries for IPC"
(https://github.com/bitcoin/bitcoin/pull/31802#pullrequestreview-3051726249)
Code review ACK 241e9d14879abbc75a17dba764ef2ad58179db57. Just rebased since last review
(https://github.com/bitcoin/bitcoin/pull/31802#pullrequestreview-3051726249)
Code review ACK 241e9d14879abbc75a17dba764ef2ad58179db57. Just rebased since last review
💬 ryanofsky commented on pull request "Add bitcoin-{node,gui} to release binaries for IPC":
(https://github.com/bitcoin/bitcoin/pull/31802#discussion_r2228555002)
In commit "cmake: enable ENABLE_IPC option by default" (969a9472a43b7e8c0ae1b8d0dd1a71e5d118ea0c)
Maybe sort these while you are splitting them up. libboost-dev libqrencode-dev and systemtap-sdt-dev seem to be the only entries out of order.
(https://github.com/bitcoin/bitcoin/pull/31802#discussion_r2228555002)
In commit "cmake: enable ENABLE_IPC option by default" (969a9472a43b7e8c0ae1b8d0dd1a71e5d118ea0c)
Maybe sort these while you are splitting them up. libboost-dev libqrencode-dev and systemtap-sdt-dev seem to be the only entries out of order.
💬 purpleKarrot commented on pull request "cmake: Move internal binaries from bin/ to libexec/":
(https://github.com/bitcoin/bitcoin/pull/31679#issuecomment-3113533739)
I confirm that the change to the CMake code is OK. I am not very fond of the `install_binary_component` function, but that is orthogonal to the PR.
(https://github.com/bitcoin/bitcoin/pull/31679#issuecomment-3113533739)
I confirm that the change to the CMake code is OK. I am not very fond of the `install_binary_component` function, but that is orthogonal to the PR.
💬 maflcko commented on pull request "rpc: Fix internal bug in descriptorprocesspsbt when encountering invalid signatures":
(https://github.com/bitcoin/bitcoin/pull/33014#issuecomment-3113534833)
Please squash your commits according to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits
(https://github.com/bitcoin/bitcoin/pull/33014#issuecomment-3113534833)
Please squash your commits according to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits
💬 fjahr commented on pull request "test, refactor: Embedded ASmap selected preparatory work":
(https://github.com/bitcoin/bitcoin/pull/33026#discussion_r2228569351)
done
(https://github.com/bitcoin/bitcoin/pull/33026#discussion_r2228569351)
done
💬 Sjors commented on pull request "Add bitcoin-{node,gui} to release binaries for IPC":
(https://github.com/bitcoin/bitcoin/pull/31802#discussion_r2228571714)
I did sort them, but missed a few.
(https://github.com/bitcoin/bitcoin/pull/31802#discussion_r2228571714)
I did sort them, but missed a few.