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; 
MIME-Version: 1.0
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
Precedence: list

--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&#39;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&#39;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--