📅 Original date posted:2017-05-08
📝 Original message:
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 <laolu32 at gmail.com> 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.
>
> <Feedback please!
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:47:11
in reply to nevent1q…84dx
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:47:11Event JSON
{
"id": "81034830f0c4a686d7f8ff642baa1982274a14069e66bd0c03fe1d6d1201a8ff",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686314831,
"kind": 1,
"tags": [
[
"e",
"56742c88f6265e0090cd0ac17729d1bb4693d9767822b89dc939db0c32d43bbb",
"",
"root"
],
[
"e",
"809ec7f65da6f4eaf2291f56cb74f885609fd627ea6dddcdf52e9b82480623eb",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2017-05-08\n📝 Original message:\nI mentioned some things off-list before but let me add them here for completeness.\n\nMy biggest concern was the use of `short_channel_id` as an alias for\nthe endpoint, it just felt wrong having to perform that lookup to get\na space saving. This is all the more strange since the remainder of\nthe spec is very generous with space, allowing arbitrary (up to 1024\nbyte) string descriptions and similar. So good job at removing it,\neven if it was only as a fallback or hint.\n\nI also don't like the amount shorthands (k/m/g/...), that's purely a\nUI/UX concern and since these invoices are not user-readable I don't\nsee the point. Even if they were user-readable, we'd be forcing people\nto do the conversion BTC -\u003e SAT on their own, since we would not\nsupport amount in bitcoin units (BTC, mBTC, ...). I'd say either get\nrid of the shorthands or add the BTC shorthands as well.\n\nOther than that, I really like the proposal, it's clean and\nextensible, and it supports testnet ;-) I also like using bech32 as a\nserialization format, if people also support the DNS bootstrapping and\nnode lookup they can simply reuse that dependency, and it is a bit\nshorter than hex. We might consider also supporting a different, human\nreadable, encoding though (without changing the signature\nserialization). And finally we could directly derive a URI scheme from\nthe bech32 encoded string by replacing the '1' with a ':', but we can\nspin that discussion off in another thread ^^\n\nCheers,\nChristian\n\nOn Sat, May 06, 2017 at 01:38:47PM +0930, Rusty Russell wrote:\n\u003e Olaoluwa Osuntokun \u003claolu32 at gmail.com\u003e writes:\n\u003e \u003e However, it utilizes an\n\u003e \u003e encoding whose rationale make sense for the Bitcoin address use-case, but in\n\u003e \u003e my opinion, doesn't carry over those compelling traits to the LN payreq\n\u003e \u003e use-case.\n\u003e \n\u003e I agree, but it's nice for QR codes too, and denser than hex. And now\n\u003e we're using your key recovery idea, having a checksum is not\n\u003e *completely* pointless.\n\u003e \n\u003e I've implemented and pushed fallback addresses in the example\n\u003e encoder/decoder, and tweaked the format slightly: the first 5-bit value\n\u003e is the witness version, or 17 for p2pkh, 18 for p2sh. It's now\n\u003e complete.\n\u003e \n\u003e In some places the encoding is a little awkward (trying to get on 5 bit\n\u003e boundaries), ideas welcome.\n\u003e \n\u003e \u003cFeedback please!\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",
"sig": "bc2515347824ba71cbcce3fb1d8ed18d437b21d6e4b54e6d5f03bbe49ba4c5a30af8580afa3710143889f4172e352cc662f05e0df0d84b43bc4e5c6ca45ad991"
}