π¬ m3dwards commented on pull request "ci: Use APT_LLVM_V in msan task":
(https://github.com/bitcoin/bitcoin/pull/32999#issuecomment-3090107388)
ACK fad040a5787a8ac0a13aef5c54e5a675de239e92
This will cut down on the msan job run time a lot when the docker build cache is empty.
(https://github.com/bitcoin/bitcoin/pull/32999#issuecomment-3090107388)
ACK fad040a5787a8ac0a13aef5c54e5a675de239e92
This will cut down on the msan job run time a lot when the docker build cache is empty.
π¬ l0rinc commented on pull request "[IBD] multi-byte block obfuscation":
(https://github.com/bitcoin/bitcoin/pull/31144#discussion_r2216551450)
Yeah, I know we're using these in `serialization.h`, but it seems to me the current option might be easier to optimize, see https://godbolt.org/z/fh8o9xdvz
It's possible my reproducer is not representative, I also don't mind switching if others prefer it.
(https://github.com/bitcoin/bitcoin/pull/31144#discussion_r2216551450)
Yeah, I know we're using these in `serialization.h`, but it seems to me the current option might be easier to optimize, see https://godbolt.org/z/fh8o9xdvz
It's possible my reproducer is not representative, I also don't mind switching if others prefer it.
π€ glozow reviewed a pull request: "[29.x] Backports"
(https://github.com/bitcoin/bitcoin/pull/32863#pullrequestreview-3034292282)
ACK 5300295083f2e199c22a7ad55e62a8dc7549a76e
(https://github.com/bitcoin/bitcoin/pull/32863#pullrequestreview-3034292282)
ACK 5300295083f2e199c22a7ad55e62a8dc7549a76e
π¬ Zeegaths commented on pull request "docs: adds correct updated documentation links":
(https://github.com/bitcoin/bitcoin/pull/32699#issuecomment-3090182245)
Yes, it's done.
On Fri, 18 Jul 2025 at 15:41, maflcko ***@***.***> wrote:
> *maflcko* left a comment (bitcoin/bitcoin#32699)
> <https://github.com/bitcoin/bitcoin/pull/32699#issuecomment-3089360188>
>
> Can this be drafted/closed, or are you still working on this?
>
> β
> Reply to this email directly, view it on GitHub
> <https://github.com/bitcoin/bitcoin/pull/32699#issuecomment-3089360188>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AZVGWLBQ4RMG7UWJVYM
...
(https://github.com/bitcoin/bitcoin/pull/32699#issuecomment-3090182245)
Yes, it's done.
On Fri, 18 Jul 2025 at 15:41, maflcko ***@***.***> wrote:
> *maflcko* left a comment (bitcoin/bitcoin#32699)
> <https://github.com/bitcoin/bitcoin/pull/32699#issuecomment-3089360188>
>
> Can this be drafted/closed, or are you still working on this?
>
> β
> Reply to this email directly, view it on GitHub
> <https://github.com/bitcoin/bitcoin/pull/32699#issuecomment-3089360188>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AZVGWLBQ4RMG7UWJVYM
...
π glozow merged a pull request: "[29.x] Backports"
(https://github.com/bitcoin/bitcoin/pull/32863)
(https://github.com/bitcoin/bitcoin/pull/32863)
π Crypt-iQ opened a pull request: "log: rate limiting followups"
(https://github.com/bitcoin/bitcoin/pull/33011)
Followups to #32604.
The only behavior change is that prefixing with `[*]` is done to all logs (regardless of `should_ratelimit`) per https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2195710943. This does not need a release note as the release notes were already a bit vague as pointed out in the comment.
(https://github.com/bitcoin/bitcoin/pull/33011)
Followups to #32604.
The only behavior change is that prefixing with `[*]` is done to all logs (regardless of `should_ratelimit`) per https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2195710943. This does not need a release note as the release notes were already a bit vague as pointed out in the comment.
π¬ Crypt-iQ commented on pull request "log: rate limiting followups":
(https://github.com/bitcoin/bitcoin/pull/33011#issuecomment-3090274955)
Addressed in this PR:
- https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2188529752
- https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2163341392
- https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2163349298
- https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2182919153
- https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2185313756
- https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2188155450
- https://github.com/bitcoin/bitcoin/pull/326
...
(https://github.com/bitcoin/bitcoin/pull/33011#issuecomment-3090274955)
Addressed in this PR:
- https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2188529752
- https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2163341392
- https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2163349298
- https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2182919153
- https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2185313756
- https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2188155450
- https://github.com/bitcoin/bitcoin/pull/326
...
π darosior opened a pull request: "script: return verification flag responsible for error upon validation failure"
(https://github.com/bitcoin/bitcoin/pull/33012)
For unconfirmed transactions, we currently distinguish between Script validation failures due to standardness rules and those due to consensus rules. The distinction is used to decide whether to disconnect the peer which submitted this transaction.
This is currently achieved by repeating Script validation with only the consensus verification flags, after it failed with the standardness flags. It is wasteful, and potentially significantly more so since we have Taproot. This PR proposes to repl
...
(https://github.com/bitcoin/bitcoin/pull/33012)
For unconfirmed transactions, we currently distinguish between Script validation failures due to standardness rules and those due to consensus rules. The distinction is used to decide whether to disconnect the peer which submitted this transaction.
This is currently achieved by repeating Script validation with only the consensus verification flags, after it failed with the standardness flags. It is wasteful, and potentially significantly more so since we have Taproot. This PR proposes to repl
...
π€ glozow reviewed a pull request: "policy: make pathological transactions packed with legacy sigops non-standard"
(https://github.com/bitcoin/bitcoin/pull/32521#pullrequestreview-3034612261)
light code review ACK 96da68a38fa, looks correct to me
(https://github.com/bitcoin/bitcoin/pull/32521#pullrequestreview-3034612261)
light code review ACK 96da68a38fa, looks correct to me
π¬ glozow commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2216772534)
When I changed this to `false`, none of the tests failed - maybe worth adding a multisig case?
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2216772534)
When I changed this to `false`, none of the tests failed - maybe worth adding a multisig case?
π¬ darosior commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2216808190)
This line is counting ops in the scriptSig. I'm not sure it makes sense to add a test case with an `OP_CHECKMULTISIG` sneaked in the scriptSig because this is already non-standard.
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2216808190)
This line is counting ops in the scriptSig. I'm not sure it makes sense to add a test case with an `OP_CHECKMULTISIG` sneaked in the scriptSig because this is already non-standard.
π¬ achow101 commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#issuecomment-3090534874)
light ACK 50024620b909fc30b68a3715680e963f048482a5
(https://github.com/bitcoin/bitcoin/pull/31829#issuecomment-3090534874)
light ACK 50024620b909fc30b68a3715680e963f048482a5
π achow101 merged a pull request: "p2p: improve TxOrphanage denial of service bounds"
(https://github.com/bitcoin/bitcoin/pull/31829)
(https://github.com/bitcoin/bitcoin/pull/31829)
π¬ achow101 commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#issuecomment-3090586828)
ACK 96da68a38fa295d2414685739c41b8626e198d27
(https://github.com/bitcoin/bitcoin/pull/32521#issuecomment-3090586828)
ACK 96da68a38fa295d2414685739c41b8626e198d27
π achow101 merged a pull request: "policy: make pathological transactions packed with legacy sigops non-standard"
(https://github.com/bitcoin/bitcoin/pull/32521)
(https://github.com/bitcoin/bitcoin/pull/32521)
π¬ caesrcd commented on pull request "Reduce minrelaytxfee to 100 sats/kvB":
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3090651380)
> Also, i don't think there is a good reason for decreasing the incremental relay fee at the same time as the min relay fee.
If `DEFAULT_INCREMENTAL_RELAY_FEE` is not lowered along with `DEFAULT_MIN_RELAY_TX_FEE`, users will be forced to pay fees above the estimates during periods of low transaction demand. Itβs as if `DEFAULT_INCREMENTAL_RELAY_FEE` were now effectively set to 10,000 sat/kvB.
Thatβs exactly what Iβm seeing. Yesterday I broadcast a transaction with a 0.2 sat/vB fee, and wit
...
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3090651380)
> Also, i don't think there is a good reason for decreasing the incremental relay fee at the same time as the min relay fee.
If `DEFAULT_INCREMENTAL_RELAY_FEE` is not lowered along with `DEFAULT_MIN_RELAY_TX_FEE`, users will be forced to pay fees above the estimates during periods of low transaction demand. Itβs as if `DEFAULT_INCREMENTAL_RELAY_FEE` were now effectively set to 10,000 sat/kvB.
Thatβs exactly what Iβm seeing. Yesterday I broadcast a transaction with a 0.2 sat/vB fee, and wit
...
π¬ naiyoma commented on issue "intermittent timeout in wallet_signer.py : 'createwallet' RPC took longer than 1200.000000 seconds":
(https://github.com/bitcoin/bitcoin/issues/32855#issuecomment-3090671325)
I was testing https://github.com/bitcoin/bitcoin/pull/32928 and made an attempt to reproduce this issue by hanging a getdescriptors call
```git diff
index aa9d286417..edbd5359ee 100755
--- a/test/functional/mock_external_signer.py
+++ b/test/functional/mock_external_signer.py
@@ -97,6 +97,15 @@ parser_signtx.add_argument('psbt', metavar='psbt')
parser_signtx.set_defaults(func=signtx)
if not sys.stdin.isatty():
+ log.debug("About to read from stdin")
+ log.debug(f"Current args: {sys.a
...
(https://github.com/bitcoin/bitcoin/issues/32855#issuecomment-3090671325)
I was testing https://github.com/bitcoin/bitcoin/pull/32928 and made an attempt to reproduce this issue by hanging a getdescriptors call
```git diff
index aa9d286417..edbd5359ee 100755
--- a/test/functional/mock_external_signer.py
+++ b/test/functional/mock_external_signer.py
@@ -97,6 +97,15 @@ parser_signtx.add_argument('psbt', metavar='psbt')
parser_signtx.set_defaults(func=signtx)
if not sys.stdin.isatty():
+ log.debug("About to read from stdin")
+ log.debug(f"Current args: {sys.a
...
π¬ marcofleon commented on pull request "refactor: GenTxid type safety followups":
(https://github.com/bitcoin/bitcoin/pull/33005#discussion_r2216903066)
Done. Thanks for the suggestion, this is quite a bit simpler. Let me know if there's something that can be improved/fixed.
(https://github.com/bitcoin/bitcoin/pull/33005#discussion_r2216903066)
Done. Thanks for the suggestion, this is quite a bit simpler. Let me know if there's something that can be improved/fixed.
π darosior opened a pull request: "Backport #32521 to 29"
(https://github.com/bitcoin/bitcoin/pull/33013)
This backports PR #32521 to make the change available to miners who can't (or don't want to) upgrade past version 29.
(https://github.com/bitcoin/bitcoin/pull/33013)
This backports PR #32521 to make the change available to miners who can't (or don't want to) upgrade past version 29.
π¬ tnndbtc commented on issue "intermittent timeout in wallet_signer.py : 'createwallet' RPC took longer than 1200.000000 seconds":
(https://github.com/bitcoin/bitcoin/issues/32855#issuecomment-3090725560)
@naiyoma I also suspect this might be the cause and put comment in https://github.com/bitcoin/bitcoin/issues/32524#issuecomment-3071393448 . As stated in that comment, one possible reason is that the close of `err_wr_pipe`, which should send the empty string to stdin for the python process (signer.py) to confirm, could return `-1` but bitcoind didn't check the return result.
`subprocess_close(err_wr_pipe);// close child side of pipe, else get stuck in read below`
Typically, close of file descr
...
(https://github.com/bitcoin/bitcoin/issues/32855#issuecomment-3090725560)
@naiyoma I also suspect this might be the cause and put comment in https://github.com/bitcoin/bitcoin/issues/32524#issuecomment-3071393448 . As stated in that comment, one possible reason is that the close of `err_wr_pipe`, which should send the empty string to stdin for the python process (signer.py) to confirm, could return `-1` but bitcoind didn't check the return result.
`subprocess_close(err_wr_pipe);// close child side of pipe, else get stuck in read below`
Typically, close of file descr
...