Bitcoin Core Github
44 subscribers
121K links
Download Telegram
πŸ’¬ farrelalfeshal10 commented on issue "Poisson Sum; Ξ³^(i/R) + βˆ‘(S[0:i]·τ·φ^j)":
(https://github.com/bitcoin/bitcoin/issues/33010#issuecomment-3090037033)
Thanks a lot if It has actually been realized even though it is not with the mathematical language that I brought, I am grateful and maybe I am the one who does not understand Bitcoin in that part😬
πŸ’¬ l0rinc commented on pull request "[IBD] multi-byte block obfuscation":
(https://github.com/bitcoin/bitcoin/pull/31144#discussion_r2216475964)
> Write may throw, but Read does not

Did that change in this PR?

> Why not just keep the code as-is here and use m_obfuscation = new_key

You mean like this?
```C++
const auto new_key{FastRandomContext{}.randbytes<Obfuscation::KEY_SIZE, uint8_t>()};
Write(OBFUSCATION_KEY_KEY, std::vector<uint8_t>{new_key.begin(), new_key.end()});
m_obfuscation = Obfuscation{MakeByteSpan(new_key)};
```
instead of
```C++
Write(OBFUSCATION_KEY_KEY, FastRandomContext{}.randbytes(Obfuscation::KEY_SIZE
...
πŸ’¬ yuvicc commented on pull request "test: Fix reorg patterns in tests to use proper fork-based approach":
(https://github.com/bitcoin/bitcoin/pull/32587#issuecomment-3090062876)
Rebased -> master@672c85cb1ea0d76ef9e596b2a964b2311b11b815
πŸ’¬ instagibbs commented on pull request "test: Fix reorg patterns in tests to use proper fork-based approach":
(https://github.com/bitcoin/bitcoin/pull/32587#issuecomment-3090094623)
think you need to fix issues first
πŸ’¬ 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.
πŸ’¬ 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.
πŸ€” glozow reviewed a pull request: "[29.x] Backports"
(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
...
πŸš€ glozow merged a pull request: "[29.x] Backports"
(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.
πŸ“ 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
...
πŸ€” 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
πŸ’¬ 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?
πŸ’¬ 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.
πŸ’¬ achow101 commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(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)
πŸ’¬ 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
πŸš€ achow101 merged a pull request: "policy: make pathological transactions packed with legacy sigops non-standard"
(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
...