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
|
Return-Path: <dave@dtrt.org>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 1BA4AC0175;
Wed, 22 Apr 2020 11:52:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 1750F87EA9;
Wed, 22 Apr 2020 11:52:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id UWAEx9XRS5em; Wed, 22 Apr 2020 11:52:34 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87])
by hemlock.osuosl.org (Postfix) with ESMTPS id 14EB687EA7;
Wed, 22 Apr 2020 11:52:34 +0000 (UTC)
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
(envelope-from <dave@dtrt.org>)
id 1jRDvb-0007k5-MJ; Wed, 22 Apr 2020 07:52:31 -0400
Date: Wed, 22 Apr 2020 07:51:30 -0400
From: "David A. Harding" <dave@dtrt.org>
To: Olaoluwa Osuntokun <laolu32@gmail.com>
Message-ID: <20200422115130.4iinxmmtlbcefyx7@ganymede>
References: <a09f5291-e7c0-0aca-6971-03ace0c38dff@mattcorallo.com>
<CAO3Pvs-SbA+6b2c3Pg-ohvovVtTenx8ve1BZWGgCiLAcSZNNVw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="i4wy6i4hw6p3ggir"
Content-Disposition: inline
In-Reply-To: <CAO3Pvs-SbA+6b2c3Pg-ohvovVtTenx8ve1BZWGgCiLAcSZNNVw@mail.gmail.com>
User-Agent: NeoMutt/20180716
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 11:52:36 -0000
--i4wy6i4hw6p3ggir
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Apr 21, 2020 at 09:13:34PM -0700, Olaoluwa Osuntokun wrote:
> On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev =
wrote:
> > While this is somewhat unintuitive, there are any number of good anti-D=
oS
> > reasons for this, eg:
>=20
> None of these really strikes me as "good" reasons for this limitation
> [...]
> 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.=20
I think it's important to remember than mempool behavior affects not
just miners but also relay nodes. Miner costs, such as bandwidth usage,
can be directly offset by their earned block rewards, so miners can be
much more tolerant of wasted bandwidth than relay nodes who receive no
direct financial compensation for the processing and relay of
unconfirmed transactions.[1]
> Why would one prefer a higher absolute fee package (which could be
> very large) over another package with a higher total _fee rate_?
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)
Assuming 50,000 active relay nodes and today's BTC price of ~$7,000
USD/BTC, the above scenario would allow an attacker to waste a
collective 20 terabytes of network bandwidth for a total fee cost of
$10.50. And, of course, the attacker could run multiple attacks of this
sort in parallel, quickly swamping the network.
To use the above concrete example to repeat the point made at the
beginning of this email: miners might be willing to accept the waste of
400 MB of bandwidth in order to gain a $10.50 fee, but I think very few
relay nodes could function for long under an onslaught of such behavior.
-Dave
[1] The reward to relay nodes of maintaining the public relay network is
that it helps protect against miner centralization. If there was no
public relay network, users would need to submit transactions
directly to miners or via a privately-controlled relay network.
Users desiring timely confirmation (and operators of private relay
networks) would have a large incentive to get transactions to the
largest miners but only a small incentive to get the transaction to
the smaller miners, increasing the economies of scale in mining and
furthering centralization.
Although users of Bitcoin benefit by reducing mining centralization
pressure, I don't think we can expect most users to be willing to
bear large costs in defense of benefits which are largely intangible
(until they're gone), so we must try to keep the cost of operating a
relay node within a reasonable margin of the cost of operating a
minimal-bandwidth blocks-only node.
--i4wy6i4hw6p3ggir
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl6gL8IACgkQ2dtBqWwi
adPTEBAAlW1qfNAZHScJ878tSxYls66RGHLennzvEQcjojkZpe8/0vVR0rKYO2Ei
s+fy1gZaTSVH0xC51OyEG+lAwx6k2iS5pO655pf/s/haJb19FEzrMM3Unw9oO1SR
xqaIY4BiBzdd/CREo6PJ+oMRw4zaqf7ZTqlF1KRN0rUWGQZ0a8kaNwTpfHKDtuH6
5iicHatBmY2fUGAaD81eM3167a3rqDxuM51GTJk6nU6pgnjHGwaMfgb8kK7XDhCF
pXE/cqEmmTbO44Cwg7YrBVLXb/bDOIZkTy5pcDKFxlBuxV5hNzG+ezXC4PDObJqV
YL8o7YkutEMXDVvuxpK1PI4GYj9ogWyyjL23p8jbUjOM2Ra3VeNfdhlo4MiX14MN
1HMACM/TJCui9eteVLkazG6Nm8XRbRB/+Bvj0gUyJieKlWfkoZBUEJIkrznXrQOq
zxs8E7ZeC9ieZmRdcfFQfDAczZvznwXlSEw8ofvm01Oyt009WUbG9jtBBde1rIyX
abzoJxSzA+xtL3ELfHSiWqXdgEF/58uI0gKFPhFCe8aj+srYxkFl75LkwgjIg5Ns
LKYwHSw4pNVkW+eAwV/T9IVbr5vuqFXQuG1+K/IfHWd+c7ixT7yg897V0R50Zw8Y
ikIb5Chh986pwx1NVch20pWukdNyiRuxa0OrPoa+4Hx+A9tcxV0=
=njA6
-----END PGP SIGNATURE-----
--i4wy6i4hw6p3ggir--
|
