Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XgCPv-0001j5-VA for bitcoin-development@lists.sourceforge.net; Mon, 20 Oct 2014 12:50:32 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.178 as permitted sender) client-ip=209.85.214.178; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f178.google.com; Received: from mail-ob0-f178.google.com ([209.85.214.178]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XgCPu-0004Ak-3m for bitcoin-development@lists.sourceforge.net; Mon, 20 Oct 2014 12:50:31 +0000 Received: by mail-ob0-f178.google.com with SMTP id wn1so3684202obc.23 for ; Mon, 20 Oct 2014 05:50:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.183.70 with SMTP id h67mr21806475oif.19.1413809424587; Mon, 20 Oct 2014 05:50:24 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.108.196 with HTTP; Mon, 20 Oct 2014 05:50:24 -0700 (PDT) In-Reply-To: <544174F8.1050208@AndySchroder.com> References: <544174F8.1050208@AndySchroder.com> Date: Mon, 20 Oct 2014 14:50:24 +0200 X-Google-Sender-Auth: 5NTWFdVW7W30UMozRs9OVAMPFqw Message-ID: From: Mike Hearn To: Andy Schroder Content-Type: multipart/alternative; boundary=001a113ce0688863510505da280e X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1XgCPu-0004Ak-3m Cc: Bitcoin Dev , Andreas Schildbach Subject: Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 12:50:32 -0000 --001a113ce0688863510505da280e Content-Type: text/plain; charset=UTF-8 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. --001a113ce0688863510505da280e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Andy,

Thanks for starting this disc= ussion!

One thing this brings up is the never-reso= lved issue of whether BIPs should document how we'd like=C2=A0th= ings to work, or how things actually do=C2=A0work. BIP32 is an examp= le 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 i= s surely useful, having a well designed protocol is also good. The current = protocol has several problems. I don't know which is more important rig= ht 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, mayb= e it can be BIPped at that point. Alternatively, if developers of other wal= let apps feel they'd like a BIP right now even in the current state, th= at would be a very important data point.

Re: the a= ctual specs:
    <= li>There may seem to be some inconsistency in the connection header messages=C2=A0
IMHO we coul= d live with that. Although Android apps are updatable, perfect header forma= t is probably not worth the inevitable hassle and transition period that wo= uld 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 B= luetooth support in Bitcoin Wallet for Android was written by me in a frant= ic 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 vers= ion of that.

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

Encr= ypting/authing the connection at the app layer does not have to be difficul= t. What we really need/want, is a simple lightweight library that does an E= CDH key agreement using secp256k1, and then does AES+HMAC on framed message= s. 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 Bitc= oin key that was in the Bitcoin URI as the payment address (when a URI is a= vailable), thus linking the request to the URI without adding any additiona= l 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 si= gned 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 identi= ty 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 bl= own 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 &quo= t;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 w= e 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 boolea= n field added to the "PaymentDetails" portion of the "PaymentRequest"= ; to allow for the payer's wallet to match the "Output&quo= t; optional "amount" fields as a total amount of all Outputs, rathe= r than requiring the amount for each output to be matched exactly.
    • <= /ul>
Extending BIP70 with more negotiable privacy fe= atures is a different effort, let's not discuss that as part of Bluetoo= th support.

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

I don't think adding even more privacy stuff to BIP70 m= akes any sense until we have implementations that actually exploit the exis= ting 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, beca= use 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 incom= patible. And then why bother, there are more important things to do.=C2=A0<= /div>
  • 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 cou= rse, but it seems unlikely that address-less URIs can be relied upon any ti= me 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 broadcas= t (but this will need yet another radio!).
Given that all interesting mobile devices have sophisticated interne= t access radios of various forms, I doubt it's worth putting much effor= t 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 "blo= ck 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 d= efine the hashing mechanism. If you reuse the backwards compatibility addre= ss, then the payment_url can of course be customised based on whatever tran= sport mechanism the request was fetched over. There is no longer any need t= o have the payment request be created (and presumably stored) the moment th= e QR code is generated. Besides, that approach has all kinds of messy imple= mentation problems. You don't know the QR code will ever=C2=A0be= scanned, but you must have the exact payment request at the time the QR co= de is generated. Payment requests expire, so you have to define some kind o= f timeout at which point the QR code itself becomes invalid. Urgh.

Much better to have the PaymentRequest formatted and signe= d on demand, once the URI is being resolved. But that means you have to aba= ndon the h=3D mechanism.
--001a113ce0688863510505da280e--