Are next claims true about ILP?

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.

Received on Friday, 25 August 2017 07:38:27 UTC