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
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adrian@coinbase.com>) id 1Z5z0P-0008V7-Fy
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 16:19:01 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of coinbase.com
designates 209.85.212.180 as permitted sender)
client-ip=209.85.212.180; envelope-from=adrian@coinbase.com;
helo=mail-wi0-f180.google.com;
Received: from mail-wi0-f180.google.com ([209.85.212.180])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z5z0O-0007pn-5c
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 16:19:01 +0000
Received: by wicgi11 with SMTP id gi11so23287672wic.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 19 Jun 2015 09:18:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=evtEqBQcX35ExB298q+Ewt6yWO1S53xmSkSe12+pATs=;
b=MKY4S72eu/eajIaIz/9J7nKPBev8LPWaatt7SJxabz/4NpvwU2Xgnt9hXdjggZvpbK
VQolZ6SHuyY/ShjSAJOZUr9O71FhPHnIlUIEnQYo7ftngjJZXP1Xbmt+sYkzAx+OQniJ
IlFFA9+3toS1qTkF4j03QKdM8SM38MS5iegJnUCNBCsADPmiKXzQsJcuFWqP9EMn0qYE
7i62NbmqWNaeHNXvIRX05sM/r+F+lth69vt/LmdYffRfWgoG0VJHv2c/gQnGgStVcQYG
SFZxTpX/wlaalMcLpBMS+lsf0Azu3KYkKWgijYJ/mst6R/Ez/Twb0xqo32mCIkNedvBt
Hirg==
X-Gm-Message-State: ALoCoQnSWNSt3ZrRogaY0fFJqEf6+7jiLsEBv/m83bkfqwL8pG6cnTQlGFo1maTU0ofjqHCaVvDY
MIME-Version: 1.0
X-Received: by 10.180.94.35 with SMTP id cz3mr8181562wib.85.1434730734127;
Fri, 19 Jun 2015 09:18:54 -0700 (PDT)
Received: by 10.27.177.99 with HTTP; Fri, 19 Jun 2015 09:18:54 -0700 (PDT)
In-Reply-To: <20150619154054.GA13498@savin.petertodd.org>
References: <20150619103959.GA32315@savin.petertodd.org>
<CABsx9T1pnT=Tty3+tg+EUphLwQrWXf9EEwUOGuyNcdu=4wAqTg@mail.gmail.com>
<20150619135245.GB28875@savin.petertodd.org>
<CAMK47c_kCgb6hEUf_JePAC_tBK8aCF1W4f1guiAah-Gj_cFfSw@mail.gmail.com>
<20150619140815.GA32470@savin.petertodd.org>
<CAMK47c9NhX2gzCioTycEPXqyYeKRM9XgXuW9MGyj=OdGsKVbFg@mail.gmail.com>
<20150619145940.GB5695@savin.petertodd.org>
<CAMK47c8Mc8v2C4aG=7GdAQ7ZCR2qXhfq-dktNS7bDa00RdKThw@mail.gmail.com>
<20150619154054.GA13498@savin.petertodd.org>
Date: Fri, 19 Jun 2015 09:18:54 -0700
Message-ID: <CAMK47c84w=2c9y8MKHTzFf05DmKXz74a=iFViA-oZ1uRDZCAWg@mail.gmail.com>
From: Adrian Macneil <adrian@coinbase.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=f46d0442724ec1a4600518e14791
X-Spam-Score: -0.6 (/)
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
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Z5z0O-0007pn-5c
Cc: Bitcoin Dev <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 16:19:01 -0000
--f46d0442724ec1a4600518e14791
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
>
> > So connecting to many nodes just because we can and it's not technicall=
y
> > prevented is bad for the network and creating systemic risks of failure=
,
>
> Well it is actually; that's why myself, Wladimir van der Laan, and
> Gregory Maxwell all specifically=C2=B9 called Chainalysis's actions a syb=
il
> attack.
>
> The Bitcoin P2P network is resilliant to failure when the chance of any
> one node going down is uncorrelated with others. For instance if you
> accidentally introduced a bug in your nodes that failed to relay
> transactions/blocks properly, you'd simultaneously be disrupting a large
> portion of the network all at once.
>
This is exactly what your RBF patch is doing. By your own logic, nodes on
the network should be allowed to relay (or not relay) whatever they wish.
> How many nodes is Coinbase connecting too? What software are they
> running? What subnets are they using? In particular, are they all on one
> subnet or multiple?
>
We're running about a dozen nodes running regular Bitcoin Core in various
subnets. We aren't doing anything particularly out of the ordinary here.
Nothing that would fall under your definition of a sybil attack or harmful
to the network.
> > You know, you're creating an interesting bit of game theory here: if I'=
m
> > > a miner who doesn't already have a mining contract, why not implement
> > > full-RBF to force Coinbase to offer me one? One reason might be becau=
se
> > > other miners with such a contract - a majority - are going to be aske=
d
> > > by Coinbase to reorg you out of the blockchain, but then we have a
> > > situation where a single entity has control of the blockchain.
> > >
> >
> > If someone did enter into contracts with miners to mine certain
> > transactions, and had a guarantee that the miners would not build on
> > previous blocks which included double spends, then they would only need
> > contracts with 51% of the network anyway. So it wouldn't really matter =
if
> > you were a small time miner and wanted to run full-RBF.
>
> But of course, you'd never 51% the network right? After all it's not
> possible to guarantee that your miner won't mine double-spends, as there
> is no single consensus definition of which transaction came first, nor
> can there be.
>
> Or do you see things differently? If I'm a small miner should I be
> worried my blocks might be rejected by the majority with hashing power
> contracts because I'm unable to predict which transactions Coinbase
> believes should go in the blockchain?
>
You seem so concerned that we are actively trying to harm or control the
network. We're simply trying to drive bitcoin adoption by making it easy
for people to spend their bitcoin with merchants online. The problems we
face are no different from other merchant processors, or small independent
merchants accepting online or point-of-sale payments.
We've historically had relatively little interest in what miners were doing
(until RBF came out) - for the most part it didn't affect our business.
However, most large merchants would be simply uninterested in accepting
bitcoin if we forced their customers to wait 10-60 minutes for their
payments to confirm. Many have inventory management systems which can not
even place items on hold that long.
If full-RBF sees any significant adoption by miners, then it will actively
harm bitcoin adoption by reducing or removing the ability for online or POS
merchants to accept bitcoin payments at all. I do not see a single benefit
to running full-RBF.
FWIW, I'm fine with the first-seen-safe RBF, that seems like a sensible
addition and a good way to allow fees to be added or increased on existing
transactions, without harming existing applications of bitcoin.
Adrian
--f46d0442724ec1a4600518e14791
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><span class=3D"">> So connecting to many node=
s just because we can and it's not technically<br>
> prevented is bad for the network and creating systemic risks of failur=
e,<br>
<br>
</span>Well it is actually; that's why myself, Wladimir van der Laan, a=
nd<br>
Gregory Maxwell all specifically=C2=B9 called Chainalysis's actions a s=
ybil<br>
attack.<br>
<br>
The Bitcoin P2P network is resilliant to failure when the chance of any<br>
one node going down is uncorrelated with others. For instance if you<br>
accidentally introduced a bug in your nodes that failed to relay<br>
transactions/blocks properly, you'd simultaneously be disrupting a larg=
e<br>
portion of the network all at once.<br></blockquote><div><br></div><div>Thi=
s is exactly what your RBF patch is doing. By your own logic, nodes on the =
network should be allowed to relay (or not relay) whatever they wish.</div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">How many nodes is Coinbase =
connecting too? What software are they<br>
running? What subnets are they using? In particular, are they all on one<br=
>
subnet or multiple?<br></blockquote><div><br></div><div>We're running a=
bout a dozen nodes running regular Bitcoin Core in various subnets. We aren=
't doing anything particularly out of the ordinary here. Nothing that w=
ould fall under your definition of a sybil attack or harmful to the network=
.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">> =
> You know, you're creating an interesting bit of game theory here: =
if I'm<br>
> > a miner who doesn't already have a mining contract, why not i=
mplement<br>
> > full-RBF to force Coinbase to offer me one? One reason might be b=
ecause<br>
> > other miners with such a contract - a majority - are going to be =
asked<br>
> > by Coinbase to reorg you out of the blockchain, but then we have =
a<br>
> > situation where a single entity has control of the blockchain.<br=
>
> ><br>
><br>
> If someone did enter into contracts with miners to mine certain<br>
> transactions, and had a guarantee that the miners would not build on<b=
r>
> previous blocks which included double spends, then they would only nee=
d<br>
> contracts with 51% of the network anyway. So it wouldn't really ma=
tter if<br>
> you were a small time miner and wanted to run full-RBF.<br>
<br>
</span>But of course, you'd never 51% the network right? After all it&#=
39;s not<br>
possible to guarantee that your miner won't mine double-spends, as ther=
e<br>
is no single consensus definition of which transaction came first, nor<br>
can there be.<br>
<br>
Or do you see things differently? If I'm a small miner should I be<br>
worried my blocks might be rejected by the majority with hashing power<br>
contracts because I'm unable to predict which transactions Coinbase<br>
believes should go in the blockchain?<br></blockquote><div><br></div><div>Y=
ou seem so concerned that we are actively trying to harm or control the net=
work. We're simply trying to drive bitcoin adoption by making it easy f=
or people to spend their bitcoin with merchants online. The problems we fac=
e are no different from other merchant processors, or small independent mer=
chants accepting online or point-of-sale payments.</div><div><br></div><div=
>We've historically had relatively little interest in what miners were =
doing (until RBF came out) - for the most part it didn't affect our bus=
iness. However, most large merchants would be simply uninterested in accept=
ing bitcoin if we forced their customers to wait 10-60 minutes for their pa=
yments to confirm. Many have inventory management systems which can not eve=
n place items on hold that long.</div><div><br></div><div>If full-RBF sees =
any significant adoption by miners, then it will actively harm bitcoin adop=
tion by reducing or removing the ability for online or POS merchants to acc=
ept bitcoin payments at all. I do not see a single benefit to running full-=
RBF.<br></div><div><br></div><div>FWIW, I'm fine with the first-seen-sa=
fe RBF, that seems like a sensible addition and a good way to allow fees to=
be added or increased on existing transactions, without harming existing a=
pplications of bitcoin.</div><div><br></div><div>Adrian</div><div><br></div=
></div></div></div>
--f46d0442724ec1a4600518e14791--
|
