From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id B220AC016F; Wed, 24 Jun 2020 08:39:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id ACF008887C; Wed, 24 Jun 2020 08:39:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kx3813by7Q0r; Wed, 24 Jun 2020 08:39:00 +0000 (UTC) X-Greylist: delayed 00:06:04 by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) by hemlock.osuosl.org (Postfix) with ESMTPS id AB44D88809; Wed, 24 Jun 2020 08:39:00 +0000 (UTC) Received: from [IPv6:2620:6e:a007:235::1] (unknown [IPv6:2620:6e:a007:235::1]) by mail.as397444.net (Postfix) with ESMTPSA id C87CE28E7DF; Wed, 24 Jun 2020 08:32:53 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-4ABBA549-16A1-4375-AFE1-69D9BBC13056 Content-Transfer-Encoding: 7bit From: Matt Corallo Mime-Version: 1.0 (1.0) Date: Wed, 24 Jun 2020 01:32:52 -0700 Message-Id: <034FCF40-B7D3-46F8-8746-98083CB0461E@mattcorallo.com> References: In-Reply-To: To: Bastien TEINTURIER , Bitcoin Protocol Discussion X-Mailer: iPhone Mail (17F80) Cc: lightning-dev Subject: Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest 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: Wed, 24 Jun 2020 08:39:01 -0000 --Apple-Mail-4ABBA549-16A1-4375-AFE1-69D9BBC13056 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Given transaction relay delays and a network topology that is rather transpa= rent if you look closely enough, I think this is very real and very practica= l (double-digit % success rate, at least, with some trial and error probably= 50+). That said, we all also probably know most of the people who know enou= gh to go from zero to doing this practically next week. As for motivated fol= ks who have lots of time to read code and dig, this seems like something wor= th fixing in the medium term. Your observation is what=E2=80=99s largely led me to conclude there isn=E2=80= =99t a lot we can do here without a lot of creativity and fundamental rethin= king of our approach. One thing I keep harping on is maybe saving the blind-= CPFP approach with a) eltoo, and b) some kind of magic transaction relay met= adata that allows you to specify =E2=80=9Cthis spends at least one output on= any transaction that spends output X=E2=80=9D so that nodes can always appl= y it properly. But maybe that=E2=80=99s a pipedream of complexity. I know An= toine has other thoughts. Matt > On Jun 22, 2020, at 04:04, Bastien TEINTURIER via bitcoin-dev wrote: >=20 > =EF=BB=BF > Hey ZmnSCPxj, >=20 > I agree that in theory this looks possible, but doing it in practice with a= ccurate control > of what parts of the network get what tx feels impractical to me (but mayb= e I'm wrong!). >=20 > It feels to me that an attacker who would be able to do this would break *= any* off-chain > construction that relies on absolute timeouts, so I'm hoping this is insan= ely hard to > achieve without cooperation from a miners subset. Let me know if I'm too o= ptimistic on > this! >=20 > Cheers, > Bastien >=20 >> Le lun. 22 juin 2020 =C3=A0 10:15, ZmnSCPxj a =C3= =A9crit : >> Good morning Bastien, >>=20 >> > Thanks for the detailed write-up on how it affects incentives and centr= alization, >> > these are good points. I need to spend more time thinking about them. >> > >> > > This is one reason I suggested using independent pay-to-preimage >> > > transactions[1] >> > >> > While this works as a technical solution, I think it has some incentive= s issues too. >> > In this attack, I believe the miners that hide the preimage tx in their= mempool have >> > to be accomplice with the attacker, otherwise they would share that tx w= ith some of >> > their peers, and some non-miner nodes would get that preimage tx and be= able to >> > gossip them off-chain (and even relay them to other mempools). >>=20 >> I believe this is technically possible with current mempool rules, withou= t miners cooperating with the attacker. >>=20 >> Basically, the attacker releases two transactions with near-equal fees, s= o that neither can RBF the other. >> It releases the preimage tx near miners, and the timelock tx near non-min= ers. >>=20 >> Nodes at the boundaries between those that receive the preimage tx and th= e timelock tx will receive both. >> However, they will receive one or the other first. >> Which one they receive first will be what they keep, and they will reject= the other (and *not* propagate the other), because the difference in fees i= s not enough to get past the RBF rules (which requires not just a feerate in= crease, but also an increase in absolute fee, of at least the minimum relay f= eerate times transaction size). >>=20 >> Because they reject the other tx, they do not propagate the other tx, so t= he boundary between the two txes is inviolate, neither can get past that bou= ndary, this occurs even if everyone is running 100% unmodified Bitcoin Core c= ode. >>=20 >> I am not a mempool expert and my understanding may be incorrect. >>=20 >> Regards, >> ZmnSCPxj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-4ABBA549-16A1-4375-AFE1-69D9BBC13056 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Given transaction relay de= lays and a network topology that is rather transparent if you look closely e= nough, I think this is very real and very practical (double-digit % success r= ate, at least, with some trial and error probably 50+). That said, we all al= so probably know most of the people who know enough to go from zero to doing= this practically next week. As for motivated folks who have lots of time to= read code and dig, this seems like something worth fixing in the medium ter= m.

Your observation is what= =E2=80=99s largely led me to conclude there isn=E2=80=99t a lot we can do he= re without a lot of creativity and fundamental rethinking of our approach. O= ne thing I keep harping on is maybe saving the blind-CPFP approach with a) e= ltoo, and b) some kind of magic transaction relay metadata that allows you t= o specify =E2=80=9Cthis spends at least one output on any transaction that s= pends output X=E2=80=9D so that nodes can always apply it properly. But mayb= e that=E2=80=99s a pipedream of complexity. I know Antoine has other thought= s.

Matt

On Jun 22, 2020, at 04:04, Bastien TEINTURI= ER via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
<= br>
=EF=BB=BFHey ZmnSCPxj,

I agree that in theory this l= ooks possible, but doing it in practice with accurate control
of w= hat parts of the network get what tx feels impractical to me (but maybe I'm w= rong!).

It feels to me that an attacker who would b= e able to do this would break *any* off-chain
construction that re= lies on absolute timeouts, so I'm hoping this is insanely hard to
= achieve without cooperation from a miners subset. Let me know if I'm to= o optimistic on
this!

Cheers,
B= astien

Le lun. 22 juin 2020 =C3=A0 10:15, ZmnSCPxj <ZmnSCPxj@protonmail.com> a =C3=A9= crit :
Good m= orning Bastien,

> Thanks for the detailed write-up on how it affects incentives and centr= alization,
> these are good points. I need to spend more time thinking about them. >
> > This is one reason I suggested using independent pay-to-preimage > > transactions[1]
>
> While this works as a technical solution, I think it has some incentive= s issues too.
> In this attack, I believe the miners that hide the preimage tx in their= mempool have
> to be accomplice with the attacker, otherwise they would share that tx w= ith some of
> their peers, and some non-miner nodes would get that preimage tx and be= able to
> gossip them off-chain (and even relay them to other mempools).

I believe this is technically possible with current mempool rules, without m= iners cooperating with the attacker.

Basically, the attacker releases two transactions with near-equal fees, so t= hat neither can RBF the other.
It releases the preimage tx near miners, and the timelock tx near non-miners= .

Nodes at the boundaries between those that receive the preimage tx and the t= imelock tx will receive both.
However, they will receive one or the other first.
Which one they receive first will be what they keep, and they will reject th= e other (and *not* propagate the other), because the difference in fees is n= ot enough to get past the RBF rules (which requires not just a feerate incre= ase, but also an increase in absolute fee, of at least the minimum relay fee= rate times transaction size).

Because they reject the other tx, they do not propagate the other tx, so the= boundary between the two txes is inviolate, neither can get past that bound= ary, this occurs even if everyone is running 100% unmodified Bitcoin Core co= de.

I am not a mempool expert and my understanding may be incorrect.

Regards,
ZmnSCPxj
_______________________________________________
bitcoi= n-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /span>
= --Apple-Mail-4ABBA549-16A1-4375-AFE1-69D9BBC13056--