path: root/ac/fa7cd81f37e4335963bc4ead6aef568ba964cf

Return-Path: <nadav@shesek.info>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id DC207C016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Jun 2020 04:36:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id 6441C21507
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Jun 2020 04:36:06 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id NGvvIlv1EcMr
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Jun 2020 04:36:05 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com
 [209.85.208.193])
 by silver.osuosl.org (Postfix) with ESMTPS id F107D2107F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Jun 2020 04:36:04 +0000 (UTC)
Received: by mail-lj1-f193.google.com with SMTP id q19so4987465lji.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Jun 2020 21:36:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shesek.info; s=shesek;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=/h48OFhY54Fy5lq/g9dLrpdQ6v6ojB3mz6ztcp5ksY8=;
 b=FHVRGXh5l4kdWknfmEh475CtTcqso1puhNHUYkSj+/2VlqzP2h1wtUKbHFSZKrRHms
 UM9DVjS/eb6cY5vSrZd5HPFle/Vp8E9ii2piEVO76MxWty/9L9zGyCxhsJTorPsNG0YI
 tOjRhLkK96wlq988nXQghG5cv2I529/+4MMv8=
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=/h48OFhY54Fy5lq/g9dLrpdQ6v6ojB3mz6ztcp5ksY8=;
 b=Zhmy/jHHhzKEc4sIf35C5N4iykqMzX4hK0fZEmbeHpFXm177PqAOKohTQts0rdioRZ
 7BkpcbfR4bKifyiQDCBhPsN3zS6ewDwqbQLiYhK7w9oc8el9A0CvUETxvcJUessKCfe6
 6yK0CB0qkJljYgbZE8aajHsiGD1SQQR9XCurAFZUrk19V+MV4yUERtwSRBUxxe90rGUi
 wzCAwaOQZ1SanfXqNGZrMfX7JJkUJHEnSB0YR6pwTe7K1EOGl3oZBASkzNjy4mOW3kWw
 MVnweSZzxnXwxRJQZuuD1OsurFIWdv3+srbyat8M+C9RiLPZtzeQcqUNkUrF2S8S1THw
 +phw==
X-Gm-Message-State: AOAM532wn1Quut6AYZO5yjCMEFbuaNiMS6Dn3Rt7EdzPMA64bAcrOVla
 NHVj2EdEwsKAQ0u23s8BwFzsbLQ3drxaTTIB3ayhoQ==
X-Google-Smtp-Source: ABdhPJyHRaxEJfs9eZbfd15UGuwV84J6AOmKq0MnPkakZPvjLxbNhxLtO+sOUdQtvy7TPwnis7aXfMWjKhyrIznM880=
X-Received: by 2002:a2e:b8ce:: with SMTP id s14mr14820423ljp.89.1593059762880; 
 Wed, 24 Jun 2020 21:36:02 -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>
In-Reply-To: <XcV-a5p3nVenGEXgv4CO2X6lh4UXi18PM4-iKnfY3_SSoi5xCeCp84wsS1yHdHMVvDftNX5TrOnhUfvei371OQQHIVAJmcF-UQ_EAAZONyE=@protonmail.com>
From: Nadav Ivgi <nadav@shesek.info>
Date: Thu, 25 Jun 2020 07:35:51 +0300
Message-ID: <CAGXD5f25Y180WoVhh+PnNP6pF_fHE1DbRqDJp_vaLz58+-5=8g@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000463bfa05a8e12126"
X-Mailman-Approved-At: Thu, 25 Jun 2020 12:45:36 +0000
Cc: Matan Yehieli <matany@campus.technion.ac.il>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 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 04:36:07 -0000

--000000000000463bfa05a8e12126
Content-Type: text/plain; charset="UTF-8"

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 bribery
as a safety margin, which does reduce the time frame in which Alice can get
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 shouldn'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 signed
> 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 == 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 planning 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
>

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

<div dir=3D"ltr"><div>Hi ZmnSCPxj,</div><div><br></div><div>You are of cour=
se 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">ZmnSCPxj@protonmail.com</a>&gt; wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning Nad=
av,<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>

--000000000000463bfa05a8e12126--