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
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1Z5wal-0004pE-RC
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 13:44:23 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.80 as permitted sender)
client-ip=62.13.149.80; envelope-from=pete@petertodd.org;
helo=outmail149080.authsmtp.com;
Received: from outmail149080.authsmtp.com ([62.13.149.80])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Z5wak-00047C-05 for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 13:44:23 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5JDiFUp000203;
Fri, 19 Jun 2015 14:44:15 +0100 (BST)
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
[75.119.251.161]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5JDi8KF057450
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 19 Jun 2015 14:44:10 +0100 (BST)
Date: Fri, 19 Jun 2015 09:44:08 -0400
From: Peter Todd <pete@petertodd.org>
To: Stephen Morse <stephencalebmorse@gmail.com>
Message-ID: <20150619134408.GB27280@savin.petertodd.org>
References: <20150619103959.GA32315@savin.petertodd.org>
<CABHVRKR7bXfDX0_frAv_Ph4Saz3SXwXeZae1DEokorvekPeinw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="vGgW1X5XWziG23Ko"
Content-Disposition: inline
In-Reply-To: <CABHVRKR7bXfDX0_frAv_Ph4Saz3SXwXeZae1DEokorvekPeinw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 441fd706-1689-11e5-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwsUEkAaAgsB AmMbWlBeVFl7WGI7 bA9PbARUfEhLXhtr
VklWR1pVCwQmRRl7 ckcWKW9ycgJCfX4+ Z0RlV3cVWEB7IxJ6
QkhJFGsObHphaTUa TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMGQE QBcGVTUmBgUIQSw5
KxEqYlABGEJZKEgq NVIqVBcSIlocBwA2
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/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: 1Z5wak-00047C-05
Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
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: Fri, 19 Jun 2015 13:44:23 -0000
--vGgW1X5XWziG23Ko
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote:
> It is disappointing that F2Pool would enable full RBF when the safe
> alternative, first-seen-safe RBF, is also available, especially since the
> fees they would gain by supporting full RBF over FSS RBF would likely be
> negligible. Did they consider using FSS RBF instead?
Specifically the following is what I told them:
> We are
> interested in the replace-by-fee patch, but I am not following the
> development closely, more background info is needed, like what the
> difference between standard and zeroconf versions? Thanks.
Great!
Basically both let you replace one transaction with another that pays a
higher fee. First-seen-safe replace-by-fee adds the additional criteria
that all outputs of the old transaction still need to be paid by the new
transaction, with >=3D as many Bitcoins. Basically, it makes sure that if
someone was paid by tx1, then tx2 will still pay them.
I've written about how wallets can use RBF and FSS-RBF to more
efficiently use the blockchain on the bitcoin-development mailing list:
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07=
813.html
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07=
829.html
Basically, for the purpose of increasing fees, RBF is something like %50
cheaper than CPFP, and FSS-RBF is something like %25 cheaper.
In addition, for ease of implementation, my new FSS-RBF has a number of
other restrictions. For instance, you can't replace multiple
transactions with one, you can't replace a transaction whose outputs
have already been spent, you can't replace a transaction with one that
spends additional unconfirmed inputs, etc. These restrictions aren't
"set in stone", but they do make the code simpler and less likely to
have bugs.
In comparison my previous standard RBF patch can replace multiple
transactions with one, can replace long chains of transactions, etc.
It's willing to do more computation before deciding if a transaction
should be replaced, with more complex logic; it probably has a higher
chance of having a bug or DoS attack.
You've probably seen the huge controversy around zeroconf with regard to
standard replace-by-fee. While FSS RBF doesn't make zeroconf any safer,
it also doesn't make it any more dangerous, so politically with regard
to zeroconf it makes no difference. You *can* still use it doublespend
by taking advantage of how different transactions are accepted
differently, but that's true of *every* change we've ever made to
Bitcoin Core - by upgrading to v0.10 from v0.9 you've also "broken"
zeroconf in the same way.
Having said that... honestly, zeroconf is pretty broken already. Only
with pretty heroic measures like connecting to a significant fraction of
the Bitcoin network at once, as well as connecting to getblocktemplate
supporting miners to figure out what transactions are being mined, are
services having any hope of avoiding getting ripped off. For the average
user their wallets do a terrible job of showing whether or not an
unconfirmed transaction will go through. For example, Schildbach's
Bitcoin wallet for Android has no code at all to detect double-spends
until they get mined, and I've been able to trick it into showing
completely invalid transactions. In fact, currently Bitcoin XT will
relay invalid transactions that are doublepsends, and Schildbach's
wallet displays them as valid, unconfirmed, payments. It's really no
surprise to me that nearly no-one in the Bitcoin ecosystem accepts
unconfirmed transactions without some kind of protection that doesn't
rely on first-seen-safe mempool behavior. For instance, many ATM's these
days know who their customers are due to AML requirements, so while you
can deposit Bitcoins and get your funds instantly, the protection for
the ATM operator is that they can go to the police if you rip them off;
I've spoken to ATM operators who didn't do this who've lost hundreds or
even thousands of dollars before giving up on zeroconf.
My big worry with zeroconf is a service like Coinbase or Shapeshift
coming to rely on it, and then attempting to secure it by gaining
control of a majority of hashing power. For instance, if Coinbase had
contracts with 80% of the Bitcoin hashing power to guarantee their
transactions would get mined, but 20% of the hashing power didn't sign
up, then the only way to guarantee their transactions could be for the
80% to not build on blocks containing doublespends by the 20%. There's
no way in a decentralized network to come to consensus about what
transactions are or are not valid without mining itself, so you could
end up in a situation where unless you're part of one of the big pools
you can't reliably mine at all because your blocks may get rejected for
containing doublespends.
One of my goal with standard replace-by-fee is to prevent this scenario
by forcing merchants and others to implement ways of accepting zeroconf
transactions safely that work in a decentralized environment regardless
of what miners do; we have a stronger and safer Bitcoin ecosystem if
we're relying on math rather than trust to secure our zeroconf
transactions. We're also being more honest to users, who right now often
have the very wrong impression that unconfirmed transactions are safe to
accept - this does get people ripped off all too often!
Anyway, sorry for the rant! FWIW I updated my FSS-RBF patch and am
waiting to get some feedback:
https://github.com/bitcoin/bitcoin/pull/6176
Suhas Daftuar did find a pretty serious bug in it, now fixed. I'm
working on porting it to v0.10.2, and once that's done I'm going to put
up a bounty for anyone who can find a DoS attack in the patch. If no-one
claims the bounty after a week or two I think I'll start feeling
confident about using it in production.
--=20
'peter'[:-1]@petertodd.org
000000000000000003188926be14e5fbe2f8f9c63c9fb8e2ba4b14ab04f1c9ab
--vGgW1X5XWziG23Ko
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJVhByjXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwMzE4ODkyNmJlMTRlNWZiZTJmOGY5YzYzYzlmYjhlMmJh
NGIxNGFiMDRmMWM5YWIvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvtxgf/S6crLQZ5L1KHkVl7+lDTZaHW
IhitrR+OGTR1YLpFdlZB/t53k0W1q22tIsz1oMuLM+akl1WW6QX7dgUbs51wGygA
NrfU4k0nAZvlocZw1un4jMo1UajCF0XwUON9UPKCbJQvWp/ojstjdk/TTmiutrA7
+e6/Gdmu9S1Kcpq3d1lRHMJBPKqPOXQ/xEBV9R2PuNTWF9rBu3Ge7S8DCIHx0Pmx
qlCgd1DSk2uNMzUn9yJZT8Jl1JOADyKiZeujrkMc++SKxl2MmD7ch/GwUThh4qVk
X2MHf9gIO3caasSLCvdvhTLwENzdz6mZOo7xFp+3pmfnA7yV7LDWNB5eZZvq+A==
=9K2b
-----END PGP SIGNATURE-----
--vGgW1X5XWziG23Ko--
|
