Re: Optimistic over Universal

@Timothy Something I'm working on 👍
<https://emojipedia.org/thumbs-up-sign/>

Best

Mr Elusio Alcalde - Founder


*TAXMAP INC*

UK: +44 (0) 77 4895 4656 <%2B44%20%280%29%2020%203700%200646>
US: +1 323 863 6556 <(305)%20927-7283>
URL: http://www.taxmap.it

*------------------------------------------*

*Company information*

TAXMAP is a Corporation registered in the State of Delaware.

*Confidentiality notice*

This message is intended solely for the addressee and may contain
confidential information. If you have received this message in error,
please send it back to us, and immediately and permanently delete it. Do
not use, copy or disclose the information contained in this message or in
any attachment.

*Privacy policy and terms of use*

For information about how we process data and monitor communications please
see our Privacy policy and for terms of use please see our Terms of use
policy.

On Thu, Jun 29, 2017 at 1:07 PM, Timothy Benest <thb@enteracc.ch> wrote:

> I need to spend some time looking in detail at how InterLedger implements
> things, but my first impressions are that it does not use a Double Entry
> model.
>
> Maybe everyone involved should take a basic bookkeeping course. Learn
> Debit vs Credit. Learn that every Nostro (My Account with you) needs a
> Vostro (Your Account with US).
>
> This is very important stuff in making sure the "Books Balance". Some big
> company failures have been down to the fact that basic bookkeeping was
> ignored in favour of someone trying to re-invent the wheel of double entry.
>
> Enough for now, I need to go back to FATCA and CRS reporting.
>
>
>
> Regards
> Tim Benest
> General Manager
>
> *EnterAcc S.A.*
>
> eMail    : thb@enteracc.ch
> Tel      : +41 22 550 8965 <+41%2022%20550%2089%2065> (Switzerland)
>          : +1 869 469 0955 <(869)%20469-0955> (Nevis)
> Telegram : @tbenest
> Skype    : tbenest
>
> EnterAcc S.A.
> C.P. 1436
> Rue de Berne 11
> 1211 Genève 1
> Suisse
>
> On 29 June 2017 at 13:25, Andrew Bransford Brown <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> 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
>>>
>>
>>
>