From laolu32 at gmail.com Mon May 1 18:03:08 2017 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Mon, 01 May 2017 18:03:08 +0000 Subject: [Lightning-dev] [RFC] Lightning payment format In-Reply-To: <87h918ghdv.fsf@rustcorp.com.au> References: <87h918ghdv.fsf@rustcorp.com.au> Message-ID: Hi Rusty, I was thinking of proposing something similar recently, but looks like you beat me to it! I really like the flexibility of the tag format. Over the past few months, I thought of quite a bit of things application developers can do by utilizing a tag-based payment request format in conjunction with either: the spare bytes of the onion payload or an abuse of the encrypted back errors (in combo with some onion payload bytes). On the topic of bech32: I'm all for piggybacking on existing emerging standards in the space, but I'm not convinced we really gain anything by using it outside of the initial prefix. The human-readable amount within the prefix is nice for UX as you can eyeball exactly how much one is about to pay/receive. However, these payment requests can get rather long, so I don't envision any user typing them out by hand or reading them to someone over the phone. As a result, I don't think we have much use for bech32 character which has been optimized for manual-entry. Additionally, as this proposal includes a signature that covers the entire payreq, what's the use of the added checksum? Detecting 3 characters out of 1024+ is rather insignificant. On the topic of signatures: as is proposed now, a user isn't able to verify the validity of the signature (and thereby authenticity of the payreq and integrity of the contents) without first having a (direction || chanID) -> pubKey mapping. In my opinion, the payreqs are already so long that optimizing for size is a bit of a waste. By replacing the chanID with the compressed serialized public key, users will be able to immediately verify the signature without the use of an external mapping. I think this is a good step in the right direction. However, it utilizes an encoding whose rationale make sense for the Bitcoin address use-case, but in my opinion, doesn't carry over those compelling traits to the LN payreq use-case. -- Laolu On Fri, Apr 28, 2017 at 5:57 PM Rusty Russell wrote: > Hi all! > > I threw together this draft format for requesting lightning > payments, and an (incomplete) implementation: > > - https://github.com/rustyrussell/lightning-payencode > > The representation size ranges from ~181 characters upwards: we could > squeeze at least 5 of those out if we cared. Bech32 only guarantees to > detect 3 errors at these lengths (beyond 1024 it's only 1), but the > signature is the final error detection. > > You'll notice one optimization for the common case: we use the 8-byte > chanid (stealing 1 bit) to compactly refer to the destination. This is > shorter than a full 33-byte pubkey, and relies on the fact that the > network topology is well-known. We use these same style of IDs in > the channel announcement messages already. > > I look forward to both the bikeshed comments, and more substantive > feedback :) > > Thanks! > Rusty. > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: