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
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <drice@greenmangosystems.com>) id 1WwdXW-0000CK-VZ
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 20:30:03 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of
greenmangosystems.com designates 209.85.220.176 as permitted
sender) client-ip=209.85.220.176;
envelope-from=drice@greenmangosystems.com;
helo=mail-vc0-f176.google.com;
Received: from mail-vc0-f176.google.com ([209.85.220.176])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WwdXU-0002Vg-Ry
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 20:30:02 +0000
Received: by mail-vc0-f176.google.com with SMTP id ik5so5401080vcb.7
for <bitcoin-development@lists.sourceforge.net>;
Mon, 16 Jun 2014 13:29:54 -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=Wchs0fLdy4AxEuAwdTpKp7gyeZfffMvgfoO0PrS09Sw=;
b=DgUH+3K/a/Ut3iNVivgxH76D3sjJYkNUBPm8tNhnlrENzHO6OCVngDKX8aLf1Ccvim
uqfgkv/dI8Om4aWmdX65EDq0W5eF0mpfOg/NoirkJor3OgjcZOihUMXHDezpyYCtB3IU
Xv7b249D5Cs0VgnzGoCULbXLHkud97+aOS7/W9T5DaFS8nXSVvGfGJ77qg6BZ0Z3Y5oe
CFBhiPtXBmADbR/Dfz/oqTeZLMJ7omQ/6w/5gxyYzoGXJ1B/KQA5CPj+ZF39Ot/BTqfV
CZEiAfXkMqk28jBJZUxOr8D+0QYES/dfW1EpjpkPGYtnOA3tQvaj6U1EH7cgmmx0Ucrs
lYJg==
X-Gm-Message-State: ALoCoQm7gRDTGZ96SEXz8J+3V2nHEYqqlKyQn7YcwAaU8f5DqCRjx+Ar6X6xYF8dNRVRuP7QRzY7
MIME-Version: 1.0
X-Received: by 10.58.236.170 with SMTP id uv10mr3288356vec.31.1402950594537;
Mon, 16 Jun 2014 13:29:54 -0700 (PDT)
Received: by 10.58.123.35 with HTTP; Mon, 16 Jun 2014 13:29:54 -0700 (PDT)
In-Reply-To: <CANEZrP384LFKaCbAL-p06FQdHHp1bqmcRs+XZDbwVXVrPRDS7g@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>
Date: Mon, 16 Jun 2014 13:29:54 -0700
Message-ID: <CAFDyEXg8OnoYCNLT1WeX2tBPTB_zcXsZ6ujP_8YmPvGyf4pzkw@mail.gmail.com>
From: Daniel Rice <drice@greenmangosystems.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=047d7bdc1a9cd34a9004fbf9e33a
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: 1WwdXU-0002Vg-Ry
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: Mon, 16 Jun 2014 20:30:03 -0000
--047d7bdc1a9cd34a9004fbf9e33a
Content-Type: text/plain; charset=UTF-8
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.
What if the protocol allowed multiple instant signatures on a transaction?
Would it encourage more instant providers? For example, a new instant
provider could bootstrap their own trust by paying an already trusted
instant provider to co-sign the same transaction. This would be useful in
the case that a new company tries to release a new wallet once the trust
ring is already established. Nobody will use that wallet because it does
not have the trusted history to do instant transactions, but if they can
pay a small amount per transaction to a third party to cosign, they can
build trust in their own signature till they can eventually have enough
trust on their own. This could be how an individual user could grow trust
in their own instant signature as well.
On Mon, Jun 16, 2014 at 11:09 AM, Mike Hearn <mike@plan99.net> wrote:
> I think many of us feel it'd be better if this kind of thing were not
> needed at all, however, the best way to ensure it doesn't end up being used
> is to write code, not to try and block alternative approaches. If Bitcoin
> is robust the market should sort it out. If it's robust for some
> transactions and not others, that makes for a fun project for a future
> generation of hackers to sort out.
>
> OK, enough philosophy - let's try and keep this thread just for discussion
> of the BIP itself from now on. If you'd like to continue debating the
> Future of Bitcoin please change the subject line and break it out into a
> new thread.
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--047d7bdc1a9cd34a9004fbf9e33a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>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.</di=
v>
<div><br></div>What if the protocol allowed multiple instant signatures on =
a transaction? Would it encourage more instant providers? For example, a ne=
w instant provider could bootstrap their own trust by paying an already tru=
sted instant provider to co-sign the same transaction. This would be useful=
in the case that a new company tries to release a new wallet once the trus=
t ring is already established. Nobody will use that wallet because it does =
not have the trusted history to do instant transactions, but if they can pa=
y a small amount per transaction to a third party to cosign, they can build=
trust in their own signature till they can eventually have enough trust on=
their own. This could be how an individual user could grow trust in their =
own instant signature as well.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon, Jun 1=
6, 2014 at 11:09 AM, Mike Hearn <span dir=3D"ltr"><<a href=3D"mailto:mik=
e@plan99.net" target=3D"_blank">mike@plan99.net</a>></span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>I think many of us feel it'd be better if this ki=
nd of thing were not needed at all, however, the best way to ensure it does=
n't end up being used is to write code, not to try and block alternativ=
e approaches. If Bitcoin is robust the market should sort it out. If it'=
;s robust for some transactions and not others, that makes for a fun projec=
t for a future generation of hackers to sort out.</div>
<div class=3D"gmail_extra"><br>OK, enough philosophy - let's try and ke=
ep this thread just for discussion of the BIP itself from now on. If you=
9;d like to continue debating the Future of Bitcoin please change the subje=
ct line and break it out into a new thread.<br>
</div></div>
<br>-----------------------------------------------------------------------=
-------<br>
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions<b=
r>
Find What Matters Most in Your Big Data with HPCC Systems<br>
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.<br>
Leverages Graph Analysis for Fast Processing & Easy Data Exploration<br=
>
<a href=3D"http://p.sf.net/sfu/hpccsystems" target=3D"_blank">http://p.sf.n=
et/sfu/hpccsystems</a><br>_______________________________________________<b=
r>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
--047d7bdc1a9cd34a9004fbf9e33a--
|
