RE: Optimistic over Universal

I don’t have an average in hand, but I know my ISP considers up to 3% constant packet loss as normal and will not consider it a breach of contract or something to be fixed (and that already dramatically affects any Internet navigation). I have experienced 50-60% packet loss when my old provider struggled in peak times, and it is complete hell when you try to do anything.

In the Internet packet loss is extremely common, every day you access websites, Skype, play videogames etc you are dropping packets, even with a “perfect” connection this will happen. If you use Wi-Fi this would happen more often. Hell, even in direct PC-to-PC LAN networks it happens although it is far more rare. This is why I believe the idea of retrying failed payments (which I’ve seen described around the Interledger specs, and would replicate how many Internet services resend failed packets) should be kept for Optimistic mode (not sure if it is already?), otherwise I don’t think it would be worth it.

Optimistic mode’s main advantage in my mind, from what you guys have said, is avoiding the setup phase (at least for the receiver). If that can be done avoiding this hurdle it would be great, otherwise… Like you just said, not worth it even for streaming or micropayments in general.



From: Evan Schwartz [mailto:evan@ripple.com]
Sent: 29 June 2017 14:53
To: Interledger Community Group <public-interledger@w3.org>
Cc: Timothy Benest <thb@enteracc.ch>; Roberto Catini <roberto.catini@gmail.com>
Subject: Re: Optimistic over Universal

Does anyone know what the average packet loss is going over the Internet? If more than a couple percent of the packets are dropped, it would make me think less of the idea of using Optimistic mode even for streaming. Even if all of the connectors were honest, I don't think there's much of a reason to expect their reliability to be higher than IP routers. If the average loss is anywhere above 1% it would represent a pretty large fee for using Optimistic mode, that may make it not worth it.


@Roberto: Interledger only uses SHA256 hashlocks, not the full suite of crypto conditions (see the discussion here<https://github.com/interledger/rfcs/issues/153>). Right now the implementation doesn't allow you to send a transfer without a condition so payments cannot already be executed.

The idea with this proposal is that the sender and/or connectors would be able to produce a valid fulfillment for the well-known hash. Any intermediaries or receivers that recognize this as Optimistic mode would treat it as such and all others would just see it as a normal Universal mode payment (because the recipient would produce a perfectly valid preimage, it would just happen to be one that isn't specific to the payment).

@Timothy: Ledgers do double-entry bookkeeping. Interledger is used to synchronize transfers (sets of debits and credits) across multiple ledgers. I'm not sure I understand what you see as the problem.


On Thu, Jun 29, 2017 at 2:55 PM Stefan Thomas <stefan@ripple.com<mailto:stefan@ripple.com>> wrote:
> Sending cash and hoping it gets there?
>
> Please find some people who know what they're doing.  IT people don't understand law or money.

The irony here, of course, is that this is exactly how bank wires work.

(Each bank sends payment instructions via SWIFT to their correspondent. Transfers are fully executed at each hop and, if something fails, have to be reversed/reconciled. The idea is that SWIFT guarantees delivery of the messages and banks are reliable and will eventually execute the requested action. However, in practice, this system sucks because "sending cash and hoping it gets there" -- as you suspect -- isn't a great idea. Corporates typically see failure rates around 10%, usually due to incorrect recipient details.)

At least we are talking about using optimistic mode for micropayments, not $10 000 payments. With micropayments, if the failure rate turns out to be 10%, you can stop sending after a few.

On Thu, Jun 29, 2017 at 4:26 AM Andrew Bransford Brown <andrewbb@gmail.com<mailto:andrewbb@gmail.com>> wrote:
Sending cash and hoping it gets there?

Please find some people who know what they're doing.  IT people don't understand law or money.

On Wed, Jun 28, 2017 at 10:48 AM, Evan Schwartz <evan@ripple.com<mailto:evan@ripple.com>> wrote:
TL;DR: We can implement Optimistic Mode on top of normal Interledger by using a well-known hash (and preimage) to indicate it's Optimistic.

What is Optimistic Mode?
Sending Interledger payments without a condition and timeout. You need to trust the connectors all the way through but that may be acceptable for payments with very low amounts or if connectors turn out to be honest and reliable in practice. The advantage is simplicity, the fact that you don't need any setup step at all, and it removes the backwards trip for the fulfillment.

Earlier we thought that Optimistic, Universal, and Atomic would be the Interledger Transport Layer (that's why there are the placeholder RFCs 5-7 for them). However, we realized they were not really end-to-end and required substantially different features from all of the intermediary nodes. So we took out support for optimistic mode and said the core Interledger protocol just uses Universal mode.

Optimistic for Streaming Payments
Last week Michiel reminded me of the idea that Optimistic mode may be preferable for streaming payments. (Paraphrasing his comments:) They are simpler, you're keeping the amounts low anyway, and the receiver can communicate out of band whether they've received the money. Using Optimistic payments would also make ILP resemble IP's best effort delivery of packets a lot more.

Implementing Optimistic Mode Using a Well-Known Hash
The Interledger.js implementation now requires all transfers to have execution conditions and so it no longer supports Optimistic mode in the way we were doing it before. However, we can implement Optimistic as more of a proper Transport Layer protocol (that may or may not have support from the underlying network).

When sending Optimistic payments you would set the condition to a well-known hash defined in the spec. Ledger plugins that support this protocol would recognize that hash and immediately execute those transfers (maybe skipping the prepare step). For plugins that don't support the protocol, connectors could immediately execute the incoming transfer. Connectors wouldn't need to do anything when they get the notification that the outgoing transfer has been executed. On the receiving side, you might want to configure the plugin to enable optimistic mode, if it supports it, and if the plugin doesn't provide support than the client can auto-fulfill all of the incoming transfers.

By implementing Optimistic in this way, we can make it an end-to-end protocol that may optionally have support from the underlying network but works fine without it as well.


PS I had the idea earlier that if you want to implement messaging on top of ledger transfers you could use a well-known condition that nobody can fulfill like the string "messagemessagemessagemessagemessagemessagem=". There may be other types of protocols that could be implemented using the idea of well-known conditions.
--
Evan Schwartz
Software Engineer
Managing Director of Ripple Luxembourg
[https://ripple.com/wp-content/themes/ripple-beta/assets/img/logo/ripple-logo-color@2x.png]

--
Evan Schwartz
Software Engineer
Managing Director of Ripple Luxembourg
[https://ripple.com/wp-content/themes/ripple-beta/assets/img/logo/ripple-logo-color@2x.png]

________________________________

AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.

CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.

________________________________

CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.