From rusty at rustcorp.com.au  Tue May  9 01:37:28 2017
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Tue, 09 May 2017 11:07:28 +0930
Subject: [Lightning-dev] [RFC] Lightning payment format
In-Reply-To: <20170508112529.GA28181@nex>
References: <87h918ghdv.fsf@rustcorp.com.au>
	<CAO3Pvs_FqtAjONw+_amy_wfhY_BDgaRKoNHE_jdfv-F9EVQkzA@mail.gmail.com>
	<87h90yeieo.fsf@rustcorp.com.au> <20170508112529.GA28181@nex>
Message-ID: <87y3u624kn.fsf@rustcorp.com.au>

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.