public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99•net>
To: Adam Back <adam@cypherspace•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>,
	Andreas Schildbach <andreas@schildbach•de>
Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Date: Thu, 20 Mar 2014 13:20:20 +0100	[thread overview]
Message-ID: <CANEZrP30auwsdGy=HKYbawajOJ8Beu8VwVPn+ZM16L2LCZY7iw@mail.gmail.com> (raw)
In-Reply-To: <20140320121221.GA25052@netbook.cypherspace.org>

[-- 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 --]

  reply	other threads:[~2014-03-20 12:20 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-27 11:59 Andreas Schildbach
2014-01-27 13:11 ` Mike Hearn
2014-01-27 18:18   ` Andreas Schildbach
2014-01-27 18:34     ` Mike Hearn
2014-01-27 20:53     ` [Bitcoin-development] Experiment with linking payment requests via href Andreas Schildbach
2014-01-27 21:47       ` Mike Hearn
2014-01-27 17:11 ` [Bitcoin-development] Payment Protocol for Face-to-face Payments Jeremy Spilman
2014-01-27 17:39   ` Andreas Schildbach
2014-01-27 18:18     ` Jeremy Spilman
2014-01-27 20:34   ` Roy Badami
2014-01-29 14:57     ` Christophe Biocca
2014-01-30 10:46 ` Andreas Schildbach
2014-01-30 10:50   ` Mike Hearn
2014-02-07 23:15   ` Andreas Schildbach
2014-03-02  9:47 ` Andreas Schildbach
2014-03-02 11:50   ` Mike Hearn
2014-03-20  2:22     ` Alex Kotenko
2014-03-20  3:31       ` Jeff Garzik
2014-03-20  8:09         ` Andreas Schildbach
2014-03-20 10:36           ` Mike Hearn
2014-03-20 12:12             ` Adam Back
2014-03-20 12:20               ` Mike Hearn [this message]
2014-03-20 17:31               ` Jeff Garzik
2014-03-20 17:42                 ` Alex Kotenko
2014-03-20 18:01                   ` Jeff Garzik
2014-03-21 10:28                 ` Andreas Schildbach
2014-03-21 13:59                   ` Alex Kotenko
2014-03-22 16:35                     ` Jeff Garzik
2014-03-22 16:45                       ` Mike Hearn
2014-03-22 16:55                       ` Mark Friedenbach
2014-03-22 17:24                         ` Jeff Garzik
2014-03-22 17:30                           ` Mike Hearn
2014-03-23  3:47                             ` Alex Kotenko
2014-03-21 10:25               ` Andreas Schildbach
2014-03-21 10:59                 ` Adam Back
2014-03-21 11:08                   ` Mike Hearn
2014-03-21 11:33                     ` Mike Hearn
2014-03-21 12:25                       ` Adam Back
2014-03-21 13:07                         ` Mike Hearn
2014-03-20 18:20             ` Alex Kotenko
2014-03-20 18:31               ` Mike Hearn
2014-03-20 18:50                 ` Alex Kotenko
2014-03-20 21:52                 ` Roy Badami
2014-03-20 23:02                   ` Mike Hearn
2014-03-26 22:48                     ` Roy Badami
2014-03-26 22:56                       ` Mike Hearn
2014-03-26 23:20                         ` Andreas Schildbach
2014-03-27 10:08                           ` Mike Hearn
2014-03-27 13:31                             ` vv01f
2014-06-30 19:26                               ` Alex Kotenko
2014-07-01  8:18                                 ` Mike Hearn
2014-07-01  9:48                                   ` Andreas Schildbach
2014-07-01 10:42                                     ` Michael Wozniak
2014-07-01 13:03                                       ` Alex Kotenko
2014-07-01 14:59                                         ` Andreas Schildbach
2014-07-01 15:07                                           ` Michael Wozniak
2014-07-01 15:39                                             ` Andreas Schildbach
2014-07-01 17:18                                               ` Alex Kotenko
2014-07-01 17:59                                                 ` Mike Hearn
2014-07-02  8:49                                                   ` Alex Kotenko
2014-03-21 10:43                   ` Andreas Schildbach
2014-03-20  8:08       ` Andreas Schildbach
2014-03-20 16:14         ` Alex Kotenko
2014-03-21  9:47           ` Andreas Schildbach
2014-03-21 13:54             ` Alex Kotenko
2014-03-21 14:51               ` Andreas Schildbach
2014-03-21 15:38                 ` Alex Kotenko
2014-03-21 15:20               ` Andreas Schildbach
2014-03-21 15:24                 ` Mike Hearn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANEZrP30auwsdGy=HKYbawajOJ8Beu8VwVPn+ZM16L2LCZY7iw@mail.gmail.com' \
    --to=mike@plan99$(echo .)net \
    --cc=adam@cypherspace$(echo .)org \
    --cc=andreas@schildbach$(echo .)de \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox