Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

[Mike Hearn <mike@plan99.net>]

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

Hey Andy,

Thanks for starting this discussion!

One thing this brings up is the never-resolved issue of whether BIPs should
document how we'd *like* things to work, or how things *actually do* work.
BIP32 is an example of the former - it was new technology and the spec was
finalised before any wallets actually implemented it. BIP 44 is an example
of the latter, it basically documents how myTREZOR works and as such there
was minimal or no scope for changes to it. Of course both kinds of document
are valuable.

Currently these specs document how Andreas' app already works. Whilst
preserving compatibility with existing Android apps is surely useful,
having a well designed protocol is also good. The current protocol has
several problems. I don't know which is more important right now and don't
have a strong opinion on that. My gut feeling is that these documents
should possibly be just wiki pages on Andreas' github. Then if the protocol
is brought to a point where it seems pretty good, maybe it can be BIPped at
that point. Alternatively, if developers of other wallet apps feel they'd
like a BIP right now even in the current state, that would be a very
important data point.

Re: the actual specs:

>
>    - There may seem to be some inconsistency in the connection header
>    messages
>
> IMHO we could live with that. Although Android apps are updatable, perfect
header format is probably not worth the inevitable hassle and transition
period that would result.

>
>    - The current method uses an unauthenticated bluetooth connection for
>    bluetooth 2.1
>
> This on the other hand is not excellent. This is actually my fault - the
first Bluetooth support in Bitcoin Wallet for Android was written by me in
a frantic Berlin hackathon over a weekend. We barely got it working at all
by the end, so doing encryption/auth was out of the question. Then I went
back to more important tasks and what got shipped was a cleaned
up/robustified version of that.

Re: hash. I'm not a fan of this approach. For one, in future there might
not even BE a uri involved, e.g. consider the Square style UX where the
merchant is broadcasting an endpoint via BLE and the phone just
automagically connects, sees a trusted merchant and pays. Super slick, we
definitely want it - but no URI. Then of course there's the usual QR code
size limitations.

Encrypting/authing the connection at the app layer does not have to be
difficult. What we really need/want, is a simple lightweight library that
does an ECDH key agreement using secp256k1, and then does AES+HMAC on
framed messages. Such a protocol would be useful not only for this use
case, but perhaps for encrypting/authing the p2p protocol in future as well.

Once the encrypted connection is set up above the Bluetooth layer, the
payment protocol request can then be signed either with a regular Bitcoin
key that was in the Bitcoin URI as the payment address (when a URI is
available), thus linking the request to the URI without adding any
additional data by doubling up the backwards compatibility support. Or if
there's no URI, then of course, the payment request must be PKI signed and
the signed PaymentDetails structure can contain a copy of the public key
that was used to set up the connection, thus binding the connection to a
PKI identity and ensuring you're not talking to a MITM.

I suspect that this is not anywhere near as hard to implement as one might
think. ECDH is not a complex protocol. You certainly don't need full blown
HTTPS involved.

>
>    - There is no acknowledgement failure message possible in the payment
>    protocol, only an acknowledgement message or lack of acknowledgement
>    message. This issue seems to be a concern and as a result, the memo field
>    is used to send an "ack" or "nack" in Schildbach's wallet. Can we add a
>    boolean status field to the payment acknowledgement message?
>
> Ugh. I did want a way to indicate failure when we designed BIP70, but I
can't remember why one wasn't included in the final spec. I think we
decided the containing protocol could do this instead (normally HTTP).

Abusing the memo field is definitely the wrong thing to do! Rather the
Bluetooth specific encapsulation protocol should have a notion of failure.

>
>    - I'd personally like a new optional boolean field added to the
>    "PaymentDetails" portion of the "PaymentRequest" to allow for the payer's
>    wallet to match the "Output" optional "amount" fields as a total amount of
>    all Outputs, rather than requiring the amount for each output to be matched
>    exactly.
>
> Extending BIP70 with more negotiable privacy features is a different
effort, let's not discuss that as part of Bluetooth support.

Besides, no wallet uses even the existing support for merge avoidance in
BIP70. In fact Andreas' wallet is one of the blocking factors here because
it violates the specs by requiring the BIP70 request to have only a single
output that matches the address specified in the URI. All because he
doesn't trust HTTPS :(

I don't think adding even more privacy stuff to BIP70 makes any sense until
we have implementations that actually exploit the existing support. And to
get there, we must fix Andreas' wallet so it doesn't violate the specs
anymore. Sorry Andreas. I know we argue about this all the time, but it's
really a big problem that your app doesn't obey the specs. It makes
everyone reluctant to use new BIP70 features, because they feel a need to
test with every possible wallet app in case one of them has simply decided
to do their own thing and become deliberately incompatible. And then why
bother, there are more important things to do.

>
>    - Amount of data stored in QR codes may be getting large when a
>    backwards compatible URL is used (for wallets that don't support the
>    payment protocol) and can be difficult to scan with outdoor screens that
>    have an extra weather resistant pane when in direct sunlight.
>
> MAC addresses could be encoded more efficiently, of course, but it seems
unlikely that address-less URIs can be relied upon any time soon - and
besides if the URI needs to bind to an authenticated channel because PKI
signing is not in use, then it makes sense to use that part of the URI to
do so.

>
>    - The number of offline transactions of a wallet is limited to the
>    known unspent outputs when they go offline. Long term, I'd like to see
>    wallet devices that can use systems such as Kryptoradio's DVB-T based
>    broadcast (but this will need yet another radio!).
>
> Given that all interesting mobile devices have sophisticated internet
access radios of various forms, I doubt it's worth putting much effort in
here. Bluetooth for submitting payments makes sense some of the time,
partly for performance and partly because it's more decentralised than
looping in an intermediary HTTPS server to temporarily host a BIP70 request
file. I don't think we should try and invent an entirely new "block chain
internet" though. At any rate, it's a separate effort.

>
>    - The additional payment_url approach is a bit sloppy of a solution in
>    the PaymentDetails portion of the PaymentRequest.
>
> This is only an issue because of the way you define the hashing mechanism.
If you reuse the backwards compatibility address, then the payment_url can
of course be customised based on whatever transport mechanism the request
was fetched over. There is no longer any need to have the payment request
be created (and presumably stored) the moment the QR code is generated.
Besides, that approach has all kinds of messy implementation problems. You
don't know the QR code will *ever* be scanned, but you must have the exact
payment request at the time the QR code is generated. Payment requests
expire, so you have to define some kind of timeout at which point the QR
code itself becomes invalid. Urgh.

Much better to have the PaymentRequest formatted and signed on demand, once
the URI is being resolved. But that means you have to abandon the h=
mechanism.

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