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
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1US44J-0001yn-MM
for bitcoin-development@lists.sourceforge.net;
Tue, 16 Apr 2013 11:28:59 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.102 as permitted sender)
client-ip=62.13.148.102; envelope-from=pete@petertodd.org;
helo=outmail148102.authsmtp.net;
Received: from outmail148102.authsmtp.net ([62.13.148.102])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1US44H-0007io-Il for bitcoin-development@lists.sourceforge.net;
Tue, 16 Apr 2013 11:28:59 +0000
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt7.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r3GBSoTq037468
for <bitcoin-development@lists.sourceforge.net>;
Tue, 16 Apr 2013 12:28:50 +0100 (BST)
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r3GBSi46053407
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
for <bitcoin-development@lists.sourceforge.net>;
Tue, 16 Apr 2013 12:28:47 +0100 (BST)
Date: Tue, 16 Apr 2013 07:28:14 -0400
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20130416112814.GA22859@savin>
References: <bitcoin/bitcoin/pull/2516@github.com>
<bitcoin/bitcoin/pull/2516/c16418736@github.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR"
Content-Disposition: inline
In-Reply-To: <bitcoin/bitcoin/pull/2516/c16418736@github.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: cdf9c0eb-a688-11e2-b10b-0025903375e2
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXgN1
IQgLXVBSFQZ4AB4L BBYUVh48cANYeX5u ZEFqQHFbVVt/fUFi
QwAWFhp0Bj5kbmAa U0RYcE1VcQNKelEW PgZ2B3NYM3hWYHJo
WlZqMmp0N2wHImEN GltQfApJGhlWE2Qq fR1QVQYlHFEOQCQ1
GlQLLFcWGEtZLlV6 K1Y5XVsTPhofDBEW GEcFHCJCO18MW2xj TUgAABdAUVUA
X-Authentic-SMTP: 61633532353630.1019:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1US44H-0007io-Il
Subject: Re: [Bitcoin-development] [bitcoin] Enable tx replacement on
testnet. (#2516)
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 11:28:59 -0000
--T4sUOijqQbZv57TR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Apr 15, 2013 at 04:59:33PM -0700, Pieter Wuille wrote:
> How about: keep a counter in the mempool, remembering the sum of the size=
s of all replacements a transaction has had. When deciding whether to accep=
t a transaction as a replacement, increase this number and then check wheth=
er its fee is enough for that size. That's certainly overkill, as it will c=
orrectly count network and processing overhead, but not blockchain or UTXO =
burdening (as those only happen after finalizing). In any case, it's easy t=
o implement, seems safe to me, and would at least allow experimenting with =
this on testnet.
Thoughts:
1) IsNewerThan() returns false if vin.size() !=3D old.vin.size(), or if any=
of
the prevouts (txhash/vout #) don't match. In other words the inputs to a
transaction can't be changed by the current transaction replacement
mechanism.
2) If not for transaction replacement, nSequence could have been a boolean =
flag
called fIgnoreLockTime.
3) The nSequence part of IsNewerThan() is essentially just another type of
zero-conf transaction where you trust miners and relaying nodes to do wh=
at
you tell them too. We shouldn't encourage zero-conf transactions.
4) Testnet may be for testing, but we know tx-replacement is trivially DoS-=
able
right now. Those who want to experiment with attacks and counter measures
should do so in a way that doesn't disrupt testnet for everyone - settin=
g up
their own tx-replacement enabled nodes is easy to do.
5) Zero-conf transactions, replacement or otherwise, have issues with conse=
nsus
failure when network bandwidth is limited. In particular even if we requ=
ire
each re-broadcast of a transation to be accompanied by an increase in the
fees it pays, fees +=3D new tx size * MIN_RELAY_FEE has been proposed by=
a few
people for instance, the cost to different nodes for that bandwidth is d=
ifferent.
While less of an issue with 1MB blocks, with large blocks, especially bl=
ocksizes
only limited by what miners think is reasonable considering available
network bandwidth, lots of nodes and miners will be bandwidth starved
and transaction fees will fall to the marginal cost of the network
bandwidth and processing power to handle them. That cost is different
for different parties - you definitely won't get consensus and thus
zero-conf security in that scenario.
6) Finally zero-conf transactions have issues with consensus failures
caused by limited mempool sizes.
In any case, the more pressing issue re: replacement is changing fees
attached to transactions after they have been broadcast. Lots of users
are getting their transactions stuck with few options to fix them.
The more I think about the issue the more I think we should nip this
zero-conf madness in the bud: change the relay rules so that
transactions are replaced based on fees regardless of how that changes
transaction outputs. Of course, this does make double-spending an
unconfirmed transaction trivial. On the other hand, this makes changing
fees after the fact trivial, and it lets us implement a limited 'undo'
button for when people screw up. It also allows for many of the
applications transaction replacement was meant for in the first place
anyway, and all the applications where it's actually secure.
We keep saying over and over again to stop accepting zero-conf
transactions, but people do it anyway because it seems secure. It's a
very dangerous situation because the security of zero-conf transactions
can change overnight simply by some fraction of the hashing power
implementing that exact change.
Some thought is required as to exactly what "replace by fees" looks
like, economically optimal is a bit complex due to it's dependency on
overall mempool backlog, but a rough first version should be easy to
hammer out.
Funny enough though: I'm working on a trusted-third-party ledger design,
intentially made to be close to 100% compatible with standard Bitcoin,
and in that system tx-replacement by nSequence will be a perfectly
reasonable thing to do.
--=20
'peter'[:-1]@petertodd.org
--T4sUOijqQbZv57TR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJRbTXNAAoJEH+rEUJn5PoE3cQH/jjQT3Vhsi10xRjGWUhHpxEB
gt88tdAavSylriB7hM4VZcWV70s0d9bhhl/+X9yGZcYTZTFfE7f8hDTT6TzZCvRT
AEJG0kGlkzT79iCtDibSa/ZTa1+xsRtcVo8C8BWaEO2rQRZMlPndcYRID+7SVXlx
eVg3JPrTZMdsDLxkE5Ebj1cwT46/Uup3y/H9H0az9jvpMb/qcne5mvQW9hNYJnsk
Y84ThX0o+pA9pRsfXs+r87tbXyiNVhQrxCg3W8cc85H3ZzMLHlf0GtQqBfb0U72r
QtWWagCcDCaDFwcgeO1D9i5w0eDwat2CeGA5U+qrW4+e0S95o8GGxR4WbY+rOeo=
=u4Yc
-----END PGP SIGNATURE-----
--T4sUOijqQbZv57TR--
|
