💬 stickies-v commented on pull request "log: [refactor] Use info level for init logs":
(https://github.com/bitcoin/bitcoin/pull/32967#discussion_r2216305511)
> All parameter interaction is (and was) info level
Fair enough, that's at least a good reason to not do it here but in a separate pull.
> A warning is for the node operator to investigate and possibly fix.
That's exactly why I was thinking it should be warning: a node operator "misconfigured" their node. It may be fine, but the node may also be behaving differently than what they expect, so best is for the node operator to investigate and fix the interaction.
Anyway, can be marked a
...
(https://github.com/bitcoin/bitcoin/pull/32967#discussion_r2216305511)
> All parameter interaction is (and was) info level
Fair enough, that's at least a good reason to not do it here but in a separate pull.
> A warning is for the node operator to investigate and possibly fix.
That's exactly why I was thinking it should be warning: a node operator "misconfigured" their node. It may be fine, but the node may also be behaving differently than what they expect, so best is for the node operator to investigate and fix the interaction.
Anyway, can be marked a
...
💬 Eunovo 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_r2216313380)
Done
(https://github.com/bitcoin/bitcoin/pull/32471#discussion_r2216313380)
Done
💬 Eunovo 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_r2216314444)
I couldn't add an assert message, but I added a comment.
(https://github.com/bitcoin/bitcoin/pull/32471#discussion_r2216314444)
I couldn't add an assert message, but I added a comment.
💬 Eunovo 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_r2216314650)
Done
(https://github.com/bitcoin/bitcoin/pull/32471#discussion_r2216314650)
Done
💬 Eunovo 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_r2216314937)
Done
(https://github.com/bitcoin/bitcoin/pull/32471#discussion_r2216314937)
Done
💬 Eunovo 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_r2216315188)
Done
(https://github.com/bitcoin/bitcoin/pull/32471#discussion_r2216315188)
Done
💬 Eunovo 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_r2216315538)
Done
(https://github.com/bitcoin/bitcoin/pull/32471#discussion_r2216315538)
Done
💬 Eunovo 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_r2216319131)
`ToStringHelper` now accepts a pointer to `has_priv_key` in https://github.com/bitcoin/bitcoin/pull/32471/commits/2a1f1f0e32829af43436eb4220164c1be86229bb
It does look cleaner, but there's a need to check for `nullptr` now.
(https://github.com/bitcoin/bitcoin/pull/32471#discussion_r2216319131)
`ToStringHelper` now accepts a pointer to `has_priv_key` in https://github.com/bitcoin/bitcoin/pull/32471/commits/2a1f1f0e32829af43436eb4220164c1be86229bb
It does look cleaner, but there's a need to check for `nullptr` now.
💬 Eunovo 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_r2216319565)
Done
(https://github.com/bitcoin/bitcoin/pull/32471#discussion_r2216319565)
Done
💬 Eunovo 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_r2216320066)
Done
(https://github.com/bitcoin/bitcoin/pull/32471#discussion_r2216320066)
Done
💬 Eunovo 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_r2216323468)
I'm confused here. Can you clarify what you're suggesting?
(https://github.com/bitcoin/bitcoin/pull/32471#discussion_r2216323468)
I'm confused here. Can you clarify what you're suggesting?
📝 Sjors opened a pull request: "wallet: support bip388 policy with external signer"
(https://github.com/bitcoin/bitcoin/pull/33008)
External signers such as Ledger, BitBox02 and Jade, when used with multisig, use [BIP388](https://github.com/bitcoin/bips/blob/master/bip-0388.mediawiki) to display (and constrain) descriptor policies to their users.
At least in the case of Ledger (haven't tested the others) this requires us to hold on to an hmac, which proves to the device that the user previously reviewed and approved it.
This PR adds a new RPC call `registerpolicy` which converts our descriptor(s) into a BIP388 policy (
...
(https://github.com/bitcoin/bitcoin/pull/33008)
External signers such as Ledger, BitBox02 and Jade, when used with multisig, use [BIP388](https://github.com/bitcoin/bips/blob/master/bip-0388.mediawiki) to display (and constrain) descriptor policies to their users.
At least in the case of Ledger (haven't tested the others) this requires us to hold on to an hmac, which proves to the device that the user previously reviewed and approved it.
This PR adds a new RPC call `registerpolicy` which converts our descriptor(s) into a BIP388 policy (
...
🤔 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)