Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.49 as permitted sender)
	client-ip=209.85.219.49; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f49.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CAFDyEXhY-KxM6dN0ngXiiB4ga85tD6e4gW6QVpST5XxJARLicw@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>
Date: Wed, 18 Jun 2014 18:09:44 +0200
Message-ID: <CANEZrP3AKLNZmt0YqNNp3-7uVAkaT4oM4GUfN4bPTqxycpq8zg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Daniel Rice <drice@greenmangosystems.com>
Content-Type: multipart/alternative; boundary=089e0158ac780f266d04fc1e7d51
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

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

>
> 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.

--089e0158ac780f266d04fc1e7d51
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"><div dir=3D"ltr"><div><font face=3D"arial, sans-=
serif">I think that&#39;s true if you assume that the instant provider list=
 is based on a by hand created list of accepted instant providers. That&#39=
;s how VISA works now and that&#39;s why I was asking for an approach where=
 the trusted_instant_providers list is scalable because that seems very dan=
gerous.</font></div>
</div></blockquote><div><br></div><div>Supporting it in the protocol is eas=
y. Building such a thing: that&#39;s hard. Decentralised automated reputati=
on systems are complex and subtle.=C2=A0</div><div><br></div><div>I don&#39=
;t feel strongly about whether the field should be &quot;optional&quot; or =
&quot;repeated&quot;, 100% of implementations in the forseeable future woul=
d 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&=
#39;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 on=
e, and then making that repeated.</div>
<div><br></div><div>Up to Lawrence.</div></div></div></div>

--089e0158ac780f266d04fc1e7d51--