Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of
	greenmangosystems.com designates 209.85.128.176 as permitted
	sender) client-ip=209.85.128.176;
	envelope-from=drice@greenmangosystems.com;
	helo=mail-ve0-f176.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP3AKLNZmt0YqNNp3-7uVAkaT4oM4GUfN4bPTqxycpq8zg@mail.gmail.com>
References: <CAKrJrGOBSiY5V59eko6g796j3wh9V9ZLjPbyHeS5=zyX6j3Wdw@mail.gmail.com>
	<lnhgsk$va6$1@ger.gmane.org>
	<loom.20140615T111027-736@post.gmane.org>
	<lnk4ii$ehf$1@ger.gmane.org>
	<loom.20140618T140509-802@post.gmane.org>
	<CANEZrP0ekAHNOHha_8ncu_QKVCidBQndw2x0+5rciD92LdOS7A@mail.gmail.com>
	<CAFDyEXhY-KxM6dN0ngXiiB4ga85tD6e4gW6QVpST5XxJARLicw@mail.gmail.com>
	<CANEZrP3AKLNZmt0YqNNp3-7uVAkaT4oM4GUfN4bPTqxycpq8zg@mail.gmail.com>
Date: Thu, 19 Jun 2014 10:36:36 -0700
Message-ID: <CAFDyEXiS75rkMY0jQLHSDptpT5YTLACyPfO519KjgNtOe6G=nA@mail.gmail.com>
From: Daniel Rice <drice@greenmangosystems.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=089e013a219c9db10004fc33d139
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

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

> Supporting it in the protocol is easy. Building such a thing: that's
hard. Decentralised automated reputation systems are complex and subtle.

Bitcoin is valuable as a protocol because it is truly decentralized. The
complexity involved in building this system was expansive, but I think we
can all agree it was worth the trouble. With this particular topic of
instant transactions it seems we have to be very careful about pushing
Bitcoin in a centralized direction for the sake of a simple quick solution.
Building an automated system to solve the instant transaction problem will
be difficult, but also well worth the effort, and exactly like you're
saying Mike, I just want to make sure the door is left open protocol wise
for a robust solution in the future.


On Wed, Jun 18, 2014 at 9:09 AM, Mike Hearn <mike@plan99.net> wrote:

> I think that's true if you assume that the instant provider list is based
>> on a by hand created list of accepted instant providers. That's how VISA
>> works now and that's why I was asking for an approach where the
>> trusted_instant_providers list is scalable because that seems very
>> dangerous.
>>
>
> Supporting it in the protocol is easy. Building such a thing: that's hard.
> Decentralised automated reputation systems are complex and subtle.
>
> I don't feel strongly about whether the field should be "optional" or
> "repeated", 100% of implementations in the forseeable future would just
> look at the first item and ignore the rest. But if later someone did crack
> this problem it would lead to a simple upgrade path. So perhaps you're
> right and the protobuf should allow multiple signatures. It means a new
> sub-message to wrap the pki_type, pki_data and signature fields into one,
> and then making that repeated.
>
> Up to Lawrence.
>

--089e013a219c9db10004fc33d139
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"font-family:arial,sans-serif;font=
-size:13px">Supporting it in the protocol is easy. Building such a thing: t=
hat&#39;s hard. Decentralised automated reputation systems are complex and =
subtle.=C2=A0</span><div>
<span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span></di=
v><div><font face=3D"arial, sans-serif">Bitcoin is valuable as a protocol b=
ecause it is truly decentralized. The complexity involved in building this =
system was expansive, but I think we can all agree it was worth the trouble=
. With this particular topic of instant transactions it seems we have to be=
 very careful about pushing Bitcoin in a centralized direction for the sake=
 of a simple quick solution. Building an automated system to solve the inst=
ant transaction problem will be difficult, but also well worth the effort, =
and exactly like you&#39;re saying Mike, I just want to make sure the door =
is left open protocol wise for a robust solution in the future.</font></div=
>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed,=
 Jun 18, 2014 at 9:09 AM, Mike Hearn <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
 class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><font face=
=3D"arial, sans-serif">I think that&#39;s true if you assume that the insta=
nt provider list is based on a by hand created list of accepted instant pro=
viders. That&#39;s how VISA works now and that&#39;s why I was asking for a=
n approach where the trusted_instant_providers list is scalable because tha=
t seems very dangerous.</font></div>

</div></blockquote><div><br></div></div><div>Supporting it in the protocol =
is easy. Building such a thing: that&#39;s hard. Decentralised automated re=
putation systems are complex and subtle.=C2=A0</div><div><br></div><div>I d=
on&#39;t feel strongly about whether the field should be &quot;optional&quo=
t; or &quot;repeated&quot;, 100% of implementations in the forseeable futur=
e would just look at the first item and ignore the rest. But if later someo=
ne did crack this problem it would lead to a simple upgrade path. So perhap=
s you&#39;re right and the protobuf should allow multiple signatures. It me=
ans a new sub-message to wrap the pki_type, pki_data and signature fields i=
nto one, and then making that repeated.</div>

<div><br></div><div>Up to Lawrence.</div></div></div></div>
</blockquote></div><br></div>

--089e013a219c9db10004fc33d139--