💬 sipa commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1477456505)
Perhaps point out that this makes it a branch-and-bound algorithm (https://en.wikipedia.org/wiki/Branch_and_bound): any branch which can only contain solutions worse than the best solution so far can be skipped.

💬 sipa commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1477465413)
Any reason not to add this test in the very beginning together with the other test cases?

💬 sipa commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1477465223)
I think you can actually do even better: it suffices that the next UTXO has a weight larger or equal to the first preceding omitted one. This is always the case when they have equal value (due to the tiebreak), but it may extend to further (lower) values too (if those have higher or equal weight).

Feel free to leave this for a follow-up.

💬 ariard commented on issue "Cluster mempool, CPFP carveout, and V3 transaction policy":
(https://github.com/bitcoin/bitcoin/issues/29319#issuecomment-1926138008)
> Not sure what you mean by "threshold effect". So long as the N block threshold isn't too large, transactions that don't quite reach the threshold have a decent chance of getting mined eventually. Similarly, since the threshold is dynamic, it's likely that the threshold will reduce at some point, allowing a fee-bump will put it over the threshold.

My understanding of the proposal is the following. We introduce a dynamic N block threshold, where everything inside the threshold is replace-by-f
...

💬 ariard commented on issue "Cluster mempool, CPFP carveout, and V3 transaction policy":
(https://github.com/bitcoin/bitcoin/issues/29319#issuecomment-1926157308)
> It looks like removal of CPFP carve out is not a concern for you; you just don't think v3 is a good idea. If that's the case, there is no need to post general criticisms of v3 here. See https://github.com/bitcoin/bitcoin/pull/28948 description for a list of threads dedicated to discussing v3.

I would appreciate a more gently online communication tone from someone I spent time sharing a lot of information (cf. my old gist [“Mitigating Tx-Relay Jamming for Time-Sensitive Contract Protocols”]
...

💬 ariard commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1926161087)
so i took time to test a NTA pinning scenario: ariard@84e12b8 which is known since https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/018011.html

I’m interested if there is a full-branch with package-relay + v3 tx policy available somewhere.

I don’t know if it’s robust against NTA pinning and if in consequence we should not be better off to reconsider the whole package relay + v3 bitcoin engineering package. take it nicely as a statement to be corroborated for now.

my apo
...

⚠️ ariard opened an issue: "Update security.md with all PGP fingerprints (version 2)"
(https://github.com/bitcoin/bitcoin/issues/29383)
https://github.com/bitcoin/bitcoin/issues/29366

> You didn't ask one, you made a statement, which I think is sufficiently addressed by encrypting directly to the people who you want to share the information with.

I’m not satisfied by this answer achow101. Let me know what should be the public communication venue to submit such concern.
If one is not satisfied to be security@bitcoincore.org list whatever the reason, one can resign.

💬 ariard commented on issue "Update security.md with all PGP fingerprints":
(https://github.com/bitcoin/bitcoin/issues/29366#issuecomment-1926167871)
@achow101

Thanks to not use your GH admin rights to close issue before someone is satisfied with your answer.

This is a qualified lack of professionalism for an open-source maintainer as such as Bitcoin, which is engaging your own reputation.

✅ achow101 closed an issue: "Update security.md with all PGP fingerprints (version 2)"
(https://github.com/bitcoin/bitcoin/issues/29383)

💬 achow101 commented on issue "Update security.md with all PGP fingerprints (version 2)":
(https://github.com/bitcoin/bitcoin/issues/29383#issuecomment-1926168873)
Don't open duplicate issues. If you think an issue should be reopened, then say so in that issue.

⚠️ achow101 reopened 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.

💬 ariard commented on issue "Update security.md with all PGP fingerprints":
(https://github.com/bitcoin/bitcoin/issues/29366#issuecomment-1926169684)
FYI - I raised the subject of securing line of sensitive communications as one of the last in-person coredev.

💬 achow101 commented on issue "Update security.md with all PGP fingerprints":
(https://github.com/bitcoin/bitcoin/issues/29366#issuecomment-1926170386)
I considered the question posed in the OP to be answered and that there was nothing further to do here.

Since you disagree, what exactly is it that you are asking? I'm having a hard time parsing from your responses what further questions you actually have other than whether the full list can be published.

💬 ishaanam commented on pull request "wallet: track mempool conflicts with wallet transactions":
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1477695130)
I have now added a test for descendants of conflicted transactions.

💬 ishaanam commented on pull request "wallet: track mempool conflicts with wallet transactions":
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1477697474)
Actually, I have just added a test in this PR.

💬 ishaanam commented on pull request "wallet: track mempool conflicts with wallet transactions":
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1477697683)
I have added a comment indicating this.

💬 ishaanam commented on pull request "wallet: track mempool conflicts with wallet transactions":
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1477699351)
Good point, this comment is from a previous version of the PR. I have fixed it.

💬 ishaanam commented on pull request "wallet: track mempool conflicts with wallet transactions":
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1477700028)
Should be fixed now.

⚠️ Rodert opened an issue: "When I make a highly concurrent request to bitcoin core, a new block appears and all my requests get blocked"
(https://github.com/bitcoin/bitcoin/issues/29384)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

When I make a highly concurrent request to bitcoin core, a new block appears and all my requests get blocked


### Expected behaviour

ok

### Steps to reproduce

When I make a highly concurrent request to bitcoin core, a new block appears and all my requests get blocked


### Relevant log output

_No response_

### How did you obtain Bitcoin Core

Package manager

### What version of Bi
...

🤔 stratospher reviewed a pull request: "test: fix intermittent failure in `rpc_setban.py --v2transport`, run it in CI"
(https://github.com/bitcoin/bitcoin/pull/29372#pullrequestreview-1861953032)
tested ACK cc87ee4. nice find!