💬 sipa commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1475072896)
(From IRL discussion)
The actually implemented optimization here is actually more powerful than what is described by the comment, because the weight isn't compared. Due to the fact that that among equal-value utxo groups, the lower weight ones sort first, higher weight ones are even worse, and can also be skipped.
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1475072896)
(From IRL discussion)
The actually implemented optimization here is actually more powerful than what is described by the comment, because the weight isn't compared. Due to the fact that that among equal-value utxo groups, the lower weight ones sort first, higher weight ones are even worse, and can also be skipped.
💬 murchandamus commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1475073648)
Yep, will update.
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1475073648)
Yep, will update.
💬 murchandamus commented on pull request "wallet, rpc: add anti-fee-sniping to `send` and `sendall`":
(https://github.com/bitcoin/bitcoin/pull/28944#issuecomment-1922141545)
I circled back to review, I think this has a merge conflict
(https://github.com/bitcoin/bitcoin/pull/28944#issuecomment-1922141545)
I circled back to review, I think this has a merge conflict
💬 ajtowns commented on pull request "logging: Update to new logging API":
(https://github.com/bitcoin/bitcoin/pull/29231#issuecomment-1922177927)
Rebased
(https://github.com/bitcoin/bitcoin/pull/29231#issuecomment-1922177927)
Rebased
💬 mzumsande commented on pull request "test: use v2 everywhere for P2PConnection if --v2transport is enabled":
(https://github.com/bitcoin/bitcoin/pull/29358#issuecomment-1922201347)
rebased and always use v1 instead of disabling completely in the three slow (sub)tests.
(https://github.com/bitcoin/bitcoin/pull/29358#issuecomment-1922201347)
rebased and always use v1 instead of disabling completely in the three slow (sub)tests.
👋 mzumsande's pull request is ready for review: "test: use v2 everywhere for P2PConnection if --v2transport is enabled"
(https://github.com/bitcoin/bitcoin/pull/29358)
(https://github.com/bitcoin/bitcoin/pull/29358)
💬 jamesob commented on pull request "test: Assumeutxo with more than just coinbase transactions":
(https://github.com/bitcoin/bitcoin/pull/29354#issuecomment-1922203109)
ACK https://github.com/bitcoin/bitcoin/pull/29354/commits/fa5cd66f0a47d1b759c93d01524ee4558432c0cc
(https://github.com/bitcoin/bitcoin/pull/29354#issuecomment-1922203109)
ACK https://github.com/bitcoin/bitcoin/pull/29354/commits/fa5cd66f0a47d1b759c93d01524ee4558432c0cc
💬 jamesob commented on pull request "rpc: Do not wait for headers inside loadtxoutset":
(https://github.com/bitcoin/bitcoin/pull/29345#issuecomment-1922205551)
Looks fine to me.
(https://github.com/bitcoin/bitcoin/pull/29345#issuecomment-1922205551)
Looks fine to me.
💬 theuni commented on pull request "serialization: c++20 endian/byteswap/clz modernization":
(https://github.com/bitcoin/bitcoin/pull/29263#issuecomment-1922260596)
I've dropped the clz changes as a test and kept only the endian/byteswap change. Locally on my machine the benchmarks look the same before and after.
If the corecheck benchmarks look better I'll update the title/description here.
(https://github.com/bitcoin/bitcoin/pull/29263#issuecomment-1922260596)
I've dropped the clz changes as a test and kept only the endian/byteswap change. Locally on my machine the benchmarks look the same before and after.
If the corecheck benchmarks look better I'll update the title/description here.
💬 sr-gi commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1475114260)
In commit: test: Add coin_grinder_tests
I think clearing the expected result here is not necessary. You can get rid of this (and potentially also just move the declaration of `expected_result` here instead.
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1475114260)
In commit: test: Add coin_grinder_tests
I think clearing the expected result here is not necessary. You can get rid of this (and potentially also just move the declaration of `expected_result` here instead.
🤔 sr-gi reviewed a pull request: "wallet: Add CoinGrinder coin selection algorithm"
(https://github.com/bitcoin/bitcoin/pull/27877#pullrequestreview-1857573521)
Concept ACK.
First pass, I need to dig a bit deeper, but it makes sense to me
(https://github.com/bitcoin/bitcoin/pull/27877#pullrequestreview-1857573521)
Concept ACK.
First pass, I need to dig a bit deeper, but it makes sense to me
💬 sr-gi commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1475116651)
In commit: test: Add coin_grinder_tests
Same as per point 5)
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1475116651)
In commit: test: Add coin_grinder_tests
Same as per point 5)
💬 sr-gi commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1475157115)
In opt: Track remaining effective_value in lookahead:
I wonder why this gets turned into a descending while loop instead of a descending for loop. Given the total number of iterations is known beforehand a for seems best suited (plus the scope of the counter is reduced to to scope of the loop)
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1475157115)
In opt: Track remaining effective_value in lookahead:
I wonder why this gets turned into a descending while loop instead of a descending for loop. Given the total number of iterations is known beforehand a for seems best suited (plus the scope of the counter is reduced to to scope of the loop)
💬 sr-gi commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1475162152)
in test: Exhaust search attempts with tiny UTXOs:
Same as for cases 5) and 6), clearing is not needed
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1475162152)
in test: Exhaust search attempts with tiny UTXOs:
Same as for cases 5) and 6), clearing is not needed
💬 ariard commented on issue "Cluster mempool, CPFP carveout, and V3 transaction policy":
(https://github.com/bitcoin/bitcoin/issues/29319#issuecomment-1922277580)
@petertodd
> Can you give a bit more detail on what challenges you think that'll pose?
from my memory: "How this new replacement rule would behave if you have a parent in the
"replace-by-feerate" half but the child is in the "replace-by-fee" one ?” see the conversation here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019839.html
in past conversations we have assumed a “static” N blocks worth of mempool, unclear to me with your proposal if dynamic.
i wonder abo
...
(https://github.com/bitcoin/bitcoin/issues/29319#issuecomment-1922277580)
@petertodd
> Can you give a bit more detail on what challenges you think that'll pose?
from my memory: "How this new replacement rule would behave if you have a parent in the
"replace-by-feerate" half but the child is in the "replace-by-fee" one ?” see the conversation here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019839.html
in past conversations we have assumed a “static” N blocks worth of mempool, unclear to me with your proposal if dynamic.
i wonder abo
...
⚠️ ariard opened an issue: "Update security.md with all PGP fingerprints"
(https://github.com/bitcoin/bitcoin/issues/29366)
As a bitcoin sec researcher, appreciated if PGP fingerprints of all receiving endpoints of security@bitcoincore.org can be public.
Thanks.
(https://github.com/bitcoin/bitcoin/issues/29366)
As a bitcoin sec researcher, appreciated if PGP fingerprints of all receiving endpoints of security@bitcoincore.org can be public.
Thanks.
💬 tdb3 commented on pull request "Support JSON-RPC 2.0 when requested by client":
(https://github.com/bitcoin/bitcoin/pull/27101#discussion_r1475182625)
>Although from discussion thread above it sounds like maybe we are willing to not fully comply with 2.0 spec if we are prioritizing backwards compatibility over spec compatibility in cases where 2.0 spec is mandating a certain response even when the request does not contain a "jsonrpc":"2.0" field.
Yeah, exactly this. If/when support for jsonrpc 1.0 and 1.1 is removed, then the implementation could be updated to achieve full/closer compliance to the 2.0 spec. If it's decided that jsonrpc 1.
...
(https://github.com/bitcoin/bitcoin/pull/27101#discussion_r1475182625)
>Although from discussion thread above it sounds like maybe we are willing to not fully comply with 2.0 spec if we are prioritizing backwards compatibility over spec compatibility in cases where 2.0 spec is mandating a certain response even when the request does not contain a "jsonrpc":"2.0" field.
Yeah, exactly this. If/when support for jsonrpc 1.0 and 1.1 is removed, then the implementation could be updated to achieve full/closer compliance to the 2.0 spec. If it's decided that jsonrpc 1.
...
💬 tdb3 commented on pull request "Support JSON-RPC 2.0 when requested by client":
(https://github.com/bitcoin/bitcoin/pull/27101#issuecomment-1922293722)
ACK for 58cb22c83c1b72af7f3c580dc6261cf50e7ed2cb. Thanks for the great feature update. Verification steps taken below.
Pulled 58cb22c83c1b72af7f3c580dc6261cf50e7ed2cb. Each of the seven cases (from above) exhibited expected behavior (i.e. non-2.0 requests match previous response behavior, 2.0-marked requests appeared spec-compliant).
The content below is as-run request/response for posterity.
### Action (1):
`curl --user test --data-binary '[]' -H 'content-type: text/plain;' h
...
(https://github.com/bitcoin/bitcoin/pull/27101#issuecomment-1922293722)
ACK for 58cb22c83c1b72af7f3c580dc6261cf50e7ed2cb. Thanks for the great feature update. Verification steps taken below.
Pulled 58cb22c83c1b72af7f3c580dc6261cf50e7ed2cb. Each of the seven cases (from above) exhibited expected behavior (i.e. non-2.0 requests match previous response behavior, 2.0-marked requests appeared spec-compliant).
The content below is as-run request/response for posterity.
### Action (1):
`curl --user test --data-binary '[]' -H 'content-type: text/plain;' h
...
💬 achow101 commented on issue "Update security.md with all PGP fingerprints":
(https://github.com/bitcoin/bitcoin/issues/29366#issuecomment-1922296387)
The full recipients list of security@bitcoincore.org is intentionally kept private in order to reduce the risk of targeted attacks against those who receive those emails. Only the people who are willing to take that risk have their fingerprints published.
(https://github.com/bitcoin/bitcoin/issues/29366#issuecomment-1922296387)
The full recipients list of security@bitcoincore.org is intentionally kept private in order to reduce the risk of targeted attacks against those who receive those emails. Only the people who are willing to take that risk have their fingerprints published.
💬 ariard commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1922316467)
> I definitely appreciate the discussions about LN usage, but it would be best to take it to the Delving thread. Here's the link > for {switching, imbuing} {commitment, HTLC-X} transactions to use {v3, ephemeral anchors}: https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418/24
no time for delving - apologies.
concern is on the lack of anti-pinning robustness of v3 policy, see my previous comments.
if correct and leave a substantial pinning loophole, i’m wo
...
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1922316467)
> I definitely appreciate the discussions about LN usage, but it would be best to take it to the Delving thread. Here's the link > for {switching, imbuing} {commitment, HTLC-X} transactions to use {v3, ephemeral anchors}: https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418/24
no time for delving - apologies.
concern is on the lack of anti-pinning robustness of v3 policy, see my previous comments.
if correct and leave a substantial pinning loophole, i’m wo
...