From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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> <54452648.8040409@AndySchroder.com> Date: Mon, 20 Oct 2014 18:29:19 +0200 X-Google-Sender-Auth: atKLa31e_9i2dmtturwh399AnOc Message-ID: From: Mike Hearn To: Andy Schroder 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 , Andreas Schildbach 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
I'm not a crypto= graphy expert, but why not just wrap the bluetooth connection with SSL and not reimplement ECDH? Is this=C2=A0
hard to d= o 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, 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'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 robu= st to not use SSL.
=C2=A0
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 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's no problem with the sender knowing the public key of= the address included in the URI.
=C2=A0
=
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.

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:

=

It summ= arises why BIP70 uses the PKI.
=C2=A0
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)?

<= /div>
It's "Respond with 500 Internal Server Error" prett= y much.

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

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.

This means a receiver cannot me= aningfully reject a payment. Some wallets will send it anyway, via the p2p = network.
=C2=A0
and a h=3D parameter, and Schildbach's wallet does accept the payment request<= br>

I suspect it won't work if yo= u leave out the non-standard h=3D parameter.

WRT t= he merge avoidance - there's an article here on how it's meant to w= ork:


It'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.

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?
= =C2=A0
I do= n'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 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'll di= scover it's a lot harder than you imagine.

Reg= ardless, I am not against an optional tighter binding between URI an= d payment request, mostly because it's useful for the cases where signi= ng with a cert isn't possible. But the simple/obvious "embed a has= h of it in the URI" 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.
=C2=A0
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.

U= nsigned requests work OK for the phone to phone case, assuming you aren'= ;t actually talking to an imposter.
=C2=A0
=
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.=C2=A0

You can just allow port 8333 and rewrite port 8= 0, 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 <= i>pay=C2=A0with bitcoins but didn't have good internet access at th= at exact moment, e.g. back of a restaurant. I'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.

I don'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's what the dedica= ted blockchain radio would provide, but it seems like a very rare use case.=
=C2=A0
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?

I thin= k I said already, but maybe am not explaining well. You use the address tha= t'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
--001a11c3d3ee74d0b00505dd373c--