path: root/4d/b5f3682e7d4d62a051ff2035858195cdb09d33

Return-Path: <bastien.teinturier@acinq.fr>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 331EFC016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 22 Jun 2020 08:25:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 2207688AC7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 22 Jun 2020 08:25:22 +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 YDqQqiRouQn7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 22 Jun 2020 08:25:21 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com
 [209.85.210.50])
 by hemlock.osuosl.org (Postfix) with ESMTPS id 1AF038877D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 22 Jun 2020 08:25:21 +0000 (UTC)
Received: by mail-ot1-f50.google.com with SMTP id s13so12393619otd.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 22 Jun 2020 01:25:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=acinq-fr.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=7mb0EBOZWBkdq+mqsln2508MQ2fQAVPDRdAc3qN7bzI=;
 b=H0CmzuO9ruUk9DLSSKrVUQVwWxpR65wE+q/n+DLnxicwREIpWEv0Z3MIqLkHuuhHdj
 bhtQTjj2E8kNDcIf4OgYwhyEHgR1CR+2UlAP1pJBlC7JzvjUTHU1Gs9G986yHZaUeCIu
 sTaW9+8BClYqZHegW9vhxp2anGtY8/HMkQLL6y3HWOw2r/Xa/DJjRXOGO7JP2aHPpAxv
 ZBvSAcVh04PZj+teKJHxLBSIyIbtof9JkIMLFZKLCS66vrOjXPWsoRNFxuMTFka4x89m
 3SIM41OVVlYkwkFOkBS5lK0OsTZd2Uzw0KWKOZhJ4qt8f6tkI6fGTa/Y5F9Hu6lJq1v1
 gvXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=7mb0EBOZWBkdq+mqsln2508MQ2fQAVPDRdAc3qN7bzI=;
 b=lluBf6RX5uMfUULO69UlkIBoce8RLZEXPEfdcIpjPGyQGEnLb+Rz2BOLa9dSBO6nlI
 kIVf7OdF04IcONoFPWRCh/QSKDYtRJ5/GFJrpDOJwEubsIfnDcs3E9+rWD00u9g4j6n2
 hKwB9PKU3RRMXyHLa1t02kbYgN8wAbz0ndOoMDH3J9r83PeuSF5oGyu1TrmjdXcSMF4X
 KP4Pn2/wmtryJXIemyZZhRuRNwroHm3hvnIxUEg3oOLxcst2KcJBVr6xrLE1blvTgUq8
 TLQLieVKyghgIcuiwZyub8hvVRxVCgEWg3M2jcPXQXkvR8d0dDRChxmFeIlilINPprqF
 WRlQ==
X-Gm-Message-State: AOAM530xla217+2AorUh2NKOvZ1CeQqNLa4c4+COY8M2hIYd6FpMAsL9
 G96Dgf9FWuml/eiqfqPekSXUbSjdh8v9Tb+NhCvOHA==
X-Google-Smtp-Source: ABdhPJzCvGzjLY7y07jyCHxED5ku6J6WD1dpyEoZ3im6DNv1uY/T34Ss2Rem41boyARDNb8NIBTvzTIHvx3NVRNCGnY=
X-Received: by 2002:a05:6830:22f1:: with SMTP id
 t17mr13314876otc.288.1592814320176; 
 Mon, 22 Jun 2020 01:25:20 -0700 (PDT)
MIME-Version: 1.0
References: <PtYNeePySy_thDHm8FwIIGEk32EjJpSmiwPctyEg0hOrLZEHjO1IBghm4MWY88g51K-XF2pf_JDnW0UdTL6QSbACEj21h9U1s5ITc_N3I6Q=@protonmail.com>
 <67334082-5ABA-45C7-9C09-FF19B119C80D@mattcorallo.com>
 <62P_3wvv8z7AVCdKPfh-bs30-LliHkx9GI9Og3wqIK6hadIG0d6MJJm077zac1erpPUy31FqgZjkAjEl9AQtrOCg4XA5cxozBb7-OIbbgvE=@protonmail.com>
 <4c4f3a06-0078-ef6a-7b06-7484f0f9edf1@mattcorallo.com>
 <CACdvm3Of_9zhNmzCxeK-z8oz6wU=8RuDjr0R9+yrGeFjLYz9pg@mail.gmail.com>
 <20200619195846.fclw4ilngvbbf2kk@ganymede>
 <20200619205220.fshbr7pbijaerbf2@ganymede>
 <CACdvm3O+A5M17rqejzAMUzE+fxLdzqnDY2m5+rnc5C=nzyPp9g@mail.gmail.com>
 <20200620103647.g62srlcxbjqpaqj6@ganymede>
 <CACdvm3NTY1UYWJg=SJm+TAZSi5RophxhRvze9gKi9PyEHx0PgA@mail.gmail.com>
 <F7ZA7-s3UnfMlhYdA1esEhJIhgNIBSKCfHWG64UAcMvQM-ZS6Do7xMg8OfYhbkHIFNodbLIe51TQG7Ps3jFXFoS80EJ6oEh8n2009vbnl04=@protonmail.com>
In-Reply-To: <F7ZA7-s3UnfMlhYdA1esEhJIhgNIBSKCfHWG64UAcMvQM-ZS6Do7xMg8OfYhbkHIFNodbLIe51TQG7Ps3jFXFoS80EJ6oEh8n2009vbnl04=@protonmail.com>
From: Bastien TEINTURIER <bastien@acinq.fr>
Date: Mon, 22 Jun 2020 10:25:09 +0200
Message-ID: <CACdvm3O3UmZcYYGaY2x23MYY=3saPFkgQtaDELd=kY93SRLLaA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000bf61e705a8a7fb58"
X-Mailman-Approved-At: Mon, 22 Jun 2020 11:03:50 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>
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 <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: Mon, 22 Jun 2020 08:25:22 -0000

--000000000000bf61e705a8a7fb58
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey ZmnSCPxj,

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

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
insanely hard to
achieve without cooperation from a miners subset. Let me know if I'm too
optimistic on
this!

Cheers,
Bastien

Le lun. 22 juin 2020 =C3=A0 10:15, ZmnSCPxj <ZmnSCPxj@protonmail.com> a =C3=
=A9crit :

> Good morning Bastien,
>
> > Thanks for the detailed write-up on how it affects incentives and
> centralization,
> > 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
> with 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, withou=
t
> miners cooperating with the attacker.
>
> 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-miners.
>
> 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
> is not enough to get past the RBF rules (which requires not just a feerat=
e
> increase, but also an increase in absolute fee, of at least the minimum
> relay feerate 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
> boundary, this occurs even if everyone is running 100% unmodified Bitcoin
> Core code.
>
> I am not a mempool expert and my understanding may be incorrect.
>
> Regards,
> ZmnSCPxj
>

--000000000000bf61e705a8a7fb58
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hey ZmnSCPxj,<div><br></div><div>I agree that in theory th=
is looks possible, but doing it in practice with accurate control</div><div=
>of what parts of the network get what tx feels impractical to me (but mayb=
e I&#39;m wrong!).</div><div><br></div><div>It feels to me that an attacker=
 who would be able to do this would break *any* off-chain</div><div>constru=
ction that relies on absolute timeouts, so I&#39;m hoping this is insanely =
hard to</div><div>achieve without cooperation from a miners=C2=A0subset. Le=
t me know if I&#39;m too optimistic on</div><div>this!</div><div><br></div>=
<div>Cheers,</div><div>Bastien</div></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0lun. 22 juin 2020 =C3=A0=C2=A01=
0:15, ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@prot=
onmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">Good morning Bastien,<br>
<br>
&gt; Thanks for the detailed write-up on how it affects incentives and cent=
ralization,<br>
&gt; these are good points. I need to spend more time thinking about them.<=
br>
&gt;<br>
&gt; &gt; This is one reason I suggested using independent pay-to-preimage<=
br>
&gt; &gt; transactions[1]<br>
&gt;<br>
&gt; While this works as a technical solution, I think it has some incentiv=
es issues too.<br>
&gt; In this attack, I believe the miners that hide the preimage tx in thei=
r mempool have<br>
&gt; to be accomplice with the attacker, otherwise they would share that tx=
 with some of<br>
&gt; their peers, and some non-miner nodes would get that preimage tx and b=
e 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 =
miners cooperating with the attacker.<br>
<br>
Basically, the attacker releases two transactions with near-equal fees, so =
that neither can RBF the other.<br>
It releases the preimage tx near miners, and the timelock tx near non-miner=
s.<br>
<br>
Nodes at the boundaries between those that receive the preimage tx and the =
timelock 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 t=
he other (and *not* propagate the other), because the difference in fees is=
 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=
 feerate times transaction size).<br>
<br>
Because they reject the other tx, they do not propagate the other tx, so th=
e 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=
 code.<br>
<br>
I am not a mempool expert and my understanding may be incorrect.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--000000000000bf61e705a8a7fb58--