>
> ​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.
>
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?
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.
So this is a bit tricky, overall. Right now I'd say things are kinda half
baked: not only is bluetooth not standardised nor encrypted (my fault, I
prototyped this code during a hackathon), but Bitcoin Wallet doesn't
properly implement BIP 72 either. To push this work forward I think we need
to sit down and do some more spec and implementation work :/
------------------------------------------------------------------------------
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
