💬 fanquake commented on issue "Unnecessary symbols being exported in `libbitcoinconsensus.so`":
(https://github.com/bitcoin/bitcoin/issues/26698#issuecomment-1925907331)
Yep.
(https://github.com/bitcoin/bitcoin/issues/26698#issuecomment-1925907331)
Yep.
:lock: fanquake locked an issue: "Bitcoin Core changed to Bitcoin locked.."
(https://github.com/bitcoin/bitcoin/issues/29382)
(https://github.com/bitcoin/bitcoin/issues/29382)
💬 murchandamus commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#issuecomment-1925913171)
Added a longer textual explanation on how the algorithm can be thought in terms of the search graph it walks.
(https://github.com/bitcoin/bitcoin/pull/27877#issuecomment-1925913171)
Added a longer textual explanation on how the algorithm can be thought in terms of the search graph it walks.
💬 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
...