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; 
MIME-Version: 1.0
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
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

--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&#39;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">&lt;<a href=3D"mailto:mik=
e@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</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&#39;d be better if this ki=
nd of thing were not needed at all, however, the best way to ensure it does=
n&#39;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&#39=
;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&#39;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 &amp; 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--