đ
Original date posted:2022-11-02
đ Original message:Sorry, I forgot one point which is pertinent to this conversation.
*Even with* fullrbf-everywhere and V3, pinning via rule#3 and rule#5 are
still an issue in coinjoin scenarios.
Each coinjoin adversary can double-spend their coin to either full package
weight(101kvb),
or give 24 descendants, which means you quickly pay out the nose in rule#3
or are excluded
from RBFing it if you have 4+ greifers in your coinjoin violating rule#5.
If we instead narrowed this policy to marking a transaction output as
opt-in to V3, it gets a bit more interesting. *Unfortunately,
double-spending counterparties can still cause rule#3 pain, one 100kvb
package of junk per peer,* but rule#5 violations is at least contained to
coinjoins with ~50 peers(assuming two transactions booted per input
double-spent, which would be the V3 max bumped per input).
It's still worth exploring, but very speculatively.
Greg
On Wed, Nov 2, 2022 at 10:04 AM Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Tue, Nov 01, 2022 at 10:21:59PM -0400, Antoine Riard via bitcoin-dev
> wrote:
> > Hi list,
> >
> > Reading Suhas's post on mempool policy consistency rules, and the
> grounded
> > suggestion that as protocol developers we should work on special policy
> > rules to support each reasonable use case on the network rather to
> arbiter
> > between class of use-cases in the design of an
> > unified set of rules, reminded me there is another solution to solve
> > multi-party funding pinning rather than wide deployment of fullrbf. This
> > was communicated to me a while back, and it was originally dismissed
> > because of the privacy trade-offs (and potential slight fees overhead
> > cost). However, if widely adopted, they might sound acceptable to
> > contracting protocol developers and operators.
>
> Strong NACK.
>
> Zeroconf is, at best, a very marginal usecase. The only services that have
> spoken up in support of it are Bitrefill and Muun, and the latter says
> they're
> working to get rid of their vulnerability to it. People attempting to make
> it
> secure have repeatedly done sybil attacks against the network in attempts
> to
> measure transaction propagation. And of course, if transaction fees and
> full
> mempools are in our near future - as is widely expected - mempool
> consistency
> will even further diminish making zeroconf even harder to achieve.
>
> Incurring a bunch of engineering costs and harming privacy for the sake of
> continuing this nonsense is ridiculous.
>
> If anything, we should be moving to full-RBF so we can undo the privacy
> cost
> that is opt-in-RBF: right now 30% of transactions are having to harm their
> privacy by signalling support for it. Full-RBF will allow that wallet
> distinguisher to be eliminated.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221102/2c4439ba/attachment-0001.html>;
Greg Sanders [ARCHIVE] /
npub1jdâŚ3gh0m
2023-06-07 23:16:13
in reply to nevent1qâŚ7kmc
Author Public Key
npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mSeen on
wss://relay.noswhere.comPublished at
2023-06-07 23:16:13Event JSON
{
"id": "5cbe3166ff2c24ae6218c05ac96f2e0aecdd2d2bf4c3755a334b4d29a4dcbea7",
"pubkey": "937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19",
"created_at": 1686179773,
"kind": 1,
"tags": [
[
"e",
"03ce8402c8d00f8fb12b6c9f61c1c16ffbea9c68da0a9950af1d09807433cf63",
"",
"root"
],
[
"e",
"e24d8afe6cae90ccb712b1fe0897999755b3d4b2199d7b0f3fe511faa1d79dc2",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "đ
Original date posted:2022-11-02\nđ Original message:Sorry, I forgot one point which is pertinent to this conversation.\n\n*Even with* fullrbf-everywhere and V3, pinning via rule#3 and rule#5 are\nstill an issue in coinjoin scenarios.\n\nEach coinjoin adversary can double-spend their coin to either full package\nweight(101kvb),\nor give 24 descendants, which means you quickly pay out the nose in rule#3\nor are excluded\nfrom RBFing it if you have 4+ greifers in your coinjoin violating rule#5.\n\nIf we instead narrowed this policy to marking a transaction output as\nopt-in to V3, it gets a bit more interesting. *Unfortunately,\ndouble-spending counterparties can still cause rule#3 pain, one 100kvb\npackage of junk per peer,* but rule#5 violations is at least contained to\ncoinjoins with ~50 peers(assuming two transactions booted per input\ndouble-spent, which would be the V3 max bumped per input).\n\nIt's still worth exploring, but very speculatively.\n\nGreg\n\nOn Wed, Nov 2, 2022 at 10:04 AM Peter Todd via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Tue, Nov 01, 2022 at 10:21:59PM -0400, Antoine Riard via bitcoin-dev\n\u003e wrote:\n\u003e \u003e Hi list,\n\u003e \u003e\n\u003e \u003e Reading Suhas's post on mempool policy consistency rules, and the\n\u003e grounded\n\u003e \u003e suggestion that as protocol developers we should work on special policy\n\u003e \u003e rules to support each reasonable use case on the network rather to\n\u003e arbiter\n\u003e \u003e between class of use-cases in the design of an\n\u003e \u003e unified set of rules, reminded me there is another solution to solve\n\u003e \u003e multi-party funding pinning rather than wide deployment of fullrbf. This\n\u003e \u003e was communicated to me a while back, and it was originally dismissed\n\u003e \u003e because of the privacy trade-offs (and potential slight fees overhead\n\u003e \u003e cost). However, if widely adopted, they might sound acceptable to\n\u003e \u003e contracting protocol developers and operators.\n\u003e\n\u003e Strong NACK.\n\u003e\n\u003e Zeroconf is, at best, a very marginal usecase. The only services that have\n\u003e spoken up in support of it are Bitrefill and Muun, and the latter says\n\u003e they're\n\u003e working to get rid of their vulnerability to it. People attempting to make\n\u003e it\n\u003e secure have repeatedly done sybil attacks against the network in attempts\n\u003e to\n\u003e measure transaction propagation. And of course, if transaction fees and\n\u003e full\n\u003e mempools are in our near future - as is widely expected - mempool\n\u003e consistency\n\u003e will even further diminish making zeroconf even harder to achieve.\n\u003e\n\u003e Incurring a bunch of engineering costs and harming privacy for the sake of\n\u003e continuing this nonsense is ridiculous.\n\u003e\n\u003e If anything, we should be moving to full-RBF so we can undo the privacy\n\u003e cost\n\u003e that is opt-in-RBF: right now 30% of transactions are having to harm their\n\u003e privacy by signalling support for it. Full-RBF will allow that wallet\n\u003e distinguisher to be eliminated.\n\u003e\n\u003e --\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221102/2c4439ba/attachment-0001.html\u003e",
"sig": "0561b299a26a136dea1d9fcd40fede32db64fd2282480276ee6e87b28f2e87aab5803a5419a0954bdefdb0398307e36364e12a25ef58c3451c901fd4e73cc0ed"
}