* [bitcoin-dev] [RFC] Lightning invoice/payment format draft
@ 2017-06-01 1:28 Rusty Russell
2017-06-01 3:42 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2017-06-01 5:54 ` [bitcoin-dev] " Andreas Schildbach
0 siblings, 2 replies; 4+ messages in thread
From: Rusty Russell @ 2017-06-01 1:28 UTC (permalink / raw)
To: lightning-dev, Bitcoin Protocol Discussion
Hi all,
There's a pull request for a lightning payment format which I'd
love wider review on. It's bech32 encoded, with optional parts tagged:
https://github.com/lightningnetwork/lightning-rfc/pull/183
There's an implementation with a less formal description here, too:
https://github.com/rustyrussell/lightning-payencode
Example:
Send 2500 microbitcoin using payment hash 00010203040506...0102 to me
@03e7156ae33b0a208d0744199163177e909e80176e55d97a2f221ede0f934dd9ad
within 1 minute from now (Tue 30 May 12:17:36 UTC 2017):
lnbc2500u1qpvj6chqqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdq5xysxxatsyp3k7enxv4jsxqz8slk6hqew9z5kzxyk33ast248j3ykmu3wncvgtgk0ewf5c6qnhen45vr43fmtzsh02j6ns096tcpfga0yfykc79e5uw3gh5ltr96q00zqppy6lfy
Thanks!
Rusty.
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [bitcoin-dev] [Lightning-dev] [RFC] Lightning invoice/payment format draft 2017-06-01 1:28 [bitcoin-dev] [RFC] Lightning invoice/payment format draft Rusty Russell @ 2017-06-01 3:42 ` ZmnSCPxj 2017-06-01 3:48 ` ZmnSCPxj 2017-06-01 5:54 ` [bitcoin-dev] " Andreas Schildbach 1 sibling, 1 reply; 4+ messages in thread From: ZmnSCPxj @ 2017-06-01 3:42 UTC (permalink / raw) To: Rusty Russell; +Cc: Bitcoin Protocol Discussion, lightning-dev [-- Attachment #1: Type: text/plain, Size: 1546 bytes --] Good morning Rusty, The fact that amount is optional, and the separator character between human-readable and data is the character "1", may mean some trouble with parsing of the optional amount. Currently, the version is 0, which translates to the character "q" appearing after "1". So 1q is obviously not an amount and is known to start the data part. However, what happens when we decide to upgrade, and version is now 1, translating to character "p"? If version 1 of invoice is avalialble, does a payment starting with lnbc1p .... indicate a 1 pico-bitcoin payment, or an arbitrary payment to a version-1 data part? Or is amount not allowed to have character "1"? It seems a strange limitation if we impose this... Or do I mistake my understanding of bech32? Alternatively we can just fix the first 5 bits to be 0 (so "1q" is an unambiguous separator between human-readable and data parts) and provide the version by other means, such as changing lnbc to ln2bc or so on... > simply reused here even though its 6-character checksum is optimized > for human errors, which are unlikely given the length of lightning > invoices. At first read, this seems wrong. My understanding is that lightning invoices are longer than segwit addresses in bech32, so human error is more likely. Of course, it seems that the intended meaning is really "lightning invoices are so long that it is unlikely humans will enter it by hand, so human errors are unlikely compared to QR reader errors etc." so perhaps better reworded as such. Regards, ZmnSCPxj [-- Attachment #2: Type: text/html, Size: 1953 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] [RFC] Lightning invoice/payment format draft 2017-06-01 3:42 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj @ 2017-06-01 3:48 ` ZmnSCPxj 0 siblings, 0 replies; 4+ messages in thread From: ZmnSCPxj @ 2017-06-01 3:48 UTC (permalink / raw) To: Rusty Russell; +Cc: Bitcoin Protocol Discussion, lightning-dev [-- Attachment #1: Type: text/plain, Size: 327 bytes --] Good morning, >Or do I mistake my understanding of bech32? Looking again at bech32 spec, yes, my understanding is wrong: the character "1" is not allowed in the data part, so the last "1" digit in the bech32 string is unambiguously the separator between the human-readable and data parts, please ignore me. Regards, ZmnSCPxj [-- Attachment #2: Type: text/html, Size: 410 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] [RFC] Lightning invoice/payment format draft 2017-06-01 1:28 [bitcoin-dev] [RFC] Lightning invoice/payment format draft Rusty Russell 2017-06-01 3:42 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj @ 2017-06-01 5:54 ` Andreas Schildbach 1 sibling, 0 replies; 4+ messages in thread From: Andreas Schildbach @ 2017-06-01 5:54 UTC (permalink / raw) To: bitcoin-dev In order for such messages to be dispatchable between apps, I suggest prepending with an URI scheme, similar to the already existing "bitcoin:" scheme. Also I suggest defining a MIME type, e.g. for usage in NFC NDEF messages or emails. What is the relation of this BIP to BIP21 and BIP70-72? Is there a reason for not extending BIP70? On 06/01/2017 03:28 AM, Rusty Russell via bitcoin-dev wrote: > Hi all, > > There's a pull request for a lightning payment format which I'd > love wider review on. It's bech32 encoded, with optional parts tagged: > > https://github.com/lightningnetwork/lightning-rfc/pull/183 > > There's an implementation with a less formal description here, too: > > https://github.com/rustyrussell/lightning-payencode > > Example: > Send 2500 microbitcoin using payment hash 00010203040506...0102 to me > @03e7156ae33b0a208d0744199163177e909e80176e55d97a2f221ede0f934dd9ad > within 1 minute from now (Tue 30 May 12:17:36 UTC 2017): > > lnbc2500u1qpvj6chqqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdq5xysxxatsyp3k7enxv4jsxqz8slk6hqew9z5kzxyk33ast248j3ykmu3wncvgtgk0ewf5c6qnhen45vr43fmtzsh02j6ns096tcpfga0yfykc79e5uw3gh5ltr96q00zqppy6lfy > > Thanks! > Rusty. > ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-06-01 5:54 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-06-01 1:28 [bitcoin-dev] [RFC] Lightning invoice/payment format draft Rusty Russell 2017-06-01 3:42 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj 2017-06-01 3:48 ` ZmnSCPxj 2017-06-01 5:54 ` [bitcoin-dev] " Andreas Schildbach
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox