Re: Are next claims true about ILP?

Sure, keeping the state of an HTLA in some kind of database and validating
conditions isn't *required*, but is there any other sensible way to
implement it? If not then I think we should talk about it using the RFC
"SHOULD" because those are such massive and unnecessary footguns otherwise.

On Mon, Aug 28, 2017 at 5:25 PM Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

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

Evan Schwartz
Software Engineer
Managing Director of Ripple Luxembourg
<http:> <http:>