path: root/8f/1122a721816d272eb013843a4a26b27e91f429

Return-Path: <ZmnSCPxj@protonmail.com>
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 <laolu32@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <_ilRrLKoKyX8r9KRUw13Gx2H8LJxLleELolnZigAtS0-tXG2BDNU7RXBr7M3a467UMN9GS2MwiZcwwmRZgXHraxRIV_y5c_Zz3ZTNbKSlqg=@protonmail.com>
In-Reply-To: <CAO3Pvs82q-LCieXVc7VWUay5QP1r7EQf1NTFwW49oZRuiyUfMQ@mail.gmail.com>
References: <a09f5291-e7c0-0aca-6971-03ace0c38dff@mattcorallo.com>
 <qJG6__L8gl0p4Dz3gcFZ-kvkrV21Ai5gPjdX0obWiUSsQ6yzaBaTnKWLlBdK-2Y_-jkSrHx36smRGN7XDs8Pnf8AnSMhLw24oEOaLIrqsUg=@protonmail.com>
 <CAO3Pvs82q-LCieXVc7VWUay5QP1r7EQf1NTFwW49oZRuiyUfMQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>
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 <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: 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 <bitcoin-dev@lis=
ts.linuxfoundation.org> 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