This is a response to Evan's question on Slack:
[what is the] main argument against removing connector-implemented quoting protocols
Interesting question! I still think the three main design principles of Interledger are:
- we only care about payments
- the complexity is in the connectors
- users trust their own ledger; connectors are trustless
Alice wants Bob's balance on ledger B to go up by a certain amount. She trusts Bob to report whether this has happened or not. She is willing to pay a translated amount from her balance on ledger A, but if that source amount is too high she may decide not to go through with the payment. She is willing to put her balance on ledger A on hold for a limited time, while the payment propagates, but if she doesn't hear from Bob in time, this money should automatically move back into her account.
Performance criteria of the Interledger would be something like:
- how many relevant ledgers are connected to it
- how often a payment is not possible at all
- how low the transaction fees are (i.e. how little of it disappears when money is moved from A to B and back to A)
- how long a payment takes to succeed (average)
- how often an attempted payment fails, excluding when that happens because of the receiver's failure
- how long a payment takes to fail (average)
- how long the source transfer timeout needs to be (max)
- how little exchange rates differ from actual difference in units of value (this may be hard to measure for small currencies, but e.g. if unidirectional network congestion makes the effective USD vs EUR rate go up during the daytime and down again during the night, or up in summer and down in winter, that's annoying)
Suppose Alice wants 1 USD to arrive at Bob, and wants to pay as little as possible, but 1.20 EUR maximum.
One way to design Interledger, without quoting, would be to fix exchange rates externally, and forcing a connector to either accept a payment at that rate, or reject it. Alice would just look up the EUR-USD exchange rate, and adds some well-known transaction fee, say 0.80 EUR and 0.1%, so then she would pay 0.8008 EUR and that will either succeed or fail. That would not be the most flexible way to allow as many payments as possible to succeed. If connectors can vary their prices based on circumstances, that allows for higher performance on other measures.
A second way would be, still without quoting, using incremental attempts: Alice tells Bob to only accept her payment if 1 USD arrives. She then tries sending 0.70 EUR. If that fails she tries with 0.71 EUR. Then 0.72 EUR, etc. If she reaches 1.20 EUR and Bob has still not accepted her payment, then she stops.
A third way would be to split the payment up in chunks (first send 0.70 EUR, then repeatedly send 0.01 EUR), but that has the downside that you cannot get back your money if you reach your source amount limit and still haven't reached the required cumulative destination amount. This doesn't sound smart.
A fourth way would be to just send 1.20 EUR and ask Bob to send back whatever arrived. But then she needs to trust Bob to do that.
A fifth way (the way we've chosen in Current Interledger) is to first do a QuoteByDestination, to get a good current market rate, then allow Alice to check whether that source amount is within her source amount limit, and if it is, pay whatever source amount the quote says.
A sixth way would be a variation on the second way, but using additional cooperation between Alice and Bob, so that Bob gives feedback to Alice about how much arrived. She can then, if from the first 0.70 EUR payment only 0.90 USD arrived, immediately try 0.77 EUR instead of being so careful taking one-cent steps. This would work well if exchange rates are linear in the payment amount, and transaction fees are zero. A little bit smarter would be to try the first and second payment and fit a first-degree polynomial, so that both exchange rate and transaction fee would be modeled.
A seventh way would combine the sixth and fourth way: she trusts Bob both to give feedback and to reject if he received too much. she tells him "accept the payment if the destination amount is higher than 1.00 USD, but lower than 1.01 USD", and then does binary search to reach the right source amount in a minimal number of steps.
The first and fifth way actually have an additional psychological advantage: Alice only has to take one boolean decision, whether 0.8008 EUR is within her source amount limit. In the other ways, she needs to take multiple decisions "is 1.00 EUR still ok? Is 1.05 EUR still ok? etc...", and that's extra mental work for Alice.
You can see this process in the ilp-kit UI: 1) pick a recipient, 2) pick a (destination) amount, 3) see what corresponding source amount appears and check that it's within your limit (only one boolean decision!), 4) click Pay.
The sixth and seventh way break the second design principle, because they require extra complexity in the receiver. The third and seventh way break the third design principle, because they require the sender to trust the receiver more.
It therefore seems to me that the way Current Interledger does it (query exchange rate; decide; pay) is better than the other options.
I really think that any solution that requires Alice to trust Bob to truthfully report something in which he has a vested interest should be considered a "non-starter". That violates one of the fundamental design goals of the inter ledger protocol.
The receiver is in effect just another connector. Bob's role is to convert money received from Alice into the goods she wants. This process is analogous to any other interledger connector. This makes Bob just another connector hop in a circular payment that starts and ends with Alice.
If we treat both Alice and Bob as connectors who aren't expected to trust each other, that rules out solutions 2, 3, 4, 6, 7
If we presume that Bob can be malicious, that it is easy to list possible ways he might try to defraud Alice in these proposals. For example:
2) reject a payment for the correct amount, hoping to receive a follow up payment for more.
3) tell Alice he received less than he really did
4) claim there was no extra to send back
6) tell Alice that he received less than he really did
7) accept a payment for too much
If we presume that Alice already trusts Bob then we are really just ducking the original problem.
If Alice "trusts" Bob, then he becomes an trusted ILP Ledger that she can open an account with. This changes the problem from one of payment, to one of account funding. Specifically, Alice's first goal is to fund her account with the correct amount of money needed. Once Bob is holding the right amount for Alice, then she can authorize Bob to debit her account to cover the business transaction they want to make.
Theoretically, Bob doesn't have a vested interest in Alice's pre-funding phase. So we can declare that we see no reason that Bob wouldn't report the outcome of 2, 3, 4, 6 or 7 back to Alice correctly. Therefore, she can use any of the above mechanisms to her ledger account with Bob. Once she does so, then Alice and Bob can execute the final debit phase assured that Bob will receive only the money than he should since only the correct amount is available to be debited.
In reality, Bob's incentives are exactly same in both cases. Presuming he won't ever cheat seems an ill conceived design decision.
I agree with Michiel that quoting seems better than the other options.