Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil <eric@voskuil.org>]

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

On 02/26/2015 04:30 AM, Andreas Schildbach wrote:
> On 02/24/2015 11:41 AM, Mike Hearn wrote:
>> On 02/23/2015 04:10 PM, Eric Voskuil wrote:
>>> Does this not also require the BT publication of the script for a P2SH
>>> address?
>>
>> You mean if the URI you're serving is like this?
>>
>>    bitcoin:3aBcD........?bt=....
>>
>> Yes it would. I guess then, the server would indicate both the script,
>> and the key within that script that it wanted to use. A bit more complex
>> but would still work to save URI space.
> 
> What if the script doesn't use any key at all?
> 
> Somehow this "re-using" the fallback address idea feels less and less
> appealing to me. I think we should add our own parameter and let go of
> fallback addresses as soon as possible. If will waste space during the
> transition period, but after that it should make no difference any more.

Agree. The amount of bitcoin URI space in question isn't a material
issue when it comes to NFC. The more significant considerations here are
the additional BT round trip to establish a session, greater complexity,
and the potential lack of a correlating address (as you point out above).

On the other hand I think the approach has merit in a scenario where the
bitcoin URI is read from a QR code and BT is available (IOW no NFC).
Generalizing it to the NFC-based bitcoin URI is the problem.

A much cleaner generalization is to rationalize the two approaches
*after* the bitcoin URI has been read (from either NFC or QR). In the QR
scenario the wallet can obtain a verifiable public key from the BT
terminal (subject to some limitations as discussed above). In the NFC
scenario the public key is just passed in the URI. The scenarios come
together at the point where they both have the public key (and the mac
address).

This of course implies that the the BT URL scheme, in order to be used
in both places, would have to allow the public key to be optional. But
in an NFC tap it would be present and in a QR scan it would not.

QR-BT
bitcoin:<bitcoin-address>?bts:<mac-address>

NFC-BT
bitcoin:[bitcoin-address]?bts:<mac-address>/<public-key>

As you say, this prevents the NFC scenario from perpetuating the
fallback address as a requirement, which eventually shortens the bitcoin
URI.

Making the public key a requirement when used with NFC would simplify
wallet development for NFC only wallets. But if a wallet supported both
NFC and QR scanning it wouldn't make much difference. So it's not
unreasonable to think of it like this:

QR-BT/NFC-BT
bitcoin:<bitcoin-address>?bts:<mac-address>
bitcoin:[bitcoin-address]?bts:<mac-address>/<public-key>

This provides greater generality, but it creates a situation where
NFC-only wallets need to support the more complex approach, and where
use in QR codes would have scanning issues. So I think it's better to
specify limits on each as in the first example.

e


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]