public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	"lightning-dev@lists.linuxfoundation.org"
	<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] [RFC] Lightning invoice/payment format draft
Date: Wed, 31 May 2017 23:42:21 -0400	[thread overview]
Message-ID: <LgBEZTIwZietTZKmz1eNigHGsoFPyrPFmGjxfpYuYqktbwXo6doj_Wfbsb9OGQ5VY1s-eTcBtJQ-qRUxTyRvZD3SPA2LkXbsVsZQ0xUiork=@protonmail.com> (raw)
In-Reply-To: <874lw0h4y3.fsf@rustcorp.com.au>

[-- 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 --]

  reply	other threads:[~2017-06-01  3:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-01  1:28 [bitcoin-dev] [RFC] Lightning invoice/payment format draft Rusty Russell
2017-06-01  3:42 ` ZmnSCPxj [this message]
2017-06-01  3:48   ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2017-06-01  5:54 ` [bitcoin-dev] " Andreas Schildbach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='LgBEZTIwZietTZKmz1eNigHGsoFPyrPFmGjxfpYuYqktbwXo6doj_Wfbsb9OGQ5VY1s-eTcBtJQ-qRUxTyRvZD3SPA2LkXbsVsZQ0xUiork=@protonmail.com' \
    --to=zmnscpxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lightning-dev@lists.linuxfoundation.org \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox