Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.42 as permitted sender)
	client-ip=209.85.219.42; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f42.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <loom.20140616T170619-497@post.gmane.org>
References: <CAKrJrGOBSiY5V59eko6g796j3wh9V9ZLjPbyHeS5=zyX6j3Wdw@mail.gmail.com>
	<CANEZrP0Euc1mPhRc9e41tU4zMDrWesvVyiBpAPq6M3m7K=aU=A@mail.gmail.com>
	<loom.20140616T170619-497@post.gmane.org>
Date: Mon, 16 Jun 2014 17:43:26 +0200
Message-ID: <CANEZrP0feDE52arsWyB_X40yd8ATCxfZaEV6RDYcG2rKm-Vapw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Lawrence Nahum <lawrence@greenaddress.it>
Content-Type: multipart/alternative; boundary=047d7b3a81a0574eb804fbf5e39c
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] instant confirmation via payment protocol
 backwards compatible proto buffer extension
Precedence: list

--047d7b3a81a0574eb804fbf5e39c
Content-Type: text/plain; charset=UTF-8

>
> I don't see more than a bunch of accepted payment methods anywhere I
> ever been in my life, I don't see merchants trusting more than a handful of
> third parties.
>

Sure. I buy this. Although the credit card market is a great example of
what we *don't* want: a stagnant duopoly of trusted third parties who
rampantly abuse their position. So I'd hope we see either (a) nobody really
caring about this BIP because Bitcoin gives good enough double spend
protection or (b) lots of anti-double-spend providers (hundreds seems fine).


> Ultimately you care because the alternative is to wait.
>

No, I will never wait. Neither me nor the merchant wants to me to be
pointlessly hanging around for an hour. The alternative is to pay by credit
card or cash. Outside of experiments there is no such thing as a shop that
only accepts only Bitcoin and will require me to wait for a block because I
didn't use a TTP to guarantee anti-double spends.

So this seems like a fundamental problem to me: having the ability to say,
"here is a proof I won't double spend" is fine, but it doesn't achieve
anything if the merchant would have sold me the goods in return for a
normal Bitcoin tx anyway, which in practice they always will because this
system starts out from zero users and would have to work upwards. I
*especially* will never use this system if I have to pay for it - I'd much
rather just put my money into a wallet that can't generate these proofs and
pay the sticker price.

Maybe what this BIP needs is an extra field that lets the merchant say, I
will give you a discount of X satoshis if you give me a no-double-spends
proof. In other words invert it: the sticker price is what normal Bitcoin
transactions cost, and then your wallet shows you the regular BIP70 price
minus the discount plus the third parties fee as what you finally pay. I
compare it to the sticker price the merchant is asking and if it's lower
I'm happy, and if it's higher my wallet would automatically avoid using the
TTP because I don't want to ever pay more, only less.

The market would then figure out if the fees the TTP charges are worth the
lower losses due to double spending fraud.

--047d7b3a81a0574eb804fbf5e39c
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 class=3D"">I don&#39;t see more than a bunc=
h of accepted payment methods anywhere I<br>
</div>
ever been in my life, I don&#39;t see merchants trusting more than a handfu=
l of<br>
third parties.<br></blockquote><div><br></div><div>Sure. I buy this. Althou=
gh the credit card market is a great example of what we <i>don&#39;t</i>=C2=
=A0want: a stagnant duopoly of trusted third parties who rampantly abuse th=
eir position. So I&#39;d hope we see either (a) nobody really caring about =
this BIP because Bitcoin gives good enough double spend protection or (b) l=
ots of anti-double-spend providers (hundreds seems fine).</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"">Ultimately you care because the alternative is to wait.<br>=
</div></blockquote><div><br></div><div>No, I will never wait. Neither me no=
r the merchant wants to me to be pointlessly hanging around for an hour. Th=
e alternative is to pay by credit card or cash. Outside of experiments ther=
e is no such thing as a shop that only accepts only Bitcoin and will requir=
e me to wait for a block because I didn&#39;t use a TTP to guarantee anti-d=
ouble spends.</div>
<div>=C2=A0<br></div><div>So this seems like a fundamental problem to me: h=
aving the ability to say, &quot;here is a proof I won&#39;t double spend&qu=
ot; is fine, but it doesn&#39;t achieve anything if the merchant would have=
 sold me the goods in return for a normal Bitcoin tx anyway, which in pract=
ice they always will because this system starts out from zero users and wou=
ld have to work upwards. I <i>especially</i>=C2=A0will never use this syste=
m if I have to pay for it - I&#39;d much rather just put my money into a wa=
llet that can&#39;t generate these proofs and pay the sticker price.</div>
<div><br></div><div>Maybe what this BIP needs is an extra field that lets t=
he merchant say, I will give you a discount of X satoshis if you give me a =
no-double-spends proof. In other words invert it: the sticker price is what=
 normal Bitcoin transactions cost, and then your wallet shows you the regul=
ar BIP70 price minus the discount plus the third parties fee as what you fi=
nally pay. I compare it to the sticker price the merchant is asking and if =
it&#39;s lower I&#39;m happy, and if it&#39;s higher my wallet would automa=
tically avoid using the TTP because I don&#39;t want to ever pay more, only=
 less.</div>
<div><br></div><div>The market would then figure out if the fees the TTP ch=
arges are worth the lower losses due to double spending fraud.</div></div><=
/div></div>

--047d7b3a81a0574eb804fbf5e39c--