💬 fanquake commented on pull request "ci: Use optimized Debug build type in test-each-commit":
(https://github.com/bitcoin/bitcoin/pull/32888#discussion_r2228252688)
The CMake here is one version too old, otherwise we could also have used `CMAKE_LINKER_TYPE=MOLD`
(https://github.com/bitcoin/bitcoin/pull/32888#discussion_r2228252688)
The CMake here is one version too old, otherwise we could also have used `CMAKE_LINKER_TYPE=MOLD`
🚀 fanquake merged a pull request: "ci: Use optimized Debug build type in test-each-commit"
(https://github.com/bitcoin/bitcoin/pull/32888)
(https://github.com/bitcoin/bitcoin/pull/32888)
👋 fanquake's pull request is ready for review: "test: Add functional tests for blockreconstructionextratxn parameter"
(https://github.com/bitcoin/bitcoin/pull/33023)
(https://github.com/bitcoin/bitcoin/pull/33023)
💬 stickies-v commented on pull request "rpc: refactor: use string_view in Arg/MaybeArg":
(https://github.com/bitcoin/bitcoin/pull/32983#issuecomment-3113155030)
Force-pushed from [319abd6](https://github.com/bitcoin/bitcoin/commit/319abd609b3d2194e7a05454b6af55b6f16adbf1) to [b8772ef](https://github.com/bitcoin/bitcoin/commit/b8772efebace3f4f0cfed6479648bce7a521ff27) to remove a `std::string` copy in `rpc/mining.cpp`, addressing (part of) @pablomartin4btc's feedback.
---
> It seems like we’re going from `string` → `string_view` → `string`
`string_view` is a non-owning read-only reference, so by definition it has to point to some other string-li
...
(https://github.com/bitcoin/bitcoin/pull/32983#issuecomment-3113155030)
Force-pushed from [319abd6](https://github.com/bitcoin/bitcoin/commit/319abd609b3d2194e7a05454b6af55b6f16adbf1) to [b8772ef](https://github.com/bitcoin/bitcoin/commit/b8772efebace3f4f0cfed6479648bce7a521ff27) to remove a `std::string` copy in `rpc/mining.cpp`, addressing (part of) @pablomartin4btc's feedback.
---
> It seems like we’re going from `string` → `string_view` → `string`
`string_view` is a non-owning read-only reference, so by definition it has to point to some other string-li
...
📝 Sjors opened a pull request: "Don't fix Python patch version"
(https://github.com/bitcoin/bitcoin/pull/33051)
Fixing the patch version can cause problems when interacting with other programs such as HWI.
E.g. if the user installed Python 3.10.14 and 3.10.16 through PyEnv, if HWI was locked to 3.10 it would default to 3.10.16. HWI then can't find any of its dependencies.
See also https://github.com/bitcoin-core/HWI/pull/695
(https://github.com/bitcoin/bitcoin/pull/33051)
Fixing the patch version can cause problems when interacting with other programs such as HWI.
E.g. if the user installed Python 3.10.14 and 3.10.16 through PyEnv, if HWI was locked to 3.10 it would default to 3.10.16. HWI then can't find any of its dependencies.
See also https://github.com/bitcoin-core/HWI/pull/695
💬 maflcko commented on pull request "Don't fix Python patch version":
(https://github.com/bitcoin/bitcoin/pull/33051#issuecomment-3113282579)
the lint CI failed
(https://github.com/bitcoin/bitcoin/pull/33051#issuecomment-3113282579)
the lint CI failed
💬 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.