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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1YkWUa-0005RE-B1
for bitcoin-development@lists.sourceforge.net;
Tue, 21 Apr 2015 11:37:28 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.95 as permitted sender)
client-ip=62.13.149.95; envelope-from=pete@petertodd.org;
helo=outmail149095.authsmtp.com;
Received: from outmail149095.authsmtp.com ([62.13.149.95])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YkWUY-0007yI-AG for bitcoin-development@lists.sourceforge.net;
Tue, 21 Apr 2015 11:37:28 +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 t3LBbJvJ074491;
Tue, 21 Apr 2015 12:37:19 +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 t3LBbFCX046099
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Tue, 21 Apr 2015 12:37:18 +0100 (BST)
Date: Tue, 21 Apr 2015 07:37:14 -0400
From: Peter Todd <pete@petertodd.org>
To: Adrian Macneil <adrian@coinbase.com>
Message-ID: <20150421113714.GA3455@savin.petertodd.org>
References: <CANEZrP3Prp6EFUdH_VDWkq508HkeFBMn+swzZ9ycAMsrOazFZA@mail.gmail.com>
<FEB90DA4-2BF3-460F-8F35-9BCE929A2A31@petertodd.org>
<C92CBBFE-A967-457B-B356-AF85F7BE8936@coinbase.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV"
Content-Disposition: inline
In-Reply-To: <C92CBBFE-A967-457B-B356-AF85F7BE8936@coinbase.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: c4521b85-e81a-11e4-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdAMUGUUGAgsB AmMbWlZeU1p7WGs7 bA9PbARUfEhLXhtr
VklWR1pVCwQmRR99 dExoIXFycwNGcXc+ ZENnXXIVD0B/d0cv
SktJQGUHNHphaTUb TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMjkh TRQPVS43EEsJRiM8
ZxUgJhYGEV4VO04/ eVEwEVwVPnc8
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: 1YkWUY-0007yI-AG
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Double spending and 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: Tue, 21 Apr 2015 11:37:28 -0000
--HcAYCG3uE/tztfnV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Apr 08, 2015 at 11:28:08PM -0700, Adrian Macneil wrote:
> Fwiw, Coinbase relies on the current first-seen mempool behaviour. Wide a=
doption of RBF (without a suitable replacement available) would make it ext=
remely difficult to pitch bitcoin as a viable alternative to credit cards p=
ayments to large merchants.
Some questions:
1) Are you contractually obliged to accept zeroconf transactions with
existing customers?
I keep hearing rumors of this, but would like some confirmation. In
particular, it would be good to know if you have the option of turning
zeroconf off at all, contractually speaking.
2) What are your double-spend losses to date?
3) Are you actively marketing zeroconf guarantees to new customers?
You're API is a bit unclear as to what exactly those guarantees are;
looks like they only apply if a merchant has "convert to fiat" turned
on.
4) What are your short, medium, and long term plans to move away from
dependency on "first-seen" mempool policy?
e.g. hub-and-spoke payment channels, Lightning network, off-chain, etc.
5) What is your plan for new Bitcoin Core releases that break zeroconf
via changed tx acceptance rules?
Basically every release we've ever made has added a zeroconf exploit due
to different tx acceptance rules. (e.g. my 95% success rate last summer)
6) What are your plans for Bitcoin Core releases that fundementally
break zeroconf?
For instance changes like limiting the mempool size create zeroconf
vulnerabilities that can't be avoided in many situations. Yet they may
also be unavoidably needed for, for instance, DoS protection. Will you
oppose these improvements?
7) If a mining pool adopts adopted policy that broke zeroconf, e.g.
replace-by-fee, would you take any action?
8) Would you take legal action against a mining pool for adopting
replace-by-fee publicly?
9) Would you take action against a mining pool who is mining
double-spends without explanation?
e.g. one that claims not to be running non-Bitcoin Core policy, but
keeps on mining double-spends.
--=20
'peter'[:-1]@petertodd.org
0000000000000000089abd68efc18c03d2a294295f3706a13966613a3ff3b390
--HcAYCG3uE/tztfnV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJVNjZlXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwM2EwNjM1MzE5OGViYTYyMzc2NmE3MTE2NmRlOWQ2MjE2
ZTFlYjRiYWQ4ZDYyZmMvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftypwf/bMkA7nzKa/telOR4yjgK0/nJ
I/9i1lpTyRmylLXP2jsPdk54qZ0RHFO9NnMiCz42Cbp7APuubuBhxSLknQsPgYtK
YL2bgJJFNBDCV0dXha6anmhfyVZh3OYbZ8pylBJthKRfS2oYom4gCyroPppAlh7/
gVZkKwxOb4SBLPw6NlO5q52UmMvJSzXmN4J4uSOsM/CdRGt3EzkWpMJVW7LiaJ3R
MHA8NJQCnOOlYkEGZAALgJYnYbB//2NfUthv21p68cnOLA84RObci/pg0WNJxgm6
z2EdivpzPVyDHjo/cgiptpcQK9zsM04H27i85qjGDli2jBDJKvwpL8I0nX0QEw==
=lNZQ
-----END PGP SIGNATURE-----
--HcAYCG3uE/tztfnV--
|
