From: Andreas Schildbach <andreas@schildbach•de>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Date: Mon, 23 Feb 2015 01:58:42 +0100 [thread overview]
Message-ID: <mcdu03$fva$1@ger.gmane.org> (raw)
In-Reply-To: <54EA5A1C.2020701@AndySchroder.com>
On 02/22/2015 11:37 PM, Andy Schroder wrote:
> Andreas and I had a number of private discussions regarding the
> payment_url parameter. I had suggested a "additional_payment_urls"
> repeated parameter, but he didn't seem to like that idea and I
> personally am indifferent, so that is why we decided to just change
> payment_url to a repeated field. The spec is simpler without the
> "additional_payment_urls", but the wallets have to be a little bit
> smarter finding the right url they want to use in the list. It's maybe
> not a bad idea for the wallet to try all payment_url mechanisms in
> parallel. Should we add this as a recommendation to wallets in TBIP75?
I think it will cause too much chaos. My recommendation for the
payment_url field is prefer the same mechanism that was used for
fetching the payment request. Only if the recommendation fails use the
alternatives in order (or in reverse order, I'm not sure at the moment).
> Regarding the NFC data formats. I would like to clarify that the wallets
> are having those events dispatched by the android OS. The "URI" and
> "mime type" events are sent to the application in the same way as from
> other sources such as a web browser, e-mail, stand alone QR code scanner
> app, etc.. So, I don't think the wallet actually knows it is receiving
> the event from NFC.
I think it can know. The method for catching these intents is very
similar and you can reuse almost all code, but in fact you need to add
an additional line to your AndroidManifest.xml.
> That is one reason why so many existing wallets
> happen to support BIP21 payment request via NFC.
Many? Bitcoin Wallet and its forks were the only ones for about a year.
Only recently Mycelium caught up and the others still do not care I guess.
> I'm a little weary sending the "mime
> type" based format over NFC because of backwards compatibility and
> because of the long certificate chain that needs to be transferred. You
> want that tap to be as robust and fast as possible. A bluetooth
> connection can have a retry without any user interaction.
I agree whatever we do must be robust. However I see no reason why NFC
can't be robust, see my previous post.
> I don't really like the Airbitz proposal. Figuring out if your selecting
> is the right one is a real nuisance. The idea is neat in a few
> applications, but I just don't think it is going to work for people as
> the most efficient and trouble free option day to day. I realize they
> are probably doing it to work with Apple's limited functionality phones
> (and BLE is a new buzz word). However, I don't think we should base
> bitcoin around what Apple wants us to do. They've already had their war
> on bitcoin. They are going to do whatever they can to protect their NFC
> based payment system. We need to make their platform the the less
> desirable one if they are going to play the game that way. If that means
> an Airbitz like proposal is implemented as a fallback, maybe that is
> fine and POS systems need to support both, but I just don't think we
> should limit what we can do because of Apple's products capabilities.
Ack on Airbitz, and ack on our relationship to Apple (-:
> There is also the "ack" memo that I mentioned in reference [2]. I think
> we can improve upon this really. Can we make a new status field or
> different bluetooth message header? I know Andreas didn't want to change
> it because that is how his app already works, but I don't think the way
> it is is ideal.
I'm not against improving this point, but I felt the BT enhancements and
the r,r1,r2 proposals are already getting complex enough. I would like
to simplify the proposal by moving unrelated things to somewhere else.
next prev parent reply other threads:[~2015-02-23 0:58 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
2015-02-23 0:58 ` Andreas Schildbach [this message]
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='mcdu03$fva$1@ger.gmane.org' \
--to=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