From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 48F3FC016F for ; 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 ; 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 ; 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 ; Tue, 23 Jun 2020 13:18:47 +0000 (UTC) Received: by mail-oi1-f181.google.com with SMTP id h17so1249133oie.3 for ; 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: In-Reply-To: From: Stanga Date: Tue, 23 Jun 2020 16:18:35 +0300 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="0000000000000a239505a8c0336d" X-Mailman-Approved-At: Tue, 23 Jun 2020 13:20:18 +0000 Cc: Matan Yehieli , Bitcoin Protocol Discussion , Itay Tsabary 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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
Of course the order at the end should have been switched:= =C2=A0

Consider first the case where Alice *does not*=C2= =A0publish=C2=A0preimage "A": Bob can safely publish preimage &qu= ot;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,=C2=A0

Thank you for taking th= e time to respond, these are very good points. Responses inline.
<= br>
On Tue,= Jun 23, 2020 at 12:48 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
Good morning Itay, Ittay, a= nd Matan,

I believe an unstated assumption in Bitcoin is that miners are short-sighte= d.

The reasoning for this assumption is:

* Deployment of new mining hardware controlled by others may occur at any t= ime you do not control.
=C2=A0 * Thus, any transactions you leave on the table are potentially take= n by somebody else and not by you.
=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*).

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

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.
=C2=A0

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.
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.

If the fee bump offered by Alice is sufficiently large, then miners will st= art 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 sat= oshi short of the total fund.
It is rational for Alice to do so since at timeout, it can expect to lose t= he 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 app= roaching the fund value, leaving miners with the fund and Alice and Bob wit= hout 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 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
=C2=A0

--

What MAD-HTLC can do would be to make different claims:

* Inputs:
=C2=A0 * Bob 1 BTC - HTLC amount
=C2=A0 * Bob 1 BTC - Bob fidelity bond

* Cases:
=C2=A0 * Alice reveals hashlock at any time:
=C2=A0 =C2=A0 * 1 BTC goes to Alice
=C2=A0 =C2=A0 * 1 BTC goes to Bob (fidelity bond refund)
=C2=A0 * Bob reveals bob-hashlock after time L:
=C2=A0 =C2=A0 * 2 BTC goes to Bob (HTLC refund + fidelity bond refund)
=C2=A0 * Bob cheated, anybody reveals both hashlock and bob-hashlock:
=C2=A0 =C2=A0 * 2 BTC goes to miner

This is an actual improvement over HTLC: Bob misbehavior leads to loss of t= he fidelity bond.
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.
It can also be implemented with `OP_CHECKTEMPLATEVERIFY`.
=
The cases you present are exactly how MAD-HTLC works. It comprise= s two contracts (UTXOs):
* Deposit (holding the intended HTLC tokens),= with three redeem paths:
=C2=A0 =C2=A0 - Alice (signature), with preima= ge "A", no timeout
=C2=A0 =C2=A0 - Bob (signature), with preim= age "B", timeout T
=C2=A0 =C2=A0 - Any entity (miner), with bo= th preimages "A" and "B", no timeout
* Collateral (= the fidelity bond, doesn't have to be of the same amount)
=C2=A0 =C2= =A0 - Bob (signature), no preimage, timeout T
=C2=A0 =C2=A0 - 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 publi= sh preimage "B" and get both the Deposit and Collateral tokens af= ter the timeout.
Now, consider the case where Alice does not publish pr= eimage "A": If Bob publishes preimage "B" he gets nothi= ng (and so does Alice - this is the mutual assured destruction), and if he = doesn't, he gets the Collateral tokens.

Best,=C2=A0
Ittay=C2=A0

=
--0000000000000a239505a8c0336d--