From laolu32 at gmail.com Sun May 28 18:42:32 2017 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Sun, 28 May 2017 18:42:32 +0000 Subject: [Lightning-dev] [RFC] Lightning payment format In-Reply-To: <87vap9zdet.fsf@rustcorp.com.au> References: <87h918ghdv.fsf@rustcorp.com.au> <87h90yeieo.fsf@rustcorp.com.au> <20170508112529.GA28181@nex> <87y3u624kn.fsf@rustcorp.com.au> <20170509082241.GA21968@nex> <87vap9zdet.fsf@rustcorp.com.au> Message-ID: Rusty wrote: > Yes, I thought about this too, but I'm reluctant to assign those onion > bytes as they're a limited resource. Easy to add later, though. If y'all recall, the initial version of the Sphinx derived onion format included an end-to-end payload. In the first revision, removed this payload as at the time it was very large (1KB iirc), an at the time, we didn't see nay clear use case for such a payload (and also due to MTU constraints?). In my opinion, we should re-introduce this payload so we aren't put into a corner where we need to shave bytes off of the per-hop payload in order to accommodate application level schemes/apps. Re-introducing the e2e payload would allow us to define a strict separation of layers: h2h payload is reserved for _forwarding_ critical information, while the e2e payload is reserved for _applications_ to place relevant data which is also onion encrypted + authenticated. IMO, the e2e payload doesn't need to be any where as large at it was previously (which doubled the size of the onion packet). I'd proposed re-introducing it with a size of somewhere around 200 bytes. With this, I could send you something to tweet once the payment has been extended :p. Fabrice wrote: > Payment requests should also include a timestamp and an expiry date (they > could be optional tagged items but I think it makes more sense to make > them mandatory) Agreed that that would make for a really useful tag. I had a user which was making a store on lnd request such a feature as his use-case depended on users only having a particular time window to make the payment. This could of course be enforced server side, but allow senders to enforce it at the origin of the payment saves them from extending an HTLC all together. Also in the world of pre-paying for HTLC's, you'd only want to extend an HTLC is you had a high degree of certainty that it'll be claimed, otherwise you've just wasted your precious mSAT :(. Rusty wrote: > Note: we will lose this ability when we switch to Schnorr, apparently. AFAIK, this isn't the case. With Schnorr signatures (that include the entire point, instead of the hash), we actually won't need to include a recovery ID at all. Rusty wrote: > OK, if people like this change, I think we can move start turning this > into BOLT 10? Let's do it (BOLT 11)! As were all getting pretty close to the stage of cross-implementation interoperability tests, having a shared payment request format will be super useful. Christian wrote: > Perfect, even though your price is already outdated, and it currently > is $1700/BTC Perfect, even through your price is already outdated, and it currently is $2200/BTC :p. -- Laolu On Tue, May 9, 2017 at 10:18 PM Rusty Russell wrote: > Christian Decker writes: > > On Tue, May 09, 2017 at 11:07:28AM +0930, Rusty Russell wrote: > >> Hey, invoices are totally human readable, for some humans :) > >> > > I know Pieter can decode bech32 on the fly :-) > > Well, Pieter can pronounce them too apparently: > > http://pieterwuillefacts.com/?43 > > >> But a good point. So let's use BTC with m (milli), u (micro), n (nano) > >> and p (pico). In theory we could allow . in that part, but I think it's > >> too distracting. > >> > >> At $1600/BTC: > >> > >> 0.01c = 62500p > >> 1c = 6250n > >> $1 = 625u > >> $1000 = 625m > > > > Perfect, even though your price is already outdated, and it currently > > is $1700/BTC. I mention the conversion confusion because I often run > > into that problem myself (and keep typing 0s until the client > > complains). > > I considered using the m/u/n modifier as the decimal point, eg: > > 0.0001c = 0n62 > 0.01c = 62n5 > 1c = 6u25 > $1 = 625u > $1000 = 625m > > Unfortunately, it's horrible to write the code to encode/decode (I just > spend an hour on it and I'm not happy with the result). > > >> OK, if people like this change, I think we can move start turning this > >> into BOLT 10? > > > > Oops, I think I did what Luke hates, and sort of self assigned a > > proposal number... I can of course assign the DNS bootstrap BOLT > > another number. > > Huh? I just did exactly the same thing! So I'll take BOLT 11. > > Cheers, > 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: