From: Eric Voskuil <eric@voskuil•org>
To: Andreas Schildbach <andreas@schildbach•de>,
bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Date: Mon, 02 Mar 2015 16:54:18 -0800 [thread overview]
Message-ID: <54F5063A.1000309@voskuil.org> (raw)
In-Reply-To: <mcn3lf$78a$1@ger.gmane.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 --]
next prev parent reply other threads:[~2015-03-03 0:54 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-22 19:08 Jan Vornberger
2015-02-22 22:37 ` Andy Schroder
2015-02-22 23:06 ` Eric Voskuil
2015-02-22 23:32 ` Andy Schroder
2015-02-23 0:05 ` Eric Voskuil
2015-02-23 1:02 ` Andreas Schildbach
2015-02-23 7:36 ` Andy Schroder
2015-02-23 9:13 ` Natanael
2015-02-23 9:40 ` Eric Voskuil
2015-02-24 2:55 ` Eric Voskuil
2015-02-24 5:53 ` Andy Schroder
2015-02-24 11:28 ` Eric Voskuil
2015-02-24 19:49 ` Andy Schroder
2015-02-24 22:14 ` Eric Voskuil
2015-02-24 22:50 ` Andy Schroder
2015-02-25 2:09 ` Eric Voskuil
2015-02-28 9:46 ` Andy Schroder
2015-02-23 9:49 ` Andreas Schildbach
2015-02-23 10:08 ` Eric Voskuil
2015-02-23 10:58 ` Mike Hearn
2015-02-23 11:58 ` Andreas Schildbach
2015-02-23 12:18 ` Mike Hearn
2015-02-23 12:30 ` Andreas Schildbach
2015-02-23 23:00 ` Eric Voskuil
2015-02-23 23:11 ` Mike Hearn
2015-02-24 0:10 ` Eric Voskuil
2015-02-24 10:41 ` Mike Hearn
2015-02-26 12:30 ` Andreas Schildbach
2015-03-03 0:54 ` Eric Voskuil [this message]
2015-02-23 0:58 ` Andreas Schildbach
2015-02-23 15:09 ` Jan Vornberger
2015-02-23 16:59 ` Mike Hearn
2015-02-23 19:56 ` Jan Vornberger
2015-02-23 20:31 ` Mike Hearn
2015-02-24 6:14 ` Andy Schroder
2015-02-24 15:41 ` Jan Vornberger
2015-02-26 12:37 ` Andreas Schildbach
2015-02-22 22:39 ` Eric Voskuil
2015-02-22 22:48 ` Eric Voskuil
2015-02-22 23:35 ` Andy Schroder
2015-02-23 0:46 ` Eric Voskuil
2015-02-23 1:05 ` Andreas Schildbach
2015-02-23 1:55 ` Aaron Voisine
2015-02-23 0:48 ` Andreas Schildbach
[not found] <54ED2F34.8090704@voskuil.org>
[not found] ` <54ED3150.4020800@AndySchroder.com>
[not found] ` <54ED7D8B.5070903@schildbach.de>
2015-02-25 9:20 ` Eric Voskuil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54F5063A.1000309@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=andreas@schildbach$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox