From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id CD7E8C016F for ; Tue, 23 Jun 2020 09:48:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id C0F432002F for ; Tue, 23 Jun 2020 09:48:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH4cTJn7m4zW for ; Tue, 23 Jun 2020 09:48:36 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by silver.osuosl.org (Postfix) with ESMTPS id B53C71FEBF for ; Tue, 23 Jun 2020 09:48:36 +0000 (UTC) Date: Tue, 23 Jun 2020 09:48:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1592905714; bh=Z8X4+7qZ/v2wOvwkkqTcXQj9T2886YTYwhuMXETdT6I=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=Y4y1OOe+0CHzJdlS9ZXio83cWNWRzn29WZ1UT+3HSRNpoSnuQOG5fRSnyjLYyais5 3HmizxB65pC5lXi7M0Rb07pvzIo+9peJ/ikgWQkM4MTalffRAh7DUrjYKtkI8hE5Rm uhexDmGRPZY0bEiMAKl43WWHq4HTYDvR2++RbpiY= To: Stanga , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Matan Yehieli , 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 09:48:38 -0000 Good morning Itay, Ittay, and 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. * 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 futur= e earnings, so any future theoretical earnings should be discounted (*in ad= dition to* expected return-on-investment on getting money you can invest *n= ow*). 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. -- 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 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`. Regards, ZmnSCPxj