From: Michael Wozniak <mw@osfda•org>
To: Andreas Schildbach <andreas@schildbach•de>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Date: Tue, 1 Jul 2014 06:42:33 -0400 [thread overview]
Message-ID: <D4B82FD9-8078-48B2-9F91-8A3AB23AEAA7@osfda.org> (raw)
In-Reply-To: <lou05t$2ra$1@ger.gmane.org>
I think it makes more sense to not add a duplicate parameter. Current implementations will break if multiple r parameters are used (either reject the URI completely, or do something undefined). If a new parameter is used, then the current implementations will just ignore it if they don’t support it.
-
Michael Wozniak
On Jul 1, 2014, at 5:48 AM, Andreas Schildbach <andreas@schildbach•de> wrote:
> On 07/01/2014 10:18 AM, Mike Hearn wrote:
>> However it's not ideal at the moment. Basically the main problem is
>> that in the BIP72 there is no way to provide a fallback alternative
>> URI for payment request fetch if client wallet supports BIP70 but
>> doesn't not support fetching over bluetooth or bluetooth connection
>> fails for any reason.
>
> I think the way to go here is using multiple r= parameters.
>
>> So the idea here is that the recipient wallet both uploads to the
>> internet and exposes the payment request over Bluetooth simultaneously,
>> then let's the sending wallet pick whatever radio layer works best in
>> its current conditions?
>
> Either that, or just use the other ones as a fallback. Currently,
> Bitcoin Wallet just falls back to BIP21 if fetching the PR via the r=
> URL fails.
>
>> I think having multiple r= params is reasonable, but the Bluetooth
>> support is not specced in any BIP anyway. And if it were to be, people
>> would point out the lack of link-layer encryption.
>
> Its "specced" in code and implemented by several parties. I think its
> clear that link-layer encryption has to be an add-on to the current
> unencrypted connection, just like HTTPS is on top of HTTP. Anyway,
> that's unrelated to the question of how to provide fallback URLs.
>
> One more thought: We have a similar problem with the BIP70 payment URL.
> It doesn't allow for fallbacks either. I brought this issue up in the
> discussion phase of BIP70, but it was dismissed I think because of
> "let's not get too complex for the first version". The fallback here is
> to send the transaction via the P2P network.
>
> (I think BIP70 via P2P radio will get used more often in future. I plan
> to look into Bluetooth 4 LE as soon as I have devices and wanted to try
> WIFI Direct again also. I hope we can skip BIP72 for both of those, but
> lets see.)
>
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
next prev parent reply other threads:[~2014-07-01 11:00 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-27 11:59 Andreas Schildbach
2014-01-27 13:11 ` Mike Hearn
2014-01-27 18:18 ` Andreas Schildbach
2014-01-27 18:34 ` Mike Hearn
2014-01-27 20:53 ` [Bitcoin-development] Experiment with linking payment requests via href Andreas Schildbach
2014-01-27 21:47 ` Mike Hearn
2014-01-27 17:11 ` [Bitcoin-development] Payment Protocol for Face-to-face Payments Jeremy Spilman
2014-01-27 17:39 ` Andreas Schildbach
2014-01-27 18:18 ` Jeremy Spilman
2014-01-27 20:34 ` Roy Badami
2014-01-29 14:57 ` Christophe Biocca
2014-01-30 10:46 ` Andreas Schildbach
2014-01-30 10:50 ` Mike Hearn
2014-02-07 23:15 ` Andreas Schildbach
2014-03-02 9:47 ` Andreas Schildbach
2014-03-02 11:50 ` Mike Hearn
2014-03-20 2:22 ` Alex Kotenko
2014-03-20 3:31 ` Jeff Garzik
2014-03-20 8:09 ` Andreas Schildbach
2014-03-20 10:36 ` Mike Hearn
2014-03-20 12:12 ` Adam Back
2014-03-20 12:20 ` Mike Hearn
2014-03-20 17:31 ` Jeff Garzik
2014-03-20 17:42 ` Alex Kotenko
2014-03-20 18:01 ` Jeff Garzik
2014-03-21 10:28 ` Andreas Schildbach
2014-03-21 13:59 ` Alex Kotenko
2014-03-22 16:35 ` Jeff Garzik
2014-03-22 16:45 ` Mike Hearn
2014-03-22 16:55 ` Mark Friedenbach
2014-03-22 17:24 ` Jeff Garzik
2014-03-22 17:30 ` Mike Hearn
2014-03-23 3:47 ` Alex Kotenko
2014-03-21 10:25 ` Andreas Schildbach
2014-03-21 10:59 ` Adam Back
2014-03-21 11:08 ` Mike Hearn
2014-03-21 11:33 ` Mike Hearn
2014-03-21 12:25 ` Adam Back
2014-03-21 13:07 ` Mike Hearn
2014-03-20 18:20 ` Alex Kotenko
2014-03-20 18:31 ` Mike Hearn
2014-03-20 18:50 ` Alex Kotenko
2014-03-20 21:52 ` Roy Badami
2014-03-20 23:02 ` Mike Hearn
2014-03-26 22:48 ` Roy Badami
2014-03-26 22:56 ` Mike Hearn
2014-03-26 23:20 ` Andreas Schildbach
2014-03-27 10:08 ` Mike Hearn
2014-03-27 13:31 ` vv01f
2014-06-30 19:26 ` Alex Kotenko
2014-07-01 8:18 ` Mike Hearn
2014-07-01 9:48 ` Andreas Schildbach
2014-07-01 10:42 ` Michael Wozniak [this message]
2014-07-01 13:03 ` Alex Kotenko
2014-07-01 14:59 ` Andreas Schildbach
2014-07-01 15:07 ` Michael Wozniak
2014-07-01 15:39 ` Andreas Schildbach
2014-07-01 17:18 ` Alex Kotenko
2014-07-01 17:59 ` Mike Hearn
2014-07-02 8:49 ` Alex Kotenko
2014-03-21 10:43 ` Andreas Schildbach
2014-03-20 8:08 ` Andreas Schildbach
2014-03-20 16:14 ` Alex Kotenko
2014-03-21 9:47 ` Andreas Schildbach
2014-03-21 13:54 ` Alex Kotenko
2014-03-21 14:51 ` Andreas Schildbach
2014-03-21 15:38 ` Alex Kotenko
2014-03-21 15:20 ` Andreas Schildbach
2014-03-21 15:24 ` Mike Hearn
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=D4B82FD9-8078-48B2-9F91-8A3AB23AEAA7@osfda.org \
--to=mw@osfda$(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