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-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1Z5yPo-0002ji-IC
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 15:41:12 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.114 as permitted sender)
client-ip=62.13.148.114; envelope-from=pete@petertodd.org;
helo=outmail148114.authsmtp.net;
Received: from outmail148114.authsmtp.net ([62.13.148.114])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Z5yPm-0005cB-G5 for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 15:41:12 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt16.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5JFf0RC080567;
Fri, 19 Jun 2015 16:41:00 +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 t5JFetID050527
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 19 Jun 2015 16:40:57 +0100 (BST)
Date: Fri, 19 Jun 2015 11:40:54 -0400
From: Peter Todd <pete@petertodd.org>
To: Adrian Macneil <adrian@coinbase.com>
Message-ID: <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ"
Content-Disposition: inline
In-Reply-To: <CAMK47c8Mc8v2C4aG=7GdAQ7ZCR2qXhfq-dktNS7bDa00RdKThw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 947f5631-1699-11e5-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdwsUEkAaAgsB AmMbWlJeVF17XGs7 bA9PbARUfEhLXhtr
VklWR1pVCwQmRRl7 cEtaK21ycgVDenk+ Z0VlXHgVVUB9I0N7
QU9JFGsPbHphaTUa TUkOcAdJcANIexZF O1F8UScOLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMGQE QBcGVTUmBgUIQSw5
KxEqYlABGEJZKEgq NVIqVBcSIlocBwA2
X-Authentic-SMTP: 61633532353630.1024: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: 1Z5yPm-0005cB-G5
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 15:41:12 -0000
--mP3DRpeJDSE+ciuQ
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jun 19, 2015 at 08:20:52AM -0700, Adrian Macneil wrote:
> >
> > Unless you're sybil attacking the network and miners, consuming valuable
> > resources and creating systemic risks of failure like we saw with
> > Chainalysis, I don't see how you're getting "very small" double-spend
> > probabilities.
> >
>=20
> So connecting to many nodes just because we can and it's not technically
> 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=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.
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?
> but relaying harmful double spend transactions just because you can and
> it's not technically prevented, is good for everyone?
You realise that Hearn/Andresen/Harding's double-spend-relaying patch,
included in Bitcoin XT, relays double-spend transactions right? Do you
consider that harmful?
> > 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 because
> > other miners with such a contract - a majority - are going to be asked
> > by Coinbase to reorg you out of the blockchain, but then we have a
> > situation where a single entity has control of the blockchain.
> >
>=20
> 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?
> > For the good of Bitcoin, and your own company, you'd do well to firmly
> > state that under no condition will Coinbase ever enter into mining
> > contracts.
> >
>=20
> I don't personally see what good this does for bitcoin. Now you are
> suggesting that we should prevent a 51% attack by using policy and
> promises, rather than a technical solution. How is this any better than us
> relying on existing double spend rules which are based on policy and
> promises?
Well, I think I've shown how dangerous mining contracts can be to the
overall health of the Bitcoin ecosystem; I'm simply asking you to
promise not to make use of this dangerous option regardless of what
happens. Like I said, if for whatever reason the first-seen mempool
behavior proves to be insufficient at preventing double-spends from your
perspective, you did suggest you might use mining contracts to ensure
txs you want mined get mined, over others.
1) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network",
March 14th 2015, Grace Caffyn, Coindesk,
http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on=
-bitcoin-network/
--=20
'peter'[:-1]@petertodd.org
00000000000000000e806870e7e9cf4d507af6b78fc709e6839a8d34b52ea334
--mP3DRpeJDSE+ciuQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJVhDgCXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwZTgwNjg3MGU3ZTljZjRkNTA3YWY2Yjc4ZmM3MDllNjgz
OWE4ZDM0YjUyZWEzMzQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvKpgf/R/1zLQTrnuULURDdeISm2KMd
aHXLl7J5SZQSgjbYCQsuv/q4cap9k6hQgpwdUS2L0vG2t+O3/3udlxGpeSQkd5bi
mp/1G56SKTyXdYaFRBzHvda06RYF6fs2SHPqvMW+Cytj2lHQ6M1APlTmGWplatHm
MBkSf8rDHxwkK3Cj0ckILmHF0E6/hDgj6g8ZT4BNP3OLVksbEEzVA3L6fm73lTFV
K+1XAofdIyHv23/sDKrbN+z6ycBEchzOENXdA4AdOiLHtLzoB9995sAUkoenRg98
Dh7u6bQB4vmx76ur9QQB7mNNmpFMU5BovjlaXCTOY/LCZm7V839vTdAvowZ5Nw==
=hLqt
-----END PGP SIGNATURE-----
--mP3DRpeJDSE+ciuQ--
|
