path: root/89/5eb1fd8d4c1b4f3b16d723d74a338505300ce4

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <drice@greenmangosystems.com>) id 1Wwe3J-0006Gb-Sf
	for bitcoin-development@lists.sourceforge.net;
	Mon, 16 Jun 2014 21:02:53 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of
	greenmangosystems.com designates 209.85.220.174 as permitted
	sender) client-ip=209.85.220.174;
	envelope-from=drice@greenmangosystems.com;
	helo=mail-vc0-f174.google.com; 
Received: from mail-vc0-f174.google.com ([209.85.220.174])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Wwe3I-00086x-3q
	for bitcoin-development@lists.sourceforge.net;
	Mon, 16 Jun 2014 21:02:53 +0000
Received: by mail-vc0-f174.google.com with SMTP id hy4so5573188vcb.33
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 16 Jun 2014 14:02:45 -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=1VCyTBcvbMsnfe0NdIr2GiCTgPnoYmB0/s8RyfJrKTs=;
	b=h68SS5kJgbL8wn7saOURkaV1URWv+0EJ+nx4WH3jA9VvHII3AMzvTUL8cbMVaYZZIW
	fw4Voh+JqegiZIuC0joZr1iaIZTreq5OzdVQVfsdt7+ry1PBTaKPeUPaWcmepFcAuybt
	fJKWzRlJSchjSsBFOH2CHX1evSxYxIFUAdBkBF4AzV+UklFBzw+NedfYLtO8GU/L97N/
	SvqJn6bYTLVaWygQVmvdPgjHfAxz3cagpbrbd4bQIJ/mMaQ+tNyYcEJoiRRvXHThgz64
	CdlEUb4AnCAEXTRdjqfbZC3wRSo63aoNEUHENOqQ7ZNt6izsGScLS/nJoqaEOED75Y22
	stZg==
X-Gm-Message-State: ALoCoQlUdxaNE9VwhqP4kbFqu8ltwwXqOX4T4u0Q53xVfNXZLrW2b2fY0KpiayW8NCRdnakxTWg1
MIME-Version: 1.0
X-Received: by 10.52.232.133 with SMTP id to5mr15131098vdc.16.1402952565713;
	Mon, 16 Jun 2014 14:02:45 -0700 (PDT)
Received: by 10.58.123.35 with HTTP; Mon, 16 Jun 2014 14:02:45 -0700 (PDT)
In-Reply-To: <CAFDyEXg8OnoYCNLT1WeX2tBPTB_zcXsZ6ujP_8YmPvGyf4pzkw@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>
	<CAFDyEXg8OnoYCNLT1WeX2tBPTB_zcXsZ6ujP_8YmPvGyf4pzkw@mail.gmail.com>
Date: Mon, 16 Jun 2014 14:02:45 -0700
Message-ID: <CAFDyEXghQ0yOpsoj2T4535m1XdKsdg6993hmp8iZQDy0ixRsQg@mail.gmail.com>
From: Daniel Rice <drice@greenmangosystems.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=089e011764d15100e204fbfa597c
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: 1Wwe3I-00086x-3q
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 21:02:54 -0000

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

Mike Hearn <mike@plan99.net> wrote:
>> A more scalable approach would be for the user to send the name and
>> signature of their "instant provider" every time and the merchant just
>> chooses whether to ignore it or not, but as Lawrence points out, this is
>> incompatible with the provider charging extra fees for "instantness". But
>> should we care? I'm trying to imagine what the purchasing experience is
like
>> with optional paid-for third party anti-double-spend protection.
Ultimately
>> it's the merchant who cares about this, not me, so why would I ever pay?

Lawrence Nahum <lawrence@greenaddress.it> wrote:
> I think you are wrong here.
> Just because up to date credit cards charged the merchant which in turn
> charged you and the ordinary cash payer doesn't mean a newer and better
> system can't be transparent from day one.

I don't think a whitelist of trust is a practical approach because you are
going to want to have varying levels of trust in different instant
providers. This would be based on how large their past transaction volume
has been. For that reason maybe another approach is an additional
negotiation message between the merchant and wallet. Merchant sends payment
details -> wallet responds with their instant information requesting if an
instant transaction will be accepted for this transaction. Merchant weighs
the risk based on historical data about this particular instant provider
and the amount of the requested transaction -> Merchant responds yes or no.

That approach avoids the scaling issue, but also allows for Lawrence's use
case of charging the user a fee only in the case where the instant
transaction is supported.


On Mon, Jun 16, 2014 at 1:29 PM, Daniel Rice <drice@greenmangosystems.com>
wrote:

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

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

<div dir=3D"ltr"><div style=3D"font-family:arial,sans-serif;font-size:13px"=
><span style=3D"color:rgb(34,34,34);white-space:nowrap">Mike Hearn &lt;<a h=
ref=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt; wr=
ote:</span><br>

</div><div style=3D"font-family:arial,sans-serif;font-size:13px">&gt;&gt; A=
 more scalable approach would be for the user to send the name and<br>&gt;&=
gt; signature of their &quot;instant provider&quot; every time and the merc=
hant just<br>

&gt;&gt; chooses whether to ignore it or not, but as Lawrence points out, t=
his is<br>&gt;&gt; incompatible with the provider charging extra fees for &=
quot;instantness&quot;. But<br>&gt;&gt; should we care? I&#39;m trying to i=
magine what the purchasing experience is like<br>

&gt;&gt; with optional paid-for third party anti-double-spend protection. U=
ltimately<br>&gt;&gt; it&#39;s the merchant who cares about this, not me, s=
o why would I ever pay?<br><span style=3D"color:rgb(34,34,34)"><br></span><=
/div>

<div style=3D"font-family:arial,sans-serif;font-size:13px"><span style=3D"c=
olor:rgb(34,34,34);white-space:nowrap">Lawrence Nahum &lt;<a href=3D"mailto=
:lawrence@greenaddress.it" target=3D"_blank">lawrence@greenaddress.it</a>&g=
t; wrote:</span><span style=3D"color:rgb(34,34,34)"><br>

</span></div><div style=3D"font-family:arial,sans-serif;font-size:13px"><sp=
an style=3D"color:rgb(34,34,34)">&gt; I think you are wrong here.</span><br=
 style=3D"color:rgb(34,34,34)"><span style=3D"color:rgb(34,34,34)">&gt; Jus=
t because up to date credit cards charged the merchant which in turn</span>=
<br style=3D"color:rgb(34,34,34)">

<span style=3D"color:rgb(34,34,34)">&gt; charged you and the ordinary cash =
payer doesn&#39;t mean a newer and better</span><br style=3D"color:rgb(34,3=
4,34)"><span style=3D"color:rgb(34,34,34)">&gt; system can&#39;t be transpa=
rent from day one.</span><br>

</div><div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br>=
</span></div><div><font face=3D"arial, sans-serif">I don&#39;t think a whit=
elist of trust is a practical approach because you are going to want to hav=
e varying levels of trust in different instant providers. This would be bas=
ed on how large their past transaction volume has been. For that reason may=
be another approach is an additional negotiation message between the mercha=
nt and wallet. Merchant sends payment details -&gt; wallet responds with th=
eir instant information requesting if an instant transaction will be accept=
ed for this transaction. Merchant weighs the risk based on historical data =
about this particular instant provider and the amount of the requested tran=
saction -&gt; Merchant responds yes or no.</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">That approach avoids the scaling issue, but also allows f=
or Lawrence&#39;s use case of charging the user a fee only in the case wher=
e the instant transaction is supported.</font></div>

</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon,=
 Jun 16, 2014 at 1:29 PM, Daniel Rice <span dir=3D"ltr">&lt;<a href=3D"mail=
to:drice@greenmangosystems.com" target=3D"_blank">drice@greenmangosystems.c=
om</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I&#39;m trying to thin=
k through how to encourage the maximum number of instant signature provider=
s and avoid the VISA monopoly. Ideal case would be that people can even be =
their own instant provider.</div>

<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"><div class=3D=
"">On Mon, Jun 16, 2014 at 11:09 AM, Mike Hearn <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</sp=
an> wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"">
<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&#3=
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></div><div class=3D"">-------------------------------------------------=
-----------------------------<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" target=3D"_bla=
nk">Bitcoin-development@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></div></blockquote></div><br></div>
</blockquote></div><br></div>

--089e011764d15100e204fbfa597c--