Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 636F6C002D for ; Thu, 3 Nov 2022 21:07:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 2B14181F86 for ; Thu, 3 Nov 2022 21:07:00 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 2B14181F86 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9f35yC2a09a6 for ; Thu, 3 Nov 2022 21:06:59 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 901CA81EFC Received: from relay10.mail.gandi.net (relay10.mail.gandi.net [217.70.178.230]) by smtp1.osuosl.org (Postfix) with ESMTPS id 901CA81EFC for ; Thu, 3 Nov 2022 21:06:58 +0000 (UTC) Received: (Authenticated sender: email@yancy.lol) by mail.gandi.net (Postfix) with ESMTPA id E48CB240009; Thu, 3 Nov 2022 21:06:52 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 03 Nov 2022 22:06:52 +0100 From: email@yancy.lol To: Anthony Towns , Bitcoin Protocol Discussion Message-ID: <16eb6a50691ccc661310051de6b8e2c0@yancy.lol> X-Sender: email@yancy.lol Content-Type: multipart/alternative; boundary="=_fa9632dcc8743c40484718294ee9c34d" X-Mailman-Approved-At: Thu, 03 Nov 2022 21:09:57 +0000 Subject: Re: [bitcoin-dev] On mempool policy consistency X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2022 21:07:00 -0000 --=_fa9632dcc8743c40484718294ee9c34d Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed AJ/Antoine et al > What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to > solve that problem if they have only opt-in RBF available? Assuming Alice is a well funded advisory, with enough resources to spam the network so that enough nodes see her malicious transaction first, how does full-rbf solve this vs. opt-in rbf? Cheers, -Yancy On 2022-10-27 19:21, Anthony Towns via bitcoin-dev wrote: > On Thu, Oct 27, 2022 at 11:56:45AM +0200, John Carvalho via bitcoin-dev > wrote: > >> I took the time to read your whole post. Despite a diplomatic tone, I >> find >> your takeaways from all your references to remain conveniently biased >> for >> protecting the plan of RBF > > Yes, I am heavily biased against zeroconf: there's no way I'd > personally > be willing to trust it for my own incoming funds, no matter how much > evidence you show me that it's safe in practice. Show me a million > transactions where every single one worked fine, and I'm still going to > assume that the payment going to me is going to be the one that makes > the error rate tick up from 0% to 0.0001%. That's okay; just because I > wouldn't do something, doesn't mean other people shouldn't. > > It does mean I'm not going to be a particularly good advocate for > zeroconf > though. I mean, I might still be a fine advocate for giving people time > to react, making it clear what's going on, finding ways that might make > everyone happy, or just digging it to random technical details; but, > for me, I'm more interested in a world where chargebacks are > impossible, > not where we just make the best of what was possible with technology > from five or ten years ago. > > But that's fine: it just means that people, like yourself, who will > tolerate the risks of zeroconf, should be involved in the discussion. > >> You show multiple examples where, when I read them, I assume the next >> thing >> you will say will be "so we really should stop trying to impose >> optional >> features, particularly when they affect existing use cases" but >> instead you >> persist. > > Sure, that's natural: you read a sign saying "you can have any ice > cream > you want for 5c" and think "Awesome, who wouldn't want cheap chocolate > ice cream!!" and see me going for a Golden Gaytime and think "wtf > dude". > Different strokes. > > For me, I see the gmaxwell github comment I quoted saying: > > There is also a matter of driving competent design rather than lazy > first thing that works. > > and think "yeah, okay, maybe we should be working harder to push > lightning > adoption, rather than letting people stick with wallet UX from 2015" > and have altcoins take over >50% of payment volume. > > Likewise, > > There is also a very clear pattern we've seen in the past where > people take anything the system lets them do as strong evidence that > they have a irrevocable right to use the system in that way, and that > their only responsibility-- and if their usage harms the system it's > the responsibility of the system to not permit it. > > seems a pretty good match against your claim "I expect the things I do > with Bitcoin today to work FOREVER." Better to nip that thinking in the > bud; and even if the best time to do that was years ago, the second > best > time to do it is still now. > > By contrast, from the same post, I'd guess you're focussing on: > > Network behavior is one of the few bits of friction > driving good technical design rather than "move fast, break things, and > force everyone else onto my way of doing thing rather than discussing > the design in public". > > and thinking "yeah, move fast, break things, force everyone else -- > that's exactly what's going on here, and shouldn't be". > > But that's also okay: even when there is common ground to be found, > sometimes it requires actual work to get people who start from > different > views to get there. > >> The problem is that RBF has already been an option for years, and >> anyone >> that wants to use it can. > > Is that true? Antoine claims [1 [1]] that opt-in RBF isn't enough to > avoid > a DoS issue when utxos are jointly funded by untrusting partners, and, > aiui, that's the main motivation for addressing this now. > > [1] > https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html > > The scenario he describes is: A, B, C create a tx: > > inputs: A1, B1, C1 [opts in to RBF] > fees: normal > outputs: > [lightning channel, DLC, etc, who knows] > > they all analyse the tx, and agree it looks great; however just before > publishing it, A spams the network with an alternative tx, double > spending her input: > > inputs: A1 [does not opt in to RBF] > fees: low > outputs: A > > If A gets the timing right, that's bad for B and C because they've > populated their mempool with the 1st transaction, while everyone else > sees the 2nd one instead; and neither tx will replace the other. B and > C can't know that they should just cancel their transaction, eg: > > inputs: B1, C1 [opts in to RBF] > fees: 50% above normal > outputs: > [smaller channel, refund, whatever] > > and might instead waste time trying to fee bump the tx to get it mined, > or similar. > > What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to > solve that problem if they have only opt-in RBF available? > > If you're right that opt-in RBF is enough, that question has a good > answer. I don't believe anyone's presented an answer to it in the 17 > months since Antoine raised the concern. > >> passive aggression >> escalation >> unfair advantage >> oppressive, dark-pattern design >> strong-arming and shoe-horning > > Do you really think any of that was helping your cause? > > Cheers, > aj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Links: ------ [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html --=_fa9632dcc8743c40484718294ee9c34d Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
= AJ/Antoine et al
=  
= What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
s= olve that problem if they have only opt-in RBF available?
=  

Assuming Alice is a well funded advisory, with= enough resources to spam the network so that enough nodes see her maliciou= s transaction first, how does full-rbf solve this vs. opt-in rbf?

=  
= Cheers,
= -Yancy
=  
= On 2022-10-27 19:21, Anthony Towns via bitcoin-dev wrote:
On Thu, Oct 27, 2022 at 11:56:45AM +0200, John Carvalh= o via bitcoin-dev wrote:
I took the time to read your whole post. Despite a dip= lomatic tone, I find
your takeaways from all your references to remain= conveniently biased for
protecting the plan of RBF

Yes, I am heavily biased against zeroconf: there's no way I'd persona= lly
be willing to trust it for my own incoming funds, no matter how mu= ch
evidence you show me that it's safe in practice. Show me a million<= br />transactions where every single one worked fine, and I'm still going t= o
assume that the payment going to me is going to be the one that make= s
the error rate tick up from 0% to 0.0001%. That's okay; just because= I
wouldn't do something, doesn't mean other people shouldn't.
It does mean I'm not going to be a particularly good advocate for zeroc= onf
though. I mean, I might still be a fine advocate for giving people= time
to react, making it clear what's going on, finding ways that mig= ht make
everyone happy, or just digging it to random technical details= ; but,
for me, I'm more interested in a world where chargebacks are im= possible,
not where we just make the best of what was possible with te= chnology
from five or ten years ago.

But that's fine: it ju= st means that people, like yourself, who will
tolerate the risks of ze= roconf, should be involved in the discussion.

You show multiple examples where, when I read them, I = assume the next thing
you will say will be "so we really should stop t= rying to impose optional
features, particularly when they affect exist= ing use cases" but instead you
persist.

Sure, that's natural: you read a sign saying "you can have any ice cr= eam
you want for 5c" and think "Awesome, who wouldn't want cheap choco= late
ice cream!!" and see me going for a Golden Gaytime and think "wtf= dude".
Different strokes.

For me, I see the gmaxwell githu= b comment I quoted saying:

  There is also a matter of= driving competent design rather than lazy
  first thing tha= t works.

and think "yeah, okay, maybe we should be working harde= r to push lightning
adoption, rather than letting people stick with wa= llet UX from 2015"
and have altcoins take over >50% of payment volu= me.

Likewise,

  There is also a very clear = pattern we've seen in the past where
  people take anything = the system lets them do as strong evidence that
  they have = a irrevocable right to use the system in that way, and that
 &nbs= p;their only responsibility-- and if their usage harms the system it's
  the responsibility of the system to not permit it.

= seems a pretty good match against your claim "I expect the things I do
with Bitcoin today to work FOREVER." Better to nip that thinking in thebud; and even if the best time to do that was years ago, the second best=
time to do it is still now.

By contrast, from the same pos= t, I'd guess you're focussing on:

  Network behavior i= s one of the few bits of friction
  driving good technical d= esign rather than "move fast, break things, and
  force ever= yone else onto my way of doing thing rather than discussing
 &nbs= p;the design in public".

and thinking "yeah, move fast, break th= ings, force everyone else --
that's exactly what's going on here, and = shouldn't be".

But that's also okay: even when there is common g= round to be found,
sometimes it requires actual work to get people who= start from different
views to get there.

The problem is that RBF has already been an option for= years, and anyone
that wants to use it can.

Is that true? Antoine claims [1] that opt-in RBF isn't enough to avoid
= a DoS issue when utxos are jointly funded by untrusting partners, and,
aiui, that's the main motivation for addressing this now.

[1] <= a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-Ma= y/003033.html" target=3D"_blank" rel=3D"noopener noreferrer">https://lists.= linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
<= br />The scenario he describes is: A, B, C create a tx:

 &n= bsp;inputs: A1, B1, C1 [opts in to RBF]
  fees: normal
=   outputs:
    [lightning channel, DLC, = etc, who knows]

they all analyse the tx, and agree it looks grea= t; however just before
publishing it, A spams the network with an alte= rnative tx, double
spending her input:

  inputs: = A1 [does not opt in to RBF]
  fees: low
  out= puts: A

If A gets the timing right, that's bad for B and C becau= se they've
populated their mempool with the 1st transaction, while eve= ryone else
sees the 2nd one instead; and neither tx will replace the o= ther. B and
C can't know that they should just cancel their transactio= n, eg:

  inputs: B1, C1 [opts in to RBF]
 &n= bsp;fees: 50% above normal
  outputs:
   = ; [smaller channel, refund, whatever]

and might instead was= te time trying to fee bump the tx to get it mined,
or similar.
What should folks wanting to do coinjoins/dualfunding/dlcs/etc do tosolve that problem if they have only opt-in RBF available?

If= you're right that opt-in RBF is enough, that question has a good
answ= er. I don't believe anyone's presented an answer to it in the 17
month= s since Antoine raised the concern.

passive aggression
escalation
unfair advanta= ge
oppressive, dark-pattern design
strong-arming and shoe-horning=

Do you really think any of that was helping your cause?

Ch= eers,
aj
_______________________________________________
bit= coin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listin= fo/bitcoin-dev
--=_fa9632dcc8743c40484718294ee9c34d--