Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-01-27 📝 Original message:Thanks Andreas, that's ...
📅 Original date posted:2014-01-27
📝 Original message:Thanks Andreas, that's really interesting work. Comments below.
On Mon, Jan 27, 2014 at 12:59 PM, Andreas Schildbach
<andreas at schildbach.de>wrote:
> Because I could not find any standard for Bluetooth URLs, I made
> up my own: "bt:112233445566" means MAC address 11:22:33:44:55:66.
I would like to see Bluetooth continue to work for scan-to-pay even in the
signed case. So for this reason the current approach with a BTMAC parameter
in the Bitcoin URI seems to work universally across NFC tags and QR codes,
and would allow download of a signed PaymentRequest even in the case where
a QR code is used.
Because a Bitcoin URI already contains a public key (hash), re-using that
to establish an encrypted/authd connection on top of an insecure RFCOMM
socket would seem to be relatively straightforward.
> Obviously such QR-encoded payment requests cannot grow in size as much
> as using other media. In particular, I expect PKI signed requests are
> out of question. However, in face to face payments the value of a sig
> based on PKI is highly questionable, and the fact the sig cannot be
> verified without TCP connectivity doesn't help.
>
Just a correction here - the reason signed payment requests are "large"
(about 4000 bytes) is exactly because they *can* be verified offline, i.e.
by a Trezor. The signed payment request contains all the data needed to
establish its authenticity, including certificates and the signature
itself. No TCP connection is needed.
For face to face payments, I think signing is still useful. For one, we
want to keep the distinction between "merchant" and "user" as blurry and
indistinct as possible. A strong separation between merchants and consumers
is one of the many bad things about the credit card system. Whilst
initially we'd expect the payment protocol to be used by online webshops,
in future it could be used by little corner shops, children's lemonade
stands and so on. You don't want to exclude entire classes of transactions
from being secure with Trezor type devices, and besides, even without a
Trezor you probably still would like a receipt if you buy something from a
local market trader.
Another use case - we heard a story about a restaurant owner who accepted
Bitcoin. He printed a static bitcoin URI onto a QR code on the menu. A
month or two later he discovered one of his waiters had re-printed the
menus with his own QR code! The people thought they had been paying for the
meal, and in fact it went right into the pocket of the waiter.
As to how it works, well, that's not hard. Comodo give away free email
address certs with a few mouse clicks, it's no harder than signing up for a
website. Then you can just open that cert file on your phone to install it
and it should become usable automatically with a future version of
bitcoinj. Email address doesn't prove a whole lot, of course, but it's
better than nothing. If the restaurant owner had even just a hotmail
address, he could have stuck it up behind the bar or painted it on the
outside of his shop and some customer would have got suspicious when he
didn't see the address (assuming we're successful at deploying it of
course).
> - I chose to re-use the "bitcoin:" URL scheme
>
Other wallets won't know what to do with it and would yield a strange error
message.
> Finally this is the usecase the payment protocol was invented for and
> it's not face-to-face. I don't have much to add, just one thing. As a
> byproduct of the above, "payment protocol URLs" can be used for links
> published on web pages as well. This might provide a nice replacement
> for the imho rather ugly BIP72 specification once the payment protocol
> is widely deployed.
URL length is limited on some versions of internet explorer (probably on
all browsers). Rather than pack a file into a URL, if you don't want to use
the current r= extension it's better for apps to just register to handle
.bitcoinpaymentrequest files / the right MIME type. Downloading it and
opening it would do the right thing automatically.
Remember BIP 73 also! It says that with the apps built-in QR scanner, if
you scan an HTTP[S] URI, you should try downloading it with a magic header.
That way you can get a payment request file out of the server. Without the
magic header (i.e. a normal generic barcode scanner app) it would open a
web page containing a bitcoin URI clickable link.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140127/55485834/attachment.html>;
📝 Original message:Thanks Andreas, that's really interesting work. Comments below.
On Mon, Jan 27, 2014 at 12:59 PM, Andreas Schildbach
<andreas at schildbach.de>wrote:
> Because I could not find any standard for Bluetooth URLs, I made
> up my own: "bt:112233445566" means MAC address 11:22:33:44:55:66.
I would like to see Bluetooth continue to work for scan-to-pay even in the
signed case. So for this reason the current approach with a BTMAC parameter
in the Bitcoin URI seems to work universally across NFC tags and QR codes,
and would allow download of a signed PaymentRequest even in the case where
a QR code is used.
Because a Bitcoin URI already contains a public key (hash), re-using that
to establish an encrypted/authd connection on top of an insecure RFCOMM
socket would seem to be relatively straightforward.
> Obviously such QR-encoded payment requests cannot grow in size as much
> as using other media. In particular, I expect PKI signed requests are
> out of question. However, in face to face payments the value of a sig
> based on PKI is highly questionable, and the fact the sig cannot be
> verified without TCP connectivity doesn't help.
>
Just a correction here - the reason signed payment requests are "large"
(about 4000 bytes) is exactly because they *can* be verified offline, i.e.
by a Trezor. The signed payment request contains all the data needed to
establish its authenticity, including certificates and the signature
itself. No TCP connection is needed.
For face to face payments, I think signing is still useful. For one, we
want to keep the distinction between "merchant" and "user" as blurry and
indistinct as possible. A strong separation between merchants and consumers
is one of the many bad things about the credit card system. Whilst
initially we'd expect the payment protocol to be used by online webshops,
in future it could be used by little corner shops, children's lemonade
stands and so on. You don't want to exclude entire classes of transactions
from being secure with Trezor type devices, and besides, even without a
Trezor you probably still would like a receipt if you buy something from a
local market trader.
Another use case - we heard a story about a restaurant owner who accepted
Bitcoin. He printed a static bitcoin URI onto a QR code on the menu. A
month or two later he discovered one of his waiters had re-printed the
menus with his own QR code! The people thought they had been paying for the
meal, and in fact it went right into the pocket of the waiter.
As to how it works, well, that's not hard. Comodo give away free email
address certs with a few mouse clicks, it's no harder than signing up for a
website. Then you can just open that cert file on your phone to install it
and it should become usable automatically with a future version of
bitcoinj. Email address doesn't prove a whole lot, of course, but it's
better than nothing. If the restaurant owner had even just a hotmail
address, he could have stuck it up behind the bar or painted it on the
outside of his shop and some customer would have got suspicious when he
didn't see the address (assuming we're successful at deploying it of
course).
> - I chose to re-use the "bitcoin:" URL scheme
>
Other wallets won't know what to do with it and would yield a strange error
message.
> Finally this is the usecase the payment protocol was invented for and
> it's not face-to-face. I don't have much to add, just one thing. As a
> byproduct of the above, "payment protocol URLs" can be used for links
> published on web pages as well. This might provide a nice replacement
> for the imho rather ugly BIP72 specification once the payment protocol
> is widely deployed.
URL length is limited on some versions of internet explorer (probably on
all browsers). Rather than pack a file into a URL, if you don't want to use
the current r= extension it's better for apps to just register to handle
.bitcoinpaymentrequest files / the right MIME type. Downloading it and
opening it would do the right thing automatically.
Remember BIP 73 also! It says that with the apps built-in QR scanner, if
you scan an HTTP[S] URI, you should try downloading it with a magic header.
That way you can get a payment request file out of the server. Without the
magic header (i.e. a normal generic barcode scanner app) it would open a
web page containing a bitcoin URI clickable link.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140127/55485834/attachment.html>;