Re: [Lightning-dev] QR of node information
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 wrote: > Robert Olsson 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
Re: [Lightning-dev] QR of node information
Robert Olsson 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
Re: [Lightning-dev] QR of node information
Hi all, On 9 April 2018 at 11:47, Corné Plooy via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > > Is this really only about reducing the size of QR codes? How many > percent reduction do you think you can accomplish with your approach? I > think, when it comes to reducing QR code size, it makes more sense to > think of a better way to encode the node ID. Hexadecimal isn't exactly > the most space-efficient encoding. > We'd save 33 bytes by not using hex. Makes the QR code a bit rarer (whatever is opposite of dense). I intend to support both approaches, if there are 33 bytes before the '@' it's raw, 66 it's hex. Igor > Op 07-04-18 om 17:17 schreef Robert Olsson: > > 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 thought there would be support for bech32 nodeid:s to keep the QR > > small, but it doesn't seem that way. > > > > If it isn't standardized yet, i think we should do it soon so all > > wallets will support it from start and we can avoid bulky QR codes. > > > > To fully utilize QR it should work with charset in text-mode, so i > > would suggest a format like > > > > lightning:ln1bech32nodeid/ipnumber/port > > > > where /port is optional if port is 9735 > > > > this is to avoid @ and confusion of : in ipv6 and :portnumber > > (skip '[' and ']' in ipv6) > > > > another approach would be to encode ip and portnumber in bech32 as > > well. my opinion is that everything coded entirely in bech32 shouldn't > > need a protocol so the 'lightning:' part could possibly be omitted as > > well. > > > > or did i just miss a bolt somewhere? > > > > best regards > > Robert Olsson > > > > > > > > > > > > > > > > ___ > > Lightning-dev mailing list > > Lightning-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -- *Igor Cota* Codex Apertus Ltd ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] QR of node information
Why put everything in bech32? It hurts readability. The only possible advantage is that data inside the bech32 blob can be digitally signed in a convenient way. If you don't need that, I'd keep your data ourside the bech32 blob, in a (expert-)human-readable format. Why not follow a regular URL format when host and port are involved? I don't see the advantage of lightning:ln1bech32nodeid/ipnumber/port over node@ip:port. In practice, I see both C-Lightning and LND also using node@ip:port, BTW. Is this really only about reducing the size of QR codes? How many percent reduction do you think you can accomplish with your approach? I think, when it comes to reducing QR code size, it makes more sense to think of a better way to encode the node ID. Hexadecimal isn't exactly the most space-efficient encoding. CJP Op 07-04-18 om 17:17 schreef Robert Olsson: > 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 thought there would be support for bech32 nodeid:s to keep the QR > small, but it doesn't seem that way. > > If it isn't standardized yet, i think we should do it soon so all > wallets will support it from start and we can avoid bulky QR codes. > > To fully utilize QR it should work with charset in text-mode, so i > would suggest a format like > > lightning:ln1bech32nodeid/ipnumber/port > > where /port is optional if port is 9735 > > this is to avoid @ and confusion of : in ipv6 and :portnumber > (skip '[' and ']' in ipv6) > > another approach would be to encode ip and portnumber in bech32 as > well. my opinion is that everything coded entirely in bech32 shouldn't > need a protocol so the 'lightning:' part could possibly be omitted as > well. > > or did i just miss a bolt somewhere? > > best regards > Robert Olsson > > > > > > > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] QR of node information
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 thought there would be support for bech32 nodeid:s to keep the QR small, but it doesn't seem that way. If it isn't standardized yet, i think we should do it soon so all wallets will support it from start and we can avoid bulky QR codes. To fully utilize QR it should work with charset in text-mode, so i would suggest a format like lightning:ln1bech32nodeid/ipnumber/port where /port is optional if port is 9735 this is to avoid @ and confusion of : in ipv6 and :portnumber (skip '[' and ']' in ipv6) another approach would be to encode ip and portnumber in bech32 as well. my opinion is that everything coded entirely in bech32 shouldn't need a protocol so the 'lightning:' part could possibly be omitted as well. or did i just miss a bolt somewhere? best regards Robert Olsson ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
