📅 Original date posted:2017-05-28
📝 Original message:
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 <rusty at rustcorp.com.au> wrote:
> Christian Decker <decker.christian at gmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170528/7dcd0cac/attachment.html>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-09 12:47:12
in reply to nevent1q…5nrk
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-09 12:47:12Event JSON
{
"id": "cb4eee93ed89dc36f31c681dfe3c945d2b22fcb946d9430ca77369fa3cf08a1e",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686314832,
"kind": 1,
"tags": [
[
"e",
"56742c88f6265e0090cd0ac17729d1bb4693d9767822b89dc939db0c32d43bbb",
"",
"root"
],
[
"e",
"e3a45fd962b23ffcce2b039672de7ae0fad6810101eae8baeefbd7b67454003c",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2017-05-28\n📝 Original message:\nRusty wrote:\n\u003e Yes, I thought about this too, but I'm reluctant to assign those onion\n\u003e bytes as they're a limited resource. Easy to add later, though.\n\nIf y'all recall, the initial version of the Sphinx derived onion format\nincluded an end-to-end payload. In the first revision, removed this\npayload as at the time it was very large (1KB iirc), an at the time, we\ndidn't see nay clear use case for such a payload (and also due to MTU\nconstraints?). In my opinion, we should re-introduce this payload so we\naren't put into a corner where we need to shave bytes off of the per-hop\npayload in order to accommodate application level schemes/apps.\n\nRe-introducing the e2e payload would allow us to define a strict\nseparation of layers: h2h payload is reserved for _forwarding_ critical\ninformation, while the e2e payload is reserved for _applications_ to place\nrelevant data which is also onion encrypted + authenticated. IMO, the e2e\npayload doesn't need to be any where as large at it was previously (which\ndoubled the size of the onion packet). I'd proposed re-introducing it with\na size of somewhere around 200 bytes. With this, I could send you\nsomething to tweet once the payment has been extended :p.\n\nFabrice wrote:\n\u003e Payment requests should also include a timestamp and an expiry date (they\n\u003e could be optional tagged items but I think it makes more sense to make\n\u003e them mandatory)\n\nAgreed that that would make for a really useful tag. I had a user which\nwas making a store on lnd request such a feature as his use-case depended\non users only having a particular time window to make the payment. This\ncould of course be enforced server side, but allow senders to enforce it\nat the origin of the payment saves them from extending an HTLC all\ntogether. Also in the world of pre-paying for HTLC's, you'd only want to\nextend an HTLC is you had a high degree of certainty that it'll be\nclaimed, otherwise you've just wasted your precious mSAT :(.\n\nRusty wrote:\n\u003e Note: we will lose this ability when we switch to Schnorr, apparently.\n\nAFAIK, this isn't the case. With Schnorr signatures (that include the\nentire point, instead of the hash), we actually won't need to include a\nrecovery ID at all.\n\nRusty wrote:\n\u003e OK, if people like this change, I think we can move start turning this\n\u003e into BOLT 10?\n\nLet's do it (BOLT 11)! As were all getting pretty close to the stage of\ncross-implementation interoperability tests, having a shared payment\nrequest format will be super useful.\n\nChristian wrote:\n\u003e Perfect, even though your price is already outdated, and it currently\n\u003e is $1700/BTC\n\nPerfect, even through your price is already outdated, and it currently is\n$2200/BTC :p.\n\n-- Laolu\n\n\nOn Tue, May 9, 2017 at 10:18 PM Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\n\u003e Christian Decker \u003cdecker.christian at gmail.com\u003e writes:\n\u003e \u003e On Tue, May 09, 2017 at 11:07:28AM +0930, Rusty Russell wrote:\n\u003e \u003e\u003e Hey, invoices are totally human readable, for some humans :)\n\u003e \u003e\u003e\n\u003e \u003e I know Pieter can decode bech32 on the fly :-)\n\u003e\n\u003e Well, Pieter can pronounce them too apparently:\n\u003e\n\u003e http://pieterwuillefacts.com/?43\n\u003e\n\u003e \u003e\u003e But a good point. So let's use BTC with m (milli), u (micro), n (nano)\n\u003e \u003e\u003e and p (pico). In theory we could allow . in that part, but I think it's\n\u003e \u003e\u003e too distracting.\n\u003e \u003e\u003e\n\u003e \u003e\u003e At $1600/BTC:\n\u003e \u003e\u003e\n\u003e \u003e\u003e 0.01c = 62500p\n\u003e \u003e\u003e 1c = 6250n\n\u003e \u003e\u003e $1 = 625u\n\u003e \u003e\u003e $1000 = 625m\n\u003e \u003e\n\u003e \u003e Perfect, even though your price is already outdated, and it currently\n\u003e \u003e is $1700/BTC. I mention the conversion confusion because I often run\n\u003e \u003e into that problem myself (and keep typing 0s until the client\n\u003e \u003e complains).\n\u003e\n\u003e I considered using the m/u/n modifier as the decimal point, eg:\n\u003e\n\u003e 0.0001c = 0n62\n\u003e 0.01c = 62n5\n\u003e 1c = 6u25\n\u003e $1 = 625u\n\u003e $1000 = 625m\n\u003e\n\u003e Unfortunately, it's horrible to write the code to encode/decode (I just\n\u003e spend an hour on it and I'm not happy with the result).\n\u003e\n\u003e \u003e\u003e OK, if people like this change, I think we can move start turning this\n\u003e \u003e\u003e into BOLT 10?\n\u003e \u003e\n\u003e \u003e Oops, I think I did what Luke hates, and sort of self assigned a\n\u003e \u003e proposal number... I can of course assign the DNS bootstrap BOLT\n\u003e \u003e another number.\n\u003e\n\u003e Huh? I just did exactly the same thing! So I'll take BOLT 11.\n\u003e\n\u003e Cheers,\n\u003e Rusty.\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170528/7dcd0cac/attachment.html\u003e",
"sig": "46f8d05d96f94d842908255c4b48d27aa4338e766dba868127114db111f6e664f230913c33187707afddbe2f2158a6e19e3deeac2cbebd5296e1f77303e162f7"
}