public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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




  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 [Bitcoin-development] Payment Protocol for Face-to-face Payments 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.org \
    --cc=andreas@schildbach.de \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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