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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 98197C1D7D;
Wed, 22 Apr 2020 16:50:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 839741FDFB;
Wed, 22 Apr 2020 16:50:52 +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 6AiBkcMHUHsx; Wed, 22 Apr 2020 16:50:51 +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 silver.osuosl.org (Postfix) with ESMTPS id 1CED31FD16;
Wed, 22 Apr 2020 16:50:51 +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 6CA9B2325D3;
Wed, 22 Apr 2020 16:50:48 +0000 (UTC)
To: Olaoluwa Osuntokun <laolu32@gmail.com>
References: <a09f5291-e7c0-0aca-6971-03ace0c38dff@mattcorallo.com>
<CAO3Pvs-SbA+6b2c3Pg-ohvovVtTenx8ve1BZWGgCiLAcSZNNVw@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <10406f38-fc9d-ac0b-cfd2-0b507d8ec573@mattcorallo.com>
Date: Wed, 22 Apr 2020 12:50:46 -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: <CAO3Pvs-SbA+6b2c3Pg-ohvovVtTenx8ve1BZWGgCiLAcSZNNVw@mail.gmail.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] 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:50:52 -0000
A few replies inline.
On 4/22/20 12:13 AM, Olaoluwa Osuntokun wrote:
> Hi Matt,
>
>
>> While this is somewhat unintuitive, there are any number of good anti-DoS
>> reasons for this, eg:
>
> None of these really strikes me as "good" reasons for this limitation, which
> is at the root of this issue, and will also plague any more complex Bitcoin
> contracts which rely on nested trees of transaction to confirm (CTV, Duplex,
> channel factories, etc). Regarding the various (seemingly arbitrary) package
> limits it's likely the case that any issues w.r.t computational complexity
> that may arise when trying to calculate evictions can be ameliorated with
> better choice of internal data structures.
>
> In the end, the simplest heuristic (accept the higher fee rate package) side
> steps all these issues and is also the most economically rationale from a
> miner's perspective. Why would one prefer a higher absolute fee package
> (which could be very large) over another package with a higher total _fee
> rate_?
This seems like a somewhat unnecessary drive-by insult of a project you don't contribute to, but feel free to start with
a concrete suggestion here :).
>> You'll note that B would be just fine if they had a way to safely monitor the
>> global mempool, and while this seems like a prudent mitigation for
>> lightning implementations to deploy today, it is itself a quagmire of
>> complexity
>
> Is it really all that complex? Assuming we're talking about just watching
> for a certain script template (the HTLC scipt) in the mempool to be able to
> pull a pre-image as soon as possible. Early versions of lnd used the mempool
> for commitment broadcast detection (which turned out to be a bad idea so we
> removed it), but at a glance I don't see why watching the mempool is so
> complex.
Because watching your own mempool is not guaranteed to work, and during upgrade cycles that include changes to the
policy rules an attacker could exploit your upgraded/non-upgraded status to perform the same attack.
>> Further, this is a really obnoxious assumption to hoist onto lightning
>> nodes - having an active full node with an in-sync mempool is a lot more
>> CPU, bandwidth, and complexity than most lightning users were expecting to
>> face.
>
> This would only be a requirement for Lightning nodes that seek to be a part
> of the public routing network with a desire to _forward_ HTLCs. This isn't
> doesn't affect laptops or mobile phones which likely mostly have private
> channels and don't participate in HTLC forwarding. I think it's pretty
> reasonable to expect a "proper" routing node on the network to be backed by
> a full-node. The bandwidth concern is valid, but we'd need concrete numbers
> that compare the bandwidth over head of mempool awareness (assuming the
> latest and greatest mempool syncing) compared with the overhead of the
> channel update gossip and gossip queries over head which LN nodes face today
> as is to see how much worse off they really would be.
If mempool-watching were practical, maybe, though there are a number of folks who are talking about designing
partially-offline local lightning hubs which would be rendered impractical.
> As detailed a bit below, if nodes watch the mempool, then this class of
> attack assuming the anchor output format as described in the open
> lightning-rfc PR is mitigated. At a glance, watching the mempool seems like
> a far less involved process compared to modifying the state machine as its
> defined today. By watching the mempool and implementing the changes in
> #lightning-rfc/688, then this issue can be mitigated _today_. lnd 0.10
> doesn't yet watch the mempool (but does include anchors [1]), but unless I'm
> missing something it should be pretty straight forward to add which mor or less
> resolves this issue all together.
>
>> not fixing this issue seems to render the whole exercise somewhat useless
>
> Depends on if one considers watching the mempool a fix. But even with that a
> base version of anchors still resolves a number of issues including:
> eliminating the commitment fee guessing game, allowing users to pay less on
> force close, being able to coalesce 2nd level HTLC transactions with the
> same CLTV expiry, and actually being able to reliably enforce multi-hop HTLC
> resolution.
>
>> Instead of making the HTLC output spending more free-form with
>> SIGHASH_ANYONECAN_PAY|SIGHASH_SINGLE, we clearly need to go the other
>> direction - all HTLC output spends need to be pre-signed.
>
> I'm not sure this is actually immediately workable (need to think about it
> more). To see why, remember that the commit_sig message includes HTLC
> signatures for the _remote_ party's commitment transaction, so they can
> spend the HTLCs if they broadcast their version of the commitment (force
> close). If we don't somehow also _gain_ signatures (our new HTLC signatures)
> allowing us to spend HTLCs on _their_ version of the commitment, then if
> they broadcast that commitment (without revoking), then we're unable to
> redeem any of those HTLCs at all, possibly losing money.
Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to braodcasted transactions, but instead to CPFP
a maybe-broadcasted transaction by sending a transaction which spends it and seeing if it is accepted. You only need to
know the transaction's exact format (ie txid, which we do, since we sent a signature for it long ago) to do this, you
don't have to actually *have* the fully-signed transaction (and you don't).
> In an attempt to counteract this, we might say ok, the revoke message also
> now includes HTLC signatures for their new commitment allowing us to spend
> our HTLCs. This resolves things in a weaker security model, but doesn't
> address the issue generally, as after they receive the commit_sig, they can
> broadcast immediately, again leaving us without a way to redeem our HTLCs.
>
> I'd need to think about it more, but it seems that following this path would
> require an overhaul in the channel state machine to make presenting a new
> commitment actually take at least _two phases_ (at least a full round trip).
> The first phase would tender the commitment, but render them unable to
> broadcast it. The second phase would then <insert something something
> scriptless scripts here> enter a new sub-protocol which upon conclusion,
> gives the commitment proposer valid HTLC signatures, and gives the responder
> what they need to be able to broadcast their commitment and claim their
> HTCLs in an atomic manner.
>
> -- Laolu
>
> [1]: https://github.com/lightningnetwork/lnd/pull/3821
|
