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-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adrian@coinbase.com>) id 1Z5y6G-0005n2-Hq
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 15:21:00 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of coinbase.com
designates 74.125.82.41 as permitted sender)
client-ip=74.125.82.41; envelope-from=adrian@coinbase.com;
helo=mail-wg0-f41.google.com;
Received: from mail-wg0-f41.google.com ([74.125.82.41])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z5y6E-0007Sr-PS
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 15:21:00 +0000
Received: by wgfq1 with SMTP id q1so45788442wgf.1
for <bitcoin-development@lists.sourceforge.net>;
Fri, 19 Jun 2015 08:20:52 -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=5buOKqYSSZXHaii5PgW+QDjJW1sUlJKIq9MYyo3s3Vc=;
b=JIRAr09F6cmn5nBnc4Mp/LKQeFuxBfW8e7rcDmEuID/rckJQdUDMNVGA20h4DoIaMX
XylTNcMMhgAVgUJCERLB5vX6kXVA/EwmMpVTCnMcPPknKUokpUfMxibpAoSUB1NggsT0
nhzObX1JWMIR/YMjkaV+3SvEZSD0uf/YUCJYMvAN9oXv8RE7SE1TiKns2EoBI+4ItTRU
Zvxgl0pQpQ7HCpoCaqos6Uiwrd4fBaN5VyB8Lyfs8/8yrwvNSgnTkcf6Rq58NZwIvFV2
prcMirKoLEDdFjWaP4SlqcQaO7IEyXFPxFaFrwkWDN6iz4H1byYKsHVi0pntUsHjTgoY
kpzg==
X-Gm-Message-State: ALoCoQl2F5W33MKqTCZaeSG28+0BKzhNUygFAybU1zj1xkNnHEL4qSAXL+ouYpoagMraMJQF6GLL
MIME-Version: 1.0
X-Received: by 10.181.11.193 with SMTP id ek1mr7655521wid.15.1434727252728;
Fri, 19 Jun 2015 08:20:52 -0700 (PDT)
Received: by 10.27.177.99 with HTTP; Fri, 19 Jun 2015 08:20:52 -0700 (PDT)
In-Reply-To: <20150619145940.GB5695@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>
Date: Fri, 19 Jun 2015 08:20:52 -0700
Message-ID: <CAMK47c8Mc8v2C4aG=7GdAQ7ZCR2qXhfq-dktNS7bDa00RdKThw@mail.gmail.com>
From: Adrian Macneil <adrian@coinbase.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=f46d043bdeda3faf3f0518e078ec
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: 1Z5y6E-0007Sr-PS
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:21:00 -0000
--f46d043bdeda3faf3f0518e078ec
Content-Type: text/plain; charset=UTF-8
>
> 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.
>
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,
but relaying harmful double spend transactions just because you can and
it's not technically prevented, is good for everyone?
> 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.
>
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.
> 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.
>
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?
--f46d043bdeda3faf3f0518e078ec
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">Unless you're sybil attacking the network an=
d miners, consuming valuable<br>
resources and creating systemic risks of failure like we saw with<br>
Chainalysis, I don't see how you're getting "very small" =
double-spend<br>
probabilities.<br></blockquote><div><br></div><div>So connecting to many no=
des just because we can and it's not technically prevented is bad for t=
he network and creating systemic risks of failure, but relaying harmful dou=
ble spend transactions just because you can and it's not technically pr=
evented, is good for everyone?</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">You know, you're creating an interesting bit of game theory he=
re: if I'm<br>
a miner who doesn't already have a mining contract, why not implement<b=
r>
full-RBF to force Coinbase to offer me one? One reason might be because<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></blockqu=
ote><div><br></div><div>If someone did enter into contracts with miners to =
mine certain transactions, and had a guarantee that the miners would not bu=
ild on previous blocks which included double spends, then they would only n=
eed contracts with 51% of the network anyway. So it wouldn't really mat=
ter if you were a small time miner and wanted to run full-RBF.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">For the good of Bitcoin, and you=
r own company, you'd do well to firmly<br>
state that under no condition will Coinbase ever enter into mining<br>
contracts.<br></blockquote><div><br></div><div>I don't personally see w=
hat good this does for bitcoin. Now you are suggesting that we should preve=
nt a 51% attack by using policy and promises, rather than a technical solut=
ion. How is this any better than us relying on existing double spend rules =
which are based on policy and promises?</div><div><br></div></div></div></d=
iv>
--f46d043bdeda3faf3f0518e078ec--
|
