path: root/a3/69e0f69f66eb262d30b26aae845290ec837515

Return-Path: <stanga@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 48F3FC016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Jun 2020 13:18:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 3699C88515
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Jun 2020 13:18:49 +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 7S-ioWjTBl+t
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Jun 2020 13:18:48 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com
 [209.85.167.181])
 by hemlock.osuosl.org (Postfix) with ESMTPS id F329A8827C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Jun 2020 13:18:47 +0000 (UTC)
Received: by mail-oi1-f181.google.com with SMTP id h17so1249133oie.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Jun 2020 06:18:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=jbJs48o+WfBA+HKM7ywrO5X0IQazYWvodn3SbX29tf4=;
 b=UZQvuek4t+YwqfdbM0IOOEN03Qb2HfuFBdJfaPE00h6/8+RQl0c6Zxd0MT+2HssbcO
 26Nw+iRA8RDUmIlFrnmPZAC8mcUhINyjLhnbG13Bgjq7XvHSUSU++spIuHwwqGPXifsM
 eE8vZpQXRgZMEiHE9j4Ca4Jfzyy803x8sWen/eltzDBbIErc5EB5F0ZCROl6bRdsTnKR
 8bqh+U2IWB/XMCUk1KvWJRNhOQipH372r4576rjjY/CEplZETL79H4zzmeScieDjCbT6
 ERi9NbPchgpKpJXln0vEPgaakQoHjo9Vo7pg+dq8dLupXicDPuXNb0unz12KPsaAgU5y
 ibuw==
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=jbJs48o+WfBA+HKM7ywrO5X0IQazYWvodn3SbX29tf4=;
 b=MtoG/5DrgoTB0Hfo429N3i5KPYfyf765kFckm0NOSCOKvVrs4vaMyzd28HB2UyviLa
 yyyt+6EH08a5RBU1BRnh3G8jwgpJBo8ItTlE7ISrttrjLecOBfMbD2O1GEztY2RHWj26
 MmrLW9vEfo2dklMKbKT5fWhFy++eFhTHEySj8ZFEUuwWz2uRibHYESE0oG90mI4Nm42J
 I8BKEGHKTBLj6KVO+pviomeMjqg3RpHJVFVrnjs+lU+9AGBBP1DsPhknCZxXyUdpjZHL
 Jo1HYGE+fvRpjo8Wx/JKbxTSaPxUqZYZby2hWabvee1SqgPlqiy78mKd1VUjAB/VurWl
 qyEA==
X-Gm-Message-State: AOAM531GZg/lLphKKBTpQCJWZgdiO4bS19k609CRh76/p4q4p/DK+Wr9
 9KwKiy1mM8IpScqelftkmKmj15An0AH7K2EL8sI=
X-Google-Smtp-Source: ABdhPJyGBW4V8nV9Fc0bFS6feerN5FX3Xj2uvqXeSzZxV/jc9+2zOLiv/EaKCjKngkf6bc0h1atEXuyvMRlXwy1kJ+c=
X-Received: by 2002:aca:cdc5:: with SMTP id d188mr17143631oig.33.1592918327041; 
 Tue, 23 Jun 2020 06:18:47 -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>
In-Reply-To: <CABT1wWknczx62uCpJPWku-KeYuaFvJHrvOS74YzqfoVe5x=edg@mail.gmail.com>
From: Stanga <stanga@gmail.com>
Date: Tue, 23 Jun 2020 16:18:35 +0300
Message-ID: <CABT1wWmm=rx1MkFeNhGeEgdu7XpBXYeq_PWaZFfBOA7MRSKezw@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000000a239505a8c0336d"
X-Mailman-Approved-At: Tue, 23 Jun 2020 13:20:18 +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: Tue, 23 Jun 2020 13:18:49 -0000

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

Of course the order at the end should have been switched:

Consider first the case where Alice *does not* publish preimage "A": Bob
can safely publish preimage "B" and get both the Deposit and Collateral
tokens after the timeout.
Now, consider the case where Alice *publishes* preimage "A": If Bob
publishes preimage "B" he gets nothing (and so does Alice - this is the
mutual assured destruction), and if he doesn't, he gets the Collateral
tokens.


On Tue, Jun 23, 2020 at 3:47 PM Stanga <stanga@gmail.com> wrote:

> Hi ZmnSCPxj,
>
> Thank you for taking the time to respond, these are very good points.
> Responses inline.
>
> On Tue, Jun 23, 2020 at 12:48 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote=
:
>
>> Good morning Itay, Ittay, and Matan,
>>
>> I believe an unstated assumption in Bitcoin is that miners are
>> short-sighted.
>>
>> The reasoning for this assumption is:
>>
>> * Deployment of new mining hardware controlled by others may occur at an=
y
>> time you do not control.
>>   * Thus, any transactions you leave on the table are potentially taken
>> by somebody else and not by you.
>>   * Sudden changes in hashpower distribution may reduce your expected
>> future earnings, so any future theoretical earnings should be discounted
>> (*in addition to* expected return-on-investment on getting money you can
>> invest *now*).
>>
>
> Our analysis assumes constant difficulty, i.e., no significant changes of
> the miners set. Indeed, hash-rate changes typically occur at a much large=
r
> granularity than your average HTLC timeout. For instance, we noticed plen=
ty
> of lightning nodes use timeouts of a day. So, we do not consider
> optimization at infinity, just a day ahead, and within this time frame al=
l
> the factors you mentioned are not expected to dramatically change.
>
> That being said, it would be interesting to analyze the effect of miners
> joining during the HTLC duration. Intuitively, this shouldn=E2=80=99t aff=
ect the
> results, as those new miners have the same incentive to wait for the
> higher-paying tx.
>
>
>>
>> It also strikes me that, in a world with RBF and CPFP, the same endpoint
>> (i.e. miners earn the entire fund of the HTLC) is achieved by existing
>> HTLCs, without the additional branch and script opcodes needed by MAD-HT=
LC.
>> For example, if an HTLC is confirmed but the hashlock-claiming
>> transaction is not being confirmed (because miners are holding it up
>> because Bob is offering a much higher fee in the future for the
>> timelock-claiming transaction), then Alice can, regardless of the reason
>> why it is not being confirmed, bump up the fee with RBF or CPFP.
>>
>> If the fee bump offered by Alice is sufficiently large, then miners will
>> start re-preferring the Alice hashlock transaction.
>> To counter this, Bob has to bid up its version higher.
>>
>> As the timeout approaches, Alice can bump up its fee until it is just 1
>> satoshi short of the total fund.
>> It is rational for Alice to do so since at timeout, it can expect to los=
e
>> the entire fund.
>> In order for Bob to win, it has to beat that fee, at which point it
>> equals or exceeds the total fund, and miners get the total fund (or more=
).
>>
>> Knowing this end-point, rational Bob will not even begin this game.
>>
>> I think this research considers these two endpoints to be distinct:
>>
>> * Bob misbehaves and the entire fund is punished by miners, leaving
>> miners with the fund and Alice and Bob without money (MAD-HTLC).
>> * Bob misbehaves, Alice counters, and the ensuing fee war leads to fees
>> approaching the fund value, leaving miners with the fund and Alice and B=
ob
>> without money (standard HTLC).
>>
>> But in practice I think both endpoints are essentially equivalent.
>>
>
> These are not the same scenario, since in HTLC there is a race between
> Alice and Bob. Alice might not wish to pay the full HTLC amount once she
> sees Bob is trying to cheat. She could wait until close to the timeout so
> as to reduce the time Bob can respond. Of course Bob would do the same. S=
o
> this is an actual race, and Bob takes no risk since his payment is all fr=
om
> the HTLC amount. Mutual destruction is only assured under certain
> assumptions in HTLC. MAD-HTLC achieves security without relying on such
> assumptions.
>
>
>>
>> --
>>
>> What MAD-HTLC can do would be to make different claims:
>>
>> * Inputs:
>>   * Bob 1 BTC - HTLC amount
>>   * Bob 1 BTC - Bob fidelity bond
>>
>> * Cases:
>>   * Alice reveals hashlock at any time:
>>     * 1 BTC goes to Alice
>>     * 1 BTC goes to Bob (fidelity bond refund)
>>   * Bob reveals bob-hashlock after time L:
>>     * 2 BTC goes to Bob (HTLC refund + fidelity bond refund)
>>   * Bob cheated, anybody reveals both hashlock and bob-hashlock:
>>     * 2 BTC goes to miner
>>
>> This is an actual improvement over HTLC: Bob misbehavior leads to loss o=
f
>> the fidelity bond.
>> The above cases can be assured by requiring both Alice and Bob to sign i=
n
>> the alice-hashlock branch, so that the splitting of the fund is enforced=
,
>> and SegWit signing so that the dependent transaction is signed before th=
e
>> HTLC-funding transaction is.
>> It can also be implemented with `OP_CHECKTEMPLATEVERIFY`.
>
>
> The cases you present are exactly how MAD-HTLC works. It comprises two
> contracts (UTXOs):
> * Deposit (holding the intended HTLC tokens), with three redeem paths:
>     - Alice (signature), with preimage "A", no timeout
>     - Bob (signature), with preimage "B", timeout T
>     - Any entity (miner), with both preimages "A" and "B", no timeout
> * Collateral (the fidelity bond, doesn't have to be of the same amount)
>     - Bob (signature), no preimage, timeout T
>     - Any entity (miner), with both preimages "A" and "B", timeout T
>
> Only Bob initially knows preimage "B", and is required to reveal it if he
> wishes to get the Deposit tokens.
>
> Consider first the case where Alice publishes preimage "A": Bob can safel=
y
> publish preimage "B" and get both the Deposit and Collateral tokens after
> the timeout.
> Now, consider the case where Alice does not publish preimage "A": If Bob
> publishes preimage "B" he gets nothing (and so does Alice - this is the
> mutual assured destruction), and if he doesn't, he gets the Collateral
> tokens.
>
> Best,
> Ittay
>
>

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

<div dir=3D"ltr">Of course the order at the end should have been switched:=
=C2=A0<div><br></div><div>Consider first the case where Alice *does not*=C2=
=A0publish=C2=A0preimage &quot;A&quot;: Bob can safely publish preimage &qu=
ot;B&quot; and get both the Deposit and Collateral tokens after the timeout=
.<br>Now, consider the case where Alice *publishes* preimage &quot;A&quot;:=
 If Bob publishes preimage &quot;B&quot; he gets nothing (and so does Alice=
 - this is the mutual assured destruction), and if he doesn&#39;t, he gets =
the Collateral tokens.<br></div><div><br></div></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jun 23, 2020 at 3:47=
 PM Stanga &lt;<a href=3D"mailto:stanga@gmail.com">stanga@gmail.com</a>&gt;=
 wrote:<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"><div dir=
=3D"ltr"><div dir=3D"ltr">Hi ZmnSCPxj,=C2=A0<br><br>Thank you for taking th=
e time to respond, these are very good points. Responses inline.<br></div><=
br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue,=
 Jun 23, 2020 at 12:48 PM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmai=
l.com" target=3D"_blank">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">Good morning Itay, Ittay, a=
nd Matan,<br>
<br>
I believe an unstated assumption in Bitcoin is that miners are short-sighte=
d.<br>
<br>
The reasoning for this assumption is:<br>
<br>
* Deployment of new mining hardware controlled by others may occur at any t=
ime you do not control.<br>
=C2=A0 * Thus, any transactions you leave on the table are potentially take=
n by somebody else and not by you.<br>
=C2=A0 * Sudden changes in hashpower distribution may reduce your expected =
future earnings, so any future theoretical earnings should be discounted (*=
in addition to* expected return-on-investment on getting money you can inve=
st *now*).<br></blockquote><div><br></div>Our analysis assumes constant dif=
ficulty, i.e., no significant changes of the miners set. Indeed, hash-rate =
changes typically occur at a much larger granularity than your average HTLC=
 timeout. For instance, we noticed plenty of lightning nodes use timeouts o=
f a day. So, we do not consider optimization at infinity, just a day ahead,=
 and within this time frame all the factors you mentioned are not expected =
to dramatically change.=C2=A0</div><div class=3D"gmail_quote"><br></div><di=
v class=3D"gmail_quote">That being said, it would be interesting to analyze=
 the effect of miners joining during the HTLC duration. Intuitively, this s=
houldn=E2=80=99t affect the results, as those new miners have the same ince=
ntive to wait for the higher-paying tx. <br><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">
<br>
It also strikes me that, in a world with RBF and CPFP, the same endpoint (i=
.e. miners earn the entire fund of the HTLC) is achieved by existing HTLCs,=
 without the additional branch and script opcodes needed by MAD-HTLC.<br>
For example, if an HTLC is confirmed but the hashlock-claiming transaction =
is not being confirmed (because miners are holding it up because Bob is off=
ering a much higher fee in the future for the timelock-claiming transaction=
), then Alice can, regardless of the reason why it is not being confirmed, =
bump up the fee with RBF or CPFP.<br>
<br>
If the fee bump offered by Alice is sufficiently large, then miners will st=
art re-preferring the Alice hashlock transaction.<br>
To counter this, Bob has to bid up its version higher.<br>
<br>
As the timeout approaches, Alice can bump up its fee until it is just 1 sat=
oshi short of the total fund.<br>
It is rational for Alice to do so since at timeout, it can expect to lose t=
he entire fund.<br>
In order for Bob to win, it has to beat that fee, at which point it equals =
or exceeds the total fund, and miners get the total fund (or more).<br>
<br>
Knowing this end-point, rational Bob will not even begin this game.<br>
<br>
I think this research considers these two endpoints to be distinct:<br>
<br>
* Bob misbehaves and the entire fund is punished by miners, leaving miners =
with the fund and Alice and Bob without money (MAD-HTLC).<br>
* Bob misbehaves, Alice counters, and the ensuing fee war leads to fees app=
roaching the fund value, leaving miners with the fund and Alice and Bob wit=
hout money (standard HTLC).<br>
<br>
But in practice I think both endpoints are essentially equivalent.<br></blo=
ckquote><div><br></div><div>These are not the same scenario, since in HTLC =
there is a race between Alice and Bob. Alice might not wish to pay the full=
 HTLC amount once she sees Bob is trying to cheat. She could wait until clo=
se to the timeout so as to reduce the time Bob can respond. Of course Bob w=
ould do the same. So this is an actual race, and Bob takes no risk since hi=
s payment is all from the HTLC amount. Mutual destruction is only assured u=
nder certain assumptions in HTLC. MAD-HTLC achieves security without relyin=
g on such assumptions.=C2=A0<br></div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">
<br>
--<br>
<br>
What MAD-HTLC can do would be to make different claims:<br>
<br>
* Inputs:<br>
=C2=A0 * Bob 1 BTC - HTLC amount<br>
=C2=A0 * Bob 1 BTC - Bob fidelity bond<br>
<br>
* Cases:<br>
=C2=A0 * Alice reveals hashlock at any time:<br>
=C2=A0 =C2=A0 * 1 BTC goes to Alice<br>
=C2=A0 =C2=A0 * 1 BTC goes to Bob (fidelity bond refund)<br>
=C2=A0 * Bob reveals bob-hashlock after time L:<br>
=C2=A0 =C2=A0 * 2 BTC goes to Bob (HTLC refund + fidelity bond refund)<br>
=C2=A0 * Bob cheated, anybody reveals both hashlock and bob-hashlock:<br>
=C2=A0 =C2=A0 * 2 BTC goes to miner<br>
<br>
This is an actual improvement over HTLC: Bob misbehavior leads to loss of t=
he fidelity bond.<br>
The above cases can be assured by requiring both Alice and Bob to sign in t=
he alice-hashlock branch, so that the splitting of the fund is enforced, an=
d SegWit signing so that the dependent transaction is signed before the HTL=
C-funding transaction is.<br>
It can also be implemented with `OP_CHECKTEMPLATEVERIFY`.</blockquote><div>=
<br></div>The cases you present are exactly how MAD-HTLC works. It comprise=
s two contracts (UTXOs): <br>	* Deposit (holding the intended HTLC tokens),=
 with three redeem paths:<br>=C2=A0 =C2=A0 - Alice (signature), with preima=
ge &quot;A&quot;, no timeout<br>=C2=A0 =C2=A0 - Bob (signature), with preim=
age &quot;B&quot;, timeout T<br>=C2=A0 =C2=A0 - Any entity (miner), with bo=
th preimages &quot;A&quot; and &quot;B&quot;, no timeout<br>	* Collateral (=
the fidelity bond, doesn&#39;t have to be of the same amount)<br>=C2=A0 =C2=
=A0 - Bob (signature), no preimage, timeout T<br>=C2=A0 =C2=A0 - Any entity=
 (miner), with both preimages &quot;A&quot; and &quot;B&quot;, timeout T<br=
>	<br>	Only Bob initially knows preimage &quot;B&quot;, and is required to =
reveal it if he wishes to get the Deposit tokens. <br>	<br>	Consider first =
the case where Alice publishes preimage &quot;A&quot;: Bob can safely publi=
sh preimage &quot;B&quot; and get both the Deposit and Collateral tokens af=
ter the timeout.<br>	Now, consider the case where Alice does not publish pr=
eimage &quot;A&quot;: If Bob publishes preimage &quot;B&quot; he gets nothi=
ng (and so does Alice - this is the mutual assured destruction), and if he =
doesn&#39;t, he gets the Collateral tokens. <br><br>Best,=C2=A0</div><div c=
lass=3D"gmail_quote">Ittay=C2=A0</div><div class=3D"gmail_quote"><br></div>=
</div>
</blockquote></div>

--0000000000000a239505a8c0336d--