[Bitcoin-development] Payment Protocol for Face-to-face Payments

[Bitcoin-development] Payment Protocol for Face-to-face Payments

[Andreas Schildbach]

As promised I'd like to present my work done on leveraging the payment
protocol for face-to-face payments. The general assumption is that
individuals don't own X.509 certificates. Their devices may be only
badly connected to the internet or in some cases not at all. I've
implemented a prototype on a branch of Bitcoin Wallet. It is using
bitcoinj 0.11 (not released).

https://github.com/schildbach/bitcoin-wallet/commits/payment-protocol


TAP TO PAY

First I looked at the NFC tap-to-pay usecase. The way it works as
currently rolled out: A BIP21 URL is published using an NDEF URI
message. The URL is supplemented by a Bluetooth MAC address that can be
connected in order to finish the payment. Once connected, a very simple
custom protocol transmits the signed transaction(s) in
bitcoin-serialized form to the payee, who replies with an ack or nack.

The way I prototyped it to work in future: Instead of the BIP21 URL a
BIP70 payment request is published using an NDEF MIME message (mime-type
as per BIP71). The paymentUrl field can (and in the face-to-face case
should) contain a Bluetooth URL which contains the MAC address of the
payee. 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. Once
connected, Payment message and PaymentACK reply are used to finish the
payment. Since Bluetooth sockets are streams, I had to use the delimited
variant of the protobufs for Payment and PaymentACK messages. This
prepends them with a VARINT containing the message length.

All of the above should be easy to migrate. NFC implementations are
rare, and the current Bluetooth protocol is implemented only by Bitcoin
Wallet afaik. Fallbacks are provided where necessary.

In future, I'd like to add encryption to the Bluetooth connection, maybe
using SSL and some DH key exchange.


SCAN TO PAY

For scan-to-pay, the current landscape looks different. I assume at
least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
into a QR-code. Nevertheless, I tried to encode a payment request into
the bitcoin URL. I used my existing work on encoding transactions into
QR-codes. Steps to encode:

1. The payment request is protobuf-serialized. For a simple payment
request, this results in only ~50 bytes thanks to the efficiency of
protobuf.
2. The bytes are encoded using "Base43", which is the same as
Base64/Base58, but its alphabet consists of the characters allowed in
so-called "alphanumeric" QR-codes, minus the characters not allowed in URLs.
3. The resulting string is prefixed by "BITCOIN:"
4. All of that goes into a QR-code, and because it only contains
"alphanumeric" characters, it will produce a very efficient code. For
simple payment requests, I could not notice any difference in scanning
difficulty.

There are some limitations however:

- 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. There should be some
headroom for multiple-output requests and moderately more complex
scripts though.

- I chose to re-use the "bitcoin:" URL scheme, because it's already
whitelisted in web browsers, QR-code scanners and so on. In order to
differentiate "payment requests URLs" from BIP21 URLs, I test for
uri.startsWith("BITCOIN:") because you'll get letters in all-caps from
alphanumeric QR-codes. I will investigate into a better solution.

- Due to wide deployment of BIP21 QR-codes, migration needs to happen in
distinct phases. Ability to parse "payment protocol URLs" comes first,
default to presenting them to users has to come (much) later.


CLICK TO PAY

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.


Open for discussion.

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 4374 bytes --]

Thanks Andreas, that's really interesting work. Comments below.

On Mon, Jan 27, 2014 at 12:59 PM, Andreas Schildbach
<andreas@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.

[-- Attachment #2: Type: text/html, Size: 5703 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Jeremy Spilman]

On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach  
<andreas@schildbach.de> wrote:

> SCAN TO PAY
> For scan-to-pay, the current landscape looks different. I assume at
> least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
> into a QR-code. Nevertheless, I tried to encode a payment request into
> the bitcoin URL. I used my existing work on encoding transactions into
> QR-codes. Steps to encode:

Really interesting work. When using scan-to-pay, after the payer scans the  
QR code with the protobuf PaymentRequest (not a URL to download the  
PaymentRequest) are they using their own connectivity to submit the  
Payment response?

If we assume connectivity on the phone, might as well just get a URL from  
the QR code and re-use existing infrastructure for serving that?

How about putting a Bluetooth address in the payment_url inside the  
PaymentDetails message for the smartphone to send back the Payment  
response and get PaymentAck?

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Andreas Schildbach]

On 01/27/2014 06:11 PM, Jeremy Spilman wrote:

>> SCAN TO PAY
>> For scan-to-pay, the current landscape looks different. I assume at
>> least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
>> into a QR-code. Nevertheless, I tried to encode a payment request into
>> the bitcoin URL. I used my existing work on encoding transactions into
>> QR-codes. Steps to encode:
> 
> Really interesting work. When using scan-to-pay, after the payer scans the  
> QR code with the protobuf PaymentRequest (not a URL to download the  
> PaymentRequest) are they using their own connectivity to submit the  
> Payment response?
>
> How about putting a Bluetooth address in the payment_url inside the
> PaymentDetails message for the smartphone to send back the Payment
> response and get PaymentAck?

That's exactly what I have prototyped. I am putting a Bluetooth MAC
address into the payment_url. Have a look at the TAP TO PAY paragraph
for details, its mostly the same mechanism.

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Andreas Schildbach]

On 01/27/2014 02:11 PM, Mike Hearn wrote:

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

I'm not saying I'm against signed payment requests, but unfortunately
they are just too big for QR-codes. Then again, QR-codes *can* take up
to 2 KB. How big would a very basic trust chain plus signature be?

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

I was under the impression that addresses will go away. Can you
elaborate on the mechanism?

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

Ok, that's good news (to me). However, you are going to manage trust
stores (adding and revoking) without TCP?

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

Ack.

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

Well I'm thinking the other way round. Use Bitcoin where its already
used today -- face to face.

> you probably still would like a receipt if you buy
> something from a local market trader.

Yes, but where is the problem?

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

Sad story, but it's really a special case. Using a printed QR-code is
clearly the wrong tool for his task, for several reasons.

And again, how is he going to provide the payment request to the payer
without TCP?

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

We don't want to force people to sign up anywhere. Bitcoin is instant-on.

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

Which is why I said we need some transition time.

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

That's a good point. I'll implement this asap.

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

Interesting, did not know about this BIP. However I don't understand the
usecase. Its not like my browsers always display QR-codes with URL of
the page being shown. And if the page in question bothers to show a QR
code, it could just as well also link to a payment request resource (as
suggested above).

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Jeremy Spilman]

On Jan 27, 2014, at 9:39 AM, Andreas Schildbach <andreas@schildbach.de> wrote:

> On 01/27/2014 06:11 PM, Jeremy Spilman wrote:
> 
>>> SCAN TO PAY
>>> For scan-to-pay, the current landscape looks different. I assume at
>>> least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
>>> into a QR-code. Nevertheless, I tried to encode a payment request into
>>> the bitcoin URL. I used my existing work on encoding transactions into
>>> QR-codes. Steps to encode:
>> 
>> Really interesting work. When using scan-to-pay, after the payer scans the  
>> QR code with the protobuf PaymentRequest (not a URL to download the  
>> PaymentRequest) are they using their own connectivity to submit the  
>> Payment response?
>> 
>> How about putting a Bluetooth address in the payment_url inside the
>> PaymentDetails message for the smartphone to send back the Payment
>> response and get PaymentAck?
> 
> That's exactly what I have prototyped. I am putting a Bluetooth MAC
> address into the payment_url. Have a look at the TAP TO PAY paragraph
> for details, its mostly the same mechanism.
> 

Same mechanism for both, of course. Sorry, that was obvious. :)

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2606 bytes --]

On Mon, Jan 27, 2014 at 7:18 PM, Andreas Schildbach
<andreas@schildbach.de>wrote:

> I'm not saying I'm against signed payment requests, but unfortunately
> they are just too big for QR-codes. Then again, QR-codes *can* take up
> to 2 KB. How big would a very basic trust chain plus signature be?
>

As I said, the test requests generated by Gavin's generator end up being
about 4kb.

Unfortunately most certs are using RSA keys which aren't very compact. You
can get ECC certs, but for whatever reason, the test requests aren't using
one.


> I was under the impression that addresses will go away. Can you
> elaborate on the mechanism?
>

There's still an address in the URI for backwards compatibility, right? In
theory if everyone some day uses wallets that support BIP70 it'd be
superfluous and could be removed, but whilst it's there, we could find
alternative uses for it ...


> Ok, that's good news (to me). However, you are going to manage trust
> stores (adding and revoking) without TCP?
>

Trust store is just a local database. Why would it involve TCP?


> Well I'm thinking the other way round. Use Bitcoin where its already
> used today -- face to face.
>

Maybe in Berlin :-) Most of my transactions are sadly with online shops,
still.


> > you probably still would like a receipt if you buy
> > something from a local market trader.
>
> Yes, but where is the problem?
>

A receipt is a proof of purchase. If the payment request isn't signed then
it proves nothing as you could have made it yourself. Of course paper
receipts are forgeable too - we sort of pretend receipt
fraud<http://en.wikipedia.org/wiki/Return_fraud>does not exist, but it
does.

Nobody would ever be forced to sign to receive money, obviously, but it's
better if people do as it leads to herd immunity. If people expect to see
it then they will be suspicious if an attacker strips the signing data. If
it's randomly hit/miss then the signing data can just be deleted by a MITM
and you'd never think anything was amiss.

And again, how is he going to provide the payment request to the payer
> without TCP?
>

Over Bluetooth, perhaps. That's what we're talking about, right?


> Interesting, did not know about this BIP. However I don't understand the
> usecase.


It was proposed by the BitPay guys. I think they feel that scanning a QR
code should always make something intelligent happen, even if you don't
(for instance) have a wallet app installed at all. Overloading the URL so
it works for both web browsers and wallet apps is easy, so I can see why
they suggested it. Doesn't seem like a big deal either way.

[-- Attachment #2: Type: text/html, Size: 4880 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Roy Badami]

On Mon, Jan 27, 2014 at 09:11:08AM -0800, Jeremy Spilman wrote:
> On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach  
> <andreas@schildbach.de> wrote:
> 
> > SCAN TO PAY
> > For scan-to-pay, the current landscape looks different. I assume at
> > least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
> > into a QR-code. Nevertheless, I tried to encode a payment request into
> > the bitcoin URL. I used my existing work on encoding transactions into
> > QR-codes. Steps to encode:
> 
> Really interesting work. When using scan-to-pay, after the payer scans the  
> QR code with the protobuf PaymentRequest (not a URL to download the  
> PaymentRequest) are they using their own connectivity to submit the  
> Payment response?
> 
> If we assume connectivity on the phone, might as well just get a URL from  
> the QR code and re-use existing infrastructure for serving that?

My first thought was likewise.  In the case where the phone needs
Internet connectivity anyway, why not include an HTTPS URL in a BIP 72 URL?

I'm assuming that every client will have to support this is any case,
since it's effectively mandated by the BIP, so why add another mode of
operation?

However, PaymentRequest-over-QR-code does seem to me to have one
rather attractive advantage: the authentication model is orders of
magnitude simpler and more intuitive for a face-to-face transaction
than anything else.  You're saying "pay the coins to that thing over
there displaying that QR code".  Which, most of the time, is exactly
what you want.

In the web case, it's fine to ignore the case where the URL domain has
been subverted (and an cert obtained by the attacker) because in that
case you've lost before you even get to payments (MitM attacker shows
you a modified web page with different payment details).  But the
face-to-face case isn't intrinsically dependent on SSL security, and
it's nice not to introduce that attack vector...

roy

[Bitcoin-development] Experiment with linking payment requests via href

[Andreas Schildbach]

On 01/27/2014 07:18 PM, Andreas Schildbach wrote:

>> 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.
> 
> That's a good point. I'll implement this asap.

It doesn't look too good. I've tried Chrome, the AOSP browser and
Firefox. All insist on handling the link with their download manager,
which would involve an additional click. In the case of Chrome and AOSP,
that download manager a separate component that is not updatable with
the browser (rather its tied to the OS version afaik).

If you click on the file in the download manager of Chrome and AOSP it
opens as expected. On Firefox, it just ignores the click.

I registered the correct mime type and also set the mime type of the
href just in case. In case you want to have a look at the href, its on
http://wallet.schildbach.de and links to Gavins generator.

I didn't try suffixes, but I'd assume it behaves similar.

Any ideas what else to try?

Re: [Bitcoin-development] Experiment with linking payment requests via href

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

>
> All insist on handling the link with their download manager, which would
> involve an additional click.


That's the expected behaviour, right? That's why I said "download and
open". The Bitcoin URI with r= is better because it lets you remove that
second click, but in some contexts the file approach is the right way to go
- like for an email attachment or payment request sent via WhatsApp.

[-- Attachment #2: Type: text/html, Size: 637 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Christophe Biocca]

> But the face-to-face case isn't intrinsically dependent on SSL security, and it's nice not to introduce that attack vector...

If the only concern is to make scan-to-pay work without reliance on
SSL's PKI, it might be better to specify the payment protocol url
*and* the public key used for signing right in the qr code. The wallet
connects to the url, fetches the payment request (maybe over a secure
connection, maybe not, doesn't matter), and verifies the signature
matches the public key from the qr code.

Downsides compared to embedding the entire request:
Payee needs to host/serve requests somewhere online. This introduces
reliability and DoS concerns.
Payer needs an internet connection to fetch the request.

Advantages:
Serve variable payment requests from the same qr code (improving
recipient privacy).
Still no hard dependency on CAs. Even if both CA and DNS are
compromised by an attacker, the worst they can do is Denial of
Service.
Optionally use CAs so that the wallet can attach an identity to who
you're paying by QR code. This partly addresses the problem of the
waiter overwriting the QR code. A non-PKI transaction would simply
show "Unknown recipient".
Much smaller QR code (only overhead is the key parameter, and you
could use a boolean param + the "address as public key" hack Mike
mentionned, for only 4 characters of overhead).
No need for a backward-incompatible bitcoin: scheme

On Mon, Jan 27, 2014 at 3:34 PM, Roy Badami <roy@gnomon.org.uk> wrote:
> On Mon, Jan 27, 2014 at 09:11:08AM -0800, Jeremy Spilman wrote:
>> On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach
>> <andreas@schildbach.de> wrote:
>>
>> > SCAN TO PAY
>> > For scan-to-pay, the current landscape looks different. I assume at
>> > least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
>> > into a QR-code. Nevertheless, I tried to encode a payment request into
>> > the bitcoin URL. I used my existing work on encoding transactions into
>> > QR-codes. Steps to encode:
>>
>> Really interesting work. When using scan-to-pay, after the payer scans the
>> QR code with the protobuf PaymentRequest (not a URL to download the
>> PaymentRequest) are they using their own connectivity to submit the
>> Payment response?
>>
>> If we assume connectivity on the phone, might as well just get a URL from
>> the QR code and re-use existing infrastructure for serving that?
>
> My first thought was likewise.  In the case where the phone needs
> Internet connectivity anyway, why not include an HTTPS URL in a BIP 72 URL?
>
> I'm assuming that every client will have to support this is any case,
> since it's effectively mandated by the BIP, so why add another mode of
> operation?
>
> However, PaymentRequest-over-QR-code does seem to me to have one
> rather attractive advantage: the authentication model is orders of
> magnitude simpler and more intuitive for a face-to-face transaction
> than anything else.  You're saying "pay the coins to that thing over
> there displaying that QR code".  Which, most of the time, is exactly
> what you want.
>
> In the web case, it's fine to ignore the case where the URL domain has
> been subverted (and an cert obtained by the attacker) because in that
> case you've lost before you even get to payments (MitM attacker shows
> you a modified web page with different payment details).  But the
> face-to-face case isn't intrinsically dependent on SSL security, and
> it's nice not to introduce that attack vector...
>
> roy
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Andreas Schildbach]

Just a small update. I merged the code to my bitcoinj-0.11 branch and
put up binary .apk files for experimentation. Just make sure to tick
"BIP70 for tap-to-pay/scan-to-pay" in the labs settings.

Source:
https://github.com/schildbach/bitcoin-wallet/commits/bitcoinj-0.11

Binaries:
https://github.com/schildbach/bitcoin-wallet/releases/tag/v3.30-bitcoinj0.11


On 01/27/2014 12:59 PM, Andreas Schildbach wrote:
> As promised I'd like to present my work done on leveraging the payment
> protocol for face-to-face payments. The general assumption is that
> individuals don't own X.509 certificates. Their devices may be only
> badly connected to the internet or in some cases not at all. I've
> implemented a prototype on a branch of Bitcoin Wallet. It is using
> bitcoinj 0.11 (not released).
> 
> https://github.com/schildbach/bitcoin-wallet/commits/payment-protocol

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]

Although it should be noted that these binaries don't yet do URI support so
you can't scan a bitcoin URI with r= in it and see the verified merchant
name, etc. I think Andreas plans to do the UI for that in the next update.


On Thu, Jan 30, 2014 at 11:46 AM, Andreas Schildbach
<andreas@schildbach.de>wrote:

> Just a small update. I merged the code to my bitcoinj-0.11 branch and
> put up binary .apk files for experimentation. Just make sure to tick
> "BIP70 for tap-to-pay/scan-to-pay" in the labs settings.
>
> Source:
> https://github.com/schildbach/bitcoin-wallet/commits/bitcoinj-0.11
>
> Binaries:
>
> https://github.com/schildbach/bitcoin-wallet/releases/tag/v3.30-bitcoinj0.11
>
>
> On 01/27/2014 12:59 PM, Andreas Schildbach wrote:
> > As promised I'd like to present my work done on leveraging the payment
> > protocol for face-to-face payments. The general assumption is that
> > individuals don't own X.509 certificates. Their devices may be only
> > badly connected to the internet or in some cases not at all. I've
> > implemented a prototype on a branch of Bitcoin Wallet. It is using
> > bitcoinj 0.11 (not released).
> >
> > https://github.com/schildbach/bitcoin-wallet/commits/payment-protocol
>
>
>
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends.  Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 3003 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Andreas Schildbach]

I have refreshed the Bitcoin Wallet preview version with beta version
3.32. It now implements BIP72 aka "URI extension for payment protocol".

There is one important deviation from the standard though: Bitcoin URI
address and amount fields need to correspond to the data from the
payment request. The makes sure the signature really signs the URI
(which you've gotten directly from the payee) and not a malicious
payment request introduced by a MITM. Note the memo isn't protected like
that, so it can still be MITM'ed.

I know this means that for the time being Bitcoin URIs must be
"backwards compatible". That should not be an issue since we will be in
transition phase for many months anyway. Until then, I hope we will have
agreed on a more sophisticated approach, e.g. a separate hash in the URI.

Source:
https://github.com/schildbach/bitcoin-wallet/commits/v3.32

Binaries:
https://github.com/schildbach/bitcoin-wallet/releases/tag/v3.32
(also published to the corresponding channels on Google Play)


On 01/30/2014 11:46 AM, Andreas Schildbach wrote:
> Just a small update. I merged the code to my bitcoinj-0.11 branch and
> put up binary .apk files for experimentation. Just make sure to tick
> "BIP70 for tap-to-pay/scan-to-pay" in the labs settings.
> 
> Source:
> https://github.com/schildbach/bitcoin-wallet/commits/bitcoinj-0.11
> 
> Binaries:
> https://github.com/schildbach/bitcoin-wallet/releases/tag/v3.30-bitcoinj0.11
> 
> 
> On 01/27/2014 12:59 PM, Andreas Schildbach wrote:
>> As promised I'd like to present my work done on leveraging the payment
>> protocol for face-to-face payments. The general assumption is that
>> individuals don't own X.509 certificates. Their devices may be only
>> badly connected to the internet or in some cases not at all. I've
>> implemented a prototype on a branch of Bitcoin Wallet. It is using
>> bitcoinj 0.11 (not released).
>>
>> https://github.com/schildbach/bitcoin-wallet/commits/payment-protocol
> 
> 
> 
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable 
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends.  Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> 

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Andreas Schildbach]

I've written up a document about all the different methods on how the
payment protocol (both the old one and BIP70) is used in Bitcoin Wallet.
It only provides an overview -- I plan to go into details with separate
(BIP?) documents where needed.

https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests

If you have any questions about compatibility, don't hesitate to contact me.


On 01/27/2014 12:59 PM, Andreas Schildbach wrote:

> As promised I'd like to present my work done on leveraging the payment
> protocol for face-to-face payments.
> [...]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 204 bytes --]

Thanks Andreas.

For BIP standardisation, I think the VIEW intent seems like an obvious one.
Bluetooth support probably should come later if/when we put encryption/auth
on the RFCOMM link (probably SSL).

[-- Attachment #2: Type: text/html, Size: 323 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 2401 bytes --]

Hi Andreas


I'm implementing support for BIP70 in my POS at the moment, and I've just
realized that with options you're proposing usecase I'm looking for is not
covered.

Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I
need to still be able to use it for backwards compatibility. But at the
same time I want to be able to support BIP70. And also I want to avoid
using external servers, the concept of my POS is that everything is
happening between just payer's phone and payee's POS device. This means
that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me.

You're also offering an option to include Base43 encoded PR body right
inside the Bitcoin URI, but in a way that is not backwards compatible with
BIP21.

In the end this all means that there is no way for me to at the same time
keep backwards compatibility with all wallets not supporting NFC and BIP70
(all other wallets right now), and keep things inside POS without need for
external servers.

I understand your intention behind base43 encoding and noncompatible URI -
you want to make most possible use of QR codes. But I wonder - did you
compare this base43 to base64 encoded request in a binary QR code format?
How much do we actually win in total bytes capacity at a price of
noncompatibility and increased complexity?

And also maybe we can extend BIP72 to include encoded payment request in
the URL directly in a backwards compatible way?


Best regards,
Alex Kotenko


2014-03-02 11:50 GMT+00:00 Mike Hearn <mike@plan99.net>:

> Thanks Andreas.
>
> For BIP standardisation, I think the VIEW intent seems like an obvious
> one. Bluetooth support probably should come later if/when we put
> encryption/auth on the RFCOMM link (probably SSL).
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 4888 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 3350 bytes --]

Take a look at BIP 73:
https://github.com/bitcoin/bips/blob/master/bip-0073.mediawiki




On Wed, Mar 19, 2014 at 10:22 PM, Alex Kotenko <alexykot@gmail.com> wrote:

> Hi Andreas
>
>
> I'm implementing support for BIP70 in my POS at the moment, and I've just
> realized that with options you're proposing usecase I'm looking for is not
> covered.
>
> Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I
> need to still be able to use it for backwards compatibility. But at the
> same time I want to be able to support BIP70. And also I want to avoid
> using external servers, the concept of my POS is that everything is
> happening between just payer's phone and payee's POS device. This means
> that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me.
>
> You're also offering an option to include Base43 encoded PR body right
> inside the Bitcoin URI, but in a way that is not backwards compatible with
> BIP21.
>
> In the end this all means that there is no way for me to at the same time
> keep backwards compatibility with all wallets not supporting NFC and BIP70
> (all other wallets right now), and keep things inside POS without need for
> external servers.
>
> I understand your intention behind base43 encoding and noncompatible URI -
> you want to make most possible use of QR codes. But I wonder - did you
> compare this base43 to base64 encoded request in a binary QR code format?
> How much do we actually win in total bytes capacity at a price of
> noncompatibility and increased complexity?
>
> And also maybe we can extend BIP72 to include encoded payment request in
> the URL directly in a backwards compatible way?
>
>
> Best regards,
> Alex Kotenko
>
>
> 2014-03-02 11:50 GMT+00:00 Mike Hearn <mike@plan99.net>:
>
>>  Thanks Andreas.
>>
>> For BIP standardisation, I think the VIEW intent seems like an obvious
>> one. Bluetooth support probably should come later if/when we put
>> encryption/auth on the RFCOMM link (probably SSL).
>>
>>
>> ------------------------------------------------------------------------------
>> Flow-based real-time traffic analytics software. Cisco certified tool.
>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
>> Customize your own dashboards, set traffic alerts and generate reports.
>> Network behavioral analysis & security monitoring. All-in-one tool.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

[-- Attachment #2: Type: text/html, Size: 6556 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Andreas Schildbach]

On 03/20/2014 03:22 AM, Alex Kotenko wrote:
> Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I
> need to still be able to use it for backwards compatibility. But at the
> same time I want to be able to support BIP70. And also I want to avoid
> using external servers, the concept of my POS is that everything is
> happening between just payer's phone and payee's POS device. This means
> that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me.

We could use Bluetooth in the "r" parameter, not unlike we use Bluetooth
in the payment_url. However, since multiple devices could access your
machine at the same time, we need some for of adressibility of different
payment requests. Something like
"bt:<btmac>-<random_id_of_payment_request>".

> You're also offering an option to include Base43 encoded PR body right
> inside the Bitcoin URI, but in a way that is not backwards compatible
> with BIP21.

Well, do we need to be compatible? If the dev community decides Base43
PR QR's (or whatever other self-contained format) is the way to go, we
just implement, roll it out and use it.

> I understand your intention behind base43 encoding and noncompatible URI
> - you want to make most possible use of QR codes. But I wonder - did you
> compare this base43 to base64 encoded request in a binary QR code
> format? How much do we actually win in total bytes capacity at a price
> of noncompatibility and increased complexity?

Alphanumeric QR codes have an alphabet of 45 chars, of which I am using
43. I skipped Space and '%' because they're not allowed in URIs. When I
invented the Base43 format back in 2011, wanted it to be URI compatible
so we can use the Android intent dispatcher.

If we let go of the URI requirement, we can use binary QR codes as well.
This means users will always have to manually start their Bitcoin app
first. (Also, there is an implementation issue with the ZXing scanner
I'm using, it returns Strings rather than a byte array so it will choke
on \0 characters.)

> And also maybe we can extend BIP72 to include encoded payment request in
> the URL directly in a backwards compatible way?

I took this into consideration. It would be space inefficient.

The Base58-encoded address from BIP21 forces the QR code into binary
mode. Still you can't encode the payment request extension (probably an
URL parameter) as binary because it needs to stay compatible to the URI
standard (RFC 3986). You could use one of the Base64 variants for the PR
in this case, but still it would be inefficient.

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Andreas Schildbach]

Afaik, BIP73 needs an external server (the web server).


On 03/20/2014 04:31 AM, Jeff Garzik wrote:
> Take a look at BIP 73:
> https://github.com/bitcoin/bips/blob/master/bip-0073.mediawiki
> 
> 
> 
> 
> On Wed, Mar 19, 2014 at 10:22 PM, Alex Kotenko <alexykot@gmail.com
> <mailto:alexykot@gmail.com>> wrote:
> 
>     Hi Andreas
> 
> 
>     I'm implementing support for BIP70 in my POS at the moment, and I've
>     just realized that with options you're proposing usecase I'm looking
>     for is not covered.
> 
>     Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code,
>     and I need to still be able to use it for backwards compatibility.
>     But at the same time I want to be able to support BIP70. And also I
>     want to avoid using external servers, the concept of my POS is that
>     everything is happening between just payer's phone and payee's POS
>     device. This means that BIP72 HTTP(S) link inside Bitcoin URI is not
>     suitable for me. 
> 
>     You're also offering an option to include Base43 encoded PR body
>     right inside the Bitcoin URI, but in a way that is not backwards
>     compatible with BIP21. 
> 
>     In the end this all means that there is no way for me to at the same
>     time keep backwards compatibility with all wallets not supporting
>     NFC and BIP70 (all other wallets right now), and keep things inside
>     POS without need for external servers. 
> 
>     I understand your intention behind base43 encoding and noncompatible
>     URI - you want to make most possible use of QR codes. But I wonder -
>     did you compare this base43 to base64 encoded request in a binary QR
>     code format? How much do we actually win in total bytes capacity at
>     a price of noncompatibility and increased complexity?
> 
>     And also maybe we can extend BIP72 to include encoded payment
>     request in the URL directly in a backwards compatible way?
> 
> 
>     Best regards, 
>     Alex Kotenko
> 
> 
>     2014-03-02 11:50 GMT+00:00 Mike Hearn <mike@plan99.net
>     <mailto:mike@plan99.net>>:
> 
>         Thanks Andreas.
> 
>         For BIP standardisation, I think the VIEW intent seems like an
>         obvious one. Bluetooth support probably should come later
>         if/when we put encryption/auth on the RFCOMM link (probably SSL).
> 
>         ------------------------------------------------------------------------------
>         Flow-based real-time traffic analytics software. Cisco certified
>         tool.
>         Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow
>         Analyzer
>         Customize your own dashboards, set traffic alerts and generate
>         reports.
>         Network behavioral analysis & security monitoring. All-in-one tool.
>         http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> 
>         _______________________________________________
>         Bitcoin-development mailing list
>         Bitcoin-development@lists.sourceforge.net
>         <mailto:Bitcoin-development@lists.sourceforge.net>
>         https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
>     ------------------------------------------------------------------------------
>     Learn Graph Databases - Download FREE O'Reilly Book
>     "Graph Databases" is the definitive new guide to graph databases and
>     their
>     applications. Written by three acclaimed leaders in the field,
>     this first edition is now available. Download your free book today!
>     http://p.sf.net/sfu/13534_NeoTech
>     _______________________________________________
>     Bitcoin-development mailing list
>     Bitcoin-development@lists.sourceforge.net
>     <mailto:Bitcoin-development@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
> 
> -- 
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
> 
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

Encoding entire payment requests into qrcodes is definitely not the way to
go. They can already be large when signed and we're just at the start of
adding features.

Finishing off and standardising the bluetooth support is the way to go
(r=bt:mac). Andreas' app already has some support for this I believe, so
Alex you could prototype with that, but we need to:

1) Add an encryption/auth layer on top, because it runs over RFCOMM
sockets. The authentication would require proof of owning the Bitcoin key
that's in the address part of the URI (which is needed for backwards compat
anyway).

2) Write a BIP for it and make sure it's interoperable

For the auth layer we could either use SSL and then just ignore the server
certificate and require signing of the session public key with the Bitcoin
key, which should be easy to code up but is rather heavy on the air, or
roll a custom lightweight thing where we just do a basic ECDH, with the
servers key being the same as the address key. But rolling such protocols
is subtle and I guess it'd need to be reviewed by people familiar with such
things.

This feels like a good opportunity to grow the community - perhaps we can
find a volunteer in the forums who enjoys crypto.

[-- Attachment #2: Type: text/html, Size: 1625 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Adam Back]

Whats a sensible limit on practical/convenient QR code size?

How much of the payment protocol message size comes from use of x509?

(Just exploring what the options are).

Adam

On Thu, Mar 20, 2014 at 11:36:09AM +0100, Mike Hearn wrote:
>   Encoding entire payment requests into qrcodes is definitely not the way
>   to go. They can already be large when signed and we're just at the
>   start of adding features.
>   Finishing off and standardising the bluetooth support is the way to go
>   (r=bt:mac). Andreas' app already has some support for this I believe,
>   so Alex you could prototype with that, but we need to:
>   1) Add an encryption/auth layer on top, because it runs over RFCOMM
>   sockets. The authentication would require proof of owning the Bitcoin
>   key that's in the address part of the URI (which is needed for
>   backwards compat anyway).
>   2) Write a BIP for it and make sure it's interoperable
>   For the auth layer we could either use SSL and then just ignore the
>   server certificate and require signing of the session public key with
>   the Bitcoin key, which should be easy to code up but is rather heavy on
>   the air, or roll a custom lightweight thing where we just do a basic
>   ECDH, with the servers key being the same as the address key. But
>   rolling such protocols is subtle and I guess it'd need to be reviewed
>   by people familiar with such things.
>   This feels like a good opportunity to grow the community - perhaps we
>   can find a volunteer in the forums who enjoys crypto.

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2753 bytes --]

Very, very limited. The more data you stuff in them, the less reliable and
slower scanning becomes. A URL is about the limit of what's practically
achievable. Even with that, BitPay have been complaining about the
increased character length from adding the https url to download the
payment request (though not escaping reduces character count by a lot and
is valid).

X.509 is extremely bloated, partly due to the number of features it
supports, partly due to its history but mostly due to the widespread use of
RSA which generates giant keys and signatures. Of course you can get ECC
certs as well, but in practice most merchants don't seem to use them yet.
There's no way you can fit a cert chain into a QR code.

However, this is no big deal, because for the serverless PoS device case
Alex cares about you need a backchannel to submit the transaction and
refund address anyway, so Bluetooth is already useful/required. Downloading
the payment request via it as well as uploading the response is not a big
change and - as mentioned - already implemented by Andreas and myself some
time ago.



On Thu, Mar 20, 2014 at 1:12 PM, Adam Back <adam@cypherspace.org> wrote:

> Whats a sensible limit on practical/convenient QR code size?
>
> How much of the payment protocol message size comes from use of x509?
>
> (Just exploring what the options are).
>
> Adam
>
>
> On Thu, Mar 20, 2014 at 11:36:09AM +0100, Mike Hearn wrote:
>
>>   Encoding entire payment requests into qrcodes is definitely not the way
>>   to go. They can already be large when signed and we're just at the
>>   start of adding features.
>>   Finishing off and standardising the bluetooth support is the way to go
>>   (r=bt:mac). Andreas' app already has some support for this I believe,
>>   so Alex you could prototype with that, but we need to:
>>   1) Add an encryption/auth layer on top, because it runs over RFCOMM
>>   sockets. The authentication would require proof of owning the Bitcoin
>>   key that's in the address part of the URI (which is needed for
>>   backwards compat anyway).
>>   2) Write a BIP for it and make sure it's interoperable
>>   For the auth layer we could either use SSL and then just ignore the
>>   server certificate and require signing of the session public key with
>>   the Bitcoin key, which should be easy to code up but is rather heavy on
>>   the air, or roll a custom lightweight thing where we just do a basic
>>   ECDH, with the servers key being the same as the address key. But
>>   rolling such protocols is subtle and I guess it'd need to be reviewed
>>   by people familiar with such things.
>>   This feels like a good opportunity to grow the community - perhaps we
>>   can find a volunteer in the forums who enjoys crypto.
>>
>

[-- Attachment #2: Type: text/html, Size: 3459 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 5183 bytes --]

2014-03-20 8:08 GMT+00:00 Andreas Schildbach <andreas@schildbach.de>:

> On 03/20/2014 03:22 AM, Alex Kotenko wrote:
> > Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I
> > need to still be able to use it for backwards compatibility. But at the
> > same time I want to be able to support BIP70. And also I want to avoid
> > using external servers, the concept of my POS is that everything is
> > happening between just payer's phone and payee's POS device. This means
> > that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me.
>
> We could use Bluetooth in the "r" parameter, not unlike we use Bluetooth
> in the payment_url. However, since multiple devices could access your
> machine at the same time, we need some for of adressibility of different
> payment requests. Something like
> "bt:<btmac>-
> ​​
> <random_id_of_payment_request>".

​I guess this would be best option​. I'm also worried about potential QR
code capacity, since as I imagine we can encounter device that has your
Wallet installed and bluetooth enabled, but no NFC available, so we will
have to operate via onscreen QR codes + bluetooth.
Hmm, if we're inventing an URI for bluetooth, I'd rather follow existing
URI's patterns. BT is strictly point-to-point connection, so BT MAC should
be considered as server address, and payment request ID can be considered
as request path. Probably "bt:<bt-mac>/​<random_id_of_payment_request>"
would be more usual and easily understandable.
Really I don't think my PoS will now support multiple simultaneous
payments, but it's good to have this thing in place for the time I will
need it.
I wonder how complex it would be to implement HTTP-over-Bluetooth. Not like
I'm willing to do that now, but HTTP is well known and proven to be quite
good for tasks like this, so in theory it would be handy to have such
capacities in here.



>  > You're also offering an option to include Base43 encoded PR body right
> > inside the Bitcoin URI, but in a way that is not backwards compatible
> > with BIP21.
>
> Well, do we need to be compatible? If the dev community decides Base43
> PR QR's (or whatever other self-contained format) is the way to go, we
> just implement, roll it out and use it.
>
My PoS needs to be compatible with BIP21, as when I'm presenting QR code or
sending NFC message - I have no way to tell what wallet/phone is ​​on the
accepting side, so I have to be compatible to existing widely supported
technologies.


> I understand your intention behind base43 encoding and noncompatible URI
> > - you want to make most possible use of QR codes. But I wonder - did you
> > compare this base43 to base64 encoded request in a binary QR code
> > format? How much do we actually win in total bytes capacity at a price
> > of noncompatibility and increased complexity?
>
> Alphanumeric QR codes have an alphabet of 45 chars, of which I am using
> 43. I skipped Space and '%' because they're not allowed in URIs. When I
> invented the Base43 format back in 2011, wanted it to be URI compatible
> so we can use the Android intent dispatcher.
>
> If we let go of the URI requirement, we can use binary QR codes as well.
> This means users will always have to manually start their Bitcoin app
> first. (Also, there is an implementation issue with the ZXing scanner
> I'm using, it returns Strings rather than a byte array so it will choke
> on \0 characters.)
>


> > And also maybe we can extend BIP72 to include encoded payment request in
> > the URL directly in a backwards compatible way?
>
> I took this into consideration. It would be space inefficient.
>
> The Base58-encoded address from BIP21 forces the QR code into binary
> mode. Still you can't encode the payment request extension (probably an
> URL parameter) as binary because it needs to stay compatible to the URI
> standard (RFC 3986). You could use one of the Base64 variants for the PR
> in this case, but still it would be inefficient.

​Well, yes, it would be less efficient than base43. But did you calculate
how much less? ​It's a compatible and already widely used way and loosing
compatibility needs to have serious reasons, so would be great to know
exact figures here.

I can find out base64 size, but I don't have a working base43
implementation (since the only existing is in Java, and I don't speak it).
Can you give me a sample uncompressed PR file of moderate size and a base43
encoded version of it? And I'll convert it into base64 and compare.



------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 8340 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Jeff Garzik]

On Thu, Mar 20, 2014 at 8:12 AM, Adam Back <adam@cypherspace.org> wrote:
> Whats a sensible limit on practical/convenient QR code size?

Extremely limited.  Preferably under 100 bytes.  You will see
increasingly poor operating in varying light conditions, such as
paying via QR code on a printed receipt in a pub at night.  That was
one of the motivations for BIP 73.


On Thu, Mar 20, 2014 at 4:09 AM, Andreas Schildbach
<andreas@schildbach.de> wrote:
> Afaik, BIP73 needs an external server (the web server).

Yes.  Internet connectivity is not a rarity these days.  Near-field
web servers also work fine.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]

2014-03-20 17:31 GMT+00:00 Jeff Garzik <jgarzik@bitpay.com>:

> On Thu, Mar 20, 2014 at 8:12 AM, Adam Back <adam@cypherspace.org> wrote:
> > Whats a sensible limit on practical/convenient QR code size?
>
> Extremely limited.  Preferably under 100 bytes.  You will see
> increasingly poor operating in varying light conditions, such as
> paying via QR code on a printed receipt in a pub at night.  That was
> one of the motivations for BIP 73.
>
​Hmm, in this case I think base43 discussion is irrelevant. Even with best
space utilization we can get ​we will not be able to fit in anything bigger
than a smallest unsigned payment certificate. And that is not so useful. So
probably we should stick with BIP73 approach and bluetooth URI scheme we're
inventing.



>
>
> On Thu, Mar 20, 2014 at 4:09 AM, Andreas Schildbach
> <andreas@schildbach.de> wrote:
> > Afaik, BIP73 needs an external server (the web server).
>
> Yes.  Internet connectivity is not a rarity these days.  Near-field
> web servers also work fine.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 3128 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Jeff Garzik]

It really depends on the physical, real world size of the QR code.

If you have a big screen, and security permits displaying a larger QR
code, you can afford more bytes.  If you are displaying a tiny postage
stamp 1-2cm in size, the practical byte limit is very low.

Ideally, you test your QR codes in real world conditions, before
picking the best path.



On Thu, Mar 20, 2014 at 1:42 PM, Alex Kotenko <alexykot@gmail.com> wrote:
> 2014-03-20 17:31 GMT+00:00 Jeff Garzik <jgarzik@bitpay.com>:
>>
>> On Thu, Mar 20, 2014 at 8:12 AM, Adam Back <adam@cypherspace.org> wrote:
>> > Whats a sensible limit on practical/convenient QR code size?
>>
>> Extremely limited.  Preferably under 100 bytes.  You will see
>> increasingly poor operating in varying light conditions, such as
>> paying via QR code on a printed receipt in a pub at night.  That was
>> one of the motivations for BIP 73.
>
> Hmm, in this case I think base43 discussion is irrelevant. Even with best
> space utilization we can get we will not be able to fit in anything bigger
> than a smallest unsigned payment certificate. And that is not so useful. So
> probably we should stick with BIP73 approach and bluetooth URI scheme we're
> inventing.
>
>
>>
>>
>>
>> On Thu, Mar 20, 2014 at 4:09 AM, Andreas Schildbach
>> <andreas@schildbach.de> wrote:
>> > Afaik, BIP73 needs an external server (the web server).
>>
>> Yes.  Internet connectivity is not a rarity these days.  Near-field
>> web servers also work fine.
>>
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc.      https://bitpay.com/
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 2248 bytes --]

Hmm, is there any other way to do it? Can we provide a signed payment
request and verify the sign on receiving side and this way protect from
bluetooth MitM attack? Quick googling showed that SSL over bluetooth isn't
a very well developed area, and my own skills are not enough to quickly
implement a reliable secure solution here.


2014-03-20 10:36 GMT+00:00 Mike Hearn <mike@plan99.net>:

> Encoding entire payment requests into qrcodes is definitely not the way to
> go. They can already be large when signed and we're just at the start of
> adding features.
>
> Finishing off and standardising the bluetooth support is the way to go
> (r=bt:mac). Andreas' app already has some support for this I believe, so
> Alex you could prototype with that, but we need to:
>
> 1) Add an encryption/auth layer on top, because it runs over RFCOMM
> sockets. The authentication would require proof of owning the Bitcoin key
> that's in the address part of the URI (which is needed for backwards compat
> anyway).
>
> 2) Write a BIP for it and make sure it's interoperable
>
> For the auth layer we could either use SSL and then just ignore the server
> certificate and require signing of the session public key with the Bitcoin
> key, which should be easy to code up but is rather heavy on the air, or
> roll a custom lightweight thing where we just do a basic ECDH, with the
> servers key being the same as the address key. But rolling such protocols
> is subtle and I guess it'd need to be reviewed by people familiar with such
> things.
>
> This feels like a good opportunity to grow the community - perhaps we can
> find a volunteer in the forums who enjoys crypto.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 3340 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 3048 bytes --]

With Java, in theory, you can use SSLSocketFactory.createSocket(btsocket,
address, 1234, true) to wrap a bluetooth socket in SSL. However I have not
tried it.

For now, just prototype and build your product without the security. We can
find someone to experiment with this, if you don't want to .

Bluetooth needs encryption and MACs as well as signing to be secure,
because there could be radio MITM. Yes, this overlaps somewhat with the PKI
signing in BIP70, but not entirely - you might want to serve unsigned
payment requests, but still have confidentiality and authenticity for a
local face to face transaction. The signing and encryption does different
things.


On Thu, Mar 20, 2014 at 7:20 PM, Alex Kotenko <alexykot@gmail.com> wrote:

> Hmm, is there any other way to do it? Can we provide a signed payment
> request and verify the sign on receiving side and this way protect from
> bluetooth MitM attack? Quick googling showed that SSL over bluetooth isn't
> a very well developed area, and my own skills are not enough to quickly
> implement a reliable secure solution here.
>
>
> 2014-03-20 10:36 GMT+00:00 Mike Hearn <mike@plan99.net>:
>
>> Encoding entire payment requests into qrcodes is definitely not the way
>> to go. They can already be large when signed and we're just at the start of
>> adding features.
>>
>> Finishing off and standardising the bluetooth support is the way to go
>> (r=bt:mac). Andreas' app already has some support for this I believe, so
>> Alex you could prototype with that, but we need to:
>>
>> 1) Add an encryption/auth layer on top, because it runs over RFCOMM
>> sockets. The authentication would require proof of owning the Bitcoin key
>> that's in the address part of the URI (which is needed for backwards compat
>> anyway).
>>
>> 2) Write a BIP for it and make sure it's interoperable
>>
>> For the auth layer we could either use SSL and then just ignore the
>> server certificate and require signing of the session public key with the
>> Bitcoin key, which should be easy to code up but is rather heavy on the
>> air, or roll a custom lightweight thing where we just do a basic ECDH, with
>> the servers key being the same as the address key. But rolling such
>> protocols is subtle and I guess it'd need to be reviewed by people familiar
>> with such things.
>>
>> This feels like a good opportunity to grow the community - perhaps we can
>> find a volunteer in the forums who enjoys crypto.
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4519 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 3687 bytes --]

We'll see how it will go, maybe I will get to implement this somewhere soon.

Yes, I'm thinking exactly about radio MitM attacks possible with bluetooth.
I'll also look into using PKI inside the PoS for the merchant. It would be
great user experience if we would be able to provide a signed payment
request with human recognizable merchant identity name in the way you
described much earlier in Bitcoin 0.9 FAQ. ​


2014-03-20 18:31 GMT+00:00 Mike Hearn <mike@plan99.net>:

> With Java, in theory, you can use SSLSocketFactory.createSocket(btsocket,
> address, 1234, true) to wrap a bluetooth socket in SSL. However I have not
> tried it.
>
> For now, just prototype and build your product without the security. We
> can find someone to experiment with this, if you don't want to .
>
> Bluetooth needs encryption and MACs as well as signing to be secure,
> because there could be radio MITM. Yes, this overlaps somewhat with the PKI
> signing in BIP70, but not entirely - you might want to serve unsigned
> payment requests, but still have confidentiality and authenticity for a
> local face to face transaction. The signing and encryption does different
> things.
>
>
> On Thu, Mar 20, 2014 at 7:20 PM, Alex Kotenko <alexykot@gmail.com> wrote:
>
>> Hmm, is there any other way to do it? Can we provide a signed payment
>> request and verify the sign on receiving side and this way protect from
>> bluetooth MitM attack? Quick googling showed that SSL over bluetooth isn't
>> a very well developed area, and my own skills are not enough to quickly
>> implement a reliable secure solution here.
>>
>>
>> 2014-03-20 10:36 GMT+00:00 Mike Hearn <mike@plan99.net>:
>>
>>> Encoding entire payment requests into qrcodes is definitely not the way
>>> to go. They can already be large when signed and we're just at the start of
>>> adding features.
>>>
>>> Finishing off and standardising the bluetooth support is the way to go
>>> (r=bt:mac). Andreas' app already has some support for this I believe, so
>>> Alex you could prototype with that, but we need to:
>>>
>>> 1) Add an encryption/auth layer on top, because it runs over RFCOMM
>>> sockets. The authentication would require proof of owning the Bitcoin key
>>> that's in the address part of the URI (which is needed for backwards compat
>>> anyway).
>>>
>>> 2) Write a BIP for it and make sure it's interoperable
>>>
>>> For the auth layer we could either use SSL and then just ignore the
>>> server certificate and require signing of the session public key with the
>>> Bitcoin key, which should be easy to code up but is rather heavy on the
>>> air, or roll a custom lightweight thing where we just do a basic ECDH, with
>>> the servers key being the same as the address key. But rolling such
>>> protocols is subtle and I guess it'd need to be reviewed by people familiar
>>> with such things.
>>>
>>> This feels like a good opportunity to grow the community - perhaps we
>>> can find a volunteer in the forums who enjoys crypto.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and
>>> their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/13534_NeoTech
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 5654 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Roy Badami]

On Thu, Mar 20, 2014 at 07:31:27PM +0100, Mike Hearn wrote:

> Yes, this overlaps somewhat with the PKI signing in BIP70, but not
> entirely - you might want to serve unsigned payment requests, but
> still have confidentiality and authenticity for a local face to face
> transaction. The signing and encryption does different things

I'm not sure if this what you're getting at, but in a common
face-to-face scenario, it really doesn't overlap so much (in that the
PKI in BIP70 isn't really helpful).

It's not unusual, in a face-to-face transaction at a bricks-and-mortar
establishment, that you know neither the legal name of the entity
running the establishment, nor any electronic identifier (domain name,
email address) that might be presented to you in an X.509 certificate,
even if such a certificate is presented in the PaymentRequest.

In many cases I want/need to simply be assured that I am paying "the
person/organisation which operates that machine behind the counter,
right there".

In many ways I'll miss the simplicity of BIP21 QR codes for
face-to-face transactions - because in this use case the payment
protocol complicates (and in many cases weakens) the assurance that
you really are paying the entity that prepared the QR code.

roy

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

>
> It's not unusual, in a face-to-face transaction at a bricks-and-mortar
> establishment, that you know neither the legal name of the entity
> running the establishment


I'd hope that people can get certs for their actual business name, but
sometimes it does differ yes.

However remember that signing in BIP70 is about more than just security,
though that's the driving factor. It's also needed for things like dispute
mediation, receipts, etc.

[-- Attachment #2: Type: text/html, Size: 719 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Andreas Schildbach]

On 03/20/2014 05:14 PM, Alex Kotenko wrote:

> Hmm, if we're inventing an URI for bluetooth, I'd rather follow existing
> URI's patterns. BT is strictly point-to-point connection, so BT MAC
> should be considered as server address, and payment request ID can be
> considered as request path. Probably "bt:<bt-mac>/​
> <random_id_of_payment_request>" would be more usual and easily
> understandable.

Agreed. I used the dash because I feared a slash would need to be
escaped if used in an URL parameter.

> I wonder how complex it would be to implement HTTP-over-Bluetooth. Not
> like I'm willing to do that now, but HTTP is well known and proven to be
> quite good for tasks like this, so in theory it would be handy to have
> such capacities in here.

Thought of that as well. On the other hand, HTTP might be overkill and
we inherit its potential downsides as well.

>     Well, do we need to be compatible? If the dev community decides Base43
>     PR QR's (or whatever other self-contained format) is the way to go, we
>     just implement, roll it out and use it.
> 
> My PoS needs to be compatible with BIP21, as when I'm presenting QR code
> or sending NFC message - I have no way to tell what wallet/phone is ​​on
> the accepting side, so I have to be compatible to existing widely
> supported technologies.

Agreed. All I wanted to say support for QR is still small enough that we
might be able to switch to an incompatible standard. If we're determined
that is.

> ​Well, yes, it would be less efficient than base43. But did you
> calculate how much less? ​It's a compatible and already widely used way
> and loosing compatibility needs to have serious reasons, so would be
> great to know exact figures here.

Base 64 via binary QR:   64 chars / 256 chars
                         ==> 6 bit / 8 bit = 0.75

Base 43 via alphanum QR: 43 chars / 45 chars
                         ==> 5.43 bit / 5.49 bit = 0.99

That would be efficiency in terms of PR data size vs. amount space used
in a QR code. Of course, the visual QR encoding also plays a role, for
example its size is increased in discrete steps.

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Andreas Schildbach]

On 03/20/2014 01:12 PM, Adam Back wrote:

> Whats a sensible limit on practical/convenient QR code size?

Technically 3 KB. In my experience codes above 1.5 KB become impossible
to scan (ZXing scanner, 3 years ago). You will want to stay below 500
bytes for convenient scanning. That said, I'm convinced there is a lot
of room for scanning improvements.

> How much of the payment protocol message size comes from use of x509?

As said in the OP, a minimal PR uses 50 bytes. X.509 seems to put about
4000 bytes on top of that.

As you can see, we have quite some room for improvements to PR payload
(PaymentDetails). X.509 certification will probably not be possible via
QR, at least not until specialized CA's will issue space-efficient certs
(using ECDSA?).

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Andreas Schildbach]

On 03/20/2014 06:31 PM, Jeff Garzik wrote:

>> Afaik, BIP73 needs an external server (the web server).
> 
> Yes.  Internet connectivity is not a rarity these days.  Near-field
> web servers also work fine.

Unfortunately it still is. At least here in Germany.

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Andreas Schildbach]

+1

I couldn't do a better job at describing my motivation behind trying to
stuff payment requests into QR codes.


On 03/20/2014 10:52 PM, Roy Badami wrote:
> On Thu, Mar 20, 2014 at 07:31:27PM +0100, Mike Hearn wrote:
> 
>> Yes, this overlaps somewhat with the PKI signing in BIP70, but not
>> entirely - you might want to serve unsigned payment requests, but
>> still have confidentiality and authenticity for a local face to face
>> transaction. The signing and encryption does different things
> 
> I'm not sure if this what you're getting at, but in a common
> face-to-face scenario, it really doesn't overlap so much (in that the
> PKI in BIP70 isn't really helpful).
> 
> It's not unusual, in a face-to-face transaction at a bricks-and-mortar
> establishment, that you know neither the legal name of the entity
> running the establishment, nor any electronic identifier (domain name,
> email address) that might be presented to you in an X.509 certificate,
> even if such a certificate is presented in the PaymentRequest.
> 
> In many cases I want/need to simply be assured that I am paying "the
> person/organisation which operates that machine behind the counter,
> right there".
> 
> In many ways I'll miss the simplicity of BIP21 QR codes for
> face-to-face transactions - because in this use case the payment
> protocol complicates (and in many cases weakens) the assurance that
> you really are paying the entity that prepared the QR code.
> 
> roy
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> 

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Adam Back]

Maybe its time to explore raw ECDSA signed message based certs.

btw I dont think its quite 4kB.  eg bitpay's looks to be about 1.5kB in der
format.  And they contain a 2048-bit RSA server key, and 2048-bit RSA
signatures (256byte each right there = 512bytes).  And even 2048 is weaker
than 256-bit ECDSA.

Adam

On Fri, Mar 21, 2014 at 11:25:59AM +0100, Andreas Schildbach wrote:
>On 03/20/2014 01:12 PM, Adam Back wrote:
>
>> Whats a sensible limit on practical/convenient QR code size?
>
>Technically 3 KB. In my experience codes above 1.5 KB become impossible
>to scan (ZXing scanner, 3 years ago). You will want to stay below 500
>bytes for convenient scanning. That said, I'm convinced there is a lot
>of room for scanning improvements.
>
>> How much of the payment protocol message size comes from use of x509?
>
>As said in the OP, a minimal PR uses 50 bytes. X.509 seems to put about
>4000 bytes on top of that.
>
>As you can see, we have quite some room for improvements to PR payload
>(PaymentDetails). X.509 certification will probably not be possible via
>QR, at least not until specialized CA's will issue space-efficient certs
>(using ECDSA?).

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]

On Fri, Mar 21, 2014 at 11:59 AM, Adam Back <adam@cypherspace.org> wrote:

> Maybe its time to explore raw ECDSA signed message based certs.
>

If you want to create and run a new CA, by all means. But I bet you don't.
So we're stuck with the current system for now.


> btw I dont think its quite 4kB.  eg bitpay's looks to be about 1.5kB in der
> format.  And they contain a 2048-bit RSA server key, and 2048-bit RSA
> signatures (256byte each right there = 512bytes).  And even 2048 is weaker
> than 256-bit ECDSA.


But you have to chain up to the root.

The only reason more certs aren't ECC is backwards compatibility. Some old
browsers don't know how to handle them. It wasn't so long ago that Fedora
and Android were deleting ECC code from upstream libraries before shipping
them, either for patent reasons for disk space saving measures.

But it's possible to get ECC certs if you want. For example, Entrust is
starting to sell them:

http://www.entrust.net/ecc-certs/index.htm

But their intermediate cert is still RSA. My understanding is that ECC
roots for many CA's have been submitted and are now included, but of course
"give up compatibility with lots of users" vs "save a bit of cpu time and a
handful of bytes" is no real competition so it will be a long time until
most websites are using ECC certs.

Regardless, it's all irrelevant. Who knows when we might want to add
another feature that uses some bytes into PaymentRequests. Stuffing them
into a QR code will never make much sense IMO - it's far more sensible to
just use Bluetooth where the data size constraints are so much easier.

[-- Attachment #2: Type: text/html, Size: 2454 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]

Oh, one other reason I found - apparently RIM, at least in the past, has
been telling CA's that they need to pay mad bux for the Certicom ECC
patents. So that's another reason why most certs are still using RSA.


On Fri, Mar 21, 2014 at 12:08 PM, Mike Hearn <mike@plan99.net> wrote:

> On Fri, Mar 21, 2014 at 11:59 AM, Adam Back <adam@cypherspace.org> wrote:
>
>> Maybe its time to explore raw ECDSA signed message based certs.
>>
>
> If you want to create and run a new CA, by all means. But I bet you don't.
> So we're stuck with the current system for now.
>
>
>> btw I dont think its quite 4kB.  eg bitpay's looks to be about 1.5kB in
>> der
>> format.  And they contain a 2048-bit RSA server key, and 2048-bit RSA
>> signatures (256byte each right there = 512bytes).  And even 2048 is weaker
>> than 256-bit ECDSA.
>
>
> But you have to chain up to the root.
>
> The only reason more certs aren't ECC is backwards compatibility. Some old
> browsers don't know how to handle them. It wasn't so long ago that Fedora
> and Android were deleting ECC code from upstream libraries before shipping
> them, either for patent reasons for disk space saving measures.
>
> But it's possible to get ECC certs if you want. For example, Entrust is
> starting to sell them:
>
> http://www.entrust.net/ecc-certs/index.htm
>
> But their intermediate cert is still RSA. My understanding is that ECC
> roots for many CA's have been submitted and are now included, but of course
> "give up compatibility with lots of users" vs "save a bit of cpu time and a
> handful of bytes" is no real competition so it will be a long time until
> most websites are using ECC certs.
>
> Regardless, it's all irrelevant. Who knows when we might want to add
> another feature that uses some bytes into PaymentRequests. Stuffing them
> into a QR code will never make much sense IMO - it's far more sensible to
> just use Bluetooth where the data size constraints are so much easier.
>

[-- Attachment #2: Type: text/html, Size: 3114 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Adam Back]

According to Bernstein it's patent FUD (expired, ancient and solid prior
art).

http://lists.randombit.net/pipermail/cryptography/2013-August/005126.html

Adam

On Fri, Mar 21, 2014 at 12:33:57PM +0100, Mike Hearn wrote:
>   Oh, one other reason I found - apparently RIM, at least in the past,
>   has been telling CA's that they need to pay mad bux for the Certicom
>   ECC patents. So that's another reason why most certs are still using
>   RSA.

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

Maybe so, but given the relatively minor advantages of ECC certs I can see
why a CA might not want to take any risks. They are sitting ducks for
patent trolls.

I think ECC will still happen, though we end up back into NSA fear
territory thanks to the stupid way secp256r1 was defined. *Hopefully* there's
no back door.


On Fri, Mar 21, 2014 at 1:25 PM, Adam Back <adam@cypherspace.org> wrote:

> According to Bernstein it's patent FUD (expired, ancient and solid prior
> art).
>
> http://lists.randombit.net/pipermail/cryptography/2013-August/005126.html
>
> Adam
>
>
> On Fri, Mar 21, 2014 at 12:33:57PM +0100, Mike Hearn wrote:
>
>>   Oh, one other reason I found - apparently RIM, at least in the past,
>>   has been telling CA's that they need to pay mad bux for the Certicom
>>   ECC patents. So that's another reason why most certs are still using
>>   RSA.
>>
>

[-- Attachment #2: Type: text/html, Size: 1593 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 3740 bytes --]

2014-03-21 9:47 GMT+00:00 Andreas Schildbach <andreas@schildbach.de>:

> On 03/20/2014 05:14 PM, Alex Kotenko wrote:
>
> > Hmm, if we're inventing an URI for bluetooth, I'd rather follow existing
> > URI's patterns. BT is strictly point-to-point connection, so BT MAC
> > should be considered as server address, and payment request ID can be
> > considered as request path. Probably "bt:<bt-mac>/​
> > <random_id_of_payment_request>" would be more usual and easily
> > understandable.
>
> Agreed. I used the dash because I feared a slash would need to be
> escaped if used in an URL parameter.
>
​It will need to be ​escaped, but HTTP URLs used in BIP72 have it already,
so don't see why we should bother.



> > I wonder how complex it would be to implement HTTP-over-Bluetooth. Not
> > like I'm willing to do that now, but HTTP is well known and proven to be
> > quite good for tasks like this, so in theory it would be handy to have
> > such capacities in here.
>
> Thought of that as well. On the other hand, HTTP might be overkill and
> we inherit its potential downsides as well.
>
​It definitely is an overkill. Don't think we should do it now unless we
will see later during implementation that we really have to.



> >     Well, do we need to be compatible? If the dev community decides
> Base43
> >     PR QR's (or whatever other self-contained format) is the way to go,
> we
> >     just implement, roll it out and use it.
> >
> > My PoS needs to be compatible with BIP21, as when I'm presenting QR code
> > or sending NFC message - I have no way to tell what wallet/phone is ​​on
> > the accepting side, so I have to be compatible to existing widely
> > supported technologies.
>
> Agreed. All I wanted to say support for QR is still small enough that we
> might be able to switch to an incompatible standard. If we're determined
> that is.

Ok. Btw, I've tested ​QR possibilities on my PoS screen, in binary mode
it's limited to about 600 chars, so really I can include only unsigned and
rather short payment request. Signed requests longer than few hundred bytes
will not work.



> > ​Well, yes, it would be less efficient than base43. But did you
> > calculate how much less? ​It's a compatible and already widely used way
> > and loosing compatibility needs to have serious reasons, so would be
> > great to know exact figures here.
>
> Base 64 via binary QR:   64 chars / 256 chars
>                          ==> 6 bit / 8 bit = 0.75
>
> Base 43 via alphanum QR: 43 chars / 45 chars
>                          ==> 5.43 bit / 5.49 bit = 0.99
>
> That would be efficiency in terms of PR data size vs. amount space used
> in a QR code. Of course, the visual QR encoding also plays a role, for
> example its size is increased in discrete steps.
>
Ok, so base43-aphanum is winning about a quarter of capacity against
base64-binary. I probably will skip this anyway and go with bluetooth URI
scheme we've just agreed + old style payments over p2p network as fallback.
So no payment requests in QR codes at all from my side.




>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 5649 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]

2014-03-21 10:28 GMT+00:00 Andreas Schildbach <andreas@schildbach.de>:

> On 03/20/2014 06:31 PM, Jeff Garzik wrote:
>
> >> Afaik, BIP73 needs an external server (the web server).
> >
> > Yes.  Internet connectivity is not a rarity these days.  Near-field
> > web servers also work fine.
>
> Unfortunately it still is. At least here in Germany.

Yes, it is a problem. Even in the middle of London you often can get into
situation when cellphone network connectivity is not good enough for quick
and reliable payment. Basement pubs, old buildings with thick walls,
overcrowded places with overloaded radio environment. We should not rely on
mobile connectivity in things like making payments.



>


>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 2794 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Andreas Schildbach]

>     > Hmm, if we're inventing an URI for bluetooth, I'd rather follow
>     existing
>     > URI's patterns. BT is strictly point-to-point connection, so BT MAC
>     > should be considered as server address, and payment request ID
can be
>     > considered as request path. Probably "bt:<bt-mac>/​
>     > <random_id_of_payment_request>" would be more usual and easily
>     > understandable.
>
>     Agreed. I used the dash because I feared a slash would need to be
>     escaped if used in an URL parameter.
>
> ​It will need to be ​escaped, but HTTP URLs used in BIP72 have it
> already, so don't see why we should bother.

Quoting from RFC 3986, Section 3.4. Query:  "The characters slash ("/")
and question mark ("?") may represent data within the query component."

> Ok. Btw, I've tested ​QR possibilities on my PoS screen, in binary mode
> it's limited to about 600 chars, so really I can include only unsigned
> and rather short payment request. Signed requests longer than few
> hundred bytes will not work.

Thanks for testing this. It would be interesting to know what device and
software you used for scanning. But anyway, it falls into the same
ballpark as my tests.

> I probably will skip this anyway and go with bluetooth
> URI scheme we've just agreed + old style payments over p2p network as
> fallback. So no payment requests in QR codes at all from my side.

So BIP72 with a BT URI in the 'r' parameter?

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Andreas Schildbach]

On 03/21/2014 02:54 PM, Alex Kotenko wrote:

>     > I wonder how complex it would be to implement HTTP-over-Bluetooth. Not
>     > like I'm willing to do that now, but HTTP is well known and proven
>     to be
>     > quite good for tasks like this, so in theory it would be handy to have
>     > such capacities in here.
> 
>     Thought of that as well. On the other hand, HTTP might be overkill and
>     we inherit its potential downsides as well.
> 
> ​It definitely is an overkill. Don't think we should do it now unless we
> will see later during implementation that we really have to.

Btw. we could also consider SPDY. I'm not sure about the advantages, but
its probably quicker and leaner.

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1849 bytes --]

SPDY requires SSL and is even more complex than HTTP.

Really, the current protocol we've got (length prefixed protobufs) is just
fine except for the lack of encryption/authentication. For that you need to
do ECDH to establish a shared AES session key, and MAC each packet. Like I
said, it's not entirely trivial which is why it's worth trying SSL too, but
it's also not a massive effort.


On Fri, Mar 21, 2014 at 4:20 PM, Andreas Schildbach
<andreas@schildbach.de>wrote:

> On 03/21/2014 02:54 PM, Alex Kotenko wrote:
>
> >     > I wonder how complex it would be to implement HTTP-over-Bluetooth.
> Not
> >     > like I'm willing to do that now, but HTTP is well known and proven
> >     to be
> >     > quite good for tasks like this, so in theory it would be handy to
> have
> >     > such capacities in here.
> >
> >     Thought of that as well. On the other hand, HTTP might be overkill
> and
> >     we inherit its potential downsides as well.
> >
> > ​It definitely is an overkill. Don't think we should do it now unless we
> > will see later during implementation that we really have to.
>
> Btw. we could also consider SPDY. I'm not sure about the advantages, but
> its probably quicker and leaner.
>
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 2587 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 303 bytes --]

2014-03-21 14:51 GMT+00:00 Andreas Schildbach <andreas@schildbach.de>:
>
> Quoting from RFC 3986, Section 3.4. Query:  "The characters slash ("/")
> and question mark ("?") may represent data within the query component."
>
Ok.​​


So BIP72 with a BT URI in the 'r' parameter?

Yes.​​

[-- Attachment #2: Type: text/html, Size: 1072 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Jeff Garzik]

Let's not pull out silly examples.  Of course you can find locations
that lack Internet.

Those locations are completely unsuitable to bitcoin transactions,
since the receiver cannot verify double-spending or anything else
about the transaction.


On Fri, Mar 21, 2014 at 9:59 AM, Alex Kotenko <alexykot@gmail.com> wrote:
> 2014-03-21 10:28 GMT+00:00 Andreas Schildbach <andreas@schildbach.de>:
>>
>> On 03/20/2014 06:31 PM, Jeff Garzik wrote:
>>
>> >> Afaik, BIP73 needs an external server (the web server).
>> >
>> > Yes.  Internet connectivity is not a rarity these days.  Near-field
>> > web servers also work fine.
>>
>> Unfortunately it still is. At least here in Germany.
>
> Yes, it is a problem. Even in the middle of London you often can get into
> situation when cellphone network connectivity is not good enough for quick
> and reliable payment. Basement pubs, old buildings with thick walls,
> overcrowded places with overloaded radio environment. We should not rely on
> mobile connectivity in things like making payments.
>
>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

>
> Those locations are completely unsuitable to bitcoin transactions,
> since the receiver cannot verify double-spending or anything else
> about the transaction.


The usual issue is that they lack internet *for some customers*. The place
may well have private wifi or hardwired connections that work. Even mobile
networks may vary so some customers will have mobile connectivity and
others won't.

[-- Attachment #2: Type: text/html, Size: 639 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mark Friedenbach]

Jeff, there are *plenty* of places that lack local Internet access for
one or both participants.

Obviously making the case where both participants lack access to the
bitcoin network is difficult to secure, but not impossible (e.g. use a
telephany-based system to connect to a centralized double-spend
database, as VISA does).

I expect the case where one participant has Internet access (the
merchant) and the other does not to be very, very common. The majority
of transactions I do on a daily basis are like this, and I live in
Silicon Valley!

On 03/22/2014 09:35 AM, Jeff Garzik wrote:
> Let's not pull out silly examples.  Of course you can find locations
> that lack Internet.
> 
> Those locations are completely unsuitable to bitcoin transactions,
> since the receiver cannot verify double-spending or anything else
> about the transaction.

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Jeff Garzik]

One participant, yes.  Two participants lacking net would require a
serious revisit of BIP 70's security assumptions and some design, at a
minimum.

On Sat, Mar 22, 2014 at 12:55 PM, Mark Friedenbach <mark@monetize.io> wrote:
> Jeff, there are *plenty* of places that lack local Internet access for
> one or both participants.
>
> Obviously making the case where both participants lack access to the
> bitcoin network is difficult to secure, but not impossible (e.g. use a
> telephany-based system to connect to a centralized double-spend
> database, as VISA does).
>
> I expect the case where one participant has Internet access (the
> merchant) and the other does not to be very, very common. The majority
> of transactions I do on a daily basis are like this, and I live in
> Silicon Valley!
>
> On 03/22/2014 09:35 AM, Jeff Garzik wrote:
>> Let's not pull out silly examples.  Of course you can find locations
>> that lack Internet.
>>
>> Those locations are completely unsuitable to bitcoin transactions,
>> since the receiver cannot verify double-spending or anything else
>> about the transaction.
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2787 bytes --]

I think it's mostly a UI issue. The recipient needs to understand that what
he received is nothing more than an IOU that can be revoked at any time. If
the UI makes it clear and the user trusts the sender, no problem. BIP70
would work as before.


On Sat, Mar 22, 2014 at 6:24 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:

> One participant, yes.  Two participants lacking net would require a
> serious revisit of BIP 70's security assumptions and some design, at a
> minimum.
>
> On Sat, Mar 22, 2014 at 12:55 PM, Mark Friedenbach <mark@monetize.io>
> wrote:
> > Jeff, there are *plenty* of places that lack local Internet access for
> > one or both participants.
> >
> > Obviously making the case where both participants lack access to the
> > bitcoin network is difficult to secure, but not impossible (e.g. use a
> > telephany-based system to connect to a centralized double-spend
> > database, as VISA does).
> >
> > I expect the case where one participant has Internet access (the
> > merchant) and the other does not to be very, very common. The majority
> > of transactions I do on a daily basis are like this, and I live in
> > Silicon Valley!
> >
> > On 03/22/2014 09:35 AM, Jeff Garzik wrote:
> >> Let's not pull out silly examples.  Of course you can find locations
> >> that lack Internet.
> >>
> >> Those locations are completely unsuitable to bitcoin transactions,
> >> since the receiver cannot verify double-spending or anything else
> >> about the transaction.
> >
> >
> ------------------------------------------------------------------------------
> > Learn Graph Databases - Download FREE O'Reilly Book
> > "Graph Databases" is the definitive new guide to graph databases and
> their
> > applications. Written by three acclaimed leaders in the field,
> > this first edition is now available. Download your free book today!
> > http://p.sf.net/sfu/13534_NeoTech
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 4063 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

I know that general approach to interaction design in Bitcoin assumes
minimal to no difference between payer and payee, and generally I agree
with this approach.
However, for the sake of my PoS development this assumption is wrong by
default, as PoS is a specialized hardware, and one who cared to buy and
install it is probably not in the same situation as the other party that
didn't care to by anything dedicated.

In short - from PoS point of view there is a customer and a merchant. And
my goal is to make thing work in assumption of fast and reliable connection
on merchant side and no connection requirement at all from customer side.

I didn't put a silly example, as of my experience there are really a lot of
places where cellphone connection isn't good enough for reliable Bitcoin
operation. However, if we're talking about merchant establishments - we can
hope for private local WiFi or wired connection on PoS side, so PoS
internet connection shouldn't be an issue. So this is the use case I'm
designing around and this is why bluetooth based BIP70 implementation is
important for me.

I partly agree with Mike on user interface and IOU idea, but I have no
intention to implement anything like that right now.

[-- Attachment #2: Type: text/html, Size: 2247 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Roy Badami]

On Fri, Mar 21, 2014 at 12:02:44AM +0100, Mike Hearn wrote:
> >
> > It's not unusual, in a face-to-face transaction at a bricks-and-mortar
> > establishment, that you know neither the legal name of the entity
> > running the establishment
> 
> 
> I'd hope that people can get certs for their actual business name, but
> sometimes it does differ yes.

The actual example I was thinking of is that of traditional British
pubs.  Often a company will own several pubs - however the pubs
themselves will typically have individual traditional pub names.  The
name of the company might not be at all prominently advertised in the
pubs.

Traders at music festivals are another example that comes to mind (they
often accept credit cards if they sell higher value items so why not
Bitcoin?)  In this example there often are no clearly advertised
business names - at least, that the customer will be aware of.

roy

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 131 bytes --]

Yeah, for those cases we'd need to think of something else. That gets into
the realm of creating our own infrastructure though ...

[-- Attachment #2: Type: text/html, Size: 187 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Andreas Schildbach]

But these cases are the norm, rather than the exception. Of all these
places I spend my money at during the day I hardly ever know their
official name. I'm thinking in terms of "bakery", "indian restaurant" or
"snack vending machine".

In Germany usually businesses are named like the people that run it.
That usually just one or two random family names plus the legal form of
the company.


On 03/26/2014 11:56 PM, Mike Hearn wrote:
> Yeah, for those cases we'd need to think of something else. That gets
> into the realm of creating our own infrastructure though ...
> 
> 
> ------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]

>
> But these cases are the norm, rather than the exception.
>

Well, you're lucky, you live in Berlin. Most of the payments I make with
Bitcoin are online, to websites. So this will differ between people.

I wonder how critical it is. Let's say you are paying for a meal. In your
head the place you're at is just "the little Indian restaurant on the
corner". In the companies register and therefore certificate it's something
like "Singh Food GmbH". That's probably good enough to prevent shenanigans.
Even if there's a virus on your phone, it can't really replace the cert
with a random stolen one, otherwise your meal could show up like "IronCore
Steel Inc" or something that's obviously bogus. It'd have to be an
incredibly smart virus that knew how to substitute one name for a different
one, from a large library of stolen identities, such that the swap seemed
plausible. That sounds very hard, certainly too hard to bother with for
stealing restaurant fees.

And if a waiter at the restaurant is corrupt and they replace the cert with
one that's for their own 1-man business "BP-Gupta" or something, OK, you
might pay the wrong person by mistake. But eventually the corrupt waiter
will be discovered and then someone will have proof of what they did. It's
FAR more likely they'd just strip the signature entirely and try to
convince you the restaurant doesn't use BIP70 at all.

Still, if we want to fix this, one approach I was thinking about is to have
a super-cheesy CA just for us that issues certs with addresses in them, for
any name you ask for. That is, if you say you want a cert for "Shamrock
Irish Pub, Wollishofen, Zurich, CH" then it either sends a postcard to that
address with a code to check ownership of the address, or it checks
ownership of the place on Google Maps (which does the same postcard trick
but for free!).

That doesn't work for vending machines, but perhaps we just don't care
about those. If a MITM steals your lunch money, boo hoo.

[-- Attachment #2: Type: text/html, Size: 2679 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[vv01f]

[-- Attachment #1: Type: text/plain, Size: 2638 bytes --]

Companies can have a Cert with their name via CAcert. It requires some work though to get assured as an organisation.
Did you already think about what CA is to be trusted or do users need to do that. The least good decision in my POV would be to accept OS/browser built in CAs only.

Am 27.03.2014 um 11:08 schrieb Mike Hearn <mike@plan99.net>:

>> But these cases are the norm, rather than the exception.
> 
> Well, you're lucky, you live in Berlin. Most of the payments I make with Bitcoin are online, to websites. So this will differ between people.
> 
> I wonder how critical it is. Let's say you are paying for a meal. In your head the place you're at is just "the little Indian restaurant on the corner". In the companies register and therefore certificate it's something like "Singh Food GmbH". That's probably good enough to prevent shenanigans. Even if there's a virus on your phone, it can't really replace the cert with a random stolen one, otherwise your meal could show up like "IronCore Steel Inc" or something that's obviously bogus. It'd have to be an incredibly smart virus that knew how to substitute one name for a different one, from a large library of stolen identities, such that the swap seemed plausible. That sounds very hard, certainly too hard to bother with for stealing restaurant fees.
> 
> And if a waiter at the restaurant is corrupt and they replace the cert with one that's for their own 1-man business "BP-Gupta" or something, OK, you might pay the wrong person by mistake. But eventually the corrupt waiter will be discovered and then someone will have proof of what they did. It's FAR more likely they'd just strip the signature entirely and try to convince you the restaurant doesn't use BIP70 at all.
> 
> Still, if we want to fix this, one approach I was thinking about is to have a super-cheesy CA just for us that issues certs with addresses in them, for any name you ask for. That is, if you say you want a cert for "Shamrock Irish Pub, Wollishofen, Zurich, CH" then it either sends a postcard to that address with a code to check ownership of the address, or it checks ownership of the place on Google Maps (which does the same postcard trick but for free!).
> 
> That doesn't work for vending machines, but perhaps we just don't care about those. If a MITM steals your lunch money, boo hoo.
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[-- Attachment #2: Type: text/html, Size: 3741 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 4710 bytes --]

It took some time but we have finally implemented bluetooth integration
offered by Andreas in our bitcoin payment terminals.

​However it's not ideal at the moment. Basically the main problem is that
in the BIP72 there is no way to provide a fallback alternative URI for
payment request fetch if client wallet supports BIP70 but doesn't not
support fetching over bluetooth or bluetooth connection fails for any
reason.
There is a way to define alternative URIs inside payment request itself,
but that doesn't really work as client first needs to get payment request
message itself somehow and this is exactly the problem.

As far as I see there is three ways to solve that:
1. add new URI parameter for bluetooth address
  (e.g. r=http://<web_address>&rbt=bt:<BT_MAC_addres>).
2. allow multiple "r" parameters
  (e.g. r=http://<web_address>&r=bt:<BT_MAC_addres>).
3. allow "r" to be an array
  (e.g. r%5B0%5D=http://<web_address>&r%5B1%5D=bt:<BT_MAC_addres>).

Option #1 isn't great at all, as it solves existing problem, but not
provides any way to solve same problem appearing again for another possible
protocol.

Options #2 & #3 may be working and seem to be nearly equal, and both are
not great in the way that URI parser behavior in these cases is not clearly
defined. I've checked through relevant RFCs and found nothing specific
about this. According to my limited web experience the array scheme is
working better than multiple repeating parameters.

So I'm looking for some advice on which route of three proposed may be
better here, or if there are any other ways I'm missing.


2014-03-27 13:31 GMT+00:00 vv01f <vv01f@riseup.net>:

> Companies can have a Cert with their name via CAcert. It requires some
> work though to get assured as an organisation.
> Did you already think about what CA is to be trusted or do users need to
> do that. The least good decision in my POV would be to accept OS/browser
> built in CAs only.
>
> Am 27.03.2014 um 11:08 schrieb Mike Hearn <mike@plan99.net>:
>
>  But these cases are the norm, rather than the exception.
>>
>
> Well, you're lucky, you live in Berlin. Most of the payments I make with
> Bitcoin are online, to websites. So this will differ between people.
>
> I wonder how critical it is. Let's say you are paying for a meal. In your
> head the place you're at is just "the little Indian restaurant on the
> corner". In the companies register and therefore certificate it's something
> like "Singh Food GmbH". That's probably good enough to prevent shenanigans.
> Even if there's a virus on your phone, it can't really replace the cert
> with a random stolen one, otherwise your meal could show up like "IronCore
> Steel Inc" or something that's obviously bogus. It'd have to be an
> incredibly smart virus that knew how to substitute one name for a different
> one, from a large library of stolen identities, such that the swap seemed
> plausible. That sounds very hard, certainly too hard to bother with for
> stealing restaurant fees.
>
> And if a waiter at the restaurant is corrupt and they replace the cert
> with one that's for their own 1-man business "BP-Gupta" or something, OK,
> you might pay the wrong person by mistake. But eventually the corrupt
> waiter will be discovered and then someone will have proof of what they
> did. It's FAR more likely they'd just strip the signature entirely and try
> to convince you the restaurant doesn't use BIP70 at all.
>
> Still, if we want to fix this, one approach I was thinking about is to
> have a super-cheesy CA just for us that issues certs with addresses in
> them, for any name you ask for. That is, if you say you want a cert for
> "Shamrock Irish Pub, Wollishofen, Zurich, CH" then it either sends a
> postcard to that address with a code to check ownership of the address, or
> it checks ownership of the place on Google Maps (which does the same
> postcard trick but for free!).
>
> That doesn't work for vending machines, but perhaps we just don't care
> about those. If a MITM steals your lunch money, boo hoo.
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 8553 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

>
> ​However it's not ideal at the moment. Basically the main problem is that
> in the BIP72 there is no way to provide a fallback alternative URI for
> payment request fetch if client wallet supports BIP70 but doesn't not
> support fetching over bluetooth or bluetooth connection fails for any
> reason.
>

So the idea here is that the recipient wallet both uploads to the internet
and exposes the payment request over Bluetooth simultaneously, then let's
the sending wallet pick whatever radio layer works best in its current
conditions?

I think having multiple r= params is reasonable, but the Bluetooth support
is not specced in any BIP anyway. And if it were to be, people would point
out the lack of link-layer encryption.

So this is a bit tricky, overall. Right now I'd say things are kinda half
baked: not only is bluetooth not standardised nor encrypted (my fault, I
prototyped this code during a hackathon), but Bitcoin Wallet doesn't
properly implement BIP 72 either. To push this work forward I think we need
to sit down and do some more spec and implementation work :/

[-- Attachment #2: Type: text/html, Size: 1508 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Andreas Schildbach]

On 07/01/2014 10:18 AM, Mike Hearn wrote:
>     ​However it's not ideal at the moment. Basically the main problem is
>     that in the BIP72 there is no way to provide a fallback alternative
>     URI for payment request fetch if client wallet supports BIP70 but
>     doesn't not support fetching over bluetooth or bluetooth connection
>     fails for any reason. 

I think the way to go here is using multiple r= parameters.

> So the idea here is that the recipient wallet both uploads to the
> internet and exposes the payment request over Bluetooth simultaneously,
> then let's the sending wallet pick whatever radio layer works best in
> its current conditions?

Either that, or just use the other ones as a fallback. Currently,
Bitcoin Wallet just falls back to BIP21 if fetching the PR via the r=
URL fails.

> I think having multiple r= params is reasonable, but the Bluetooth
> support is not specced in any BIP anyway. And if it were to be, people
> would point out the lack of link-layer encryption.

Its "specced" in code and implemented by several parties. I think its
clear that link-layer encryption has to be an add-on to the current
unencrypted connection, just like HTTPS is on top of HTTP. Anyway,
that's unrelated to the question of how to provide fallback URLs.

One more thought: We have a similar problem with the BIP70 payment URL.
It doesn't allow for fallbacks either. I brought this issue up in the
discussion phase of BIP70, but it was dismissed I think because of
"let's not get too complex for the first version". The fallback here is
to send the transaction via the P2P network.

(I think BIP70 via P2P radio will get used more often in future. I plan
to look into Bluetooth 4 LE as soon as I have devices and wanted to try
WIFI Direct again also. I hope we can skip BIP72 for both of those, but
lets see.)

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Michael Wozniak]

I think it makes more sense to not add a duplicate parameter.  Current implementations will break if multiple r parameters are used (either reject the URI completely, or do something undefined).  If a new parameter is used, then the current implementations will just ignore it if they don’t support it.

-
Michael Wozniak

On Jul 1, 2014, at 5:48 AM, Andreas Schildbach <andreas@schildbach.de> wrote:

> On 07/01/2014 10:18 AM, Mike Hearn wrote:
>>    ​However it's not ideal at the moment. Basically the main problem is
>>    that in the BIP72 there is no way to provide a fallback alternative
>>    URI for payment request fetch if client wallet supports BIP70 but
>>    doesn't not support fetching over bluetooth or bluetooth connection
>>    fails for any reason. 
> 
> I think the way to go here is using multiple r= parameters.
> 
>> So the idea here is that the recipient wallet both uploads to the
>> internet and exposes the payment request over Bluetooth simultaneously,
>> then let's the sending wallet pick whatever radio layer works best in
>> its current conditions?
> 
> Either that, or just use the other ones as a fallback. Currently,
> Bitcoin Wallet just falls back to BIP21 if fetching the PR via the r=
> URL fails.
> 
>> I think having multiple r= params is reasonable, but the Bluetooth
>> support is not specced in any BIP anyway. And if it were to be, people
>> would point out the lack of link-layer encryption.
> 
> Its "specced" in code and implemented by several parties. I think its
> clear that link-layer encryption has to be an add-on to the current
> unencrypted connection, just like HTTPS is on top of HTTP. Anyway,
> that's unrelated to the question of how to provide fallback URLs.
> 
> One more thought: We have a similar problem with the BIP70 payment URL.
> It doesn't allow for fallbacks either. I brought this issue up in the
> discussion phase of BIP70, but it was dismissed I think because of
> "let's not get too complex for the first version". The fallback here is
> to send the transaction via the P2P network.
> 
> (I think BIP70 via P2P radio will get used more often in future. I plan
> to look into Bluetooth 4 LE as soon as I have devices and wanted to try
> WIFI Direct again also. I hope we can skip BIP72 for both of those, but
> lets see.)
> 
> 
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 1890 bytes --]

In my mind it's not like the client's phone is going all directions at the
same time. There should be a priority method and fallback method(s). ​And I
​see p2p radio as priority, and web as fallback, and BIP21 in the end as
always-working-default.

​So I'm keeping support for it all while want to be able to provide best
user experience.
Mike, a while ago in ​this thread you've described contactless cards user
experience. I'm also using contactless cards often, and what I'm aiming at
is creating same level of user experience for Bitcoin users.

Encryption over bluetooth is a matter to worry about, and we will introduce
that, but we need to sort out more low level problems first before coming
into that stage.


So, the backwards compatibility is a good issue Michael pointed out.
While processing of multiple "r" parameters is indeed uncertain (since
there is no RFC for that various implementations may behave differently),
the array solution is somewhat better. The array parameter name is "
r%5B1%5D=", i.e. it's not "r=", and we can add plain "r=" alongside. And if
particular implementation understands the array construct - it will use it,
otherwise it will ignore the "r%5B1%5D=" and use only usual "r=".

This doens't work though for cases where particular implementation
understands array construct but doesn't work well with repeating
parameters, since it will see two repeating "r" - an array and a string. I
don't have a solution for that atm.


If add completely new parameter to solve this we will need to make it an
array straight away to address upcoming issues with accommodating other
protocols.
And then I would also modify existing BIP72 to strictly define "r=" as
"http(s)" ​only ​parameter, while all other protocols (bluetooth, WiFi
Direct, ultrasound, chirp etc) should go to the new array parameter.


​

[-- Attachment #2: Type: text/html, Size: 3708 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Andreas Schildbach]

Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd
advocate for a simple array parameter name, like rs= ("plural" of r).
Length really does matter for QR codes.

I'm fine with either multiple r= params or exactly one r= plus zero to
many r[]= params. Although I think it is a violation of the (current)
spec to choke on more than one r= parameters, I admit that bitcoinj is
currently implemented that way. (We could however fix this in a
maintenance release.)

However, r= should also allow all other protocols, exactly like any of
the r[]= params. I don't think we should do a distinction here. Also
because of backwards compatibility to the status quo.


On 07/01/2014 03:03 PM, Alex Kotenko wrote:
> In my mind it's not like the client's phone is going all directions at
> the same time. There should be a priority method and fallback method(s).
> ​And I ​see p2p radio as priority, and web as fallback, and BIP21 in the
> end as always-working-default.
> 
> ​So I'm keeping support for it all while want to be able to provide best
> user experience. 
> Mike, a while ago in ​this thread you've described contactless cards
> user experience. I'm also using contactless cards often, and what I'm
> aiming at is creating same level of user experience for Bitcoin users. 
> 
> Encryption over bluetooth is a matter to worry about, and we will
> introduce that, but we need to sort out more low level problems first
> before coming into that stage. 
> 
> 
> So, the backwards compatibility is a good issue Michael pointed out. 
> While processing of multiple "r" parameters is indeed uncertain (since
> there is no RFC for that various implementations may behave
> differently), the array solution is somewhat better. The array parameter
> name is "r%5B1%5D=", i.e. it's not "r=", and we can add plain "r="
> alongside. And if particular implementation understands the array
> construct - it will use it, otherwise it will ignore the "r%5B1%5D=" and
> use only usual "r=". 
> 
> This doens't work though for cases where particular implementation
> understands array construct but doesn't work well with repeating
> parameters, since it will see two repeating "r" - an array and a string.
> I don't have a solution for that atm. 
> 
> 
> If add completely new parameter to solve this we will need to make it an
> array straight away to address upcoming issues with accommodating other
> protocols. 
> And then I would also modify existing BIP72 to strictly define "r=" as
> "http(s)" ​only ​parameter, while all other protocols (bluetooth, WiFi
> Direct, ultrasound, chirp etc) should go to the new array parameter.
> 
> 
> ​
> 
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Michael Wozniak]

Multiple parameters is currently undefined as far as I can tell.  Should the client take the first, last, or ignore it completely if there are multiple of any parameter?  I think that’s the point of the parameter pollution discussion, which will define it one way or the other.

I’m only familiar with the Electrum implementation, which is currently checking for any duplicate parameters and treating the entire URI as invalid if duplicate parameters exist (following the parameter pollution suggestions).

-
Michael Wozniak

On Jul 1, 2014, at 10:59 AM, Andreas Schildbach <andreas@schildbach.de> wrote:

> Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd
> advocate for a simple array parameter name, like rs= ("plural" of r).
> Length really does matter for QR codes.
> 
> I'm fine with either multiple r= params or exactly one r= plus zero to
> many r[]= params. Although I think it is a violation of the (current)
> spec to choke on more than one r= parameters, I admit that bitcoinj is
> currently implemented that way. (We could however fix this in a
> maintenance release.)
> 
> However, r= should also allow all other protocols, exactly like any of
> the r[]= params. I don't think we should do a distinction here. Also
> because of backwards compatibility to the status quo.
> 
> 
> On 07/01/2014 03:03 PM, Alex Kotenko wrote:
>> In my mind it's not like the client's phone is going all directions at
>> the same time. There should be a priority method and fallback method(s).
>> ​And I ​see p2p radio as priority, and web as fallback, and BIP21 in the
>> end as always-working-default.
>> 
>> ​So I'm keeping support for it all while want to be able to provide best
>> user experience. 
>> Mike, a while ago in ​this thread you've described contactless cards
>> user experience. I'm also using contactless cards often, and what I'm
>> aiming at is creating same level of user experience for Bitcoin users. 
>> 
>> Encryption over bluetooth is a matter to worry about, and we will
>> introduce that, but we need to sort out more low level problems first
>> before coming into that stage. 
>> 
>> 
>> So, the backwards compatibility is a good issue Michael pointed out. 
>> While processing of multiple "r" parameters is indeed uncertain (since
>> there is no RFC for that various implementations may behave
>> differently), the array solution is somewhat better. The array parameter
>> name is "r%5B1%5D=", i.e. it's not "r=", and we can add plain "r="
>> alongside. And if particular implementation understands the array
>> construct - it will use it, otherwise it will ignore the "r%5B1%5D=" and
>> use only usual "r=". 
>> 
>> This doens't work though for cases where particular implementation
>> understands array construct but doesn't work well with repeating
>> parameters, since it will see two repeating "r" - an array and a string.
>> I don't have a solution for that atm. 
>> 
>> 
>> If add completely new parameter to solve this we will need to make it an
>> array straight away to address upcoming issues with accommodating other
>> protocols. 
>> And then I would also modify existing BIP72 to strictly define "r=" as
>> "http(s)" ​only ​parameter, while all other protocols (bluetooth, WiFi
>> Direct, ultrasound, chirp etc) should go to the new array parameter.
>> 
>> 
>> ​
>> 
>> 
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> 
>> 
>> 
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Andreas Schildbach]

Ok, one more idea:
r= is used for the first URL, and we *think* of it as r0=
additional URLs are appended as
r1=
r2=
and so on. This would also define an ordering in case we need it.


On 07/01/2014 05:07 PM, Michael Wozniak wrote:
> Multiple parameters is currently undefined as far as I can tell.  Should the client take the first, last, or ignore it completely if there are multiple of any parameter?  I think that’s the point of the parameter pollution discussion, which will define it one way or the other.
> 
> I’m only familiar with the Electrum implementation, which is currently checking for any duplicate parameters and treating the entire URI as invalid if duplicate parameters exist (following the parameter pollution suggestions).
> 
> -
> Michael Wozniak
> 
> On Jul 1, 2014, at 10:59 AM, Andreas Schildbach <andreas@schildbach.de> wrote:
> 
>> Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd
>> advocate for a simple array parameter name, like rs= ("plural" of r).
>> Length really does matter for QR codes.
>>
>> I'm fine with either multiple r= params or exactly one r= plus zero to
>> many r[]= params. Although I think it is a violation of the (current)
>> spec to choke on more than one r= parameters, I admit that bitcoinj is
>> currently implemented that way. (We could however fix this in a
>> maintenance release.)
>>
>> However, r= should also allow all other protocols, exactly like any of
>> the r[]= params. I don't think we should do a distinction here. Also
>> because of backwards compatibility to the status quo.
>>
>>
>> On 07/01/2014 03:03 PM, Alex Kotenko wrote:
>>> In my mind it's not like the client's phone is going all directions at
>>> the same time. There should be a priority method and fallback method(s).
>>> ​And I ​see p2p radio as priority, and web as fallback, and BIP21 in the
>>> end as always-working-default.
>>>
>>> ​So I'm keeping support for it all while want to be able to provide best
>>> user experience. 
>>> Mike, a while ago in ​this thread you've described contactless cards
>>> user experience. I'm also using contactless cards often, and what I'm
>>> aiming at is creating same level of user experience for Bitcoin users. 
>>>
>>> Encryption over bluetooth is a matter to worry about, and we will
>>> introduce that, but we need to sort out more low level problems first
>>> before coming into that stage. 
>>>
>>>
>>> So, the backwards compatibility is a good issue Michael pointed out. 
>>> While processing of multiple "r" parameters is indeed uncertain (since
>>> there is no RFC for that various implementations may behave
>>> differently), the array solution is somewhat better. The array parameter
>>> name is "r%5B1%5D=", i.e. it's not "r=", and we can add plain "r="
>>> alongside. And if particular implementation understands the array
>>> construct - it will use it, otherwise it will ignore the "r%5B1%5D=" and
>>> use only usual "r=". 
>>>
>>> This doens't work though for cases where particular implementation
>>> understands array construct but doesn't work well with repeating
>>> parameters, since it will see two repeating "r" - an array and a string.
>>> I don't have a solution for that atm. 
>>>
>>>
>>> If add completely new parameter to solve this we will need to make it an
>>> array straight away to address upcoming issues with accommodating other
>>> protocols. 
>>> And then I would also modify existing BIP72 to strictly define "r=" as
>>> "http(s)" ​only ​parameter, while all other protocols (bluetooth, WiFi
>>> Direct, ultrasound, chirp etc) should go to the new array parameter.
>>>
>>>
>>> ​
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Open source business process management suite built on Java and Eclipse
>>> Turn processes into business applications with Bonita BPM Community Edition
>>> Quickly connect people, data, and systems into organized workflows
>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>> http://p.sf.net/sfu/Bonitasoft
>>>
>>>
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 6770 bytes --]

Hmm, r1, r2 etc is actually interesting. It takes less chars then array
(yes, array brackets have to be escaped) and provides unlimited number of
options, uniformed approach and priority definition. I'd say that is the
way to go. Any objections?
On 1 Jul 2014 16:39, "Andreas Schildbach" <andreas@schildbach.de> wrote:

> Ok, one more idea:
> r= is used for the first URL, and we *think* of it as r0=
> additional URLs are appended as
> r1=
> r2=
> and so on. This would also define an ordering in case we need it.
>
>
> On 07/01/2014 05:07 PM, Michael Wozniak wrote:
> > Multiple parameters is currently undefined as far as I can tell.  Should
> the client take the first, last, or ignore it completely if there are
> multiple of any parameter?  I think that’s the point of the parameter
> pollution discussion, which will define it one way or the other.
> >
> > I’m only familiar with the Electrum implementation, which is currently
> checking for any duplicate parameters and treating the entire URI as
> invalid if duplicate parameters exist (following the parameter pollution
> suggestions).
> >
> > -
> > Michael Wozniak
> >
> > On Jul 1, 2014, at 10:59 AM, Andreas Schildbach <andreas@schildbach.de>
> wrote:
> >
> >> Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd
> >> advocate for a simple array parameter name, like rs= ("plural" of r).
> >> Length really does matter for QR codes.
> >>
> >> I'm fine with either multiple r= params or exactly one r= plus zero to
> >> many r[]= params. Although I think it is a violation of the (current)
> >> spec to choke on more than one r= parameters, I admit that bitcoinj is
> >> currently implemented that way. (We could however fix this in a
> >> maintenance release.)
> >>
> >> However, r= should also allow all other protocols, exactly like any of
> >> the r[]= params. I don't think we should do a distinction here. Also
> >> because of backwards compatibility to the status quo.
> >>
> >>
> >> On 07/01/2014 03:03 PM, Alex Kotenko wrote:
> >>> In my mind it's not like the client's phone is going all directions at
> >>> the same time. There should be a priority method and fallback
> method(s).
> >>> ​And I ​see p2p radio as priority, and web as fallback, and BIP21 in
> the
> >>> end as always-working-default.
> >>>
> >>> ​So I'm keeping support for it all while want to be able to provide
> best
> >>> user experience.
> >>> Mike, a while ago in ​this thread you've described contactless cards
> >>> user experience. I'm also using contactless cards often, and what I'm
> >>> aiming at is creating same level of user experience for Bitcoin users.
> >>>
> >>> Encryption over bluetooth is a matter to worry about, and we will
> >>> introduce that, but we need to sort out more low level problems first
> >>> before coming into that stage.
> >>>
> >>>
> >>> So, the backwards compatibility is a good issue Michael pointed out.
> >>> While processing of multiple "r" parameters is indeed uncertain (since
> >>> there is no RFC for that various implementations may behave
> >>> differently), the array solution is somewhat better. The array
> parameter
> >>> name is "r%5B1%5D=", i.e. it's not "r=", and we can add plain "r="
> >>> alongside. And if particular implementation understands the array
> >>> construct - it will use it, otherwise it will ignore the "r%5B1%5D="
> and
> >>> use only usual "r=".
> >>>
> >>> This doens't work though for cases where particular implementation
> >>> understands array construct but doesn't work well with repeating
> >>> parameters, since it will see two repeating "r" - an array and a
> string.
> >>> I don't have a solution for that atm.
> >>>
> >>>
> >>> If add completely new parameter to solve this we will need to make it
> an
> >>> array straight away to address upcoming issues with accommodating other
> >>> protocols.
> >>> And then I would also modify existing BIP72 to strictly define "r=" as
> >>> "http(s)" ​only ​parameter, while all other protocols (bluetooth, WiFi
> >>> Direct, ultrasound, chirp etc) should go to the new array parameter.
> >>>
> >>>
> >>> ​
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Open source business process management suite built on Java and Eclipse
> >>> Turn processes into business applications with Bonita BPM Community
> Edition
> >>> Quickly connect people, data, and systems into organized workflows
> >>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> >>> http://p.sf.net/sfu/Bonitasoft
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Bitcoin-development mailing list
> >>> Bitcoin-development@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Open source business process management suite built on Java and Eclipse
> >> Turn processes into business applications with Bonita BPM Community
> Edition
> >> Quickly connect people, data, and systems into organized workflows
> >> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> >> http://p.sf.net/sfu/Bonitasoft
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> >
> ------------------------------------------------------------------------------
> > Open source business process management suite built on Java and Eclipse
> > Turn processes into business applications with Bonita BPM Community
> Edition
> > Quickly connect people, data, and systems into organized workflows
> > Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > http://p.sf.net/sfu/Bonitasoft
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 9042 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 124 bytes --]

Nope, r1/r2 sounds good to me. BTW we should update the spec to reflect
that escaping is largely unnecessary in many cases.

[-- Attachment #2: Type: text/html, Size: 247 bytes --]

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]

Ok, agreed. I will submit a pull request to BIP72 then.
Not sure about escaping though. It is indeed not critical for bitcoin URIs,
but still it is a part of RFC, don't think we should go against it.

Andreas, we will implement this on our side, with bluetooth on r= and web
address on r1=.


2014-07-01 18:59 GMT+01:00 Mike Hearn <mike@plan99.net>:

> Nope, r1/r2 sounds good to me. BTW we should update the spec to reflect
> that escaping is largely unnecessary in many cases.
>
>
>

[-- Attachment #2: Type: text/html, Size: 1305 bytes --]