Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XgEd8-0004ji-Ia for bitcoin-development@lists.sourceforge.net; Mon, 20 Oct 2014 15:12:18 +0000 X-ACL-Warn: Received: from uschroder.com ([74.142.93.202]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1XgEd5-0002vG-Dg for bitcoin-development@lists.sourceforge.net; Mon, 20 Oct 2014 15:12:18 +0000 Received: from [192.168.253.4] (cpe-74-139-170-82.swo.res.rr.com [74.139.170.82]) by uschroder.com (Postfix) with ESMTPSA id 4FDF62295C9A6; Mon, 20 Oct 2014 11:12:09 -0400 (EDT) Message-ID: <54452648.8040409@AndySchroder.com> Date: Mon, 20 Oct 2014 11:12:08 -0400 From: Andy Schroder User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mike Hearn References: <544174F8.1050208@AndySchroder.com> In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: id=2D44186B; url=http://andyschroder.com/static/AndySchroder.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NGn5USirRDK5SrTc10hCsBXFcLxEDmV1u" X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1XgEd5-0002vG-Dg 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 15:12:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NGn5USirRDK5SrTc10hCsBXFcLxEDmV1u Content-Type: multipart/alternative; boundary="------------010608070102050309080509" This is a multi-part message in MIME format. --------------010608070102050309080509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello Mike, Thanks for the feedback. I have indicated some replies below... Andy Schroder On 10/20/2014 08:50 AM, Mike Hearn wrote: > Hey Andy, > > Thanks for starting this discussion! > > One thing this brings up is the never-resolved issue of whether BIPs=20 > should document how we'd /like/ things to work, or how things=20 > /actually do/ work. BIP32 is an example of the former - it was new=20 > technology and the spec was finalised before any wallets actually=20 > implemented it. BIP 44 is an example of the latter, it basically=20 > 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=20 > preserving compatibility with existing Android apps is surely useful,=20 > 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=20 > don't have a strong opinion on that. My gut feeling is that these=20 > documents should possibly be just wiki pages on Andreas' github. Then=20 > if the protocol is brought to a point where it seems pretty good,=20 > maybe it can be BIPped at that point. Alternatively, if developers of=20 > other wallet apps feel they'd like a BIP right now even in the current = > state, that would be a very important data point. Whatever you all want to do here is fine with me. I am new to this=20 process, so I have no preference. The payment_url portion is not=20 actually part of "Bitcoin Wallet" yet though. > > 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,=20 > perfect header format is probably not worth the inevitable hassle and=20 > transition period that would result. That's kind of what Schildbach and I were thinking so it is why we left=20 the proposed spec defined as his app currently functions. > * 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 -=20 > the first Bluetooth support in Bitcoin Wallet for Android was written=20 > by me in a frantic Berlin hackathon over a weekend. We barely got it=20 > working at all by the end, so doing encryption/auth was out of the=20 > question. Then I went back to more important tasks and what got=20 > shipped was a cleaned up/robustified version of that. > > Re: hash. I'm not a fan of this approach. For one, in future there=20 > might not even BE a uri involved, e.g. consider the Square style UX=20 > where the merchant is broadcasting an endpoint via BLE and the phone=20 > just automagically connects, sees a trusted merchant and pays. Super=20 > slick, we definitely want it - but no URI. Then of course there's the=20 > usual QR code size limitations. "Bitcoin Wallet" currently does a similar thing by submitting a payment=20 request via NFC and skipping the bitcoin URI. This works just fine in=20 conjunction with bitcoin: URI support. I'm not doing it this way on my=20 fuel pump (still submitting a bitcoin: URI), because I don't think any=20 other wallets (other than "Bitcoin Wallet" derivatives) support such a=20 feature and because I'm not sure if signed payment requests can be=20 transmitted over NFC well because the message may be too large when the=20 certificate chain is included. My point is, you can have both and if you are going to it doesn't hurt=20 to include the h=3D parameter for cases when a bitcoin: URI will still be= =20 used. > > Encrypting/authing the connection at the app layer does not have to be = > difficult. What we really need/want, is a simple lightweight library=20 > that does an ECDH key agreement using secp256k1, and then does=20 > AES+HMAC on framed messages. Such a protocol would be useful not only=20 > for this use case, but perhaps for encrypting/authing the p2p protocol = > in future as well. I'm not a cryptography expert, but why not just wrap the bluetooth=20 connection with SSL and not reimplement ECDH? Is this hard to do with=20 android/java? > > Once the encrypted connection is set up above the Bluetooth layer, the = > payment protocol request can then be signed either with a regular=20 > 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=20 > any additional data by doubling up the backwards compatibility=20 > support. Or if there's no URI, then of course, the payment request=20 > 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=20 > binding the connection to a PKI identity and ensuring you're not=20 > talking to a MITM. This sounds great, but I thought it is not desired to divulge a bitcoin=20 public key until the time of signing a transaction. Isn't that the whole = point of having a public key hash and never reusing addresses? This=20 could be resolved by the payee immediately sending the payment to=20 another address after receiving it, but that is kind of a waste of a=20 transaction. Also, I would love a less PKI dependent way to authenticate = a transaction between the two parties, but I was trying to minimize the=20 discussion of general payment protocol modifications in this announcement= =2E > > I suspect that this is not anywhere near as hard to implement as one=20 > might think. ECDH is not a complex protocol. You certainly don't need=20 > 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=20 > 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 failu= re. We can do something like this, I guess. The issue I mentioned about the=20 message headers being inconsistent will have to be fixed though to to do = this. However, is anyone even using the HTTP base failure signal (I=20 don't even know what it is)? What about when new protocols other than=20 bluetooth are created? I'm just wondering if it's better to have more=20 functionality defined at the payment protocol level so that developers=20 have to learn less nuances about each particular protocol they are=20 implementing the payment protocol over. The other thing is what if you=20 want to indicate a failure, and a reason for that 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=20 > effort, let's not discuss that as part of Bluetooth support. Understood, I was just throwing this thought out there, but do realize=20 it is a separate discussion. > > Besides, no wallet uses even the existing support for merge avoidance=20 > in BIP70. In fact Andreas' wallet is one of the blocking factors here=20 > because it violates the specs by requiring the BIP70 request to have=20 > only a single output that matches the address specified in the URI.=20 > All because he doesn't trust HTTPS :( To be clear, the way I am currently implementing my fuel pump, I am=20 specifying 4 payment addresses with no amount requirement and a h=3D=20 parameter, and Schildbach's wallet does accept the payment request, but=20 only chooses to use the first payment address (this may have something=20 to do with the unspent outputs on my phone though). I believe=20 Schildbach's wallet still works if multiple addresses are defined and=20 multiple amounts, however, I'm not currently submitting payment requests = this way because of the merge avoidance constraints mentioned below. I don't trust HTTPS for a number of reasons. First off, it is way to=20 easy to get a signed certificate with no real validation by the=20 certificate signer. Second, the current PKI is a target for manipulation = by surveillance organizations because there are too few parties=20 involved. Third, even if you have a signed certificate that is really=20 owned by the person they say it is, it's not easy for a payer to quickly = verify the signer is really the correct one because retailers can=20 contract out their payment process to another party, have a central=20 office, subsidiary, or be doing business under a name that is not=20 necessarily their legal company name. Even if we replace the PKI with=20 something more distributed like namecoin, the third option is still=20 going to be an issue, which warrants the need for the h=3D parameter. > > I don't think adding even more privacy stuff to BIP70 makes any sense=20 > until we have implementations that actually exploit the existing=20 > support. And to get there, we must fix Andreas' wallet so it doesn't=20 > violate the specs anymore. Sorry Andreas. I know we argue about this=20 > 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,=20 > because they feel a need to test with every possible wallet app in=20 > case one of them has simply decided to do their own thing and become=20 > deliberately incompatible. And then why bother, there are more=20 > important things to do. I don't totally understand the background of what you are talking about=20 here, but I think the h=3D parameter may designed to address the issues=20 Schildbach has complying with the spec as you mention. > * 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=20 > 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=20 > because PKI signing is not in use, then it makes sense to use that=20 > part of the URI to do so. PKI is not in use for "Bitcoin Wallet" for providing payment request,=20 but it is in use in my fuel dispenser that was demonstrated in the=20 video. Actually, I should have clarified in my announcement that=20 "Bitcoin Wallet" only allows for bluetooth incoming connections for=20 submitting payment, not providing payment requests. Since the payment=20 request is unsigned and small, it can just be submitted via NFC (as I=20 have mentioned above), and bluetooth isn't really needed. Andreas does=20 have a branch that supports this but it is not included in the master=20 distribution branch. The primary reason he does not have this in the=20 master branch is because the payment protocol only supports signing of=20 payment requests via PKI, and it is difficult for a user to install a=20 PKI signed certificate on android, just for a single peer to peer use=20 case. I think for now he just uses that branch to test his functionality = for fetching bluetooth payment requests from devices like mine (although = I'm not aware of any other devices that actually exist right now). > * 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=20 > access radios of various forms, I doubt it's worth putting much effort = > in here. Bluetooth for submitting payments makes sense some of the=20 > time, partly for performance and partly because it's more=20 > decentralised than looping in an intermediary HTTPS server to=20 > 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,=20 > it's a separate effort. It is a separate effort, but I was mentioning it because it is related.=20 Your comment "Given that all interesting mobile devices have=20 sophisticated internet access radios of various forms, I doubt it's=20 worth putting much effort in here" makes me believe that you don't=20 understand the need for this. If you are to provide a full fledged wifi=20 connection to the customer, there would then have to be a very=20 sophisticated proxy server that can allow only access to bitcoin nodes,=20 and how to do that would be difficult since every node doesn't know all=20 of the nodes in the network. You'd also have to be able to make the=20 customer's phone automatically connect and disconnect from this service=20 without leaving a saved access point name in their wifi access point=20 list (otherwise you will have a bunch of them accumulate that you don't=20 care about). Having dedicated blockchain access is going to be a=20 necessity: everyone doesn't want a cellular internet plan, they can't=20 always afford it, and it isn't always available, and as I just=20 explained, wifi is currently a cumbersome solution to this problem. > * 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=20 > mechanism. If you reuse the backwards compatibility address, then the=20 > payment_url can of course be customised based on whatever transport=20 > 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=20 > messy implementation problems. You don't know the QR code will=20 > /ever/ be scanned, but you must have the exact payment request at the=20 > 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=20 > 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=3D mechanism. All this was already known but was not proposed because it does not=20 allow you to use the h=3D parameter. What do you propose to do instead of= =20 the h=3D parameter, but still allow for a trust anchor with the payee=20 still be maintained? Another option is to do the hashing to the payment=20 request before the payment_url is added to the payment request, however, = this then can allow a hacker to change the payment_url. --------------010608070102050309080509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Mike,

Thanks for the feedback. I have indicated some replies below...
= 
Andy Schroder
On 10/20/2014 08:50 AM, Mike Hearn wrote:
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 t= o 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.


Whatever you all want to do here is fine with me. I am new to this process, so I have no preference. The payment_url portion is not actually part of "Bitcoin Wallet" yet though.



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.<= /div>

That's kind of what Schildbach and I were thinking so it is why we left the proposed spec defined as his app currently functions.

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


"Bitcoin Wallet" currently does a similar thing by submitting a payment request via NFC and skipping the bitcoin URI. This works just fine in conjunction with bitcoin: URI support. I'm not doing it this way on my fuel pump (still submitting a bitcoin: URI), because I don't think any other wallets (other than "Bitcoin Wallet" derivatives) support such a feature and because I'm not sure if signed payment requests can be transmitted over NFC well because the message may be too large when the certificate chain is included.

My point is, you can have both and if you are going to it doesn't hurt to include the h=3D parameter for cases when a bitcoin: URI will= still be used.



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.

I'm not a cryptography expert, but why not just wrap the bluetooth connection with SSL and not reimplement ECDH? Is this hard to do with android/java?



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.

This sounds great, but I thought it is not desired to divulge a bitcoin public key until the time of signing a transaction. Isn't that the whole point of having a public key hash and never reusing addresses? This could be resolved by the payee immediately sending the payment to another address after receiving it, but that is kind of a waste of a transaction. Also, I would love a less PKI dependent way to authenticate a transaction between the two parties, but I was trying to minimize the discussion of general payment protocol modifications in this announcement.



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?<= br>
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).<= /div>

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

We can do something like this, I guess. The issue I mentioned about the message headers being inconsistent will have to be fixed though to to do this. However, is anyone even using the HTTP base failure signal (I don't even know what it is)? What about when new protocols other than bluetooth are created? I'm just wondering if it's better to have more functionality defined at the payment protocol level so that developers have to learn less nuances about each particular protocol they are implementing the payment protocol over. The other thing is what if you want to indicate a failure, and a reason for that 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.

Understood, I was just throwing this thought out there, but do realize it is a separate discussion.


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 :(

To be clear, the way I am currently implementing my fuel pump, I am specifying 4 payment addresses with no amount requirement and a h=3D parameter, and Schildbach's wallet does accept the payment request, but only chooses to use the first payment address (this may have something to do with the unspent outputs on my phone though). I believe Schildbach's wallet still works if multiple addresses are defined and multiple amounts, however, I'm not currently submitting payment requests this way because of the merge avoidance constraints mentioned below.

I don't trust HTTPS for a number of reasons. First off, it is way to easy to get a signed certificate with no real validation by the certificate signer. Second, the current PKI is a target for manipulation by surveillance organizations because there are too few parties involved. Third, even if you have a signed certificate that is really owned by the person they say it is, it's not easy for a payer to quickly verify the signer is really the correct one because retailers can contract out their payment process to another party, have a central office, subsidiary, or be doing business under a name that is not necessarily their legal company name. Even if we replace the PKI with something more distributed like namecoin, the third option is still going to be an issue, which warrants the need for the h=3D parameter.




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.


I don't totally understand the background of what you are talking about here, but I think the h=3D parameter may designed to address th= e issues Schildbach has complying with the spec as you mention.


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


PKI is not in use for "Bitcoin Wallet" for providing payment request, but it is in use in my fuel dispenser that was demonstrated in the video. Actually, I should have clarified in my announcement that "Bitcoin Wallet" only allows for bluetooth incoming connections for submitting payment, not providing payment requests. Since the payment request is unsigned and small, it can just be submitted via NFC (as I have mentioned above), and bluetooth isn't really needed. Andreas does have a branch that supports this but it is not included in the master distribution branch. The primary reason he does not have this in the master branch is because the payment protocol only supports signing of payment requests via PKI, and it is difficult for a user to install a PKI signed certificate on android, just for a single peer to peer use case. I think for now he just uses that branch to test his functionality for fetching bluetooth payment requests from devices like mine (although I'm not aware of any other devices that actually exist right now).





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

It is a separate effort, but I was mentioning it because it is related. Your comment "Given that all interesting mobile devices have sophisticated internet access radios of various forms, I doubt it's worth putting much effort in here" makes me believe that you don't understand the need for this. If you are to provide a full fledged wifi connection to the customer, there would then have to be a very sophisticated proxy server that can allow only access to bitcoin nodes, and how to do that would be difficult since every node doesn't know all of the nodes in the network. You'd also have to be able to make the customer's phone automatically connect and disconnect from this service without leaving a saved access point name in their wifi access point list (otherwise you will have a bunch of them accumulate that you don't care about). Having dedicated blockchain access is going to be a necessity: everyone doesn't want a cellular internet plan, they can't always afford it, and it isn't always available, and as I just explained, wifi is currently a cumbersome solution to this problem.

  • 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=3D mechanism.


All this was already known but was not proposed because it does not allow you to use the h=3D parameter. What do you propose to do instea= d of the h=3D parameter, but still allow for a trust anchor with the payee still be maintained? Another option is to do the hashing to the payment request before the payment_url is added to the payment request, however, this then can allow a hacker to change the payment_url.




--------------010608070102050309080509-- --NGn5USirRDK5SrTc10hCsBXFcLxEDmV1u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJURSZIAAoJEDT679stRBhrNwsIAMvuNh1jSbsr1OzV1IY862QB laAYz1cubtT/rKjJz7Z4QhP36agePrGgt60xvviqX78Flhgyz8mqTaDdd+s4Ar0y 0u2V7O0WXF1yv8vG4kNZ8WXSGlUH6PweYe5xyr5bi9EPCO1TJR6WF9v0ENOM5S9n Jma1eCFRzWdT+dtFA1iNEslGTa9KiLlP3lHRSQzRz7EEgVbvNtJSpQmNmxH9OrJb UQftm0DLire9fboVROFtnzpNDz/mXK6UlKv9HVrqr4RBoIYbzRcd3BuxeNNHCwOK P/D8KN8UwJtObYFOjCRtCattFi0+mjH2ro9WDDuBzD/x1rCTuvHWbCpZOWtXbTQ= =VIsY -----END PGP SIGNATURE----- --NGn5USirRDK5SrTc10hCsBXFcLxEDmV1u--