From decker.christian at gmail.com Mon May 8 11:25:29 2017 From: decker.christian at gmail.com (Christian Decker) Date: Mon, 8 May 2017 13:25:29 +0200 Subject: [Lightning-dev] [RFC] Lightning payment format In-Reply-To: <87h90yeieo.fsf@rustcorp.com.au> References: <87h918ghdv.fsf@rustcorp.com.au> <87h90yeieo.fsf@rustcorp.com.au> Message-ID: <20170508112529.GA28181@nex> I mentioned some things off-list before but let me add them here for completeness. My biggest concern was the use of `short_channel_id` as an alias for the endpoint, it just felt wrong having to perform that lookup to get a space saving. This is all the more strange since the remainder of the spec is very generous with space, allowing arbitrary (up to 1024 byte) string descriptions and similar. So good job at removing it, even if it was only as a fallback or hint. I also don't like the amount shorthands (k/m/g/...), that's purely a UI/UX concern and since these invoices are not user-readable I don't see the point. Even if they were user-readable, we'd be forcing people to do the conversion BTC -> SAT on their own, since we would not support amount in bitcoin units (BTC, mBTC, ...). I'd say either get rid of the shorthands or add the BTC shorthands as well. Other than that, I really like the proposal, it's clean and extensible, and it supports testnet ;-) I also like using bech32 as a serialization format, if people also support the DNS bootstrapping and node lookup they can simply reuse that dependency, and it is a bit shorter than hex. We might consider also supporting a different, human readable, encoding though (without changing the signature serialization). And finally we could directly derive a URI scheme from the bech32 encoded string by replacing the '1' with a ':', but we can spin that discussion off in another thread ^^ Cheers, Christian On Sat, May 06, 2017 at 01:38:47PM +0930, Rusty Russell wrote: > Olaoluwa Osuntokun writes: > > 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. > > I agree, but it's nice for QR codes too, and denser than hex. And now > we're using your key recovery idea, having a checksum is not > *completely* pointless. > > I've implemented and pushed fallback addresses in the example > encoder/decoder, and tweaked the format slightly: the first 5-bit value > is the witness version, or 17 for p2pkh, 18 for p2sh. It's now > complete. > > In some places the encoding is a little awkward (trying to get on 5 bit > boundaries), ideas welcome. > > Rusty. > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev