📅 Original date posted:2017-05-08
📝 Original message:
Christian Decker <decker.christian at gmail.com> writes:
> 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.
Hey, invoices are totally human readable, for some humans :)
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
> 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 ^^
OK, if people like this change, I think we can move start turning this
into BOLT 10?
Thanks!
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:47:11
in reply to nevent1q…j535
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:47:11Event JSON
{
"id": "4a87422b417969c7c1f5898a2865b128a6d7a109d3c6774202f09deb7012ec5a",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314831,
"kind": 1,
"tags": [
[
"e",
"56742c88f6265e0090cd0ac17729d1bb4693d9767822b89dc939db0c32d43bbb",
"",
"root"
],
[
"e",
"81034830f0c4a686d7f8ff642baa1982274a14069e66bd0c03fe1d6d1201a8ff",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2017-05-08\n📝 Original message:\nChristian Decker \u003cdecker.christian at gmail.com\u003e writes:\n\u003e I also don't like the amount shorthands (k/m/g/...), that's purely a\n\u003e UI/UX concern and since these invoices are not user-readable I don't\n\u003e see the point. Even if they were user-readable, we'd be forcing people\n\u003e to do the conversion BTC -\u003e SAT on their own, since we would not\n\u003e support amount in bitcoin units (BTC, mBTC, ...). I'd say either get\n\u003e rid of the shorthands or add the BTC shorthands as well.\n\nHey, invoices are totally human readable, for some humans :)\n\nBut a good point. So let's use BTC with m (milli), u (micro), n (nano)\nand p (pico). In theory we could allow . in that part, but I think it's\ntoo distracting.\n\nAt $1600/BTC:\n\n 0.01c = 62500p\n 1c = 6250n\n $1 = 625u\n $1000 = 625m\n\n\u003e Other than that, I really like the proposal, it's clean and\n\u003e extensible, and it supports testnet ;-) I also like using bech32 as a\n\u003e serialization format, if people also support the DNS bootstrapping and\n\u003e node lookup they can simply reuse that dependency, and it is a bit\n\u003e shorter than hex. We might consider also supporting a different, human\n\u003e readable, encoding though (without changing the signature\n\u003e serialization). And finally we could directly derive a URI scheme from\n\u003e the bech32 encoded string by replacing the '1' with a ':', but we can\n\u003e spin that discussion off in another thread ^^\n\nOK, if people like this change, I think we can move start turning this\ninto BOLT 10?\n\nThanks!\nRusty.",
"sig": "34b08f2be5071fba5431de7450f6037d9515561bdc467b78c0d3655610d8b685183f32c1817d173ac2422c32e4550a28e64dbccf2823c63ee1b988bf26ad32ed"
}