Eric Voskuil [ARCHIVE] on Nostr: 📅 Original date posted:2015-02-05 📝 Original message:Hi Andy, This is good ...
📅 Original date posted:2015-02-05
📝 Original message:Hi Andy,
This is good stuff. I've spent quite a bit of time on this question, but
set aside most of it earlier in the year in order to make some progress
in other areas. I did review what I found available at the time
pertaining to the Schildbach implementation and these questions.
Skimming the links now I'm encouraged, but I see several things that I'd
like to discuss at greater length than is appropriate here.
The main advantage of BLE over BT is that it uses much less power, with
a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can
be even greater and connection latency lower than BT. For payment
purposes the lower bandwidth isn't much of a hit.
e
On 02/05/2015 03:38 PM, Andy Schroder wrote:
> Hello,
>
> With the recent discussion started today regarding another bluetooth
> communication proposal created by Airbitz, I'd like to bring people's
> attention back to this proposal that saw little discussion last fall. I
> guess I'm not sure why two proposals are being created. Is their some
> advantage of using bluetooth low energy over standard bluetooth (I'm not
> well versed in bluetooth low energy)? This NFC coupled approach seems to
> avoid a lot of issues with identifying the correct payee. You can see
> this proposed scheme demonstrated in action in a POS application in the
> video link below which demonstrates it with my fuel pump and Andreas
> Schildbach's wallet.
>
> There was a small discussion that occurred after my original
> announcement below. If you are new to this e-mail list, you can find an
> archive of those few replies here:
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html
>
> Since this original announcement, a few improvements have been made to
> the proposal:
>
> 1. Improved documentation and explanation of the use cases in
> Schildbach's wallet's wiki
> 1. https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests
> 2. Issue with the payment_url field has resolved by changing to a
> repeated field and requiring the wallet to search for the protocol
> they want to use, rather than expecting it to be a certain element
> number in the list.
> 1. https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki
>
>
> Although there are some interesting use cases of Airbitz's proposal's
> work flow, tapping an NFC radio with a 5 mm range requires much less
> brain power and time than picking the correct name on the app's screen.
> The manual name picking is going to be especially crazy in a very
> congested location. The payer isn't ever going to want to have to try
> and figure out what register or payment terminal they are at for most
> applications I would ever use.
>
> I'd like to see something happen with this technology. I've also noticed
> that micropayment channels have little formality to being established
> practically and it would be awesome if they could be managed over
> bluetooth as well. Maybe more improvements to the payment protocol can
> simultaneously result (and also extended to bluetooth) that embrace the
> establishment of micropayment channels.
>
>
>
> Andy Schroder
>
> On 10/17/2014 03:58 PM, Andy Schroder wrote:
>> Hello,
>>
>> I'd like to introduce two proposed BIPs. They are primarily focused on
>> implementing the payment protocol using bluetooth connections. I've
>> been working on automated point of sale devices and bluetooth
>> communication is critical in my mind due to the potential lack of
>> internet access at many points of sale, either due to lack of cellular
>> internet coverage, lack of payee providing wireless internet, and/or
>> due to financial constraints of the payer prohibiting them from
>> maintaining a cellular internet service plan. These BIPs are largely
>> modeled after the current functionality of Andreas Schildbach's
>> android Bitcoin Wallet's bluetooth capability. I've discussed the
>> communication scheme with him in depth and believe these proposals to
>> clearly and accurately represent the communication scheme.
>>
>> There is also an additional &h= parameter added to the bitcoin: URI
>> scheme which applies to both bluetooth and http payment protocol
>> requests which allows for a hash of the payment request to be
>> included. This hash was proposed by Andreas as an amendment to BIP72,
>> but others preferred not to amend BIP72 since it has already been put
>> into place. The current version of Schildbach's bitcoin wallet already
>> supports the "h parameter".
>>
>> I'd appreciate feedback from everyone, particularly wallet developers
>> as widespread bluetooth support among wallets is very important to me.
>> I'm also very new to this mailing list as well as the BIP writing
>> process, so I'd appreciate your understanding if my conventions are
>> not standard. I am currently using the naming conventions "TBIP", so
>> that I can propose /temporary/ BIP numbers, and cross reference
>> between the two. Obviously these will change if the BIPs are formally
>> adopted. You can find a copy of these proposed BIPs at the following
>> links:
>>
>> * https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki
>> * https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki
>>
>>
>> If you are interested, you can see a demonstration of many of the
>> proposed features using Schildbach's wallet and my fuel pump in a
>> video I recently created: https://youtu.be/kkVAhA75k1Y . The main
>> thing not implemented is multiple URLs for the payment protocol, so,
>> as a hack, I'm just presenting https vi QR code and bluetooth via NFC
>> on my fuel pump for now.
>>
>>
>>
>> There are a few known issues that could be improved to this bluetooth
>> communication scheme as well as the general payment protocol and
>> myself and Andreas would like to receive feedback regarding concerns
>> and potential solutions. Some of the known issues are:
>>
>> * There may seem to be some inconsistency in the connection header
>> messages between the payment request connection and the payment
>> connection. This is largely because it is how Andreas originally
>> implemented the communication and is hesitant to change it since
>> there are many instances of is software already deployed that
>> implement this scheme.
>> * The current method uses an unauthenticated bluetooth connection
>> for bluetooth 2.1 and newer devices (subject to man in the middle
>> attacks, but not passive eavesdroppers), and an unsecure and
>> unauthenticated connection for older devices. The known concerns
>> here are that someone within 100 meters of the payer could track
>> the bitcoin addresses used for the transaction and could possibly
>> replace the refund address by submitting a forged payment message
>> to the payee. Requiring bluetooth 2.1 and authenticating the
>> connection out of band unfortunately don't seem to be as
>> straightforward/simple of a task with most bluetooth libraries
>> (although I'd love for someone to prove me wrong). It's possible
>> this communication scheme could be extended to use an https "like"
>> protocol that would not care if the underlying bluetooth
>> connection is authenticated or encrypted. It's actually possible
>> that http over a bluetooth socket (instead of tcp socket) could be
>> implemented, however it is presently uncertain whether this would
>> be too slow, too much overhead (both on the devices software and
>> communication), or if http could easily be run over bluetooth
>> sockets on all platforms.
>> * 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?
>> * 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. As it currently is, the payee
>> can specify multiple receiving addresses in order to require a
>> payer split up the payments so that when the payee then goes to
>> spend the funds later, they don't necessarily have to give their
>> payees as much knowledge of their balances and spending and
>> receiving habits and sources. As the payment protocol currently is
>> requiring all output amounts to be matched exactly for each
>> output, there is no flexibility given to the payer in order to
>> reduce a merging or unnecessary diverging of account funds, which
>> can reduce the privacy of both the payer and the payee. If the
>> payee were given the option to allow the payer the option to
>> divide the amounts amount the outputs intelligently, there can be
>> some privacy gained.
>> * 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.
>> * 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!).
>> Another project may be to develop a blockchain query protocol of
>> some kind where retailers can provide access to blockchain data so
>> that customer's wallets can update their known unspent outputs via
>> bluetooth. It's possible such a bluetooth system could be used in
>> combination of "Kryptoradio" like broadcasts to provide multiple
>> blockchain references.
>> * The additional payment_url approach is a bit sloppy of a solution
>> in the PaymentDetails portion of the PaymentRequest. It would have
>> been ideal to just change this from an optional field to a
>> repeated field, however, the backwards compatibility in the
>> protocol buffer format will provide the last item in the array for
>> a repeated field (to a code that expects it to be an optional
>> field), rather than the first. Because of this, backwards
>> compatibility with https payment requests wouldn't work if the
>> payment_url field is just changed to a repeated field.
>> o Possible alternatives to what is described in the proposed BIP
>> + Change payment_url to a repeated field and then reverse
>> the order of the parameter numbers in the payment_url,
>> compared to the bitcoin URL "r parameter".
>> + Create an additional, new payment_url_multi repeated field
>> (or some better name), and then leave the original
>> payment_url field in there for backwards compatibility
>> (and then maybe phase it out in the future).
>> o Reference
>> + https://developers.google.com/protocol-buffers/docs/proto#updating
>> # "|optional| is compatible with |repeated|. Given
>> serialized data of a repeated field as input, clients
>> that expect this field to be |optional| will take the
>> last input value if it's a primitive type field or
>> merge all input elements if it's a message type field."
>>
>>
>>
>> Your comments and suggestions would be greatly appreciated.
>>
>> --
>> Andy Schroder
>>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/cd2b0987/attachment.sig>;
📝 Original message:Hi Andy,
This is good stuff. I've spent quite a bit of time on this question, but
set aside most of it earlier in the year in order to make some progress
in other areas. I did review what I found available at the time
pertaining to the Schildbach implementation and these questions.
Skimming the links now I'm encouraged, but I see several things that I'd
like to discuss at greater length than is appropriate here.
The main advantage of BLE over BT is that it uses much less power, with
a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can
be even greater and connection latency lower than BT. For payment
purposes the lower bandwidth isn't much of a hit.
e
On 02/05/2015 03:38 PM, Andy Schroder wrote:
> Hello,
>
> With the recent discussion started today regarding another bluetooth
> communication proposal created by Airbitz, I'd like to bring people's
> attention back to this proposal that saw little discussion last fall. I
> guess I'm not sure why two proposals are being created. Is their some
> advantage of using bluetooth low energy over standard bluetooth (I'm not
> well versed in bluetooth low energy)? This NFC coupled approach seems to
> avoid a lot of issues with identifying the correct payee. You can see
> this proposed scheme demonstrated in action in a POS application in the
> video link below which demonstrates it with my fuel pump and Andreas
> Schildbach's wallet.
>
> There was a small discussion that occurred after my original
> announcement below. If you are new to this e-mail list, you can find an
> archive of those few replies here:
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html
>
> Since this original announcement, a few improvements have been made to
> the proposal:
>
> 1. Improved documentation and explanation of the use cases in
> Schildbach's wallet's wiki
> 1. https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests
> 2. Issue with the payment_url field has resolved by changing to a
> repeated field and requiring the wallet to search for the protocol
> they want to use, rather than expecting it to be a certain element
> number in the list.
> 1. https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki
>
>
> Although there are some interesting use cases of Airbitz's proposal's
> work flow, tapping an NFC radio with a 5 mm range requires much less
> brain power and time than picking the correct name on the app's screen.
> The manual name picking is going to be especially crazy in a very
> congested location. The payer isn't ever going to want to have to try
> and figure out what register or payment terminal they are at for most
> applications I would ever use.
>
> I'd like to see something happen with this technology. I've also noticed
> that micropayment channels have little formality to being established
> practically and it would be awesome if they could be managed over
> bluetooth as well. Maybe more improvements to the payment protocol can
> simultaneously result (and also extended to bluetooth) that embrace the
> establishment of micropayment channels.
>
>
>
> Andy Schroder
>
> On 10/17/2014 03:58 PM, Andy Schroder wrote:
>> Hello,
>>
>> I'd like to introduce two proposed BIPs. They are primarily focused on
>> implementing the payment protocol using bluetooth connections. I've
>> been working on automated point of sale devices and bluetooth
>> communication is critical in my mind due to the potential lack of
>> internet access at many points of sale, either due to lack of cellular
>> internet coverage, lack of payee providing wireless internet, and/or
>> due to financial constraints of the payer prohibiting them from
>> maintaining a cellular internet service plan. These BIPs are largely
>> modeled after the current functionality of Andreas Schildbach's
>> android Bitcoin Wallet's bluetooth capability. I've discussed the
>> communication scheme with him in depth and believe these proposals to
>> clearly and accurately represent the communication scheme.
>>
>> There is also an additional &h= parameter added to the bitcoin: URI
>> scheme which applies to both bluetooth and http payment protocol
>> requests which allows for a hash of the payment request to be
>> included. This hash was proposed by Andreas as an amendment to BIP72,
>> but others preferred not to amend BIP72 since it has already been put
>> into place. The current version of Schildbach's bitcoin wallet already
>> supports the "h parameter".
>>
>> I'd appreciate feedback from everyone, particularly wallet developers
>> as widespread bluetooth support among wallets is very important to me.
>> I'm also very new to this mailing list as well as the BIP writing
>> process, so I'd appreciate your understanding if my conventions are
>> not standard. I am currently using the naming conventions "TBIP", so
>> that I can propose /temporary/ BIP numbers, and cross reference
>> between the two. Obviously these will change if the BIPs are formally
>> adopted. You can find a copy of these proposed BIPs at the following
>> links:
>>
>> * https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki
>> * https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki
>>
>>
>> If you are interested, you can see a demonstration of many of the
>> proposed features using Schildbach's wallet and my fuel pump in a
>> video I recently created: https://youtu.be/kkVAhA75k1Y . The main
>> thing not implemented is multiple URLs for the payment protocol, so,
>> as a hack, I'm just presenting https vi QR code and bluetooth via NFC
>> on my fuel pump for now.
>>
>>
>>
>> There are a few known issues that could be improved to this bluetooth
>> communication scheme as well as the general payment protocol and
>> myself and Andreas would like to receive feedback regarding concerns
>> and potential solutions. Some of the known issues are:
>>
>> * There may seem to be some inconsistency in the connection header
>> messages between the payment request connection and the payment
>> connection. This is largely because it is how Andreas originally
>> implemented the communication and is hesitant to change it since
>> there are many instances of is software already deployed that
>> implement this scheme.
>> * The current method uses an unauthenticated bluetooth connection
>> for bluetooth 2.1 and newer devices (subject to man in the middle
>> attacks, but not passive eavesdroppers), and an unsecure and
>> unauthenticated connection for older devices. The known concerns
>> here are that someone within 100 meters of the payer could track
>> the bitcoin addresses used for the transaction and could possibly
>> replace the refund address by submitting a forged payment message
>> to the payee. Requiring bluetooth 2.1 and authenticating the
>> connection out of band unfortunately don't seem to be as
>> straightforward/simple of a task with most bluetooth libraries
>> (although I'd love for someone to prove me wrong). It's possible
>> this communication scheme could be extended to use an https "like"
>> protocol that would not care if the underlying bluetooth
>> connection is authenticated or encrypted. It's actually possible
>> that http over a bluetooth socket (instead of tcp socket) could be
>> implemented, however it is presently uncertain whether this would
>> be too slow, too much overhead (both on the devices software and
>> communication), or if http could easily be run over bluetooth
>> sockets on all platforms.
>> * 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?
>> * 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. As it currently is, the payee
>> can specify multiple receiving addresses in order to require a
>> payer split up the payments so that when the payee then goes to
>> spend the funds later, they don't necessarily have to give their
>> payees as much knowledge of their balances and spending and
>> receiving habits and sources. As the payment protocol currently is
>> requiring all output amounts to be matched exactly for each
>> output, there is no flexibility given to the payer in order to
>> reduce a merging or unnecessary diverging of account funds, which
>> can reduce the privacy of both the payer and the payee. If the
>> payee were given the option to allow the payer the option to
>> divide the amounts amount the outputs intelligently, there can be
>> some privacy gained.
>> * 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.
>> * 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!).
>> Another project may be to develop a blockchain query protocol of
>> some kind where retailers can provide access to blockchain data so
>> that customer's wallets can update their known unspent outputs via
>> bluetooth. It's possible such a bluetooth system could be used in
>> combination of "Kryptoradio" like broadcasts to provide multiple
>> blockchain references.
>> * The additional payment_url approach is a bit sloppy of a solution
>> in the PaymentDetails portion of the PaymentRequest. It would have
>> been ideal to just change this from an optional field to a
>> repeated field, however, the backwards compatibility in the
>> protocol buffer format will provide the last item in the array for
>> a repeated field (to a code that expects it to be an optional
>> field), rather than the first. Because of this, backwards
>> compatibility with https payment requests wouldn't work if the
>> payment_url field is just changed to a repeated field.
>> o Possible alternatives to what is described in the proposed BIP
>> + Change payment_url to a repeated field and then reverse
>> the order of the parameter numbers in the payment_url,
>> compared to the bitcoin URL "r parameter".
>> + Create an additional, new payment_url_multi repeated field
>> (or some better name), and then leave the original
>> payment_url field in there for backwards compatibility
>> (and then maybe phase it out in the future).
>> o Reference
>> + https://developers.google.com/protocol-buffers/docs/proto#updating
>> # "|optional| is compatible with |repeated|. Given
>> serialized data of a repeated field as input, clients
>> that expect this field to be |optional| will take the
>> last input value if it's a primitive type field or
>> merge all input elements if it's a message type field."
>>
>>
>>
>> Your comments and suggestions would be greatly appreciated.
>>
>> --
>> Andy Schroder
>>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/cd2b0987/attachment.sig>;