Re: Are next claims true about ILP?

I really dislike how we keep saying that ILP "requires" X or Y with regard
to the HTLA or talk about protocol requirements in terms of implementation
details.

For example, I disagree with with 1. ILP does not have any requirements
with regards to implementation details like where the HTLA status is kept.
If we say ILP requires it be kept in the ledger or connector plugin that is
incorrect because those are implementation details. ILP only requires that
the condition and fulfillment are passed along.

I agree with 2 because that is a functional requirement not an
implementation requirement.

I think Enrique is correct regarding 3.2. The protocol has no requirement
that connectors use the conditions and fulfillments. An ILP payment will
still work if one of the host-to-host transfers in the middle ignores the
condition and fulfillment with respect to the validity of the transfer and
simply passes them on to the next host.


On 25 August 2017 at 06:50, Evan Schwartz <evan@ripple.com> wrote:

> 1-3.1 are correct.
>
> 3.2 Connectors use conditions and fulfillments even in trustlines. They
> only update their balance with their peer when they agree that the (valid)
> fulfillment has been submitted before the timeout.
>
> 4 is kind of correct. The current view is that the most important thing to
> standardize are the protocols that will be used across ILP "Autonomous
> Systems", and that's more likely to be universal mode than atomic. Atomic
> is very useful for removing connector risk but since it requires commonly
> trusted parties anyway, it's slightly less important to have widespread
> standards for how you do it. That said, I think there will be standards for
> atomic ILP, so if others are interested in working on that we can
> definitely start some discussion about it.
>
> On Fri, Aug 25, 2017 at 3:39 AM Enrique Arizon Benito <
> enrique.arizon.benito@everis.com> wrote:
>
>> Hi,
>>
>> Trying to keep in sync with this long thread "An attempt to clean up the
>> protocol architecture" and the current state of ILP in general, I just
>> would appreciate if someone can correct me about next claims:
>>
>> 1. During the payment process, ILP requires to keep the current HTLA
>> status in a ledger (using the escrow).
>>
>>   1.1 If the ledger does not support HTLA this status must be kept in the
>> connector plugin.
>>
>> 2. During the payment process, fulfillments and errors must be returned
>> through the same payment path that initiated the payment (same set of
>> connectors/ledger) forcing to keep an status on each connector mapping
>> incomming to outgoing transfers.
>>
>> 3. For  trust-lines, connectors can connect without a "real"
>> intermediate  ledger, but they will still use a plugin that certainly will
>> act as a virtual ledger to keep balances.
>>
>>   3.1 That means a ledger always exists, either real or virtual.
>>
>>   3.2 For trust-lines, connectors are allowed to ignore
>> conditions/fulfillments but must still forward them.
>>
>> 4. There is no support for atomic mode in ILP, but can be build in a
>> non-standard (non-ILP-defined) way on-top of it using for example an
>> external arbiter for all connectors in the payment proccess.
>>
>> Regards,
>>
>> Enrique
>>
>> ________________________________
>>
>> 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.
>>
> --
>
> Evan Schwartz
> Software Engineer
> Managing Director of Ripple Luxembourg
>