1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <drice@greenmangosystems.com>) id 1WxgGT-0007Gi-7I
for bitcoin-development@lists.sourceforge.net;
Thu, 19 Jun 2014 17:36:45 +0000
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;
Received: from mail-ve0-f176.google.com ([209.85.128.176])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WxgGR-0002kP-CA
for bitcoin-development@lists.sourceforge.net;
Thu, 19 Jun 2014 17:36:45 +0000
Received: by mail-ve0-f176.google.com with SMTP id db12so2599443veb.21
for <bitcoin-development@lists.sourceforge.net>;
Thu, 19 Jun 2014 10:36:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=2/BmW19mDy/+9ggBdEh3sc+CqvBgQmTO67PraHBXsVE=;
b=Ge0S1jQnEywNApWiTH4ZPJ7s79wJIph7MQUkDOhRHSEULrZE6B+IVTuiHAmReTCaWx
/7Bn7sqGJiRu7YYErZ+OyUEpJrzw2OcBMSlFgK1cMAW5xxoMW35ocTbGNuxWQLhIKcGQ
Hu2sV/pV5QLH09l6KTYFqF8+pf+XcjVQA+pMVb9DfZ13+1SfbJHf+sr35vbBRXqsXySB
9aCtY/u6Upirx50EgBkvLXuhlfOMDlbDR/ozes66HOqxRhbLXjy1Hdm1aZr4ysfO0jVQ
f8H8jzUDyES98J2zhMVc83bM5w2O4Snm9MQUFybhzALDzEwLk/Ebq5NltUps4AgmM8dO
BlBA==
X-Gm-Message-State: ALoCoQnjpjy/edkvkLPfU3SoAMWeOcdgEDUeIedyomf6VE/sbRsS2oNi7KAKmrt7n+AOSCuOinkm
MIME-Version: 1.0
X-Received: by 10.52.191.68 with SMTP id gw4mr1311479vdc.65.1403199397140;
Thu, 19 Jun 2014 10:36:37 -0700 (PDT)
Received: by 10.58.123.35 with HTTP; Thu, 19 Jun 2014 10:36:36 -0700 (PDT)
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
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WxgGR-0002kP-CA
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
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 19 Jun 2014 17:36:45 -0000
--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">>=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'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'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"><<a href=3D"mailt=
o:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>></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'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's how VISA works now and that'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's hard. Decentralised automated re=
putation systems are complex and subtle.=C2=A0</div><div><br></div><div>I d=
on't feel strongly about whether the field should be "optional&quo=
t; or "repeated", 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'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--
|
