1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 97F58C0175;
Wed, 22 Apr 2020 16:56:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 860BC85899;
Wed, 22 Apr 2020 16:56:42 +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 Z458Ob1Vx-6F; Wed, 22 Apr 2020 16:56:41 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by whitealder.osuosl.org (Postfix) with ESMTPS id 5A6A785209;
Wed, 22 Apr 2020 16:56:41 +0000 (UTC)
Received: from [IPv6:2620:6e:a007:233::100] (unknown
[IPv6:2620:6e:a007:233::100])
by mail.as397444.net (Postfix) with ESMTPSA id D5BA6232649;
Wed, 22 Apr 2020 16:56:39 +0000 (UTC)
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
References: <a09f5291-e7c0-0aca-6971-03ace0c38dff@mattcorallo.com>
<qJG6__L8gl0p4Dz3gcFZ-kvkrV21Ai5gPjdX0obWiUSsQ6yzaBaTnKWLlBdK-2Y_-jkSrHx36smRGN7XDs8Pnf8AnSMhLw24oEOaLIrqsUg=@protonmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <b12b6e69-6002-d803-8ac9-073000ee0d14@mattcorallo.com>
Date: Wed, 22 Apr 2020 12:56:38 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <qJG6__L8gl0p4Dz3gcFZ-kvkrV21Ai5gPjdX0obWiUSsQ6yzaBaTnKWLlBdK-2Y_-jkSrHx36smRGN7XDs8Pnf8AnSMhLw24oEOaLIrqsUg=@protonmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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 16:56:42 -0000
On 4/22/20 12:12 AM, ZmnSCPxj wrote:
> Good morning Matt, and list,
>
>
>
>> RBF Pinning HTLC Transactions (aka "Oh, wait, I can steal funds, how, now?")
>> =============================
>>
>> You'll note that in the discussion of RBF pinning we were pretty broad, 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 preimage with a low-fee, RBF-disabled transaction.
>> After a few blocks, A could claim the HTLC from B via the timeout mechanism, 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 hashlock branch may be sufficient to prevent C from making an RBF-disabled transaction.
Hmm, indeed, though note that (IIRC) you can break this by adding children or parents which are *not* RBF-enabled and
then the package may lose the ability to be RBF'd.
> But then you mention out-of-band agreements with miners, which basically means the transaction might not be in the mempool at all, in which case the vulnerability is not really about RBF or relay, but sheer economics.
No. The whole point of this attack is that you keep a transaction in the mempool but unconfirmed via RBF pinning, which
prevents an *alternative* transaction from being confirmed. You then have plenty of time to go get it confirmed later.
> 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 be L + 1 or greater ("A could claim the HTLC from B via the timeout mechanism", 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 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.)
Right, I think I didn't explain clearly enough. The point is that, here, B tries to broadcast the timeout transaction
but cannot because there is an in-mempool conflict.
> Before L+1, C has no incentive to bid, since placing any bid at all will 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 committed 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 needed 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 blockspace.
> * 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-fee version of HTLC-Timeout (assuming my cached understanding of `SIGHASH_NOINPUT` still holds).
This does not solve the issue because you can add as many fees as you want, as long as the transaction is RBF-pinned,
there is not much you can do in an automated fashion.
> 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 spent.
>
> In particular, it does not seem to me that it is necessary to change the hashlock-branch transaction of C at all, since this mechanism is enough to sidestep the issue (as I understand it).
> But it does point to a need to make HTLC-Timeout (and possibly symmetrically, 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 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 is 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 happen 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 at mining and evict the censoring miner.
> * Thus, letting B bump the fee on HTLC-Timeout is precisely the mechanism we need.
> * This sets up a bidding war between C requesting miners to censor, vs. B requesting miners to confirm, but that only sets the stage for a second 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 miners to confirm its transaction after L+1, whereas B can offer its bribe as 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 requires another transaction to claim later.
> And if we have `SIGHASH_NOINPUT`, it seems to me that Decker-Russell-Osuntokun 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-Osuntokun channel: sign a transaction spending the funding tx to a txo that has been set up as Decker-Russell-Osuntokun, do not broadcast that transaction, then revoke the latest Poon-Dryja commitment transactions, then switch the mechanism over to Decker-Russell-Osuntokun; you still need to monitor for previous Poon-Dryja commitment transactions, but HTLCs now sidestep the issue under discussion here.)
>
> Regards,
> ZmnSCPxj
>
|
