From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id ABD45C0175; Wed, 22 Apr 2020 04:13:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id A263986D78; Wed, 22 Apr 2020 04:13:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnB-jrSUERqI; Wed, 22 Apr 2020 04:13:10 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by whitealder.osuosl.org (Postfix) with ESMTPS id 6165986746; Wed, 22 Apr 2020 04:13:10 +0000 (UTC) Date: Wed, 22 Apr 2020 04:12:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1587528784; bh=0pF1jfbO8I7uBDa1FyuVOWDPCxIOuthd48LmKBT3B54=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=DdIVJ+ghJYQ3lsx5rU6XhN1Wtg/r03VvIwMjtnxbhImU7uM3ug22mPsNxVq7OW/WO zd6pzj24ErzG1ShZ8OpxxSud8aB5SDyiftF8PkujrHHpfnDZX/LI5+J3LqyBf+Q+zA 1NF4xu+wyzlxx4T0p6SbxSyh2NYCs5J881gH5TsM= To: Matt Corallo 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: Bitcoin Protocol Discussion , lightning-dev Subject: Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest 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: Wed, 22 Apr 2020 04:13:18 -0000 Good morning Matt, and list, > RBF Pinning HTLC Transactions (aka "Oh, wait, I can steal funds, how,= now?") > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > You'll note that in the discussion of RBF pinning we were pretty broa= d, and that that discussion seems to in fact cover > our HTLC outputs, at least when spent via (3) or (4). It does, and in= fact this is a pretty severe issue in today's > lightning protocol [2]. A lightning counterparty (C, who received the= HTLC from B, who received it from A) today could, > if B broadcasts the commitment transaction, spend an HTLC using the p= reimage with a low-fee, RBF-disabled transaction. > After a few blocks, A could claim the HTLC from B via the timeout mec= hanism, and then after a few days, C could get the > HTLC-claiming transaction mined via some out-of-band agreement with a= small miner. This leaves B short the HTLC value. My (cached) understanding is that, since RBF is signalled using `nSequence`= , any `OP_CHECKSEQUENCEVERIFY` also automatically imposes the requirement "= must be RBF-enabled", including `<0> OP_CHECKSEQUENCEVERIFY`. Adding that clause (2 bytes in witness if my math is correct) to the hashlo= ck branch may be sufficient to prevent C from making an RBF-disabled transa= ction. But then you mention out-of-band agreements with miners, which basically me= ans the transaction might not be in the mempool at all, in which case the v= ulnerability is not really about RBF or relay, but sheer economics. The payment is A->B->C, and the HTLC A->B must have a larger timeout (L + 1= ) than the HTLC B->C (L), in abstract non-block units. The vulnerability you are describing means that the current time must now b= e L + 1 or greater ("A could claim the HTLC from B via the timeout mechanis= m", meaning the A->B HTLC has timed out already). If so, then the B->C transaction has already timed out in the past and can = be claimed in two ways, either via B timeout branch or C hashlock branch. This sets up a game where B and C bid to miners to get their version of rea= lity committed onchain. (We can neglect out-of-band agreements here; miners have the incentive to p= ublicly leak such agreements so that other potential bidders can offer even= higher fees for their versions of that transaction.) Before L+1, C has no incentive to bid, since placing any bid at all will le= ak the preimage, which B can then turn around and use to spend from A, and = A and C cannot steal from B. Thus, B should ensure that *before* L+1, the HTLC-Timeout has been committe= d onchain, which outright prevents this bidding war from even starting. The issue then is that B is using a pre-signed HTLC-timeout, which is neede= d since it is its commitment tx that was broadcast. This prevents B from RBF-ing the HTLC-Timeout transaction. So what is needed is to allow B to add fees to HTLC-Timeout: * We can add an RBF carve-out output to HTLC-Timeout, at the cost of more b= lockspace. * With `SIGHASH_NOINPUT` we can make the C-side signature `SIGHASH_NOINPUT|= SIGHASH_SINGLE` and allow B to re-sign the B-side signature for a higher-fe= e version of HTLC-Timeout (assuming my cached understanding of `SIGHASH_NOI= NPUT` still holds). With this, B can exponentially increase the fee as L+1 approaches. If B can get HTLC-Timeout confirmed before L+1, then C cannot steal the HTL= C value at all, since the UTXO it could steal from has already been spent. In particular, it does not seem to me that it is necessary to change the ha= shlock-branch transaction of C at all, since this mechanism is enough to si= destep the issue (as I understand it). But it does point to a need to make HTLC-Timeout (and possibly symmetricall= y, HTLC-Success) also fee-bumpable. Note as well that this does not require a mempool: B can run in `blocksonly= ` mode and as each block comes in from L to L+1, if HTLC-Timeout is not con= firmed, feebump HTLC-Timeout. In particular, HTLC-Timeout comes into play only if B broadcast its own com= mitment transaction, and B *should* be aware that it did so --- there is st= ill no need for mempool monitoring here. Now, of course this only delays the war. Let us now consider what C can do to ensure that the bidding war will happe= n eventually. * C can bribe a miner to prevent HTLC-Timeout from confirming between L and= L+1. * Or in other words, this is a censorship attack. * The Bitcoin censorship-resistance model is that censored transactions= can be fee-bumped, which attracts non-censoring miners to try their luck a= t mining and evict the censoring miner. * Thus, letting B bump the fee on HTLC-Timeout is precisely the mecha= nism we need. * This sets up a bidding war between C requesting miners to censor, v= s. B requesting miners to confirm, but that only sets the stage for a secon= d bidding war later between C and B, thus C is at a disadvantage: it has to= bribe miners to censor continuously from L to L+1 *and* additional bribe m= iners to confirm its transaction after L+1, whereas B can offer its bribe a= s being something that miners can claim now without waiting after L+1. The issue of course is the additional output that bloats the UTXO set and r= equires another transaction to claim later. And if we have `SIGHASH_NOINPUT`, it seems to me that Decker-Russell-Osunto= kun sidesteps this issue as well, as any timed-out HTLC can be claimed with= a fee-bumpable transaction directly without RBF-carve-out. (As well, it seems to me that, if both nodes support doing so, a Poon-Dryja= channel can be upgraded, without onchain activity, to a Decker-Russell-Osu= ntokun channel: sign a transaction spending the funding tx to a txo that ha= s been set up as Decker-Russell-Osuntokun, do not broadcast that transactio= n, then revoke the latest Poon-Dryja commitment transactions, then switch t= he mechanism over to Decker-Russell-Osuntokun; you still need to monitor fo= r previous Poon-Dryja commitment transactions, but HTLCs now sidestep the i= ssue under discussion here.) Regards, ZmnSCPxj