path: root/27/27e35311b5b0743bde78c1b7a8cad48449a520

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 90388C016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Jun 2020 01:38:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 84A9B882E7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Jun 2020 01:38:31 +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 V9iM2Nwvr7BC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Jun 2020 01:38:29 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27])
 by hemlock.osuosl.org (Postfix) with ESMTPS id B512A882E3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Jun 2020 01:38:28 +0000 (UTC)
Date: Thu, 25 Jun 2020 01:38:17 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1593049106;
 bh=Z6f/x3P3e0g5JlsO0N+jrQaW651y4unwtnB9/T8mQOM=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
 b=ZUvOyBZC1JacUp1KfgyoluZ9kEozRiQ/LPWTQo0vPQGQ2rWun5Zj0tBAtxImEWO1/
 GI2EcKR/cp/jFEPjtTqDrqZif1H24x4Z4ijxsysfqyfUseUap/s9OwAYe1MRlPeSMz
 h+H9JC7maivZr3yIdKgglzDyofKzgKB+SEEeKB/E=
To: Stanga <stanga@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <xFJlIP6z6qhjxDAP8xUBnqPF-Wulexjr9izry8mIWCQzQdNrULtX_TwWGfuHo7VNfTdXZNmy05QHxMF3iJbjZm_-jFO_WRJjSQR0N_Dreic=@protonmail.com>
In-Reply-To: <CABT1wWmm=rx1MkFeNhGeEgdu7XpBXYeq_PWaZFfBOA7MRSKezw@mail.gmail.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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 01:38:31 -0000

Good morning Stanga et al,


> > Hi ZmnSCPxj,=C2=A0
> >
> > Thank you for taking the time to respond, these are very good points. R=
esponses inline.
> >
> > On Tue, Jun 23, 2020 at 12:48 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wro=
te:
> >
> > > 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.
> > > =C2=A0 * Thus, any transactions you leave on the table are potentiall=
y taken by somebody else and not by you.
> > > =C2=A0 * Sudden changes in hashpower distribution may reduce your exp=
ected future earnings, so any future theoretical earnings should be discoun=
ted (*in addition to* expected return-on-investment on getting money you ca=
n 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 larg=
er granularity than your average HTLC timeout. For instance, we noticed ple=
nty of lightning nodes use timeouts of a day. So, we do not consider optimi=
zation at infinity, just a day ahead, and within this time frame all the fa=
ctors you mentioned are not expected to dramatically change.=C2=A0
> >
> > That being said, it would be interesting to analyze the effect of miner=
s 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 th=
e higher-paying tx.

We already know that hashrate tends to trend upwards, and that we do not ex=
pect hashrate to fall except for occasional transients.

The expectation is not that new miners have different incentives.
Instead, the expectation is that current miners discount future possible ga=
ins because in the future, they expect to have less hashrate share than rig=
ht now.

The only trustless way for Bob to bribe miners into deferring Alice tx is t=
o attach the bribe to the future confirmation of the Bob tx, thus Bob is of=
fering future-coins, not present-coins like Alice can offer, and the fact t=
hat miners expect an overall uptrend in total hashrate (leading to an overa=
ll downtrend in their hashrate share) means that miners discount the Bob of=
fered future-coins.
The discounting is proportional to the time delay involved, as a larger del=
ay implies greater reduction in hashrate share.

This discounting is, again, *in addition to* natural discounting a.k.a. "I =
will gladly pay you Thursday for a hamburger today", the hamburger seller w=
ill want some pretty stiff assurances plus a bigger payment on Thursday for=
 giving you a hamburger today, due to expected returns on investment.


> > =C2=A0
> >
> > > It also strikes me that, in a world with RBF and CPFP, the same endpo=
int (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 transa=
ction 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 trans=
action), then Alice can, regardless of the reason why it is not being confi=
rmed, bump up the fee with RBF or CPFP.
> > >
> > > If the fee bump offered by Alice is sufficiently large, then miners w=
ill 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 e=
quals 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 m=
iners with the fund and Alice and Bob without money (MAD-HTLC).
> > > * Bob misbehaves, Alice counters, and the ensuing fee war leads to fe=
es 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 se=
es 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 thi=
s is an actual race, and Bob takes no risk since his payment is all from th=
e HTLC amount. Mutual destruction is only assured under certain assumptions=
 in HTLC. MAD-HTLC achieves security without relying on such assumptions.=
=C2=A0

Alice already knows that a rational Bob (who it might never interact with a=
gain in the future) will take the funds at the locktime L.
Thus, Alice can offer, at time L - 1, the entire fund, minus 1 satoshi, to =
miners.
Alice getting 1 satoshi versus 0 satoshi is a no-brainer for Alice.
Bob can only  beat this offer by offering the entire fund, at which point B=
ob earns nothing and it performed an attack for no benefit.

I and some number of Lightning devs consider this to be sufficient disincen=
tive to Bob not attacking in the first place.


> > =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 los=
s of the fidelity bond.
> > > The above cases can be assured by requiring both Alice and Bob to sig=
n in the alice-hashlock branch, so that the splitting of the fund is enforc=
ed, and SegWit signing so that the dependent transaction is signed before t=
he 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:
> > =C2=A0 =C2=A0 - Alice (signature), with preimage "A", no timeout
> > =C2=A0 =C2=A0 - Bob (signature), with preimage "B", timeout T
> > =C2=A0 =C2=A0 - Any entity (miner), with both 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", ti=
meout 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 saf=
ely publish preimage "B" and get both the Deposit and Collateral tokens aft=
er the timeout.
> > Now, consider the case where Alice does not publish preimage "A": If Bo=
b publishes preimage "B" he gets nothing (and so does Alice - this is the m=
utual assured destruction), and if he doesn't, he gets the Collateral token=
s.

Thank you for the clarification.

Regards,
ZmnSCPxj