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:?bts: NFC-BT bitcoin:[bitcoin-address]?bts:/ 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:?bts: bitcoin:[bitcoin-address]?bts:/ 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