Optimistic over Universal

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
<http:> <http:>