path: root/ff/4ac597539661adb9de696ee449111b2ca6026c

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 BF72FC016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Jun 2020 12:48:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id ABE9789354
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Jun 2020 12:48:11 +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 sef3mh1NlGAD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Jun 2020 12:48:08 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com
 [209.85.210.43])
 by hemlock.osuosl.org (Postfix) with ESMTPS id C43598951C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Jun 2020 12:48:08 +0000 (UTC)
Received: by mail-ot1-f43.google.com with SMTP id e5so16391778ote.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Jun 2020 05:48:08 -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=2MuMWgsN2QDb86QLldg3luk62sPUyQ4QMwzZA+1ePOo=;
 b=LZDzCUVBp2Koc5VD8Z3LjrilXJd69qSA8W94xROd0fh68SHFu07d2+CQSoOIjp9w55
 QDVlbhfmYAX2U9wHXmZ8lyp0RyJF1EBlkGRFc9SWbabLYuTEvyQeNcizEq0SusKVcNda
 ABaX8nq6xUsaPSsZPjwDo97OSx8hb0SaCLszBcnw2ONI4vVnptz7AMS4dm2bqRb98Ahb
 svH1RQSZ26UDauA5Fx3eCakg+XwIOSslYloYkzD5mgdwejVZCnlxTbPrcRqM3HNFD98R
 bCnlZIaS15HSHkbOD5JRqdalVY3l+PzEftax6RGCiP17nBxWZJSMUQUtFYZKn228TJWx
 V88Q==
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=2MuMWgsN2QDb86QLldg3luk62sPUyQ4QMwzZA+1ePOo=;
 b=U+5mXU6HhU53oSNZ91O+QGAhY+KwG4h9S1QZFmlqZFYIGcA72a6qtxcMWOb8+fz/hq
 yi4XehzPlj8fUM4kl4IdLH1B6oaEQ37X07b5TiagtTX5HvjTD9YetVXW/jR+aNt70P7U
 balFGCV/qaP9pxTGn4dNe32trXeOmeZW7LwthkL944fI3B0Wki4iQF73Qn7yKsAnFKi4
 QiWnTb2QTOQncglU+Otp+SD9CDofQx+y5MdHit5BOorLeIbxTSNu4rAYTORKz3pdfaEz
 J2tmWha3RrCvLoYmYnoXukvZ5lSb79V4NgT7EcBX/xxZzLQ6HFQolQIiPJZ/SqWXf6m8
 X5bw==
X-Gm-Message-State: AOAM530IzGsBJBwrxp0K8K8U/YhF6fdTJC4SFvWyuBXsr3JP7v9a1Wf5
 4UuR0sFiPO4vRRXqDgDo8gOuNNY0kMIemRmEkAE=
X-Google-Smtp-Source: ABdhPJx2NspalKTopk9c9kbFFa20UK/pSpCDQJR5HGLa8LCpQRen0JPHJ+jtkdAza9vOe6a9OMR6icZZu88mHzHXJxE=
X-Received: by 2002:a4a:b804:: with SMTP id g4mr18625456oop.40.1592916487852; 
 Tue, 23 Jun 2020 05:48:07 -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>
In-Reply-To: <ahTHfoyyTpBrMiKdJWMn9Qa8CMCEd1-y8OXPSjsDmttTOVC3zGuDoSHkm_oOe5mBYgIAY7jOPocQhLW29n544xFsqVyq51NFApvaFYYSvFY=@protonmail.com>
From: Stanga <stanga@gmail.com>
Date: Tue, 23 Jun 2020 15:47:56 +0300
Message-ID: <CABT1wWknczx62uCpJPWku-KeYuaFvJHrvOS74YzqfoVe5x=edg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000006a56de05a8bfc59d"
X-Mailman-Approved-At: Tue, 23 Jun 2020 12:49:30 +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 12:48:11 -0000

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

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 any
> time you do not control.
>   * Thus, any transactions you leave on the table are potentially taken b=
y
> 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 larger
granularity than your average HTLC timeout. For instance, we noticed plenty
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 all
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 affec=
t 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-HTL=
C.
> For example, if an HTLC is confirmed but the hashlock-claiming transactio=
n
> 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 bein=
g
> 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 lose
> the entire fund.
> In order for Bob to win, it has to beat that fee, at which point it equal=
s
> 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 miner=
s
> 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 Bo=
b
> 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. So
this is an actual race, and Bob takes no risk since his payment is all from
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 of
> the fidelity bond.
> The above cases can be assured by requiring both Alice and Bob to sign in
> the alice-hashlock branch, so that the splitting of the fund is enforced,
> and SegWit signing so that the dependent transaction is signed before the
> 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 safely
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

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

<div dir=3D"ltr"><div dir=3D"ltr">Hi ZmnSCPxj,=C2=A0<br><br>Thank you for t=
aking the 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@p=
rotonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">Good morning Itay, Ittay, and 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>

--0000000000006a56de05a8bfc59d--