<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div style="font-family:'courier new',monospace;color:rgb(0,51,0)">
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. </div>
</div></div></blockquote><div><br></div><div>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?</div>
<div><br></div><div>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.</div><div><br>
</div><div>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 :/</div>
</div></div></div>