From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3649EC0733 for ; Sat, 4 Jul 2020 21:05:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 329248756A for ; Sat, 4 Jul 2020 21:05:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSZQvUgn0tUm for ; Sat, 4 Jul 2020 21:05:44 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch [185.70.40.140]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 7DA8687516 for ; Sat, 4 Jul 2020 21:05:44 +0000 (UTC) Date: Sat, 04 Jul 2020 21:05:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1593896742; bh=n0bpSf6255ksZNzT822HVkY4fxoU5c31aTrEfTVBDYU=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=VNvrVd6AbjF/ky/R7cJjbogj8H/ehZe8cmztI3bfcD2hKX4bfDh3mhNUd3V922AHw XCZi7bWnB7uW+L6IfZvHMB5IXRPxHO6hOPAOOCJ3+bwwYzNVd2BAYAEWeZqvVSiYGR ek4LzW5rSFIetnZ4X/ZvOqFwC2ZXYSF/Y9b9IeqQ= To: "David A. Harding" From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <20200628164132.mmpimgcrxpai2gnb@ganymede> References: <20200628164132.mmpimgcrxpai2gnb@ganymede> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Sat, 04 Jul 2020 21:05:46 -0000 Good morning Dave, > > > - 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 > > > > > > [...] > > > > 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 amoun= t) > > - Bob (signature), no preimage, timeout T > > - Any entity (miner), with both preimages "A" and "B", timeout T > > I'm not these are safe if your counterparty is a miner. Imagine Bob > offers Alice a MAD-HTLC. Alice knows the payment preimage ("preimage > A"). Bob knows the bond preimage ("preimage B") and he's the one making > the payment and offering the bond. > > After receiving the HTLC, Alice takes no action on it, so the timelock > expires. Bob publicly broadcasts the refund transaction with the bond > preimage. Unbeknownst to Bob, Alice is actually a miner and she uses her > pre-existing knowledge of the payment preimage plus her received > knowledge of the bond preimage to privately attempt mining a transaction > that pays her both the payment ("deposit") and the bond ("collateral"). > > Assuming Alice is a non-majority miner, she isn't guaranteed to > succeed---her chance of success depends on her percentage of the network > hashrate and how much fee Bob paid to incentivize other miners to > confirm his refund transaction quickly. However, as long as Alice has a > non-trivial amount of hashrate, she will succeed some percentage of the > time in executing this type of attack. Any of her theft attempts that > fail will leave no public trace, perhaps lulling users into a false > sense of security. This note seems to have gotten missed in discussion. Another note is that from what I can tell, the preimages "A" and "B" can be= provided by any miner. If the fund value plus the collateral is large enough, it may incentivize c= ompeting miners to reorg the chain, redirecting the funds of the MAD-HTLC t= o themselves, rather than advance the blockchain state, at least until alte= rnative transctions bump their fees up enough that the collateral + fund is= matched. This may not apply to Lightning at least if you do not go beyond the Wumbo = limit, but *could* apply to e.g. SwapMarket, if it uses MAD-HTLCs. Regards, ZmnSCPxj