💬 04487 commented on issue "Update security.md with all PGP fingerprints":
(https://github.com/bitcoin/bitcoin/issues/29366#issuecomment-1925914511)
FHfh3647@$#....
در تاریخ یکشنبه ۴ فوریهٔ ۲۰۲۴، ۲۳:۴۱ Will Clark ***@***.***>
نوشت:
> @ariard <https://github.com/ariard> does being able to contact the
> persons who have chosen to be listed resolve this issue for you?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/bitcoin/bitcoin/issues/29366#issuecomment-1925899691>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ATSXOP5EWS64IO7D2MF4IBLYR7TQZAVCNFSM6AAAAABCVT75OCVHI2DSMVQWIX3
...
(https://github.com/bitcoin/bitcoin/issues/29366#issuecomment-1925914511)
FHfh3647@$#....
در تاریخ یکشنبه ۴ فوریهٔ ۲۰۲۴، ۲۳:۴۱ Will Clark ***@***.***>
نوشت:
> @ariard <https://github.com/ariard> does being able to contact the
> persons who have chosen to be listed resolve this issue for you?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/bitcoin/bitcoin/issues/29366#issuecomment-1925899691>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ATSXOP5EWS64IO7D2MF4IBLYR7TQZAVCNFSM6AAAAABCVT75OCVHI2DSMVQWIX3
...
💬 ariard commented on issue "Update security.md with all PGP fingerprints":
(https://github.com/bitcoin/bitcoin/issues/29366#issuecomment-1925939033)
> The full recipients list of [security@bitcoincore.org](mailto: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.
As a sec researcher, you’re exposing your own skin too by handling sensitive information to unknown members of a list.
Encrypting communications and knowing who are the endpoints to guarantee infosec eth
...
(https://github.com/bitcoin/bitcoin/issues/29366#issuecomment-1925939033)
> The full recipients list of [security@bitcoincore.org](mailto: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.
As a sec researcher, you’re exposing your own skin too by handling sensitive information to unknown members of a list.
Encrypting communications and knowing who are the endpoints to guarantee infosec eth
...
💬 achow101 commented on issue "Update security.md with all PGP fingerprints":
(https://github.com/bitcoin/bitcoin/issues/29366#issuecomment-1925943156)
> Encrypting communications and knowing who are the endpoints to guarantee infosec ethics are best practices in my eyes.
Then encrypt your emails to any of the published keys and no one else on the list will be able to read your emails.
(https://github.com/bitcoin/bitcoin/issues/29366#issuecomment-1925943156)
> Encrypting communications and knowing who are the endpoints to guarantee infosec ethics are best practices in my eyes.
Then encrypt your emails to any of the published keys and no one else on the list will be able to read your emails.
💬 ariard commented on issue "Update security.md with all PGP fingerprints":
(https://github.com/bitcoin/bitcoin/issues/29366#issuecomment-1925945051)
> Then encrypt your emails to any of the published keys and no one else on the list will be able to read your emails.
Thanks if the 3 published PGP fingerprints can add an authoritative dedicated mail. No wish to go through email alias.
You don’t answer my second q on infosec ethics, and transparency if re-sharing of sensitive info with unknown members.
(https://github.com/bitcoin/bitcoin/issues/29366#issuecomment-1925945051)
> Then encrypt your emails to any of the published keys and no one else on the list will be able to read your emails.
Thanks if the 3 published PGP fingerprints can add an authoritative dedicated mail. No wish to go through email alias.
You don’t answer my second q on infosec ethics, and transparency if re-sharing of sensitive info with unknown members.
💬 achow101 commented on issue "Update security.md with all PGP fingerprints":
(https://github.com/bitcoin/bitcoin/issues/29366#issuecomment-1925947832)
> Thanks if the 3 published PGP fingerprints can add an authoritative dedicated mail.
PGP keys contain emails, signed by the key itself. That is itself authoritative for each person. If you really want to, email those people directly, encrypted to their keys.
> You don’t answer my second q on infosec ethics, and transparency if re-sharing of sensitive info with unknown members.
You didn't ask one, you made a statement, which I think is sufficiently addressed by encrypting directly to th
...
(https://github.com/bitcoin/bitcoin/issues/29366#issuecomment-1925947832)
> Thanks if the 3 published PGP fingerprints can add an authoritative dedicated mail.
PGP keys contain emails, signed by the key itself. That is itself authoritative for each person. If you really want to, email those people directly, encrypted to their keys.
> You don’t answer my second q on infosec ethics, and transparency if re-sharing of sensitive info with unknown members.
You didn't ask one, you made a statement, which I think is sufficiently addressed by encrypting directly to th
...
✅ achow101 closed an issue: "Update security.md with all PGP fingerprints"
(https://github.com/bitcoin/bitcoin/issues/29366)
(https://github.com/bitcoin/bitcoin/issues/29366)
💬 sipa commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1477447986)
I think you can drop `{}`, `{____}`, and the second `{__C}` here (you currently have 18, not 15, entries).
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1477447986)
I think you can drop `{}`, `{____}`, and the second `{__C}` here (you currently have 18, not 15, entries).
💬 sipa commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1477447553)
It's linear, not constant? (`curr_selections` is $\mathcal{O}(n)$ in the number of UTXOs/groups). I assume that the point you're trying to make is that it doesn't scale with the search space (which is exponential in the number of UTXOs), but as-is it can be misunderstood.
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1477447553)
It's linear, not constant? (`curr_selections` is $\mathcal{O}(n)$ in the number of UTXOs/groups). I assume that the point you're trying to make is that it doesn't scale with the search space (which is exponential in the number of UTXOs), but as-is it can be misunderstood.
💬 sipa commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1477448371)
Maybe add, "thus we can SHIFT in this case".
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1477448371)
Maybe add, "thus we can SHIFT in this case".
💬 sipa commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1477448626)
Maybe add that this corresponds to deciding whether SHIFT or CUT are appropriate.
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1477448626)
Maybe add that this corresponds to deciding whether SHIFT or CUT are appropriate.
💬 sipa commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1477456250)
Document that this only holds for CG, or alternatively, set it in other algorithms were it applies too (only BNB, I assume)?
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1477456250)
Document that this only holds for CG, or alternatively, set it in other algorithms were it applies too (only BNB, I assume)?
💬 sipa commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1477455976)
You can use the (test) global `g_insecure_rand_ctx` instead of creating your own RNG.
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1477455976)
You can use the (test) global `g_insecure_rand_ctx` instead of creating your own RNG.
💬 sipa commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1477448598)
Maybe add that this is the EXPLORE step, or the final addition part of SHIFT/CUT.
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1477448598)
Maybe add that this is the EXPLORE step, or the final addition part of SHIFT/CUT.
💬 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.
(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?
(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.
(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
...
(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”]
...
(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
...
(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.
(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.