Andy Schroder [ARCHIVE] on Nostr: š Original date posted:2015-02-22 š Original message:Andy Schroder On ...
š
Original date posted:2015-02-22
š Original message:Andy Schroder
On 02/22/2015 05:48 PM, Eric Voskuil wrote:
> One correction inline below.
>
> e
>
> On 02/22/2015 02:39 PM, Eric Voskuil wrote:
>> Hi Jan,
>>
>> This is really nice work.
>>
>> WRT the Schroder and Schildbach proposal, the generalization of the "r"
>> and "payment_url" parameters makes sense, with only the potential
>> backward compat issue on payment_url.
>>
>>> TBIP75 furthermore proposes to include an additional 'h' parameter
>>> which would be a hash of the BIP70 payment request, preventing a MITM
>>> attack on the Bluetooth channel even if the BIP70 payment request
>>> isn't signed. This would have also been my suggestion, although I
>>> know that Mike Hearn has raised concerns about this approach. One
>>> being, that one needs to finalize the BIP70 payment request at the
>>> time the QR code and NFC URI is generated.
>>> ...
>>> 3) Are there other comments regarding 'h' parameter as per TBIP75?
>> Yes, this design is problematic from a privacy standpoint. Anyone within
>> the rather significant range of the Bluetooth terminal is able to
>> capture payment requests and correlate them to people. In other words it
>> can be used to automate tainting.
>>
>> The problem is easily resolved by recognizing that, in the envisioned
>> face-to-face trade, proximity is the source of trust. Even in the above
>> proposal the "h" parameter is trusted because it was obtained by
>> proximity to the NFC terminal. The presumption is that this proximity
>> produces a private channel.
>>
>> As such the "tap" should transfer a session key used for symmetric block
>> cipher over the Bluetooth channel. This also resolves the issue of
>> needing to formulate the payment request before the NFC.
>>
>> As an aside, in other scenarios, such as an automated dispenser, this
>> presumption does not hold. The merchant is not present to guard against
>> device tampering. Those scenarios can be secured using BIP70, but cannot
>> guarantee privacy.
>>
>> The other differences I have with the proposal pertain to efficiency,
>> not privacy or integrity of the transaction:
>>
>> The proposed resource name is redundant with any unique identifier for
>> the session. For example, the "h" parameter is sufficient. But with the
>> establishment of a session key both as I propose above, the parties can
>> derive a sufficiently unique public resource name from a hash of the
>> key. An additional advantage is that the resource name can be
>> fixed-length, simplifying the encoding/decoding.
>>
>> The MAC address (and resource name) should be encoded using base58. This
> The MAC address (and session key) should be encoded using base58. This
As I mentioned in my other e-mail, I don't know that we can consider
this NFC a private channel, so I don't think a session key should be
transmitted over it.
>
>> is shorter than base16, is often shorter than base64, better
>> standardized and does not require URI encoding, and is generally
>> available to implementers.
>>
>> There is no need for the establishment of two Bluetooth services.
>>
>> I would change the payment_url recommendation so that the list order
>> represents a recommended ordering provided by the terminal for the wallet.
>>
>> I wrote up my thoughts on these considerations last year and recently
>> revised it by adding a section at the end to incorporate the "r" and
>> "payment_url" generalizations from Andreas and Andy.
The order is set so that it maintains backwards compatibility by
providing the https request first. As mentioned in the proposal, the
order of the r parameters has the recommended (but not required)
priority. The wallet is encouraged to use the same protocol (but not
required).
>>
>> https://github.com/evoskuil/bips/tree/master/docs
>>
>> e
>>
>>
>> On 02/22/2015 11:08 AM, Jan Vornberger wrote:
>>> Hi everyone,
>>>
>>> I am working on a Bitcoin point of sale terminal based on a Raspberry Pi, which
>>> displays QR codes, but also provides payment requests via NFC. It can optionally
>>> receive the sender's transaction via Bluetooth, so if the sender wallet
>>> supports it, the sender can be completely offline. Only the terminal needs an
>>> internet connection.
>>>
>>> Typical scenario envisioned: Customer taps their smartphone (or maybe smartwatch
>>> in the future) on the NFC pad, confirms the transaction on their phone
>>> (or smartwatch) and the transaction completes via Bluetooth and/or the phone's
>>> internet connection.
>>>
>>> You can see a prototype in action here:
>>>
>>> https://www.youtube.com/watch?v=P7vKHMoapr8
>>>
>>> The above demo uses a release version of Schildbach's Bitcoin Wallet, so it
>>> works as shown today. However, some parts - especially the Bluetooth stuff - are
>>> custom extensions of Schildbach's wallet which are not yet standard.
>>>
>>> I'm writing this post to document my experience implementing NFC and offline
>>> payments and hope to move the discussion forward around standardizing some of
>>> this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1,2]
>>> follows along the same lines, so his proposed TBIP74 [3] and TBIP75 [4] are
>>> relevant here as well.
>>>
>>>
>>> ## NFC vs Bluetooth vs NFC+Bluetooth ##
>>>
>>> Before I get into the implementation details, a few words for why I decided to
>>> go with the combination of NFC and Bluetooth:
>>>
>>> Doing everything via NFC is an interesting option to keep things simple, but the
>>> issue is, that one usually can't maintain the connection while the user confirms
>>> the transaction (as they take the device back to press a button or maybe enter a
>>> PIN). So there are three options:
>>>
>>> 1. Do a "double tap": User taps, takes the device back, confirms, then taps
>>> again to transmit the transaction. (I think Google Wallet does something like
>>> this.)
>>>
>>> 2. Confirm beforehand: User confirms, then taps and everything can happen in one
>>> go. The disadvantage is, that you confirm the transaction before you have seen
>>> the details. (I believe Google Wallet can also work this way.)
>>>
>>> 3. Tap the phone, then establish a Bluetooth connection which allows you to do
>>> all necessary communication even if the user takes the device back.
>>>
>>> I feel that option 3 is the nicest UX, so that is what I am focusing on right
>>> now, but there are pros and cons to all options. One disadvantage of option 3 in
>>> practice is, that many users - in my experience - have Bluetooth turned off, so
>>> it can result in additional UI dialogs popping up, asking the user to turn on
>>> Bluetooth.
>>>
>>> Regarding doing everything via Bluetooth or maybe BLE: I have been following the
>>> work that Airbitz has done around that, but personally I prefer the NFC
>>> interaction of "I touch what I want to pay" rather than "a payment request comes
>>> to me through the air and I figure out whether it is meant for me/is legitimate".
>>>
>>>
>>> ## NFC data formats ##
>>>
>>> A bit of background for those who are not that familiar with NFC: Most Bitcoin
>>> wallets with NFC support make use of NDEF (NFC Data Exchange Format) as far as I
>>> am aware (with CoinBlesk being an exception, which uses host-based card
>>> emulation, if I understand it correctly). NDEF defines a number of record types,
>>> among them 'URI' and 'Mime Type'.
>>>
>>> A common way of using NFC with Bitcoin is to create a URI record that contains a
>>> Bitcoin URI. Beyond that Schildbach's wallet (and maybe others?) also support
>>> the mime type record, which is then set to 'application/bitcoin-paymentrequest'
>>> and the rest of the NFC data is a complete BIP70 payment request.
>>>
>>>
>>> ## Implementation ##
>>>
>>> To structure the discussion a little bit, I have listed a number of scenarios to
>>> consider below. Not every possible combination is listed, but it should cover a
>>> bit of everything.
>>>
>>> Scenarios:
>>>
>>> 1) Scan QR code, transmit transaction via Bitcoin network
>>> Example QR code: bitcoin:1asdf...?amount=42
>>>
>>> 2) Touch NFC pad, transmit transaction via Bitcoin network
>>> Example NFC URI: bitcoin:1asdf...?amount=42
>>>
>>> 3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HTTP
>>> Example QR code: bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest
>>>
>>> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HTTP
>>> Example NFC URI: bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest
>>>
>>> 5) Touch NFC pad, receive BIP70 details directly, post transaction via HTTP
>>> Example NFC MIME record: application/bitcoin-paymentrequest + BIP70 payment request
>>>
>>> 6) Scan QR code, fetch BIP70 details via Bluetooth, post transaction via Bluetooth
>>> Example QR code: bitcoin:1asdf...?amount=42&bt=1234567890AB
>>> Payment request has 'payment_url' set to 'bt:1234567890AB'
>>>
>>> 7) Touch NFC pad, fetch BIP70 details via Bluetooth, post transaction via Bluetooth
>>> Example NFC URI: bitcoin:1asdf...?amount=42&bt=1234567890AB
>>> Payment request has 'payment_url' set to 'bt:1234567890AB'
>>>
>>> Scenarios 1 and 2 are basically the 'legacy'/pre-BIP70 approach and I am just
>>> listing them here for comparison. Scenario 3 is what is often in use now, for
>>> example when using a checkout screen by BitPay or Coinbase.
>>>
>>> I played around with both scenarios 4 and 5, trying to decide whether I should
>>> use an NFC URI record or already provide the complete BIP70 payment request via
>>> NFC.
>>>
>>> My experience here has been, that the latter was fairly fragile in my setup
>>> (Raspberry Pi, NFC dongle from a company called Sensor ID, using nfcpy). I tried
>>> with signed payment requests that were around 4k to 5k and the transfer would
>>> often not complete if I didn't hold the phone perfectly in place. So I quickly
>>> switched to using the NFC URI record instead and have the phone fetch the BIP70
>>> payment request via Bluetooth afterwards. Using this approach the amount of data
>>> is small enough that it's usually 'all or nothing' and that seems more robust to
>>> me.
>>>
>>> That said, I continue to have problems with the NFC stack that I'm using, so it
>>> might just be my NFC setup that is causing these problems. I will probably give
>>> the NXP NFC library a try next (which I believe is also the stack that is used
>>> by Android). Maybe I have more luck with that approach and could then switch to
>>> scenario 5.
>>>
>>> Scenarios 6 and 7 is what the terminal is doing right now. The 'bt' parameter is
>>> the non-standard extension of Andreas' wallet that I was mentioning. TBIP75
>>> proposes to change 'bt' into 'r1' as part of a more generic approach of
>>> numbering different sources for the BIP70 payment request. I think that is a
>>> good idea and would express my vote for this proposal. So the QR code or NFC URI
>>> would then look something like this:
>>>
>>> bitcoin:1asdf...?amount=42&r=https://example.org/bip70&r1=bt:1234567890AB/resource
>>>
>>> In addition the payment request would need to list additional 'payment_url's. My
>>> proposal would be to do something like this:
>>>
>>> message PaymentDetails {
>>> ...
>>> optional string payment_url = 6;
>>> optional bytes merchant_data = 7;
>>> repeated string additional_payment_urls = 8;
>>> // ^-- new; to hold things like 'bt:1234567890AB'
>>> }
>>>
>>> TBIP75 proposes to just change 'optional string payment_url' into 'repeated
>>> string payment_url'. If this isn't causing any problems (and hopefully not too
>>> much confusion?) I guess that would be fine too.
>>>
>>> In my opinion a wallet should then actually attempt all or multiple of the
>>> provided mechanisms in parallel (e.g. try to fetch the BIP70 payment request via
>>> both HTTP and Bluetooth) and go with whatever completes first. But that is of
>>> course up to each wallet to decide how to handle.
>>>
>>> TBIP75 furthermore proposes to include an additional 'h' parameter which would
>>> be a hash of the BIP70 payment request, preventing a MITM attack on the
>>> Bluetooth channel even if the BIP70 payment request isn't signed. This would
>>> have also been my suggestion, although I know that Mike Hearn has raised
>>> concerns about this approach. One being, that one needs to finalize the BIP70
>>> payment request at the time the QR code and NFC URI is generated.
>>>
>>>
>>> ## Questions ##
>>>
>>> My questions to the list:
>>>
>>> 1) Do you prefer changing 'optional string payment_url' into 'repeated string
>>> payment_url' or would you rather introduce a new field 'additional_payment_urls'?
>>>
>>> 2) @Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoin Wallet?
>>>
>>> 3) Are there other comments regarding 'h' parameter as per TBIP75?
>>>
>>> 4) General comments, advice, feedback?
>>>
>>> I appreciate your input! :-)
>>>
>>> Cheers,
>>> Jan
>>>
>>> [1] http://andyschroder.com/BitcoinFluidDispenser/
>>> [2] https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html
>>> [3] https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki
>>> [4] https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki
>>>
>>> ------------------------------------------------------------------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/ef4d3d0f/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/ef4d3d0f/attachment.sig>;
š Original message:Andy Schroder
On 02/22/2015 05:48 PM, Eric Voskuil wrote:
> One correction inline below.
>
> e
>
> On 02/22/2015 02:39 PM, Eric Voskuil wrote:
>> Hi Jan,
>>
>> This is really nice work.
>>
>> WRT the Schroder and Schildbach proposal, the generalization of the "r"
>> and "payment_url" parameters makes sense, with only the potential
>> backward compat issue on payment_url.
>>
>>> TBIP75 furthermore proposes to include an additional 'h' parameter
>>> which would be a hash of the BIP70 payment request, preventing a MITM
>>> attack on the Bluetooth channel even if the BIP70 payment request
>>> isn't signed. This would have also been my suggestion, although I
>>> know that Mike Hearn has raised concerns about this approach. One
>>> being, that one needs to finalize the BIP70 payment request at the
>>> time the QR code and NFC URI is generated.
>>> ...
>>> 3) Are there other comments regarding 'h' parameter as per TBIP75?
>> Yes, this design is problematic from a privacy standpoint. Anyone within
>> the rather significant range of the Bluetooth terminal is able to
>> capture payment requests and correlate them to people. In other words it
>> can be used to automate tainting.
>>
>> The problem is easily resolved by recognizing that, in the envisioned
>> face-to-face trade, proximity is the source of trust. Even in the above
>> proposal the "h" parameter is trusted because it was obtained by
>> proximity to the NFC terminal. The presumption is that this proximity
>> produces a private channel.
>>
>> As such the "tap" should transfer a session key used for symmetric block
>> cipher over the Bluetooth channel. This also resolves the issue of
>> needing to formulate the payment request before the NFC.
>>
>> As an aside, in other scenarios, such as an automated dispenser, this
>> presumption does not hold. The merchant is not present to guard against
>> device tampering. Those scenarios can be secured using BIP70, but cannot
>> guarantee privacy.
>>
>> The other differences I have with the proposal pertain to efficiency,
>> not privacy or integrity of the transaction:
>>
>> The proposed resource name is redundant with any unique identifier for
>> the session. For example, the "h" parameter is sufficient. But with the
>> establishment of a session key both as I propose above, the parties can
>> derive a sufficiently unique public resource name from a hash of the
>> key. An additional advantage is that the resource name can be
>> fixed-length, simplifying the encoding/decoding.
>>
>> The MAC address (and resource name) should be encoded using base58. This
> The MAC address (and session key) should be encoded using base58. This
As I mentioned in my other e-mail, I don't know that we can consider
this NFC a private channel, so I don't think a session key should be
transmitted over it.
>
>> is shorter than base16, is often shorter than base64, better
>> standardized and does not require URI encoding, and is generally
>> available to implementers.
>>
>> There is no need for the establishment of two Bluetooth services.
>>
>> I would change the payment_url recommendation so that the list order
>> represents a recommended ordering provided by the terminal for the wallet.
>>
>> I wrote up my thoughts on these considerations last year and recently
>> revised it by adding a section at the end to incorporate the "r" and
>> "payment_url" generalizations from Andreas and Andy.
The order is set so that it maintains backwards compatibility by
providing the https request first. As mentioned in the proposal, the
order of the r parameters has the recommended (but not required)
priority. The wallet is encouraged to use the same protocol (but not
required).
>>
>> https://github.com/evoskuil/bips/tree/master/docs
>>
>> e
>>
>>
>> On 02/22/2015 11:08 AM, Jan Vornberger wrote:
>>> Hi everyone,
>>>
>>> I am working on a Bitcoin point of sale terminal based on a Raspberry Pi, which
>>> displays QR codes, but also provides payment requests via NFC. It can optionally
>>> receive the sender's transaction via Bluetooth, so if the sender wallet
>>> supports it, the sender can be completely offline. Only the terminal needs an
>>> internet connection.
>>>
>>> Typical scenario envisioned: Customer taps their smartphone (or maybe smartwatch
>>> in the future) on the NFC pad, confirms the transaction on their phone
>>> (or smartwatch) and the transaction completes via Bluetooth and/or the phone's
>>> internet connection.
>>>
>>> You can see a prototype in action here:
>>>
>>> https://www.youtube.com/watch?v=P7vKHMoapr8
>>>
>>> The above demo uses a release version of Schildbach's Bitcoin Wallet, so it
>>> works as shown today. However, some parts - especially the Bluetooth stuff - are
>>> custom extensions of Schildbach's wallet which are not yet standard.
>>>
>>> I'm writing this post to document my experience implementing NFC and offline
>>> payments and hope to move the discussion forward around standardizing some of
>>> this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1,2]
>>> follows along the same lines, so his proposed TBIP74 [3] and TBIP75 [4] are
>>> relevant here as well.
>>>
>>>
>>> ## NFC vs Bluetooth vs NFC+Bluetooth ##
>>>
>>> Before I get into the implementation details, a few words for why I decided to
>>> go with the combination of NFC and Bluetooth:
>>>
>>> Doing everything via NFC is an interesting option to keep things simple, but the
>>> issue is, that one usually can't maintain the connection while the user confirms
>>> the transaction (as they take the device back to press a button or maybe enter a
>>> PIN). So there are three options:
>>>
>>> 1. Do a "double tap": User taps, takes the device back, confirms, then taps
>>> again to transmit the transaction. (I think Google Wallet does something like
>>> this.)
>>>
>>> 2. Confirm beforehand: User confirms, then taps and everything can happen in one
>>> go. The disadvantage is, that you confirm the transaction before you have seen
>>> the details. (I believe Google Wallet can also work this way.)
>>>
>>> 3. Tap the phone, then establish a Bluetooth connection which allows you to do
>>> all necessary communication even if the user takes the device back.
>>>
>>> I feel that option 3 is the nicest UX, so that is what I am focusing on right
>>> now, but there are pros and cons to all options. One disadvantage of option 3 in
>>> practice is, that many users - in my experience - have Bluetooth turned off, so
>>> it can result in additional UI dialogs popping up, asking the user to turn on
>>> Bluetooth.
>>>
>>> Regarding doing everything via Bluetooth or maybe BLE: I have been following the
>>> work that Airbitz has done around that, but personally I prefer the NFC
>>> interaction of "I touch what I want to pay" rather than "a payment request comes
>>> to me through the air and I figure out whether it is meant for me/is legitimate".
>>>
>>>
>>> ## NFC data formats ##
>>>
>>> A bit of background for those who are not that familiar with NFC: Most Bitcoin
>>> wallets with NFC support make use of NDEF (NFC Data Exchange Format) as far as I
>>> am aware (with CoinBlesk being an exception, which uses host-based card
>>> emulation, if I understand it correctly). NDEF defines a number of record types,
>>> among them 'URI' and 'Mime Type'.
>>>
>>> A common way of using NFC with Bitcoin is to create a URI record that contains a
>>> Bitcoin URI. Beyond that Schildbach's wallet (and maybe others?) also support
>>> the mime type record, which is then set to 'application/bitcoin-paymentrequest'
>>> and the rest of the NFC data is a complete BIP70 payment request.
>>>
>>>
>>> ## Implementation ##
>>>
>>> To structure the discussion a little bit, I have listed a number of scenarios to
>>> consider below. Not every possible combination is listed, but it should cover a
>>> bit of everything.
>>>
>>> Scenarios:
>>>
>>> 1) Scan QR code, transmit transaction via Bitcoin network
>>> Example QR code: bitcoin:1asdf...?amount=42
>>>
>>> 2) Touch NFC pad, transmit transaction via Bitcoin network
>>> Example NFC URI: bitcoin:1asdf...?amount=42
>>>
>>> 3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HTTP
>>> Example QR code: bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest
>>>
>>> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HTTP
>>> Example NFC URI: bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest
>>>
>>> 5) Touch NFC pad, receive BIP70 details directly, post transaction via HTTP
>>> Example NFC MIME record: application/bitcoin-paymentrequest + BIP70 payment request
>>>
>>> 6) Scan QR code, fetch BIP70 details via Bluetooth, post transaction via Bluetooth
>>> Example QR code: bitcoin:1asdf...?amount=42&bt=1234567890AB
>>> Payment request has 'payment_url' set to 'bt:1234567890AB'
>>>
>>> 7) Touch NFC pad, fetch BIP70 details via Bluetooth, post transaction via Bluetooth
>>> Example NFC URI: bitcoin:1asdf...?amount=42&bt=1234567890AB
>>> Payment request has 'payment_url' set to 'bt:1234567890AB'
>>>
>>> Scenarios 1 and 2 are basically the 'legacy'/pre-BIP70 approach and I am just
>>> listing them here for comparison. Scenario 3 is what is often in use now, for
>>> example when using a checkout screen by BitPay or Coinbase.
>>>
>>> I played around with both scenarios 4 and 5, trying to decide whether I should
>>> use an NFC URI record or already provide the complete BIP70 payment request via
>>> NFC.
>>>
>>> My experience here has been, that the latter was fairly fragile in my setup
>>> (Raspberry Pi, NFC dongle from a company called Sensor ID, using nfcpy). I tried
>>> with signed payment requests that were around 4k to 5k and the transfer would
>>> often not complete if I didn't hold the phone perfectly in place. So I quickly
>>> switched to using the NFC URI record instead and have the phone fetch the BIP70
>>> payment request via Bluetooth afterwards. Using this approach the amount of data
>>> is small enough that it's usually 'all or nothing' and that seems more robust to
>>> me.
>>>
>>> That said, I continue to have problems with the NFC stack that I'm using, so it
>>> might just be my NFC setup that is causing these problems. I will probably give
>>> the NXP NFC library a try next (which I believe is also the stack that is used
>>> by Android). Maybe I have more luck with that approach and could then switch to
>>> scenario 5.
>>>
>>> Scenarios 6 and 7 is what the terminal is doing right now. The 'bt' parameter is
>>> the non-standard extension of Andreas' wallet that I was mentioning. TBIP75
>>> proposes to change 'bt' into 'r1' as part of a more generic approach of
>>> numbering different sources for the BIP70 payment request. I think that is a
>>> good idea and would express my vote for this proposal. So the QR code or NFC URI
>>> would then look something like this:
>>>
>>> bitcoin:1asdf...?amount=42&r=https://example.org/bip70&r1=bt:1234567890AB/resource
>>>
>>> In addition the payment request would need to list additional 'payment_url's. My
>>> proposal would be to do something like this:
>>>
>>> message PaymentDetails {
>>> ...
>>> optional string payment_url = 6;
>>> optional bytes merchant_data = 7;
>>> repeated string additional_payment_urls = 8;
>>> // ^-- new; to hold things like 'bt:1234567890AB'
>>> }
>>>
>>> TBIP75 proposes to just change 'optional string payment_url' into 'repeated
>>> string payment_url'. If this isn't causing any problems (and hopefully not too
>>> much confusion?) I guess that would be fine too.
>>>
>>> In my opinion a wallet should then actually attempt all or multiple of the
>>> provided mechanisms in parallel (e.g. try to fetch the BIP70 payment request via
>>> both HTTP and Bluetooth) and go with whatever completes first. But that is of
>>> course up to each wallet to decide how to handle.
>>>
>>> TBIP75 furthermore proposes to include an additional 'h' parameter which would
>>> be a hash of the BIP70 payment request, preventing a MITM attack on the
>>> Bluetooth channel even if the BIP70 payment request isn't signed. This would
>>> have also been my suggestion, although I know that Mike Hearn has raised
>>> concerns about this approach. One being, that one needs to finalize the BIP70
>>> payment request at the time the QR code and NFC URI is generated.
>>>
>>>
>>> ## Questions ##
>>>
>>> My questions to the list:
>>>
>>> 1) Do you prefer changing 'optional string payment_url' into 'repeated string
>>> payment_url' or would you rather introduce a new field 'additional_payment_urls'?
>>>
>>> 2) @Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoin Wallet?
>>>
>>> 3) Are there other comments regarding 'h' parameter as per TBIP75?
>>>
>>> 4) General comments, advice, feedback?
>>>
>>> I appreciate your input! :-)
>>>
>>> Cheers,
>>> Jan
>>>
>>> [1] http://andyschroder.com/BitcoinFluidDispenser/
>>> [2] https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html
>>> [3] https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki
>>> [4] https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki
>>>
>>> ------------------------------------------------------------------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/ef4d3d0f/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/ef4d3d0f/attachment.sig>;