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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1Z5zIr-00056a-Nr
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 16:38:05 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.108 as permitted sender)
client-ip=62.13.148.108; envelope-from=pete@petertodd.org;
helo=outmail148108.authsmtp.net;
Received: from outmail148108.authsmtp.net ([62.13.148.108])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Z5zIq-0008PV-HF for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 16:38:05 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5JGbpL8007205;
Fri, 19 Jun 2015 17:37:51 +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 t5JGbkA9015264
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 19 Jun 2015 17:37:49 +0100 (BST)
Date: Fri, 19 Jun 2015 12:37:46 -0400
From: Peter Todd <pete@petertodd.org>
To: Adrian Macneil <adrian@coinbase.com>
Message-ID: <20150619163745.GA26347@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>
<CAMK47c84w=2c9y8MKHTzFf05DmKXz74a=iFViA-oZ1uRDZCAWg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G"
Content-Disposition: inline
In-Reply-To: <CAMK47c84w=2c9y8MKHTzFf05DmKXz74a=iFViA-oZ1uRDZCAWg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 85dd4c04-16a1-11e5-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdwsUEkAaAgsB AmMbWlNeU1p7XWo7 bA9PbARUfEhLXhtr
VklWR1pVCwQmRRl7 cUxFIxBydgBEfno+ Z0VmWngVVEEuIUIu
QkpJFGtXZHphaTUa 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
-0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z5zIq-0008PV-HF
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:38:05 -0000
--k1lZvvs/B4yU6o8G
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jun 19, 2015 at 09:18:54AM -0700, Adrian Macneil wrote:
> >
> > > So connecting to many nodes just because we can and it's not technica=
lly
> > > prevented is bad for the network and creating systemic risks of failu=
re,
> >
> > Well it is actually; that's why myself, Wladimir van der Laan, and
> > Gregory Maxwell all specifically=B9 called Chainalysis's actions a sybil
> > 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.
> >
>=20
> 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.
Ah, seems you misunderstand the problem.
By properly we're concerned that things do get relayed, not that they do
not. In particularl with blocks a fairly to relay valid blocks will
quickly lead to a loss of consensus.
> > 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?
> >
>=20
> 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.
Right, so those dozen nodes, how many outgoing connections are they
making?
> > 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?
> >
>=20
> 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 doi=
ng
> (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.
While your goals may be reasonable, again, the question is how are you
going to achieve them? Do you accept that you may be in a position where
you can't guarantee confirmations? Again, what's your plan to deal with
this? For instance, I know Coinbase is contractually obliged to accept
zeroconf payments with at least some of your customers - how strong are
those agreements?
What we're worried about is your plan appears to include nothing
concrete beyond the possibility of getting contracts with hashing power,
maybe even just a majority of hashing power. This is something that
should concern everyone in the Bitcoin ecosystem, and it'd help if you
clearly stated what your intentions are.
--=20
'peter'[:-1]@petertodd.org
00000000000000001128683847671e0ca022f9c74df90a3dc718545379101b72
--k1lZvvs/B4yU6o8G
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJVhEVWXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwOTlmZmQzOTc5MDRhMGFkNzEwYzVhZDI3YWU5ZGZiZjg3
NTY4Y2ExMzI5MWEyNzcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfs9hggAiZnB4i7zOilQnOKpEogIPq+t
lzshbYlZJhSo+j5J+pwFiijXABJVZXin6RnVXpim6l1TV27F5fVSInVAgSIr29oH
KTy2/uwZIDuFyrwo0HWL9Nz3bkVMnwsnswAt5JQRjmoAKPZSyr37BYE4idxfjtwT
zAll/XHo2WPUMemLBnEYTAhnU2vja++IBvgywSeceVQIde0TmcY+zfuSLNZYC9ZX
FVPJ0J0Rzctqf/Tj2/wmszJ7LvE6ewDyaopoL5AyUcpo4g5OASLNhSX6MzLjoNtY
3/I2CQjhoSZeLO9lmRPJ4Q0yherhL4dKZAnCHuKQOBz1rUJgjdmTrGrMp1ZEbA==
=OWBL
-----END PGP SIGNATURE-----
--k1lZvvs/B4yU6o8G--
|
