path: root/f3/2a6669b22bb55a07a1e73744900335f13bcd9a

Return-Path: <bastien.teinturier@acinq.fr>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 35DC5C016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Jun 2020 13:13:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 3252A85A76
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Jun 2020 13:13:10 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 8J97xrRbIzZq
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Jun 2020 13:13:09 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com
 [209.85.210.48])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id E8D8185A60
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Jun 2020 13:13:08 +0000 (UTC)
Received: by mail-ot1-f48.google.com with SMTP id k15so5159584otp.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Jun 2020 06:13:08 -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=LBPzyaHsTQFpsi3367EWKMv6S48Qna5ArWcynFXjaFE=;
 b=jLlPlsTWzwmx4gW4CtUY31rd6RSRXHULcRsMiOSmy1/bCRcFry7xoVpOrv98idvmgC
 zglq40ih5yq4dgxa1yoY5NNgEiUO2p2FlSohVCKUwOGq02bjBYyKCYqQEEwZalWt2428
 dB30zP9+stGwO8T5GnlLiSXCuvp2kA0DajSjTUvoND+cQPlG1iZXBnJol/aSelpJf6la
 NBDsoxXZ/z377tbb4xUemMJfdAXj1wU9bYdBOVFCgY6hPmDNWobvdLt7VPCF4AzxPN3O
 ah3JucdEtmKOj8fOQQfndiZfYAY7I9UkSVyq9DvItr6YdMemetdDQv9V7ykHahnCiZ22
 BUvw==
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=LBPzyaHsTQFpsi3367EWKMv6S48Qna5ArWcynFXjaFE=;
 b=OALiX1gUNyciSVcDtzze59oac5WQuaTTbPW1HVfrpMdMpkFhrSD3PYUkxd4DrP8Gmd
 4lvwy+BZ6NvxhnZy30TPNUKM1GubihJmCIXniytq6ZHn4IcabcrZExkezafTOhf/TO5N
 g+CuzdiapNLQH75n6hbqYKTqBr3QOQR7v99zZTenC6Jx5xn10hdXrtFHi8F1yKQbTU2e
 mspXtACadOK/YV9d0veUmbCMKICXOZkhmfOPTrOnipsCQJivej7kPd7PDh6mNZBjx2o3
 GZwOmIAAOez1b7c6rttm68NGUrshC/FPZIU4YRRlK798LVpadwaEe1unVOa6GUWjBjYb
 BAqw==
X-Gm-Message-State: AOAM532MafAA7+OJOAsCkr11vRogeUezAyRZOVjqTJZrEWmpjOCySmG1
 XxIpz5Ndpo1bjFawoOsIK350neeyySxyYplyT1hs9Q==
X-Google-Smtp-Source: ABdhPJzIZuXqc1KgwAsLrhEOdMgwjaQ+JBBgnKtTQfapyRlT1M4WaOn3RbY9OgpQcFcpiExK2PO+7rHylZzZIXMxiZ0=
X-Received: by 2002:a9d:6d8c:: with SMTP id x12mr26289375otp.86.1593090788056; 
 Thu, 25 Jun 2020 06:13:08 -0700 (PDT)
MIME-Version: 1.0
References: <CABT1wW=X35HRVGuP-BHUhDrkBEw27+-iDkNnHWjRU-1mRkn0JQ@mail.gmail.com>
 <CABT1wW=KWtoo6zHs8=yUQ7vAYcFSdAzdpDJ9yfw6sJrLd6dN5A@mail.gmail.com>
 <ahTHfoyyTpBrMiKdJWMn9Qa8CMCEd1-y8OXPSjsDmttTOVC3zGuDoSHkm_oOe5mBYgIAY7jOPocQhLW29n544xFsqVyq51NFApvaFYYSvFY=@protonmail.com>
 <CABT1wWknczx62uCpJPWku-KeYuaFvJHrvOS74YzqfoVe5x=edg@mail.gmail.com>
 <CABT1wWmm=rx1MkFeNhGeEgdu7XpBXYeq_PWaZFfBOA7MRSKezw@mail.gmail.com>
 <xFJlIP6z6qhjxDAP8xUBnqPF-Wulexjr9izry8mIWCQzQdNrULtX_TwWGfuHo7VNfTdXZNmy05QHxMF3iJbjZm_-jFO_WRJjSQR0N_Dreic=@protonmail.com>
 <CAGXD5f0PXDMbVMiUNnqK-HGwB1yDEmBQgtLbQU4xcad3pDaGmw@mail.gmail.com>
 <XcV-a5p3nVenGEXgv4CO2X6lh4UXi18PM4-iKnfY3_SSoi5xCeCp84wsS1yHdHMVvDftNX5TrOnhUfvei371OQQHIVAJmcF-UQ_EAAZONyE=@protonmail.com>
 <CAGXD5f25Y180WoVhh+PnNP6pF_fHE1DbRqDJp_vaLz58+-5=8g@mail.gmail.com>
In-Reply-To: <CAGXD5f25Y180WoVhh+PnNP6pF_fHE1DbRqDJp_vaLz58+-5=8g@mail.gmail.com>
From: Bastien TEINTURIER <bastien@acinq.fr>
Date: Thu, 25 Jun 2020 15:12:56 +0200
Message-ID: <CACdvm3OJOJ9TXxR5x=j6+aC4s71geXXRF9XOj0Bi=Pw+p2i6PQ@mail.gmail.com>
To: Nadav Ivgi <nadav@shesek.info>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000846ef705a8e85a9b"
X-Mailman-Approved-At: Thu, 25 Jun 2020 13:31:12 +0000
Cc: Matan Yehieli <matany@campus.technion.ac.il>,
 Itay Tsabary <sitay@campus.technion.ac.il>
Subject: Re: [bitcoin-dev] MAD-HTLC
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, 25 Jun 2020 13:13:10 -0000

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

Good morning list,

This is an interesting and simple idea, thanks for sharing this paper!

However I think there are a couple of important issues (but it could be me
misunderstanding):

* the assumption that the mempool is a shared resource is flawed: it's
entirely possible
  to have very different mempools in different areas of the network, for a
potentially long
  period of time (see the RBF pinning thread [1]), and an attacker can
leverage this fact
* a corollary is that Bob may not know that Alice has published her
transaction, and will
  end up publishing his timeout tx, unknowingly giving the two preimages to
the miners
* a corollary of that is a very unhealthy incentive to miners, when they
receive an HTLC
  success tx, to always wait for the timeout before confirming the
transaction, in hope that
  they'll receive the second preimage and will be able to claim the funds
for themselves
  (whereas currently they don't gain anything by waiting before confirming
these txs)

To be fair the paper states that it doesn't address issues of malicious
miners or an attacker
colluding with a miner, but I think that even honest miners now have an
unhealthy incentive
regarding htlc success confirmation.

Let me know if I misunderstood something, or if you have ideas on how to
explore that
threat model in the future.

Cheers,
Bastien

[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002639=
.html



Le jeu. 25 juin 2020 =C3=A0 14:45, Nadav Ivgi via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> Hi ZmnSCPxj,
>
> You are of course correct. I had considered the effect of reorgs, but the
> email seemed to be getting too lengthy to mention that too.
>
> You would need a few spare blocks in which Bob won't be accused of briber=
y
> as a safety margin, which does reduce the time frame in which Alice can g=
et
> her transaction confirmed in order to have a valid bribery fraud. This
> seems workable if the time frame was long enough (over a few hours should
> be sufficient, assuming we consider reorgs of over 3-4 blocks to be
> unlikely), but could indeed be problematic if the time frame is already
> short to begin with.
>
> Nadav
>
> On Thu, Jun 25, 2020 at 7:04 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
>> Good morning Nadav,
>>
>> > > I and some number of Lightning devs consider this to be sufficient
>> disincentive to Bob not attacking in the first place.
>> >
>> > An additional disincentive could be introduced in the form of bribery
>> proofs for failed attempts.
>> >
>> > If we assume that "honest" users of the LN protocol won't reveal their
>> timelocked transactions before reaching the timelock expiry (they should=
n't
>> anyway because standard full node implementations won't relay them), we =
can
>> prove that Bob attempted bribery and failed to an outside observer by
>> showing Bob's signed timelocked transaction, spending an output that was=
 in
>> reality spent by a different transaction prior to the locktime expiry,
>> which should not be possible if Bob had waited.
>>
>>
>> Unfortunately this could be subject to an inversion of this attack.
>>
>> Alice can wait for the timelock to expire, then bribe miners to prevent
>> confirmation of the Bob timelocked transaction, getting the Alice
>> hashlocked transaction confirmed.
>>
>> Now of course you do mention "prior to the locktime expiry" but there is
>> now risk at around locktime.
>>
>> Particularly, "natural" orphaned blocks and short-term chainsplits can
>> exist.
>> Bob might see that the locktime has arrived and broadcast the signed
>> timelocked transaction, then Alice sees the locktime has not yet arrived
>> (due to short-term chainsplits/propagation delays) and broadcast the sig=
ned
>> hashlocked transaction, then in the end the Alice side of the short-term
>> chainsplit is what solidifies into reality due to random chance on which
>> miner wins which block.
>> Then Bob can now be accused of bribery, even though it acted innocently;
>> it broadcasted the timelock branch due to a natural chainsplit but Alice
>> hashlocked branch got confirmed.
>>
>> Additional complications can be added on top to help mitigate this edge
>> case but more complex =3D=3D worse in general.
>> For example it could "prior to locktime expiry" can ignore a few blocks
>> before the actual timelock, but this might allow Bob to mount the attack=
 by
>> initiating its bribery behavior earlier by those few blocks.
>>
>> Finally, serious attackers would just use new pseudonyms, the important
>> thing is to make pseudonyms valuable and costly to lose, so it is
>> considered sufficient that LN nodes need to have some commitment to the =
LN
>> in the form of actual channels (which are valuable, potentially
>> money-earning constructs, and costly to set up).
>>
>> Other HTLC-using systems, such as the "SwapMarket" being proposed by
>> Chris Belcher, could use similar disincentivizing; I know Chris is plann=
ing
>> a fidelity bond system for SwapMarket makers, for example, which would
>> mimic the properties of LN channels (costly to set up, money-earning).
>>
>> Regards,
>> ZmnSCPxj
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Good morning list,<div><br></div><div>This is an interesti=
ng and simple idea, thanks for sharing this paper!</div><div><br></div><div=
>However I think there are a couple of important issues (but it could be me=
 misunderstanding):</div><div><br></div><div>* the assumption that the memp=
ool is a shared resource is flawed: it&#39;s entirely possible</div><div>=
=C2=A0 to have very different mempools in different areas of the network, f=
or a potentially long</div><div>=C2=A0 period of time (see the RBF pinning =
thread [1]), and an attacker can leverage this fact</div><div>* a corollary=
 is that Bob may not know that Alice has published her transaction, and wil=
l</div><div>=C2=A0 end up publishing his timeout tx, unknowingly giving the=
 two preimages to the miners</div><div>* a corollary of that is a very unhe=
althy incentive to miners, when they receive an HTLC</div><div>=C2=A0 succe=
ss tx, to always wait for the timeout before confirming the transaction, in=
 hope that</div><div>=C2=A0 they&#39;ll receive the second preimage and wil=
l be able to claim the funds for themselves</div><div>=C2=A0 (whereas curre=
ntly they don&#39;t gain anything by waiting before confirming these txs)</=
div><div><br></div><div>To be fair the paper states that it doesn&#39;t add=
ress issues of malicious miners or an attacker</div><div>colluding with a m=
iner, but I think that even honest miners now have an unhealthy incentive</=
div><div>regarding htlc success confirmation.</div><div><br></div><div>Let =
me know if I misunderstood something, or if you have ideas on how to explor=
e that</div><div>threat model in the future.</div><div><br></div><div>Cheer=
s,</div><div>Bastien</div><div><br></div><div>[1]=C2=A0<a href=3D"https://l=
ists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002639.html">ht=
tps://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002639.h=
tml</a></div><div><br></div><div><br></div></div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0jeu. 25 juin 2020 =C3=A0=
=C2=A014:45, Nadav Ivgi via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; a =
=C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><div>Hi ZmnSCPxj,</div><div><br></div><div>You are of co=
urse correct. I=20
had considered the effect of reorgs, but the email seemed to be getting=20
too lengthy to mention that too.<br></div><div><br></div><div>You would=20
need a few spare blocks in which Bob won&#39;t be accused of bribery as a=
=20
safety margin, which does reduce the time frame in which Alice can get=20
her transaction confirmed in order to have a valid bribery fraud. This=20
seems workable if the time frame was long enough (over a few hours=20
should be sufficient, assuming we consider reorgs of over 3-4 blocks to=20
be unlikely), but could indeed be problematic if the time frame is=20
already short to begin with.</div><font color=3D"#888888"><div><br></div><d=
iv>Nadav</div></font></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Thu, Jun 25, 2020 at 7:04 AM ZmnSCPxj &lt;<a href=
=3D"mailto:ZmnSCPxj@protonmail.com" target=3D"_blank">ZmnSCPxj@protonmail.c=
om</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">Good morning Nadav,<br>
<br>
&gt; &gt; I and some number of Lightning devs consider this to be sufficien=
t disincentive to Bob not attacking in the first place.<br>
&gt;<br>
&gt; An additional disincentive could be introduced in the form of bribery =
proofs for failed attempts.<br>
&gt;<br>
&gt; If we assume that &quot;honest&quot; users of the LN protocol won&#39;=
t reveal their timelocked transactions before reaching the timelock expiry =
(they shouldn&#39;t anyway because standard full node implementations won&#=
39;t relay them), we can prove that Bob attempted bribery and failed to an =
outside observer by showing Bob&#39;s signed timelocked transaction, spendi=
ng an output that was in reality spent by a different transaction prior to =
the locktime expiry, which should not be possible if Bob had waited.<br>
<br>
<br>
Unfortunately this could be subject to an inversion of this attack.<br>
<br>
Alice can wait for the timelock to expire, then bribe miners to prevent con=
firmation of the Bob timelocked transaction, getting the Alice hashlocked t=
ransaction confirmed.<br>
<br>
Now of course you do mention &quot;prior to the locktime expiry&quot; but t=
here is now risk at around locktime.<br>
<br>
Particularly, &quot;natural&quot; orphaned blocks and short-term chainsplit=
s can exist.<br>
Bob might see that the locktime has arrived and broadcast the signed timelo=
cked transaction, then Alice sees the locktime has not yet arrived (due to =
short-term chainsplits/propagation delays) and broadcast the signed hashloc=
ked transaction, then in the end the Alice side of the short-term chainspli=
t is what solidifies into reality due to random chance on which miner wins =
which block.<br>
Then Bob can now be accused of bribery, even though it acted innocently; it=
 broadcasted the timelock branch due to a natural chainsplit but Alice hash=
locked branch got confirmed.<br>
<br>
Additional complications can be added on top to help mitigate this edge cas=
e but more complex =3D=3D worse in general.<br>
For example it could &quot;prior to locktime expiry&quot; can ignore a few =
blocks before the actual timelock, but this might allow Bob to mount the at=
tack by initiating its bribery behavior earlier by those few blocks.<br>
<br>
Finally, serious attackers would just use new pseudonyms, the important thi=
ng is to make pseudonyms valuable and costly to lose, so it is considered s=
ufficient that LN nodes need to have some commitment to the LN in the form =
of actual channels (which are valuable, potentially money-earning construct=
s, and costly to set up).<br>
<br>
Other HTLC-using systems, such as the &quot;SwapMarket&quot; being proposed=
 by Chris Belcher, could use similar disincentivizing; I know Chris is plan=
ning a fidelity bond system for SwapMarket makers, for example, which would=
 mimic the properties of LN channels (costly to set up, money-earning).<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000846ef705a8e85a9b--