Content-Type: multipart/alternative;
 boundary=Apple-Mail-4ABBA549-16A1-4375-AFE1-69D9BBC13056
Content-Transfer-Encoding: 7bit
From: Matt Corallo <lf-lists@mattcorallo.com>
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: <CACdvm3O3UmZcYYGaY2x23MYY=3saPFkgQtaDELd=kY93SRLLaA@mail.gmail.com>
In-Reply-To: <CACdvm3O3UmZcYYGaY2x23MYY=3saPFkgQtaDELd=kY93SRLLaA@mail.gmail.com>
To: Bastien TEINTURIER <bastien@acinq.fr>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties
	and Competing Interest
Precedence: list


--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 <bitcoin-dev=
@lists.linuxfoundation.org> 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 <ZmnSCPxj@protonmail.com> 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

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr">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.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">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.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Matt</div><div dir=3D"lt=
r"><br><blockquote type=3D"cite">On Jun 22, 2020, at 04:04, Bastien TEINTURI=
ER via bitcoin-dev &lt;bitcoin-dev@lists.linuxfoundation.org&gt; wrote:<br><=
br></blockquote></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<d=
iv dir=3D"ltr">Hey ZmnSCPxj,<div><br></div><div>I agree that in theory this l=
ooks possible, but doing it in practice with accurate control</div><div>of w=
hat parts of the network get what tx feels impractical to me (but maybe I'm w=
rong!).</div><div><br></div><div>It feels to me that an attacker who would b=
e able to do this would break *any* off-chain</div><div>construction that re=
lies on absolute timeouts, so I'm hoping this is insanely hard to</div><div>=
achieve without cooperation from a miners&nbsp;subset. Let me know if I'm to=
o optimistic on</div><div>this!</div><div><br></div><div>Cheers,</div><div>B=
astien</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">Le&nbsp;lun. 22 juin 2020 =C3=A0&nbsp;10:15, ZmnSCPxj &lt;<a href=
=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; a =C3=A9=
crit&nbsp;:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good m=
orning Bastien,<br>
<br>
&gt; Thanks for the detailed write-up on how it affects incentives and centr=
alization,<br>
&gt; these are good points. I need to spend more time thinking about them.<b=
r>
&gt;<br>
&gt; &gt; This is one reason I suggested using independent pay-to-preimage<b=
r>
&gt; &gt; transactions[1]<br>
&gt;<br>
&gt; While this works as a technical solution, I think it has some incentive=
s issues too.<br>
&gt; In this attack, I believe the miners that hide the preimage tx in their=
 mempool have<br>
&gt; to be accomplice with the attacker, otherwise they would share that tx w=
ith some of<br>
&gt; their peers, and some non-miner nodes would get that preimage tx and be=
 able to<br>
&gt; gossip them off-chain (and even relay them to other mempools).<br>
<br>
I believe this is technically possible with current mempool rules, without m=
iners cooperating with the attacker.<br>
<br>
Basically, the attacker releases two transactions with near-equal fees, so t=
hat neither can RBF the other.<br>
It releases the preimage tx near miners, and the timelock tx near non-miners=
.<br>
<br>
Nodes at the boundaries between those that receive the preimage tx and the t=
imelock tx will receive both.<br>
However, they will receive one or the other first.<br>
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).<br>
<br>
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.<br>
<br>
I am not a mempool expert and my understanding may be incorrect.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>
<span>_______________________________________________</span><br><span>bitcoi=
n-dev mailing list</span><br><span>bitcoin-dev@lists.linuxfoundation.org</sp=
an><br><span>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/span><br></div></blockquote></body></html>=

--Apple-Mail-4ABBA549-16A1-4375-AFE1-69D9BBC13056--