<div dir="ltr">hello all,<div><br></div><div>yes the biggest advantage of bech32 would be for making small QR codes, where it does much more savings than in ascii.</div><div>(you could still print the hex underneath the QR code of course if you want to enter it manually. personally i would prefer bech32 there as well because of its advantages for manual typing, with checksums and error-corrections) <br><div><br><div>bech32 is designed also to make small QR codes because of the ability to create text-mode QR-codes which are much smaller.</div><div>that is *if* the bech32 string first is made uppercase, and you avoid inserting certain characters such as '@' and ':'</div><div><br></div><div>the invoices are pure bech32 and satisfies those requirements for small QR codes. however the only live case i've seen that actually realizes that and makes the QR code for invoices uppercase is blockstream, but i might be wrong.</div><div><br></div><div>anyhows, if you upon payment for lets say a burger can't find a route that will handle the amount, i think you probably would like to connect to the receiving party directly.</div><div>(rather than randomly select a node and open a channel to that one and hope that one has a path, and repeat that until it succeeds or you run out of onchain funds while your burger is getting cold. maybe the payee for the moment doesn't have any available inbound capacity at all, you'd be stuck forever trying out new channels)</div><div><br></div><div>i think connecting to the recipients node directly is far better. it could of course be optional, and the UX could ask the user "your current channels doesn't have a route to mcdonalds with sufficient capacity, do you want to open a new channel directly to mcdonalds, or to a randomly selected goat farmer on the other side of the world that might have a well funded path?"</div><div><br></div><div>if you DO want to open a direct channel to the stores you use the most, the invoice does already contain the node-id, and sure you could look that up in the graph to find out and your wallet will establish a properly sized connection, perhaps depending on your payment history, perhaps automatic even after successful payments via other routes.</div><div><br></div><div>imho it would be awesome if the invoice contained the addr-part (from node) as well to provide for automatic opening of channel without having to scan the graph, or better yet the proposed bolt12, even if it means you would have to rely on DNSSEC to make sure <a href="http://mcdonalds.com">mcdonalds.com</a> isn't hijacked by someone that wants to prevent you from using LN, just as you would have to while bootstrapping.<br></div><div><br></div><div>i imagine mcdonalds could print the QR-code on the papers on your trays and say "scan this and next time use our node! we have lower LN fees than burger king" and preferably use a protocol of some sorts to provide multiple alternative nodes (like bolt12), rather than just a single node-id that might be changed.</div><div><br></div><div>the lightning network is impressive, and it grows in connectivity and capacity. but i think direct channels to the nodes you pay frequently and from they guys that pay you will make the network grow faster and more natural rather than if you *only* make random channels to nodes that perhaps have made random channels to random nodes that in turn randomly connects to mcdonalds. and even when the lightning network is well funded, i still might want to avoid routing fees. shouldn't i be allowed to do that in an easy way?</div><div><br></div><div>sure it would make mcdonalds nodes turn into big hubs. at least slightly bigger and cheaper than burger king ones. free competition is a bitch.</div><div>and also your employer would have a direct channel to you, rather than via some random dude that for some reason decided that opening a channel to you enough for your monthly salary was a good idea.</div><div><br></div><div>regarding sizes of QR codes, i've made a reckless PoC-implementation of current hex, bech32 and bolt12(RIP?) QR-codes so you can compare the sizes.</div><div><br><div><a href="https://www.robtex.com/lightning/node/02ad6fb8d693dc1e4569bcedefadf5f72a931ae027dc0f0c544b34c1c6f3b9a02b">https://www.robtex.com/lightning/node/02ad6fb8d693dc1e4569bcedefadf5f72a931ae027dc0f0c544b34c1c6f3b9a02b</a><br></div><div><br></div></div></div></div><div><br></div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 11, 2018 at 2:47 AM, Rusty Russell <span dir="ltr"><<a href="mailto:rusty@rustcorp.com.au" target="_blank">rusty@rustcorp.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Robert Olsson <<a href="mailto:robban@robtex.com">robban@robtex.com</a>> writes:<br>
> Hello all,<br>
><br>
> I seem to not find a bolt regarding the QR code of node@ip:port<br>
><br>
> It seems eclair only supports the format hex@ip:port format, and i haven't<br>
> tried any other mobile wallets.<br>
<br>
</span>I anticipate a move away from "manually connect to node" and this wart<br>
will be less visible. We could come up with a bech32 'ln1' encoding, I<br>
guess. It would be 62 chars vs 66 though, if my math is correct...<br>
<br>
Cheers,<br>
Rusty.<br>
</blockquote></div><br></div></div>