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
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 19B86C0175;
Thu, 23 Apr 2020 04:50:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 0AC7B86C23;
Thu, 23 Apr 2020 04:50:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ua6tWmfwFGlJ; Thu, 23 Apr 2020 04:50:34 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27])
by fraxinus.osuosl.org (Postfix) with ESMTPS id 8828386C1B;
Thu, 23 Apr 2020 04:50:18 +0000 (UTC)
Date: Thu, 23 Apr 2020 04:50:09 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1587617416;
bh=vOtlaP1Y9u47LG2VL70vssjtpfll83QFol+d9quFANg=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=dXLA7je24/55fF3q5YCk2WeIiGmN7fm2SPoFAQsJzp+r2rkt8whsN1BWDCvu8z+m4
ME1WSsVefSqJX6cWDy2Lwar/Rd9E0fK1EaF2DndiZ0QM9rDoHrUQGz71ywNnEInM84
8LjZNiv8/qaCqLdRUdhJ5g74tZ+Gft6Cjz46eB3A=
To: Matt Corallo <lf-lists@mattcorallo.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <PtYNeePySy_thDHm8FwIIGEk32EjJpSmiwPctyEg0hOrLZEHjO1IBghm4MWY88g51K-XF2pf_JDnW0UdTL6QSbACEj21h9U1s5ITc_N3I6Q=@protonmail.com>
In-Reply-To: <4def6907-d380-c053-d361-5a7f12202b34@mattcorallo.com>
References: <CAO3Pvs8Dx8ATXfQRA3p7DzzHcYZz1nF4g=+ZHvSukL0jMbxAOw@mail.gmail.com>
<9F7F7A00-FFA5-48E8-9BA3-8D71A55B2659@mattcorallo.com>
<CAO3Pvs_hNhEjX_tAatnij-4vd1cgPk8DPxOdrgDVuia7h=z5UQ@mail.gmail.com>
<4def6907-d380-c053-d361-5a7f12202b34@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
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: Thu, 23 Apr 2020 04:50:36 -0000
Good morning lists et al,
Let me try to summarize things a little:
* Suppose we have a forwarding payment A->B->C.
* Suppose B does not want to maintain a mempool and is running in `blockson=
ly` mode to reduce operational costs.
* C triggers B somehow dropping the B<->C channel, such as by sending an `e=
rror` message, which will usually cause the other side to drop the channel =
onchain using its commitment transaction.
* The dropped B<->C channel has an HTLC (that was set up during the A->B->C=
forwarding).
* The HTLC, being used in a Poon-Dryja channel, actually has the following =
contract text:
* The fund may be claimed by either of these clauses:
* C can claim, if C shows the preimage of some hash H (hashlock branch)=
.
* B and C must agree, and claim after time L (timelock branch).
* B holds a signature from C that can claim the timelock branch of the HTLC=
, for a transaction that spends to an output with an `OP_CHECKSEQUENCEVERIF=
Y`.
* The signature is `SIGHASH_ALL`, so the transaction has a fixed feerate.
* C can "pin" the HTLC output by spending using the hashlock branch, and cr=
eating a large fee, low fee-rate (tree of) transactions.
* As it is a low fee-rate, miners have no incentive to put this in a bloc=
k, especially if unrelated higher-fee-rate transactions exist that would ea=
rn them more money.
* Even in a full RBF universe, because of the anti-DoS mempool rules, B c=
annot evict this pinned transaction by just bidding up the feerate.
* A replacing transaction cannot evict alternatives unless its absolute=
fee is greater than the absolute fee of the alternative.
* The pinning transaction has a high fee, but is blockspace-wasteful, s=
o it is:
* Undesirable to mine (low feerate).
* Difficult to evict (high fee).
* Thus, B is unable to get its timelock-branch transaction in the mempools =
of miners.
* C waits until the A->B HTLC times out, then:
* C directly contacts miners with an out-of-band proposal to replace its =
transaction with an alternative that is much smaller and has a low fee, but=
much better feerate.
* Miners, being economically rational, accept this proposal and include t=
his in a block.
The proposal by Matt is then:
* The hashlock branch should instead be:
* B and C must agree, and show the preimage of some hash H (hashlock bran=
ch).
* Then B and C agree that B provides a signature spending the hashlock bran=
ch, to a transaction with the outputs:
* Normal payment to C.
* Hook output to B, which B can use to CPFP this transaction.
* Hook output to C, which C can use to CPFP this transaction.
* B can still (somehow) not maintain a mempool, by:
* B broadcasts its timelock transaction.
* B tries to CPFP the above hashlock transaction.
* If CPFP succeeds, it means the above hashlock transaction exists and =
B queries the peer for this transaction, extracting the preimage and claimi=
ng the A->B HTLC.
Is that a fair summary?
--
Naively, and remembering I am completely ignorant of the exact details of t=
he mempool rules, it seems to me quite strange that we are allowing an unde=
sirable transaction (tree) into the mempool:
* Undesirable to mine (low fee-rate).
* Difficult to evict (high fee).
Miners are not interested in low fee-rate transactions, as long as higher f=
ee-rate transactions exist.
And being difficult to evict means miners cannot get alternatives that are =
more lucrative for them.
The reason (as I understand it) eviction is purposely made difficult here i=
s to prevent certain DoS attacks on Bitcoin nodes, specifically:
1. Attacker sends a low fee-rate tx as a "root" transaction.
2 Attacker sends thousands of low fee-rate tx that build off the above roo=
t.
3. Attacker sends a slightly higher fee-rate alternative to the root, evict=
ing the above tree of txes.
4. Attacker sends thousands of low fee-rate tx that build off the latest ro=
ot.
5. GOTO 3.
However, it seems to me, naively, that "an ounce of prevention is worth a p=
ound of cure".
As I understand it, the mempool is organized already into "packages" of tra=
nsactions, and adding a transaction into the mempool involves extending and=
merging packages.
Perhaps the size of a package with low fee-rate (relative to the other pack=
ages in the mempool) can be limited, so that mempools drop incoming txes th=
at extend a low-fee-rate tree of transactions.
This means an attacker cannot send thousands of low fee-rate tx that build =
off some low fee-rate root tx in the first place, so it can still be evicte=
d easily later without much impact.
Naively, it seems to me to prevent the DoS attack as well, as at step 2 it =
would be prevented from sending thousands of low fee-rate tx building off t=
he root.
As well, as I understand it, this merely tightens the mempool acceptance ru=
les, preventing low fee-rate packages from growing (analogous to a consensu=
s-layer softfork).
The "cannot evict high absolute fee" rule can be retained, as the low-fee-r=
ate package is prevented from reaching a large size.
Would that be workable as a general solution to solve (what I think is) the=
root cause of this problem?
(This assumes full RBF, I suppose.)
Regards,
ZmnSCPxj
|
