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
|
Return-Path: <rhavar@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 10517F32
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Feb 2018 23:23:29 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E9AE6D0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Feb 2018 23:23:27 +0000 (UTC)
Date: Mon, 12 Feb 2018 18:23:12 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1518477804;
bh=9AfZQVDj8C3eoQNCQzRGffwQHUAabROSeRFywCpJDd8=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=QKPM0m193L02ORtjkdelOlaP+yRBsLT+ODUr6qCHE9+udjmQ19tFxEMKYZ2xXivUJ
8waLtJ4XOYv3MVM16+ukQzYKtlu2uZtcNsdscMCVirmSwk9UXodqM99C7OQri3d3h5
A6ggqDJC0htsLj//dzZPDVwnOgkxh34V3jVFrR+0=
To: Peter Todd <pete@petertodd.org>
From: rhavar@protonmail.com
Reply-To: rhavar@protonmail.com
Message-ID: <0uRiPitofHOu2G_7h4lk1q-BKJOZ_x9UecbP8aqyy7FLlrme06od_H79G7rfIs1uk3Vs470_PSlCHjRqsC9ObqhQRyhZ_9JdEzYJzNd-QRM=@protonmail.com>
In-Reply-To: <20180212225828.GB8551@fedora-23-dvm>
References: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
<20180212225828.GB8551@fedora-23-dvm>
Feedback-ID: RdfuD--Ffc-FNb_4UIG1XA3s5stj1f6Yt84KENdha_3WoiW3STYpu7X5uGR72LvTfQZpxEhSRHGSlNfV5XM5RA==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW 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: Tue, 13 Feb 2018 00:57:20 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.
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: Mon, 12 Feb 2018 23:23:29 -0000
On February 12, 2018 5:58 PM, Peter Todd via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
> I don't actually see where the problem is here. First of all, suppose we =
have a
> transaction T_a that already pays Alice with a feerate sufficiently high =
that
> we expect it to get mined in the near future. If we want to pay Bob, we c=
an do
> that by simply creating a double-spend of T_a that pays both Bob and Alic=
e,
> T_{ab}. BIP125 only requires that double-spend to have an absolute fee hi=
gher
> than the minimum relay feerate * size of the transaction.
It's a bit of a made up term, but when Russel said "pinned" it refers to a =
child transaction that was made (i.e. in this case by Alice) and for us to=
replace our transaction we need to "unpin" it.
However to unpin it, the current bip125 rules require you pay not only the =
relay of the transactions you're throwing away, but the absolute fee. This =
is general is cost prohibitive, as even a normalish transaction can be spen=
ding $20 in fees.=20
Also FWIW this whole idea of T_a and T_ab is good, but it's also pretty im=
practical at the moment due to the sheer amount complexity it introduces (i=
.e. monitoring, seeing which confirms, trying to rebroadcast the missing on=
e in a way that is safe against reorgs, blah blah).
>
> I just checked one of my nodes, and the absolute minimum relay fee is abo=
ut
> 1/5th that of what estimatefee returns for the longest possible estimate,=
48
> blocks.
If you use estimatesmartfee you should be able to get estimates all the way=
to 1008 or something btw
> [...]
> I think this is very important. For example, without this condition I cou=
ld do
> a DoS attack by repeatedly broadcasting a transaction, then spending the
> outputs of that transaction with a very large number of child transaction=
s, all
> of minimum fee.=20
I agree.
>
> A better way to solve this class of problems may be diffed tx replacement
> propagation: basically broadcast a diff between the original tx and the
> proposed replacement, allowing you to do the minimum bandwidth accounting=
based
> on the size of the diff instead.
This would definitely work for some specific use-case. For instance current=
ly if you do n replacements of a transaction, each time adding an additiona=
l output .. you need to pay something like O(n^2) relay fee. If you used a =
diff instead, you could probably get it to O(n)ish.=20
But relay fee (and n) at the moment, mean it's not a big deal at all. The b=
ig flaw (imo) in bip125 is that you need to pay the absolute fee from the t=
ransactions you are evicting. And that can be from transactions you didn't =
even generate yourself. We can already compactly represent the diff (the =
new transaction invalidates it) the debate is more "Should you have to pay=
the absolute fee or just relay fee for the stuff you invalidate"
|
