path: root/1b/f3a4e755398e75045ff6cc4d60773ec824a662

Return-Path: <email@yancy.lol>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 636F6C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <aj@erisian.com.au>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen=
eva,sans-serif'>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
AJ/Antoine et al</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to<br />s=
olve that problem if they have only opt-in RBF available?</div>
</blockquote>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">
<p style=3D"color: #252525;">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?</p>
</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
Cheers,</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
-Yancy</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
On 2022-10-27 19:21, Anthony Towns via bitcoin-dev wrote:
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">On Thu, Oct 27, 2022 at 11:56:45AM +0200, John Carvalh=
o via bitcoin-dev wrote:
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">I took the time to read your whole post. Despite a dip=
lomatic tone, I find<br />your takeaways from all your references to remain=
 conveniently biased for<br />protecting the plan of RBF</blockquote>
<br />Yes, I am heavily biased against zeroconf: there's no way I'd persona=
lly<br />be willing to trust it for my own incoming funds, no matter how mu=
ch<br />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<br />assume that the payment going to me is going to be the one that make=
s<br />the error rate tick up from 0% to 0.0001%. That's okay; just because=
 I<br />wouldn't do something, doesn't mean other people shouldn't.<br /><b=
r />It does mean I'm not going to be a particularly good advocate for zeroc=
onf<br />though. I mean, I might still be a fine advocate for giving people=
 time<br />to react, making it clear what's going on, finding ways that mig=
ht make<br />everyone happy, or just digging it to random technical details=
; but,<br />for me, I'm more interested in a world where chargebacks are im=
possible,<br />not where we just make the best of what was possible with te=
chnology<br />from five or ten years ago.<br /><br />But that's fine: it ju=
st means that people, like yourself, who will<br />tolerate the risks of ze=
roconf, should be involved in the discussion.<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">You show multiple examples where, when I read them, I =
assume the next thing<br />you will say will be "so we really should stop t=
rying to impose optional<br />features, particularly when they affect exist=
ing use cases" but instead you<br />persist.</blockquote>
<br />Sure, that's natural: you read a sign saying "you can have any ice cr=
eam<br />you want for 5c" and think "Awesome, who wouldn't want cheap choco=
late<br />ice cream!!" and see me going for a Golden Gaytime and think "wtf=
 dude".<br />Different strokes.<br /><br />For me, I see the gmaxwell githu=
b comment I quoted saying:<br /><br />&nbsp;&nbsp;There is also a matter of=
 driving competent design rather than lazy<br />&nbsp;&nbsp;first thing tha=
t works.<br /><br />and think "yeah, okay, maybe we should be working harde=
r to push lightning<br />adoption, rather than letting people stick with wa=
llet UX from 2015"<br />and have altcoins take over &gt;50% of payment volu=
me.<br /><br />Likewise,<br /><br />&nbsp;&nbsp;There is also a very clear =
pattern we've seen in the past where<br />&nbsp;&nbsp;people take anything =
the system lets them do as strong evidence that<br />&nbsp;&nbsp;they have =
a irrevocable right to use the system in that way, and that<br />&nbsp;&nbs=
p;their only responsibility-- and if their usage harms the system it's<br /=
>&nbsp;&nbsp;the responsibility of the system to not permit it.<br /><br />=
seems a pretty good match against your claim "I expect the things I do<br /=
>with Bitcoin today to work FOREVER." Better to nip that thinking in the<br=
 />bud; and even if the best time to do that was years ago, the second best=
<br />time to do it is still now.<br /><br />By contrast, from the same pos=
t, I'd guess you're focussing on:<br /><br />&nbsp;&nbsp;Network behavior i=
s one of the few bits of friction<br />&nbsp;&nbsp;driving good technical d=
esign rather than "move fast, break things, and<br />&nbsp;&nbsp;force ever=
yone else onto my way of doing thing rather than discussing<br />&nbsp;&nbs=
p;the design in public".<br /><br />and thinking "yeah, move fast, break th=
ings, force everyone else --<br />that's exactly what's going on here, and =
shouldn't be".<br /><br />But that's also okay: even when there is common g=
round to be found,<br />sometimes it requires actual work to get people who=
 start from different<br />views to get there.<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">The problem is that RBF has already been an option for=
 years, and anyone<br />that wants to use it can.</blockquote>
<br />Is that true? Antoine claims [<a href=3D"https://lists.linuxfoundatio=
n.org/pipermail/lightning-dev/2021-May/003033.html" target=3D"_blank" rel=
=3D"noopener noreferrer">1</a>] that opt-in RBF isn't enough to avoid<br />=
a DoS issue when utxos are jointly funded by untrusting partners, and,<br /=
>aiui, that's the main motivation for addressing this now.<br /><br />[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</a><br /><=
br />The scenario he describes is: A, B, C create a tx:<br /><br />&nbsp;&n=
bsp;inputs: A1, B1, C1 [opts in to RBF]<br />&nbsp;&nbsp;fees: normal<br />=
&nbsp;&nbsp;outputs:<br />&nbsp;&nbsp;&nbsp;&nbsp;[lightning channel, DLC, =
etc, who knows]<br /><br />they all analyse the tx, and agree it looks grea=
t; however just before<br />publishing it, A spams the network with an alte=
rnative tx, double<br />spending her input:<br /><br />&nbsp;&nbsp;inputs: =
A1 [does not opt in to RBF]<br />&nbsp;&nbsp;fees: low<br />&nbsp;&nbsp;out=
puts: A<br /><br />If A gets the timing right, that's bad for B and C becau=
se they've<br />populated their mempool with the 1st transaction, while eve=
ryone else<br />sees the 2nd one instead; and neither tx will replace the o=
ther. B and<br />C can't know that they should just cancel their transactio=
n, eg:<br /><br />&nbsp;&nbsp;inputs: B1, C1 [opts in to RBF]<br />&nbsp;&n=
bsp;fees: 50% above normal<br />&nbsp;&nbsp;outputs:<br />&nbsp;&nbsp;&nbsp=
;&nbsp;[smaller channel, refund, whatever]<br /><br />and might instead was=
te time trying to fee bump the tx to get it mined,<br />or similar.<br /><b=
r />What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to<br=
 />solve that problem if they have only opt-in RBF available?<br /><br />If=
 you're right that opt-in RBF is enough, that question has a good<br />answ=
er. I don't believe anyone's presented an answer to it in the 17<br />month=
s since Antoine raised the concern.<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">passive aggression<br />escalation<br />unfair advanta=
ge<br />oppressive, dark-pattern design<br />strong-arming and shoe-horning=
</blockquote>
<br />Do you really think any of that was helping your cause?<br /><br />Ch=
eers,<br />aj<br />_______________________________________________<br />bit=
coin-dev mailing list<br /><a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org">bitcoin-dev@lists.linuxfoundation.org</a><br /><a href=3D"https://=
lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank" r=
el=3D"noopener noreferrer">https://lists.linuxfoundation.org/mailman/listin=
fo/bitcoin-dev</a></blockquote>
</div>
</body></html>

--=_fa9632dcc8743c40484718294ee9c34d--