Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of coinbase.com
	designates 209.85.212.175 as permitted sender)
	client-ip=209.85.212.175; envelope-from=adrian@coinbase.com;
	helo=mail-wi0-f175.google.com; 
MIME-Version: 1.0
In-Reply-To: <20150619140815.GA32470@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>
Date: Fri, 19 Jun 2015 07:30:17 -0700
Message-ID: <CAMK47c9NhX2gzCioTycEPXqyYeKRM9XgXuW9MGyj=OdGsKVbFg@mail.gmail.com>
From: Adrian Macneil <adrian@coinbase.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=e89a8f64701d50f0620518dfc3be
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
Precedence: list

--e89a8f64701d50f0620518dfc3be
Content-Type: text/plain; charset=UTF-8

>
> > 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.
>
> What happens if the mining pools who are mining double-spends aren't
> doing it delibrately? Sybil attacking pools appears to have been done
> before to get double-spends though, equally there are many other changes
> the reduce the reliability of transaction confirmations. For instance
> the higher demands on bandwidth of a higher blocksize will inevitably
> reduce the syncronicity of mempools, resulting in double-spend
> opportunities. Similarly many proposals to limit mempool size allow
> zeroconf double-spends.
>
> In that case would you enter into such contracts?
>

We take it as it comes.

Currently, it's perfectly possible to accept zeroconf transactions with
only a very small chance of double spend. As long as it's only possible to
double spend a small fraction of the time, it's an acceptable cost to us in
exchange for being able to provide a fast checkout experience to customers
and merchants.

If the status quo changes, then we will need to investigate alternatives
(which realistically would include mining contracts, or only accepting
instant payments from other trusted hosted wallets, which would be a net
loss for decentralization).

Long term we would prefer to see an open, decentralized solution, such as
payment channels / green addresses / lightening networks. However, I think
as a community we are a long way away from choosing a standard here and
implementing it across all popular wallet software and merchant processors.

Adrian

--e89a8f64701d50f0620518dfc3be
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"><span class=3D"">&gt; We have no contracts in pl=
ace or plans to do this that I am aware of.<br>
&gt;<br>
&gt; However, we do rely pretty heavily on zeroconf transactions for mercha=
nt<br>
&gt; processing, so if any significant portion of the mining pools started<=
br>
&gt; running your unsafe RBF patch, then we would probably need to look int=
o<br>
&gt; this as a way to prevent fraud.<br>
<br>
</span>What happens if the mining pools who are mining double-spends aren&#=
39;t<br>
doing it delibrately? Sybil attacking pools appears to have been done<br>
before to get double-spends though, equally there are many other changes<br=
>
the reduce the reliability of transaction confirmations. For instance<br>
the higher demands on bandwidth of a higher blocksize will inevitably<br>
reduce the syncronicity of mempools, resulting in double-spend<br>
opportunities. Similarly many proposals to limit mempool size allow<br>
zeroconf double-spends.<br>
<br>
In that case would you enter into such contracts?<br></blockquote><div><br>=
</div><div>We take it as it comes.</div><div><br></div><div>Currently, it&#=
39;s perfectly possible to accept zeroconf transactions with only a very sm=
all chance of double spend. As long as it&#39;s only possible to double spe=
nd a small fraction of the time, it&#39;s an acceptable cost to us in excha=
nge for being able to provide a fast checkout experience to customers and m=
erchants.</div><div><br></div><div>If the status quo changes, then we will =
need to investigate alternatives (which realistically would include mining =
contracts, or only accepting instant payments from other trusted hosted wal=
lets, which would be a net loss for decentralization).</div><div><br></div>=
<div>Long term we would prefer to see an open, decentralized solution, such=
 as payment channels / green addresses / lightening networks. However, I th=
ink as a community we are a long way away from choosing a standard here and=
 implementing it across all popular wallet software and merchant processors=
.</div><div><br></div><div>Adrian</div></div></div></div>

--e89a8f64701d50f0620518dfc3be--