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
|
Return-Path: <rusty@ozlabs.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 44E602C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Jun 2019 03:59:58 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from ozlabs.org (ozlabs.org [203.11.71.1])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 020C267F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Jun 2019 03:59:55 +0000 (UTC)
Received: by ozlabs.org (Postfix, from userid 1011)
id 45M2bF2PJ0z9s7h; Sun, 9 Jun 2019 13:59:53 +1000 (AEST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <F252D824-5BE6-4B03-B59D-D40EAFBAEE84@mattcorallo.com>
References: <871s0c1tvg.fsf@rustcorp.com.au>
<F252D824-5BE6-4B03-B59D-D40EAFBAEE84@mattcorallo.com>
Date: Thu, 06 Jun 2019 14:46:54 +0930
Message-ID: <871s07nvi1.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 09 Jun 2019 08:18:41 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Sun, 09 Jun 2019 03:59:58 -0000
Matt Corallo <lf-lists@mattcorallo.com> writes:
> I think this needs significantly improved motivation/description. A few areas I'd like to see calculated out:
>
> 1) wrt rule 3, for this to be obviously-incentive-compatible-for-the-next-miner, I'd think no evicted transactions would be allowed to be in the next block range. This would probably require some significant additional tracking in today's mempool logic.
This is a good question, which is why I really wanted to look into the
implementation details. There are some approximations possible wrt. pre-
and post- tx bundle feerate, but they have to be examined closely.
> 2) wrt rule 4, I'd like to see a calculation of worst-case free relay. I think we're already not in a great place, but maybe it's worth it or maybe there is some other way to reduce this cost (intuitively it looks like this proposal could make things very, very, very bad).
I *think* you can currently create a tx at 1 sat/byte, have it
propagate, then RBF it to 2 sat/byte, 3... and do that a few thousand
times before your transaction gets mined.
If that's true, I don't think this proposal makes it worse.
>> 3) wrt rule 5, I'd like to see benchmarks, it's probably a pretty nasty DoS attack, but it may also be the case that is (a) not worse than other fundamental issues or (b) sufficiently expensive.
I thought we still meet rule 5 in practice since bitcoind will never
even accept a tree of unconfirmed txs which is > 100 txs? That would
still stand, it's just that we'd still consider a replacement.
> 4) As I've indicated before, I'm generaly not a fan of such vague
> protections for time-critical transactions such as payment channel
> punishment transactions.
The bitcoin network offers no propagation guarantees; it's all best
effort anyway. This makes it no worse, and we can tunnel txs through
the lightning network if we have to.
> At a high-level, in this context your counterparty's transactions (not to mention every other transaction in everyone's mempool) are still involved in the decision about whether to accept an RBF, in contrast to previous proposals, which makes it much harder to reason about. As a specific example, if an attacker exploits mempool policy differences they may cause your concept of "top 4M weight" to be bogus for a subeset of nodes, causing propogation to be limited.
If miners have a conflicting tx in the top 4MSipa, you don't have a
problem. So an attacker needs to limit propagation in a way which
isolates the miners from either the new tx or the conflicting one, which
is much harder.
> Obviously there is also a ton more client-side knowledge required and complexity to RBF decisions here than other previous, more narrowly-targeted proposals.
Define client-side here?
I'd say from the lightning side it's as simple as a normal RBF policy
until you get within a few blocks of a deadline, then you increase the
fees until it's well within reach of the next block. You can even
approximate this by looking at fees on the previous block, with some
care for outliers.
> (I don't think this one use-case being not optimal should prevent such a proposal, i agree it's quite nice for some other cases).
I like that it's conceptually simple and inventive-robust, and doesn't
really rely on bitcoind's internal policy mechanics of RBF.
I think in the longer term we're going to need other mechanisms for
restricting abusive propagation anyway, but that's a bit out-of-scope.
Thanks!
Rusty.
|
