hello all,

yes the biggest advantage of bech32 would be for making small QR codes,
where it does much more savings than in ascii.
(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)

bech32 is designed also to make small QR codes because of the ability to
create text-mode QR-codes which are much smaller.
that is *if* the bech32 string first is made uppercase, and you avoid
inserting certain characters such as '@' and ':'

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.

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.
(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)

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?"

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.

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 mcdonalds.com isn't hijacked by someone
that wants to prevent you from using LN, just as you would have to while
bootstrapping.

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.

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?

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.
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.

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.

https://www.robtex.com/lightning/node/02ad6fb8d693dc1e4569bcedefadf5f72a931ae027dc0f0c544b34c1c6f3b9a02b





On Wed, Apr 11, 2018 at 2:47 AM, Rusty Russell <ru...@rustcorp.com.au>
wrote:

> Robert Olsson <rob...@robtex.com> writes:
> > Hello all,
> >
> > I seem to not find a bolt regarding the QR code of node@ip:port
> >
> > It seems eclair only supports the format hex@ip:port format, and i
> haven't
> > tried any other mobile wallets.
>
> I anticipate a move away from "manually connect to node" and this wart
> will be less visible.  We could come up with a bech32 'ln1' encoding, I
> guess.  It would be 62 chars vs 66 though, if my math is correct...
>
> Cheers,
> Rusty.
>
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to