From mboxrd@z Thu Jan 1 00:00:00 1970 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