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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adrian@coinbase.com>) id 1Z5wqy-0000Qp-6M
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 14:01:08 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of coinbase.com
designates 209.85.212.169 as permitted sender)
client-ip=209.85.212.169; envelope-from=adrian@coinbase.com;
helo=mail-wi0-f169.google.com;
Received: from mail-wi0-f169.google.com ([209.85.212.169])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z5wqs-0003gn-8j
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 14:01:08 +0000
Received: by wibdq8 with SMTP id dq8so19584170wib.1
for <bitcoin-development@lists.sourceforge.net>;
Fri, 19 Jun 2015 07:00:56 -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=4rbbCWubBPe9fOja2fxraq/PET2TeYqO+67KahTaFog=;
b=kXujNUQgUmz6ujWP8/5uq6MGNh0OORMZch7c1iaBiT5PlH5osiCEX1Aahh2J1WqH8s
fhng0O4cp5MlypNLN6HUJgsOdpGowxo/bxKjdC0ntQEP+P4UhMfSy3eAwSqFI5ONyY//
osgRJegKHvhZfkxPvaAcx//V+0uvyM8ln2WYdfRd4WJXYsbc9dioyemkF4KOrEudtrSB
lN4G+B5jgrr8RfCxtr7XCTih7FEl0nNLr6UcudqoZo02nEdmsbuINpLiayFaqYbU4h0D
EcnIQZPwBGJidXNbo7wMwFlR0bn/fAqIp/G8Ob/AUkB4M0sPO4CdjQauSJADzKLDCf2i
acIg==
X-Gm-Message-State: ALoCoQls7112M7XhHIYiLD63wNK6+BVytt1PiS4YNWrBQvr2qM1oKfdRhbJgrTxeMH+8jRDtQlnb
MIME-Version: 1.0
X-Received: by 10.194.187.170 with SMTP id ft10mr26126044wjc.26.1434722456259;
Fri, 19 Jun 2015 07:00:56 -0700 (PDT)
Received: by 10.27.177.99 with HTTP; Fri, 19 Jun 2015 07:00:56 -0700 (PDT)
In-Reply-To: <20150619135245.GB28875@savin.petertodd.org>
References: <20150619103959.GA32315@savin.petertodd.org>
<CABsx9T1pnT=Tty3+tg+EUphLwQrWXf9EEwUOGuyNcdu=4wAqTg@mail.gmail.com>
<20150619135245.GB28875@savin.petertodd.org>
Date: Fri, 19 Jun 2015 07:00:56 -0700
Message-ID: <CAMK47c_kCgb6hEUf_JePAC_tBK8aCF1W4f1guiAah-Gj_cFfSw@mail.gmail.com>
From: Adrian Macneil <adrian@coinbase.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=047d7bb03a925b66f20518df5a25
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: 1Z5wqs-0003gn-8j
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 14:01:08 -0000
--047d7bb03a925b66f20518df5a25
Content-Type: text/plain; charset=UTF-8
>
> For instance, if Coinbase had
> contracts with 80% of the Bitcoin hashing power to guarantee their
> transactions would get mined, but 20% of the hashing power didn't sign
> up, then the only way to guarantee their transactions could be for the
> 80% to not build on blocks containing doublespends by the 20%.
>
This seems to be more of a problem with centralized mining than zeroconf
transactions.
Speaking of, could we get a confirmation that Coinbase is, or is not,
> one of the merchant service providers trying to get hashing power
> contracts with mining pools for guaranteed transaction acceptance? IIRC
> you are still an advisor to them. This is a serious concern for the
> reasons I outlined in my post.
>
We have no contracts in place or plans to do this that I am aware of.
However, we do rely pretty heavily on zeroconf transactions for merchant
processing, so if any significant portion of the mining pools started
running your unsafe RBF patch, then we would probably need to look into
this as a way to prevent fraud.
In the long term, I would love to see a safe, decentralized solution for
accepting zeroconf transactions. However, right now there is no such
solution supported by any wallets in use, and I don't think breaking the
current bitcoin behavior for everyone is the best way to achieve this.
Adrian
--047d7bb03a925b66f20518df5a25
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">For instance, if Coinbase had<br>contract=
s with 80% of the Bitcoin hashing power to guarantee their<br>transactions =
would get mined, but 20% of the hashing power didn't sign<br>up, then t=
he only way to guarantee their transactions could be for the<br>80% to not =
build on blocks containing doublespends by the 20%.<br></blockquote><div>=
=C2=A0</div><div>This seems to be more of a problem with centralized mining=
than zeroconf transactions.</div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">Speaking of, could we get a=
confirmation that Coinbase is, or is not,<br>
one of the merchant service providers trying to get hashing power<br>
contracts with mining pools for guaranteed transaction acceptance? IIRC<br>
you are still an advisor to them. This is a serious concern for the<br>
reasons I outlined in my post.<br></blockquote><div><br></div><div>We have =
no contracts in place or plans to do this that I am aware of.</div><div><br=
></div><div>However, we do rely pretty heavily on zeroconf transactions for=
merchant processing, so if any significant portion of the mining pools sta=
rted running your unsafe RBF patch, then we would probably need to look int=
o this as a way to prevent fraud.</div><div><br></div><div>In the long term=
, I would love to see a safe, decentralized solution for accepting zeroconf=
transactions. However, right now there is no such solution supported by an=
y wallets in use, and I don't think breaking the current bitcoin behavi=
or for everyone is the best way to achieve this.</div><div><br></div><div>A=
drian</div><div><br></div></div></div></div>
--047d7bb03a925b66f20518df5a25--
|
