path: root/9c/c9e5aa1baba1587d07d5e5431317a229f9e67f

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 <mh.in.england@gmail.com>) id 1XgFpn-0006PS-B6
	for bitcoin-development@lists.sourceforge.net;
	Mon, 20 Oct 2014 16:29:27 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.177 as permitted sender)
	client-ip=209.85.214.177; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f177.google.com; 
Received: from mail-ob0-f177.google.com ([209.85.214.177])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XgFpl-0003Ef-Bo
	for bitcoin-development@lists.sourceforge.net;
	Mon, 20 Oct 2014 16:29:27 +0000
Received: by mail-ob0-f177.google.com with SMTP id uy5so3982971obc.8
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 20 Oct 2014 09:29:19 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.64.8 with SMTP id k8mr2786801oes.59.1413822559864; Mon,
	20 Oct 2014 09:29:19 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.108.196 with HTTP; Mon, 20 Oct 2014 09:29:19 -0700 (PDT)
In-Reply-To: <54452648.8040409@AndySchroder.com>
References: <544174F8.1050208@AndySchroder.com>
	<CANEZrP33KH1F8GrTDnTP95G1MyxZ+DXWrC6QKBrj61HXv-eg2w@mail.gmail.com>
	<54452648.8040409@AndySchroder.com>
Date: Mon, 20 Oct 2014 18:29:19 +0200
X-Google-Sender-Auth: atKLa31e_9i2dmtturwh399AnOc
Message-ID: <CANEZrP16jex2AtvU0p-daULKW2yUFJNy+7pHNRRm=ZTCiS0dow@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andy Schroder <info@andyschroder.com>
Content-Type: multipart/alternative; boundary=001a11c3d3ee74d0b00505dd373c
X-Spam-Score: -0.5 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1XgFpl-0003Ef-Bo
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth
 Communication and bitcoin: URI Scheme Improvements
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, 20 Oct 2014 16:29:27 -0000

--001a11c3d3ee74d0b00505dd373c
Content-Type: text/plain; charset=UTF-8

>
> I'm not a cryptography expert, but why not just wrap the bluetooth
> connection with SSL and not reimplement ECDH? Is this
>
hard to do with android/java?
>

Not at all, it should be very easy in Java because of how the SSL API is
designed. I'd worry more about non-Java platforms.

However, SSL is extremely large, old and complicated. We use it on the web
because of a mix of its feature set and legacy concerns. When discussing
encrypted connections in the past, there has been a desire to avoid SSL
because of these issues and do something much simpler and home grown. Of
course, part of the reason SSL is so convoluted is because cryptography
evolves over time, and thus it's not 100% clear to me that a simple
home-rolled crypto link would avoid falling into the same traps as SSL
eventually.

But, at least for now, it's probably more secure and more robust to not use
SSL.


> This sounds great, but I thought it is not desired to divulge a bitcoin
> public key until the time of signing a transaction. Isn't that the whole
> point of having a public key hash and never reusing addresses?
>

Eh, no. Satoshi originally introduced key hashing simply to make shorter
and easier to type destinations. Actually he envisioned most payments being
routed by IP address, where Bitcoin would just connect to the other node
and request a public key directly. There's no problem with the sender
knowing the public key of the address included in the URI.


> This could be resolved by the payee immediately sending the payment to
> another address after receiving it, but that is kind of a waste of a
> transaction. Also, I would love a less PKI dependent way to authenticate a
> transaction between the two parties, but I was trying to minimize the
> discussion of general payment protocol modifications in this announcement.
>

Alternative PKIs would be a topic for another thread, indeed. But I doubt
you will get anywhere. There are no usable alternatives to the SSL PKI. I
wrote an article on the topic here, you may find it useful:

https://medium.com/@octskyward/why-you-think-the-pki-sucks-b64cf5912aa7

It summarises why BIP70 uses the PKI.


> We can do something like this, I guess. The issue I mentioned about the
> message headers being inconsistent will have to be fixed though to to do
> this. However, is anyone even using the HTTP base failure signal (I don't
> even know what it is)?
>

It's "Respond with 500 Internal Server Error" pretty much.

Originally the idea of BIP70 was that clients would not broadcast
transactions. They would submit them to the merchant for broadcast. If the
merchant didn't like the payment for some reason (e.g. paying with a non
standard transaction or with lots of dust), they could just return an error.

Unfortunately Bitcoin Core does broadcast transactions simultaneously.
Additionally, whilst other wallets  did not, one major payment processor
had a very unreliable BIP70 payment_url endpoint for a while, whilst
broadcasting a tx via the p2p network was fully functioning. So to work
around bugs in this one payment processor some other wallets have started
broadcasting the payment tx simultaneously as well.

This means a receiver cannot meaningfully reject a payment. Some wallets
will send it anyway, via the p2p network.


> and a h= parameter, and Schildbach's wallet does accept the payment request
>

I suspect it won't work if you leave out the non-standard h= parameter.

WRT the merge avoidance - there's an article here on how it's meant to work:

https://medium.com/@octskyward/merge-avoidance-7f95a386692f

It's totally OK for you to specify the amounts you want to avoid merges in
your own wallet. The sending wallet could (but none do today) then pay with
multiple transactions.

Your case is really weird because you aren't actually requesting a specific
amout of money. I recall that there's some reason for this, from your
video, but suddenly it escapes me. Because the user scans the payment
request before pumping?


> I don't trust HTTPS for a number of reasons.
>

I disagree with all your reasons (e.g. there is nothing wrong with
outsourcing payment processing and it doesn't have to imply the user sees
an incorrect name), and I believe you should trust the PKI a lot more than
you do. If you try and build a better replacement, I think you'll discover
it's a lot harder than you imagine.

Regardless, I am not against an *optional* tighter binding between URI and
payment request, mostly because it's useful for the cases where signing
with a cert isn't possible. But the simple/obvious "embed a hash of it in
the URI" is inefficient, not compatible with the current specs, can make QR
codes harder to scan, and forces you to format your payment request up
front rather than generating it on demand.


> The primary reason he does not have this in the master branch is because
> the payment protocol only supports signing of payment requests via PKI, and
> it is difficult for a user to install a PKI signed certificate on android,
> just for a single peer to peer use case.
>

Unsigned requests work OK for the phone to phone case, assuming you aren't
actually talking to an imposter.


> If you are to provide a full fledged wifi connection to the customer,
> there would then have to be a very sophisticated proxy server that can
> allow only access to bitcoin nodes, and how to do that would be difficult
> since every node doesn't know all of the nodes in the network.
>

You can just allow port 8333 and rewrite port 80, as most wifi hotspots do
today already.

But my point about this was that all smartphones get internet access from
time to time. In my own life, I've definitely been in cases where I wanted
to *pay* with bitcoins but didn't have good internet access at that exact
moment, e.g. back of a restaurant. I've also been in the situation more
rarely where I wanted to receive coins from someone in front of me, without
good internet access, but Bluetooth already addresses that.

I don't recall ever being in a situation where I had no internet access,
but somehow knew there was a payment waiting for me on the block chain, and
I needed it right now because it was necessary for me to receive that money
in order to pay a bill. That's what the dedicated blockchain radio would
provide, but it seems like a very rare use case.


> All this was already known but was not proposed because it does not allow
> you to use the h= parameter. What do you propose to do instead of the h=
> parameter, but still allow for a trust anchor with the payee still be
> maintained?
>

I think I said already, but maybe am not explaining well. You use the
address that's already in all backwards compatible URIs. The payment
details can be additionally signed with the key corresponding to that
address. Or, that key can be covered by the PKI signature if there is one.
But dual signing is always possible.

--001a11c3d3ee74d0b00505dd373c
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:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000">I&#39;m not a crypto=
graphy expert, but why not just wrap the bluetooth
    connection with SSL and not reimplement ECDH? Is this=C2=A0</div></bloc=
kquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:=
solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000">hard to d=
o
    with android/java?</div></blockquote><div><br></div><div>Not at all, it=
 should be very easy in Java because of how the SSL API is designed. I&#39;=
d worry more about non-Java platforms.</div><div><br></div><div>However, SS=
L is extremely large, old and complicated. We use it on the web because of =
a mix of its feature set and legacy concerns. When discussing encrypted con=
nections in the past, there has been a desire to avoid SSL because of these=
 issues and do something much simpler and home grown. Of course, part of th=
e reason SSL is so convoluted is because cryptography evolves over time, an=
d thus it&#39;s not 100% clear to me that a simple home-rolled crypto link =
would avoid falling into the same traps as SSL eventually.</div><div><br></=
div><div>But, at least for now, it&#39;s probably more secure and more robu=
st to not use SSL.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:r=
gb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor=3D"#=
FFFFFF" text=3D"#000000">This sounds great, but I thought it is not desired=
 to divulge a
    bitcoin public key until the time of signing a transaction. Isn&#39;t
    that the whole point of having a public key hash and never reusing
    addresses? </div></blockquote><div><br></div><div>Eh, no. Satoshi origi=
nally introduced key hashing simply to make shorter and easier to type dest=
inations. Actually he envisioned most payments being routed by IP address, =
where Bitcoin would just connect to the other node and request a public key=
 directly. There&#39;s no problem with the sender knowing the public key of=
 the address included in the URI.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div bgcolor=3D"#FFFFFF" text=3D"#000000">This could be resolved by the pay=
ee immediately sending
    the payment to another address after receiving it, but that is kind
    of a waste of a transaction. Also, I would love a less PKI dependent
    way to authenticate a transaction between the two parties, but I was
    trying to minimize the discussion of general payment protocol
    modifications in this announcement.</div></blockquote><div><br></div><d=
iv>Alternative PKIs would be a topic for another thread, indeed. But I doub=
t you will get anywhere. There are no usable alternatives to the SSL PKI. I=
 wrote an article on the topic here, you may find it useful:</div><div><br>=
</div><div><a href=3D"https://medium.com/@octskyward/why-you-think-the-pki-=
sucks-b64cf5912aa7" target=3D"_blank">https://medium.com/@octskyward/why-yo=
u-think-the-pki-sucks-b64cf5912aa7</a><br></div><div><br></div><div>It summ=
arises why BIP70 uses the PKI.</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div =
bgcolor=3D"#FFFFFF" text=3D"#000000">We can do something like this, I guess=
. The issue I mentioned about
    the message headers being inconsistent will have to be fixed though
    to to do this. However, is anyone even using the HTTP base failure
    signal (I don&#39;t even know what it is)?</div></blockquote><div><br><=
/div><div>It&#39;s &quot;Respond with 500 Internal Server Error&quot; prett=
y much.</div><div><br></div><div>Originally the idea of BIP70 was that clie=
nts would not broadcast transactions. They would submit them to the merchan=
t for broadcast. If the merchant didn&#39;t like the payment for some reaso=
n (e.g. paying with a non standard transaction or with lots of dust), they =
could just return an error.</div><div><br></div><div>Unfortunately Bitcoin =
Core does broadcast transactions simultaneously. Additionally, whilst other=
 wallets =C2=A0did not, one major payment processor had a very unreliable B=
IP70 payment_url endpoint for a while, whilst broadcasting a tx via the p2p=
 network was fully functioning. So to work around bugs in this one payment =
processor some other wallets have started broadcasting the payment tx simul=
taneously as well.</div><div><br></div><div>This means a receiver cannot me=
aningfully reject a payment. Some wallets will send it anyway, via the p2p =
network.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" te=
xt=3D"#000000"> and a h=3D
    parameter, and Schildbach&#39;s wallet does accept the payment request<=
br></div></blockquote><div><br></div><div>I suspect it won&#39;t work if yo=
u leave out the non-standard h=3D parameter.</div><div><br></div><div>WRT t=
he merge avoidance - there&#39;s an article here on how it&#39;s meant to w=
ork:</div><div><br></div><div><a href=3D"https://medium.com/@octskyward/mer=
ge-avoidance-7f95a386692f" target=3D"_blank">https://medium.com/@octskyward=
/merge-avoidance-7f95a386692f</a><br></div><div><br></div><div>It&#39;s tot=
ally OK for you to specify the amounts you want to avoid merges in your own=
 wallet. The sending wallet could (but none do today) then pay with multipl=
e transactions.</div><div><br></div><div>Your case is really weird because =
you aren&#39;t actually requesting a specific amout of money. I recall that=
 there&#39;s some reason for this, from your video, but suddenly it escapes=
 me. Because the user scans the payment request before pumping?</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000">I do=
n&#39;t trust HTTPS for a number of reasons.</div></blockquote><div><br></d=
iv><div>I disagree with all your reasons (e.g. there is nothing wrong with =
outsourcing payment processing and it doesn&#39;t have to imply the user se=
es an incorrect name), and I believe you should trust the PKI a lot more th=
an you do. If you try and build a better replacement, I think you&#39;ll di=
scover it&#39;s a lot harder than you imagine.</div><div><br></div><div>Reg=
ardless, I am not against an <i>optional</i> tighter binding between URI an=
d payment request, mostly because it&#39;s useful for the cases where signi=
ng with a cert isn&#39;t possible. But the simple/obvious &quot;embed a has=
h of it in the URI&quot; is inefficient, not compatible with the current sp=
ecs, can make QR codes harder to scan, and forces you to format your paymen=
t request up front rather than generating it on demand.</div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000">The primary r=
eason he does not
    have this in the master branch is because the payment protocol only
    supports signing of payment requests via PKI, and it is difficult
    for a user to install a PKI signed certificate on android, just for
    a single peer to peer use case.</div></blockquote><div><br></div><div>U=
nsigned requests work OK for the phone to phone case, assuming you aren&#39=
;t actually talking to an imposter.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div bgcolor=3D"#FFFFFF" text=3D"#000000">If you are to provide a full
    fledged wifi connection to the customer, there would then have to be
    a very sophisticated proxy server that can allow only access to
    bitcoin nodes, and how to do that would be difficult since every
    node doesn&#39;t know all of the nodes in the network.=C2=A0</div></blo=
ckquote><div><br></div><div>You can just allow port 8333 and rewrite port 8=
0, as most wifi hotspots do today already.</div><div><br></div><div>But my =
point about this was that all smartphones get internet access from time to =
time. In my own life, I&#39;ve definitely been in cases where I wanted to <=
i>pay</i>=C2=A0with bitcoins but didn&#39;t have good internet access at th=
at exact moment, e.g. back of a restaurant. I&#39;ve also been in the situa=
tion more rarely where I wanted to receive coins from someone in front of m=
e, without good internet access, but Bluetooth already addresses that.</div=
><div><br></div><div>I don&#39;t recall ever being in a situation where I h=
ad no internet access, but somehow knew there was a payment waiting for me =
on the block chain, and I needed it right now because it was necessary for =
me to receive that money in order to pay a bill. That&#39;s what the dedica=
ted blockchain radio would provide, but it seems like a very rare use case.=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#0=
00000">All this was already known but was not proposed because it does not
    allow you to use the h=3D parameter. What do you propose to do instead
    of the h=3D parameter, but still allow for a trust anchor with the
    payee still be maintained?</div></blockquote><div><br></div><div>I thin=
k I said already, but maybe am not explaining well. You use the address tha=
t&#39;s already in all backwards compatible URIs. The payment details can b=
e additionally signed with the key corresponding to that address. Or, that =
key can be covered by the PKI signature if there is one. But dual signing i=
s always possible.=C2=A0</div></div></div></div>

--001a11c3d3ee74d0b00505dd373c--