W3C home > Mailing lists > Public > public-interledger@w3.org > June 2017

Re: Optimistic over Universal

From: Andrew Bransford Brown <andrewbb@gmail.com>
Date: Thu, 29 Jun 2017 07:25:03 -0400
Message-ID: <CAPS+YFLam8gGUheSpQbZna4TK+FPSTdkvxyP7D=h1PC-PmBCUQ@mail.gmail.com>
To: Evan Schwartz <evan@ripple.com>
Cc: Interledger Community Group <public-interledger@w3.org>
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> 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
Received on Thursday, 29 June 2017 11:25:35 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 June 2017 11:25:36 UTC