Use Java Money ExchangeRate instead of LiquidityCurve

[sappenin]

What does everyone think About translating from a liquidity point collection to a java money exchange rate? I've found that using Java Monetary types is actually quite nice, especially for performing arithmetic on money values.

Currently java-ILP-core defines a special type called a liquidity curve with points and interpolation, but the impl doesn't do any linear interpolation for us, so I think we should add this in, or else just defer to the ExchangeRate class to do it for us. I lean toward the latter.

[adrianhopebailie]

I agree. Would be useful to be able to convert from one to the other.

[michielbdejong]

Take into account that route broadcasts will come in with piece-wise-linear liquidity curves, so it's useful (though not strictly mandatory) that your implementation understands those.

The other way around is easier; say:

• a connector knows an exchange rate, e.g. 2 units on the source ledger equal 1 unit on the destination ledger,
• the connector has a balance of 1,000,000 on the destination ledger
• the connector is willing to use half that balance for a single transfer
• the connector wants to charge a flatrate fee of 10 (its relative fee is calculated into the exchange rate) then it can broadcast that route with a piece-wise-linear function of: [ [10, 0], [1000010, 500000] ]

[andrew-g-za]

The interpolation and other useful functions was next on my todo list :)

My only reservation for using java monetary types is that (from the small part I've seen) it seems to be tightly bound to currencies - something that ILP isn't (at least, that's my take) - for example, if you receive a liquidity quote response, there is no unit-of-value information in the quote itself - we must rely on meta-information about the ledger to know. Wouldn't this make the use of monetary amounts awkward?

I also wonder how the Monetary api copes with non-traditional currencies like bitcoin etc - something that an ILP ledger is likely to encounter?

[sappenin]

@andrew-g-za These are excellent points!

I was actually thinking that the Java Money code would operate at a slightly different layer than the ILP code -- I guess one way to think about it would be like "utility" or "helper" classes that we package with java-ilp-core.

So, in the ILP packets we would continue to use data-types that don't involve money (like BigInteger, long, or BigDecimal), and consumers of this library could ignore Java Money entirely if they so wished, because Java Money isn't strictly required to use ILP packets and such.

However, for others who might want a bit more sophistication, we have some code that can translate into Java Money when it becomes useful. For me, this is somewhat limited to just the quoting area where there is a thing called a Liquidity Curve. At the least, we need some utilty code that will help us get information in an out of that thing (like, if the curve has only 2 points, what are the values in the middle).

Operating on a Liquidity Curve is an interesting abstraction, but the real use-case for that thing is an Exchange Rate, where you need to determine the rate of exchange between two assets (might be money, might be gold, etc). Java Money supports a wide range of currency codes (you can even supply your own if it doesn't support it, like BTC or XRP), and you can represent non-currency assets as well using a code.

Anyway, maybe the JavaMoney stuff would be more appropriate in a separate library so that we don't introduce a JavaMoney dependency into java-ilp-core if we don't actually need to.

[adrianhopebailie]

I'm 100% behind this!

ILP treats money as 64 bit unsigned integers. Let's keep it that way in this library.

I think we should consider pulling the ledger adaptor stuff out of this as it's not "core" to the protocol. It's actually just an example of a ledger adaptor interface.

[andrew-g-za]

Agreed on all points :)

[sappenin]

Agreed. Closing this issue.