🤔 glozow reviewed a pull request: "cluster mempool: add TxGraph work controls"
(https://github.com/bitcoin/bitcoin/pull/32263#pullrequestreview-3033795100)
ACK 62ed1f92efff42bc79c50935e6dbd9da4e072020
(https://github.com/bitcoin/bitcoin/pull/32263#pullrequestreview-3033795100)
ACK 62ed1f92efff42bc79c50935e6dbd9da4e072020
💬 glozow commented on pull request "cluster mempool: add TxGraph work controls":
(https://github.com/bitcoin/bitcoin/pull/32263#discussion_r2216207547)
I was confused by why we use `max_iters` instead of `cost` to gauge whether we did enough work to make the cluster acceptable (intuitively, we care about actual work done rather than the upper bound given). But when `optimal` is not true that means we ~used up the iters available (or determined it wasn't enough).
Alternatively I thought maybe `max_iters == graph.m_acceptable_iters` is used as a way to tell that we're still in the "make things acceptable" stage and haven't yet run out of budge
...
(https://github.com/bitcoin/bitcoin/pull/32263#discussion_r2216207547)
I was confused by why we use `max_iters` instead of `cost` to gauge whether we did enough work to make the cluster acceptable (intuitively, we care about actual work done rather than the upper bound given). But when `optimal` is not true that means we ~used up the iters available (or determined it wasn't enough).
Alternatively I thought maybe `max_iters == graph.m_acceptable_iters` is used as a way to tell that we're still in the "make things acceptable" stage and haven't yet run out of budge
...
💬 glozow commented on pull request "cluster mempool: add TxGraph work controls":
(https://github.com/bitcoin/bitcoin/pull/32263#discussion_r2216375120)
To check my understanding of the `improved` logic:
- We have `improved = true` when either (1) we took the cluster from any non-optimal state -> optimal regardless of iters usage or (2) we are working on a non-acceptable cluster and had `m_acceptable_iters` to spend.
- That means `improved = false` if we didn't have enough iters to do `m_acceptable_iters` on a non-acceptable cluster (ran out of iters), or we have moved on to acceptable clusters but didn't have enough to make it optimal.
- It'
...
(https://github.com/bitcoin/bitcoin/pull/32263#discussion_r2216375120)
To check my understanding of the `improved` logic:
- We have `improved = true` when either (1) we took the cluster from any non-optimal state -> optimal regardless of iters usage or (2) we are working on a non-acceptable cluster and had `m_acceptable_iters` to spend.
- That means `improved = false` if we didn't have enough iters to do `m_acceptable_iters` on a non-acceptable cluster (ran out of iters), or we have moved on to acceptable clusters but didn't have enough to make it optimal.
- It'
...
💬 rkrux commented on pull request "wallet/rpc: fix listdescriptors RPC fails to return descriptors with private key information when wallet contains descriptors missing any key":
(https://github.com/bitcoin/bitcoin/pull/32471#discussion_r2216402469)
I had something like this in mind because in all the descriptors that can be added in a non-watch-only wallet, there must be at least 1 private key that is available. So, it seemed reasonable to me to add an `Assume` here on `has_priv_key` being true. I don't suppose `ToPrivateString` function would be called in any case for a watch-only wallet.
```diff
diff --git a/src/script/descriptor.cpp b/src/script/descriptor.cpp
index bd85ddd9e2..b22bf3fa4a 100644
--- a/src/script/descriptor.cpp
+++
...
(https://github.com/bitcoin/bitcoin/pull/32471#discussion_r2216402469)
I had something like this in mind because in all the descriptors that can be added in a non-watch-only wallet, there must be at least 1 private key that is available. So, it seemed reasonable to me to add an `Assume` here on `has_priv_key` being true. I don't suppose `ToPrivateString` function would be called in any case for a watch-only wallet.
```diff
diff --git a/src/script/descriptor.cpp b/src/script/descriptor.cpp
index bd85ddd9e2..b22bf3fa4a 100644
--- a/src/script/descriptor.cpp
+++
...
💬 stickies-v commented on pull request "log: [refactor] Use info level for init logs":
(https://github.com/bitcoin/bitcoin/pull/32967#discussion_r2216432893)
Woops, sorry. I thought these parameter interactions handled incompatible explicit user settings, but they're only updating unset settings, in which case `LogInfo` is absolutely appropriate.
(https://github.com/bitcoin/bitcoin/pull/32967#discussion_r2216432893)
Woops, sorry. I thought these parameter interactions handled incompatible explicit user settings, but they're only updating unset settings, in which case `LogInfo` is absolutely appropriate.
⚠️ farrelalfeshal10 opened an issue: "BIP Draft: Poisson Sum; γ^(i/R) + ∑(S[0:i]·τ·φ^j)"
(https://github.com/bitcoin/bitcoin/issues/33009)
BIP:
Layer: Consensus (soft fork)
Title: Poisson Sum; γ^(i/R) + ∑(S[0:i]·τ·φ^j)
Author: [Farrel Al Feshal] farrelalfeshal10@gmail.com
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-
Status: Draft
Type: Standards Track
Created: 2025-07-18
License: BSD-2-Clause
Abstract
Gödel Untouched Money Negotiation Approval, Poisson Sum being the Spearhead of Bitcoin and this Abstract Presents a Mathematical formula in Poisson Sum, every Poisson Sum that is
...
(https://github.com/bitcoin/bitcoin/issues/33009)
BIP:
Layer: Consensus (soft fork)
Title: Poisson Sum; γ^(i/R) + ∑(S[0:i]·τ·φ^j)
Author: [Farrel Al Feshal] farrelalfeshal10@gmail.com
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-
Status: Draft
Type: Standards Track
Created: 2025-07-18
License: BSD-2-Clause
Abstract
Gödel Untouched Money Negotiation Approval, Poisson Sum being the Spearhead of Bitcoin and this Abstract Presents a Mathematical formula in Poisson Sum, every Poisson Sum that is
...
⚠️ farrelalfeshal10 opened an issue: "Poisson Sum; γ^(i/R) + ∑(S[0:i]·τ·φ^j)"
(https://github.com/bitcoin/bitcoin/issues/33010)
Abstract
Gödel Untouched Money Negotiation Approval, Poisson Sum being the Spearhead of Bitcoin and this Abstract Presents a Mathematical formula in Poisson Sum, every Poisson Sum that is Exposed will be through Weighted Summing, γ^(i/R) + ∑(S[0:i]·τ·φ^j) In the electron charge has been discussed in the Journal of Cryptographers, including about DPA on N Bit, the reason for the logical mathematical formula above is that Bitcoin is a concept of money, the concept of an Electronic Cash System that
...
(https://github.com/bitcoin/bitcoin/issues/33010)
Abstract
Gödel Untouched Money Negotiation Approval, Poisson Sum being the Spearhead of Bitcoin and this Abstract Presents a Mathematical formula in Poisson Sum, every Poisson Sum that is Exposed will be through Weighted Summing, γ^(i/R) + ∑(S[0:i]·τ·φ^j) In the electron charge has been discussed in the Journal of Cryptographers, including about DPA on N Bit, the reason for the logical mathematical formula above is that Bitcoin is a concept of money, the concept of an Electronic Cash System that
...
✅ fanquake closed an issue: "BIP Draft: Poisson Sum; γ^(i/R) + ∑(S[0:i]·τ·φ^j)"
(https://github.com/bitcoin/bitcoin/issues/33009)
(https://github.com/bitcoin/bitcoin/issues/33009)
✅ fanquake closed an issue: "Poisson Sum; γ^(i/R) + ∑(S[0:i]·τ·φ^j)"
(https://github.com/bitcoin/bitcoin/issues/33010)
(https://github.com/bitcoin/bitcoin/issues/33010)
💬 BitcoinMechanic commented on pull request "Reduce minrelaytxfee to 100 sats/kvB":
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3090015438)
> > DUST_RELAY_TX_FEE should be decreased along with this as well...
>
> DEFAULT_MIN_RELAY_TX_FEE and DUST_RELAY_TX_FEE serve different purposes. The former is about protecting the P2P network, while the latter also aims at protecting the UTXO set from DoS attacks. Given that half of the UTXO set is spam these days, it seems like the dust limit should rather get _increased_ than decreased. So it's a whole different discussion, and I would not want to conflate these two in this PR.
The issu
...
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3090015438)
> > DUST_RELAY_TX_FEE should be decreased along with this as well...
>
> DEFAULT_MIN_RELAY_TX_FEE and DUST_RELAY_TX_FEE serve different purposes. The former is about protecting the P2P network, while the latter also aims at protecting the UTXO set from DoS attacks. Given that half of the UTXO set is spam these days, it seems like the dust limit should rather get _increased_ than decreased. So it's a whole different discussion, and I would not want to conflate these two in this PR.
The issu
...
💬 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😬
(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
...
(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
(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
(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.
(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.