Re: AGENDA - Community Call - 22 February - 3pm UTC

@David: That's great, because that's exactly what we ended up on as well.
We actually had favored a decimal floating point for most of Interledger's
history, but only recently really dove deeply into the subject.

The current proposal for the amount field in Interledger packets is:

- Unsigned Integer, 64-bits, Big Endian (network byte order)
- Scale is chosen by each ledger or ledger plugin and provided as part of
the ledger metadata; the default scale for ILP Kit will be nanodollars for
USD. Defaults for other currencies will be chosen accordingly. That means
the largest amount of USD you can send in one transaction on ILP Kit would
be 18 446 744 073.709 551 615 or about $18.45 billion. And the precision
would be nanodollar.
- If someone needs to create a ledger that can send both micropayments with
nanodollar accuracy and payments larger than $18 billion, they can
advertise their ledger with a different ledger prefix per precision. To be
clear, you can even use a different prefix for the same physical account.
You just can't exceed the precision within a single Interledger payment.
You can, however, do a large and a simultaneous small payment with the same
condition. The use case is so extreme and obscure that it seems perfectly
fine to require some extra hoop jumping in this case. ("...Really? You have
to have nanodollar precision for your 100 billion dollar payments?")
- Similarly, if somebody wants to change their ledger's precision, they
could advertise a new prefix for a while, then seamlessly make the switch
and after waiting some more, turn off the old prefix. In other words,
ledgers can change their Interledger precision setting without any
disruption to their users.
- Integers are pretty easy to parse, so this choice simplifies
implementations a good deal. Connectors merely have to watch out when
calculating liquidity curves (the data format we use to describe exchange
rates) to avoid overflows. The structural constraints on liquidity curves
(monotonically increasing) would make it very likely that even in a buggy
connector implementation, an overflow condition would be caught because it
would - with very high likelihood - generate invalid curves.
- Because liquidity curves also use UInt64, overflowing amounts cannot be
expressed at all, so they will be incredibly safe to use once generated.

If you have questions, try to make it onto the call, because we'll be
spending some time chatting about this stuff!

On Tue, Feb 21, 2017 at 6:35 PM David Nicol <davidnicol@gmail.com> wrote:

>
> In my opinion:
>
>    1. you want integers not floating point.
>    2. And that integer should be 10,000 x the smallest unit the currency
>    supports. So USD transactions should be, at packet level, denominated as
>    millionths of dollars, and BTC transactions should be, at packet level,
>    denominated as ten-thousandths of satoshis.
>    3. As this is a "binary only" wire format, the amounts should be 64
>    bit integers in "network byte order" a/k/a big-endian a/k/a most
>    significant byte first. I don't know if negative amounts are supported or
>    not, if they are a decision needs to be recorded about format for negative
>    numbers. I think they shouldn't be allowed at all but don't know if that's
>    how it is.
>    4. The above gives a maximum packet value of around sixteen trillion
>    dollars, enough to express repayment of the US National debt with one
>    packet (okay, no more coffee for me for a while)
>
>
>
> On Tue, Feb 21, 2017 at 8:55 AM, Adrian Hope-Bailie <adrian@hopebailie.com
> > wrote:
>
>
> *AGENDA*
>
> 3. ILP Packet format (binary only)
>
> 4. Amounts in ILP Packet. Do we use Base2 (Floating Point) or Base10
> (Decimal)
>
>