Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.179 as permitted sender)
	client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f179.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CADE3-jA8LizD8cjdqKm0pFc8OV7JqPBGhs4uvp6=VhEU2emV6w@mail.gmail.com>
References: <CAKrJrGOBSiY5V59eko6g796j3wh9V9ZLjPbyHeS5=zyX6j3Wdw@mail.gmail.com>
	<CANEZrP0Euc1mPhRc9e41tU4zMDrWesvVyiBpAPq6M3m7K=aU=A@mail.gmail.com>
	<CAFDyEXgKpbE4WGAqROJ4J1UST=tXWgfn7uKhRO_tngJfVK_Czw@mail.gmail.com>
	<CADE3-jA8LizD8cjdqKm0pFc8OV7JqPBGhs4uvp6=VhEU2emV6w@mail.gmail.com>
Date: Mon, 16 Jun 2014 17:48:28 +0200
Message-ID: <CANEZrP3KKSkD7_R0Dvt600b7vh0oia78vHhPrPqSGBbwf9DsSQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Paul Goldstein <paul@realfoot.com>
Content-Type: multipart/alternative; boundary=001a11c2f644594a3b04fbf5f53f
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] instant confirmation via payment protocol
 backwards compatible proto buffer extension
Precedence: list

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

>
> Mike Hearn, why don't we just have all nodes report attempted double
> spends through the node network.
>

Please see https://github.com/bitcoin/bitcoin/pull/3883 which implements
this exact scheme. It can solve some kinds of double spends (probably), but
others - like ones done by corrupt miners (see bitundo) - can't be solved
this way.

Lawrence's motivation for this BIP is essentially to act as a backup in
case the Bitcoin native double spending protections end up being too weak
to be useful. It reintroduces a notion of centralised trust as a layer on
top of the Bitcoin protocol, but only for cases where the seller/recipient
feels it'd be useful. In this way it gives us slack: if someone is able to
reliably double spend and the merchants losses due to payment fraud go up,
we can fall back to TTPs for a while until someone finds a solution for
Bitcoin, or we just give up on the Bitcoin experiment, but hey - at least
we now have a better intermediary protocol than SWIFT :-)

In practice of course this is something payment processors like Bitpay and
Coinbase will think about. Individual cafes etc who are just using mobile
wallets won't be able to deal with this complexity: if we can't make native
Bitcoin work well enough there, we're most likely to just lose that market
or watch it become entirely centralised around a handful of payment
processing companies.

--001a11c2f644594a3b04fbf5f53f
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:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">
<div dir=3D"ltr">Mike Hearn, why don&#39;t we just have all nodes report at=
tempted double spends through the node network.</div></blockquote><div><br>=
</div><div>Please see <a href=3D"https://github.com/bitcoin/bitcoin/pull/38=
83">https://github.com/bitcoin/bitcoin/pull/3883</a> which implements this =
exact scheme. It can solve some kinds of double spends (probably), but othe=
rs - like ones done by corrupt miners (see bitundo) - can&#39;t be solved t=
his way.</div>
<div><br></div><div>Lawrence&#39;s motivation for this BIP is essentially t=
o act as a backup in case the Bitcoin native double spending protections en=
d up being too weak to be useful. It reintroduces a notion of centralised t=
rust as a layer on top of the Bitcoin protocol, but only for cases where th=
e seller/recipient feels it&#39;d be useful. In this way it gives us slack:=
 if someone is able to reliably double spend and the merchants losses due t=
o payment fraud go up, we can fall back to TTPs for a while until someone f=
inds a solution for Bitcoin, or we just give up on the Bitcoin experiment, =
but hey - at least we now have a better intermediary protocol than SWIFT :-=
)</div>
<div><br></div><div>In practice of course this is something payment process=
ors like Bitpay and Coinbase will think about. Individual cafes etc who are=
 just using mobile wallets won&#39;t be able to deal with this complexity: =
if we can&#39;t make native Bitcoin work well enough there, we&#39;re most =
likely to just lose that market or watch it become entirely centralised aro=
und a handful of payment processing companies.</div>
<div><br></div><div><br></div></div></div></div>

--001a11c2f644594a3b04fbf5f53f--