Michael Wozniak [ARCHIVE] on Nostr: 📅 Original date posted:2014-07-01 📝 Original message:I think it makes more ...

📅 Original date posted:2014-07-01
📝 Original message: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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development