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 BF988C0175; Wed, 22 Apr 2020 06:08:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id AA1E82035B; Wed, 22 Apr 2020 06:08:19 +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 Jn-0vbFvlom7; Wed, 22 Apr 2020 06:08:16 +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-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by silver.osuosl.org (Postfix) with ESMTPS id 06D5620111; Wed, 22 Apr 2020 06:08:15 +0000 (UTC) Date: Wed, 22 Apr 2020 06:08:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1587535693; bh=4sPA4WJe0tjQQh7xoga9EG7NX/S3zqrwHX3jAsX67jU=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=l1P/5H5fGZtmhVnrc7UO5wZRz8PB1dwMt067LTnd4jHaWFx9e+yxc/O+oVm8f7k7Z jAun0kgGeioxUV2fYpZ2xDzLdJ5VLzoY+zQaWoYXL7Z2eqZaUwy7WQyHGTdba8B1qm LJEmyk/M7i6UNt7Vuvdi626dqQf9bxbGvS+rD2OA= To: Olaoluwa Osuntokun From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <_ilRrLKoKyX8r9KRUw13Gx2H8LJxLleELolnZigAtS0-tXG2BDNU7RXBr7M3a467UMN9GS2MwiZcwwmRZgXHraxRIV_y5c_Zz3ZTNbKSlqg=@protonmail.com> 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 06:08:19 -0000 Good morning Laolu, Matt, and list, > > =C2=A0* With `SIGHASH_NOINPUT` we can make the C-side signature > > =C2=A0`SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-sid= e > > =C2=A0signature for a higher-fee version of HTLC-Timeout (assuming my c= ached > > =C2=A0understanding of `SIGHASH_NOINPUT` still holds). > > no_input isn't needed. With simply single+anyone can pay, then B can atta= ch > a new input+output pair to increase the fees on their HTLC redemption > transaction. As you mention, they now enter into a race against this > malicious ndoe to bump up their fees in order to win over the other party= . Right, right, that works as well. > > If the malicious node uses a non-RBF signalled transaction to sweep their > HTLC, then we enter into another level of race, but this time on the memp= ool > propagation level. However, if there exists a relay path to a miner runni= ng > full RBF, then B's higher fee rate spend will win over. Hmm. So basically: * B has no mempool, because it wants to reduce its costs and etc. * C broadcasts a non-RBF claim tx with low fee before A->B locktime (L+1). * B does not notice this tx because: 1. The tx is too low fee to be put in a block. 2. B has no mempool so it cannot see the tx being propagated over the P2= P network. * B tries to broadcast higher-fee HTLC-timeout, but fails because it cannot= replace a non-RBF tx. * After L+1, C contacts the miners off-band and offers fee payment by other= means. It seems to me that, if my cached understanding that `<0> OP_CHECKSEQUENCEV= ERIFY` is sufficient to require RBF-flagging, then adding that to the hashl= ock branch (2 witness bytes, 0.5 weight) would be a pretty low-weight mitig= ation against this attack. So I think the combination below gives us good size: * The HTLC-Timeout signature from C is flagged with `OP_SINGLE|OP_ANYONECAN= PAY`. * Normally, the HTLC-Timeout still deducts the fee from the value of the = UTXO being spent. * However, if B notices that the L+1 timeout is approaching, it can fee-b= ump HTLC-Timeout with some onchain funds, recreating its own signature but = reusing the (still valid) C signature. * The hashlock branch in this case includes `<0> OP_CHECKSEQUENCEVERIFY`, p= reventing C from broadcasting a low-fee claim tx. This has the advantages: * B does not need a mempool still and can run in `blocksonly`. * The normal path is still the same as current behavior, we "only" add a ne= w path where if the L+1 timeout is approaching we fee-bump the HTLC-Timeout= . * Costs are pretty low: * No need for extra RBF carve-out txo. * Just two additional witness bytes in the hashlock branch. * No mempool rule changes needed, can be done with the P2P network of today= . * Probably still resilient even with future changes in mempool rules, as = long as typical RBF behaviors still remain. Is my understanding correct? Regards, ZmnSCPxj > > -- Laolu > > On Tue, Apr 21, 2020 at 9:13 PM ZmnSCPxj via bitcoin-dev wrote: > > > Good morning Matt, and list, > > > > >=C2=A0 =C2=A0 =C2=A0RBF Pinning HTLC Transactions (aka "Oh, wait, I ca= n steal funds, how, now?") > > >=C2=A0 =C2=A0 =C2=A0=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 > > > > > >=C2=A0 =C2=A0 =C2=A0You'll note that in the discussion of RBF pinning = we were pretty broad, and that that discussion seems to in fact cover > > >=C2=A0 =C2=A0 =C2=A0our HTLC outputs, at least when spent via (3) or (= 4). It does, and in fact this is a pretty severe issue in today's > > >=C2=A0 =C2=A0 =C2=A0lightning protocol [2]. A lightning counterparty (= C, who received the HTLC from B, who received it from A) today could, > > >=C2=A0 =C2=A0 =C2=A0if B broadcasts the commitment transaction, spend = an HTLC using the preimage with a low-fee, RBF-disabled transaction. > > >=C2=A0 =C2=A0 =C2=A0After a few blocks, A could claim the HTLC from B = via the timeout mechanism, and then after a few days, C could get the > > >=C2=A0 =C2=A0 =C2=A0HTLC-claiming transaction mined via some out-of-ba= nd agreement with a small miner. This leaves B short the HTLC value. > > > > My (cached) understanding is that, since RBF is signalled using `nSeque= nce`, any `OP_CHECKSEQUENCEVERIFY` also automatically imposes the requireme= nt "must be RBF-enabled", including `<0> OP_CHECKSEQUENCEVERIFY`. > > Adding that clause (2 bytes in witness if my math is correct) to the ha= shlock branch may be sufficient to prevent C from making an RBF-disabled tr= ansaction. > > > > But then you mention out-of-band agreements with miners, which basicall= y means the transaction might not be in the mempool at all, in which case t= he vulnerability 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 n= ow be L + 1 or greater ("A could claim the HTLC from B via the timeout mech= anism", 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 branc= h. > > This sets up a game where B and C bid to miners to get their version of= reality committed onchain. > > (We can neglect out-of-band agreements here; miners have the incentive = to publicly 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 wil= l leak 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 comm= itted 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 n= eeded 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 mo= re blockspace. > > * With `SIGHASH_NOINPUT` we can make the C-side signature `SIGHASH_NOIN= PUT|SIGHASH_SINGLE` and allow B to re-sign the B-side signature for a highe= r-fee version of HTLC-Timeout (assuming my cached understanding of `SIGHASH= _NOINPUT` 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= HTLC value at all, since the UTXO it could steal from has already been spe= nt. > > > > In particular, it does not seem to me that it is necessary to change th= e hashlock-branch transaction of C at all, since this mechanism is enough t= o sidestep the issue (as I understand it). > > But it does point to a need to make HTLC-Timeout (and possibly symmetri= cally, HTLC-Success) also fee-bumpable. > > > > Note as well that this does not require a mempool: B can run in `blocks= only` mode and as each block comes in from L to L+1, if HTLC-Timeout is not= confirmed, feebump HTLC-Timeout. > > In particular, HTLC-Timeout comes into play only if B broadcast its own= commitment transaction, and B *should* be aware that it did so --- there i= s still 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 h= appen eventually. > > > > * C can bribe a miner to prevent HTLC-Timeout from confirming between L= and L+1. > > =C2=A0 * Or in other words, this is a censorship attack. > > =C2=A0 =C2=A0 * The Bitcoin censorship-resistance model is that censore= d transactions can be fee-bumped, which attracts non-censoring miners to tr= y their luck at mining and evict the censoring miner. > > =C2=A0 =C2=A0 =C2=A0 * Thus, letting B bump the fee on HTLC-Timeout is = precisely the mechanism we need. > > =C2=A0 =C2=A0 =C2=A0 * This sets up a bidding war between C requesting = miners to censor, vs. B requesting miners to confirm, but that only sets th= e stage for a second bidding war later between C and B, thus C is at a disa= dvantage: it has to bribe miners to censor continuously from L to L+1 *and*= additional bribe miners to confirm its transaction after L+1, whereas B ca= n offer its bribe as being something that miners can claim now without wait= ing after L+1. > > > > The issue of course is the additional output that bloats the UTXO set a= nd requires another transaction to claim later. > > And if we have `SIGHASH_NOINPUT`, it seems to me that Decker-Russell-Os= untokun 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-D= ryja channel can be upgraded, without onchain activity, to a Decker-Russell= -Osuntokun channel: sign a transaction spending the funding tx to a txo tha= t has been set up as Decker-Russell-Osuntokun, do not broadcast that transa= ction, then revoke the latest Poon-Dryja commitment transactions, then swit= ch the mechanism over to Decker-Russell-Osuntokun; you still need to monito= r for previous Poon-Dryja commitment transactions, but HTLCs now sidestep t= he issue under discussion here.) > > > > Regards, > > ZmnSCPxj > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev