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
|
Return-Path: <rusty@ozlabs.org>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 2EFFDC0172;
Wed, 29 Apr 2020 04:52:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 180DA8757F;
Wed, 29 Apr 2020 04:52:09 +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 PHXh8IU4MuuY; Wed, 29 Apr 2020 04:52:07 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from ozlabs.org (ozlabs.org [203.11.71.1])
by whitealder.osuosl.org (Postfix) with ESMTPS id AF555874D4;
Wed, 29 Apr 2020 04:52:07 +0000 (UTC)
Received: by ozlabs.org (Postfix, from userid 1011)
id 49BmMQ6jV9z9sP7; Wed, 29 Apr 2020 14:52:02 +1000 (AEST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: "David A. Harding" <dave@dtrt.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Olaoluwa Osuntokun <laolu32@gmail.com>
In-Reply-To: <20200422115130.4iinxmmtlbcefyx7@ganymede>
References: <a09f5291-e7c0-0aca-6971-03ace0c38dff@mattcorallo.com>
<CAO3Pvs-SbA+6b2c3Pg-ohvovVtTenx8ve1BZWGgCiLAcSZNNVw@mail.gmail.com>
<20200422115130.4iinxmmtlbcefyx7@ganymede>
Date: Tue, 28 Apr 2020 06:56:19 +0930
Message-ID: <87blncfwn8.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
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, 29 Apr 2020 04:52:09 -0000
"David A. Harding via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> writes:
> To avoid the excessive wasting of bandwidth. Bitcoin Core's defaults
> require each replacement pay a feerate of 10 nBTC/vbyte over an existing
> transaction or package, and the defaults also allow transactions or
> packages up to 100,000 vbytes in size (~400,000 bytes). So, without
> enforcement of BIP125 rule 3, an attacker starting at the minimum
> default relay fee also of 10 nBTC/vbyte could do the following:
>
> - Create a ~400,000 bytes tx with feerate of 10 nBTC/vbyte (1 mBTC total
> fee)
>
> - Replace that transaction with 400,000 new bytes at a feerate of 20
> nBTC/vbyte (2 mBTC total fee)
>
> - Perform 998 additional replacements, each increasing the feerate by 10
> nBTC/vbyte and the total fee by 1 mBTC, using a total of 400 megabytes
> (including the original transaction and first replacement) to
> ultimately produce a transaction with a feerate of 10,000 nBTC/vbyte
> (1 BTC total fee)
>
> - Perform one final replacement of the latest 400,000 byte transaction
> with a ~200-byte (~150 vbyte) 1-in, 1-out P2WPKH transaction that pays
> a feerate of 10,010 nBTC/vbyte (1.5 mBTC total fee)
To be fair, if the feerate you want is 100x the minimum permitted, you
can always use 100x as much bandwidth as necessary without extra cost.
If everyone (or some major tx producers) were to do that, it would suck.
To fix this properly, you really need to agressively delay processing
(thus propagation) of transactions which aren't likely to be in the next
(few?) blocks. This is a more miner incentive compatible scheme.
However, I realize this is a complete rewrite of bitcoind's logic, and
I'm not volunteering to do it!
Cheers,
Rusty,
|
