Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.174 as permitted sender)
	client-ip=209.85.214.174; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f174.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CAFDyEXg8OnoYCNLT1WeX2tBPTB_zcXsZ6ujP_8YmPvGyf4pzkw@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>
	<CANEZrP3KKSkD7_R0Dvt600b7vh0oia78vHhPrPqSGBbwf9DsSQ@mail.gmail.com>
	<loom.20140616T181739-326@post.gmane.org>
	<CANEZrP3er1NVoAiVmROTxQ3TC80r7enKaHkWjOYTbKehf7qJjQ@mail.gmail.com>
	<loom.20140616T184930-521@post.gmane.org>
	<CANEZrP2fg9k9fC+QAO2GQS7VC-JCtbEjubHB9j1TJtR9vuaDSQ@mail.gmail.com>
	<loom.20140616T190550-931@post.gmane.org>
	<CALDj+Bbvvs4rkrSOndk4rbt9JGwSwF1VeFk2XPjFy7Ro4O9heg@mail.gmail.com>
	<CANEZrP384LFKaCbAL-p06FQdHHp1bqmcRs+XZDbwVXVrPRDS7g@mail.gmail.com>
	<CAFDyEXg8OnoYCNLT1WeX2tBPTB_zcXsZ6ujP_8YmPvGyf4pzkw@mail.gmail.com>
Date: Mon, 16 Jun 2014 22:32:15 +0200
Message-ID: <CANEZrP2NKG8etGtGgbkA8rPr3BqCMPmVQ-3xqiKXVOK2vf9+7w@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Daniel Rice <drice@greenmangosystems.com>
Content-Type: multipart/alternative; boundary=001a11c2dbce3674a904fbf9ecd1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Lawrence Nahum <lawrence@greenaddress.it>
Subject: Re: [Bitcoin-development] instant confirmation via payment protocol
 backwards compatible proto buffer extension
Precedence: list

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

On Mon, Jun 16, 2014 at 10:29 PM, Daniel Rice <drice@greenmangosystems.com>
wrote:

> I'm trying to think through how to encourage the maximum number of instant
> signature providers and avoid the VISA monopoly. Ideal case would be that
> people can even be their own instant provider.
>

A provider does not have to be an interactive third party. One reason I
suggested using X.509 is so secure hardware devices like the TREZOR could
also be instant providers. The hardware would be tamperproof and assert
using a secret key embedded in it that the tx came from a genuine,
unflashed TREZOR. The the server can know the device won't double spend.

In this way you have decentralised anti-double spending. Of course, it's an
old solution. MintChip sort of worked a bit like this.

--001a11c2dbce3674a904fbf9ecd1
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">On M=
on, Jun 16, 2014 at 10:29 PM, Daniel Rice <span dir=3D"ltr">&lt;<a href=3D"=
mailto:drice@greenmangosystems.com" target=3D"_blank">drice@greenmangosyste=
ms.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I&#39;m trying to thin=
k through how to encourage the maximum number of instant signature provider=
s and avoid the VISA monopoly. Ideal case would be that people can even be =
their own instant provider.</div>
</div></blockquote><div><br></div><div>A provider does not have to be an in=
teractive third party. One reason I suggested using X.509 is so secure hard=
ware devices like the TREZOR could also be instant providers. The hardware =
would be tamperproof and assert using a secret key embedded in it that the =
tx came from a genuine, unflashed TREZOR. The the server can know the devic=
e won&#39;t double spend.</div>
<div><br></div><div>In this way you have decentralised anti-double spending=
. Of course, it&#39;s an old solution. MintChip sort of worked a bit like t=
his.</div></div></div></div>

--001a11c2dbce3674a904fbf9ecd1--