Date: Wed, 22 Apr 2020 04:12:59 +0000
To: Matt Corallo <lf-lists@mattcorallo.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <qJG6__L8gl0p4Dz3gcFZ-kvkrV21Ai5gPjdX0obWiUSsQ6yzaBaTnKWLlBdK-2Y_-jkSrHx36smRGN7XDs8Pnf8AnSMhLw24oEOaLIrqsUg=@protonmail.com>
In-Reply-To: <a09f5291-e7c0-0aca-6971-03ace0c38dff@mattcorallo.com>
References: <a09f5291-e7c0-0aca-6971-03ace0c38dff@mattcorallo.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
Precedence: list

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