Re: Are next claims true about ILP?

Millions of entities make transfers between one another today without
conditions and fulfillments. Routing an ILP payment through one of these
existing channels is very likely in future. I agree that it makes a lot of
sense to secure the transfers using conditions and fulfillments but that's
not a requirement of ILP.

The point I'm making is we need to come to agreement on what the
Interledger protocol *requires* from lower layers vs what we have
implemented in our reference implementations to-date and consider good
practice.

Here's a slightly different view of ILP to the one I think most of us have.
After the "enlightenment" I thought we were all on this page but it seems
not :)

The Interledger protocol is not actually about ledgers. It is about
reliably proving that a receiver (identified by an ILP address) was paid
irrespective of how the payment got there.

This is done by agreeing the condition and fulfillment between the sender
and receiver before the payment is sent so that when the sender gets the
fulfillment later they can trust that the receiver was paid. ILP
incentivizes the participants to complete the payment because each node is
paid to deliver the ILP packet to the next node on condition they return
the proof back to the previous node. On the last hop the receiver is paid
for the proof (not passing on the packet).

Having ledgers (payment networks) between nodes which can bind the local
transfers between them to the same condition and fulfillment used in the
end-to-end payment is useful for the incentives that maintain the network.
It allows nodes to establish payment channels using a third-party ledger
(i.e. not controlled by either node) and so they can reduce their trust
boundary to just the ledger and not the other node. It also allows them to
use those conditions and fulfillments internally for reconciliation or
later enforcement of their agreements (although this is limited).

If you look at ILP in this way, the only requirements that it puts on the
lower layers are support for the following functions:
- Send a message (data)
- Send a transfer (value + data)
- Send a reply (linked to original message/transfer)

That's all. There is no requirement around conditions and fulfillments. How
these functions are actually implemented is not a concern of the
Interledger protocol.

It could be that two nodes decide to peer over a system like PayPal (with
no conditional payments support) and so they devise a lower layer protocol
that works like this.

1. Send PayPal payment to peer
2. Send message to peer with id of payment and ILP packet
3. Get response from peer containing fulfillment

OR (for an error)

1. Send PayPal payment to peer
2. Send message to peer with id of payment and ILP packet
3. Receive PayPal payment from peer
4. Get response from peer containing error and id of refund payment

It's not pretty but it would work if the two entities trust each other to
do a refund in the case of an error. Alternatively they could just exchange
messages until the payment is successful:

1. Send message to peer with ILP packet
2. Get response from peer containing fulfillment
3. Send PayPal payment to peer
4. Send message to peer with id of payment and id of original ILP message


On 28 August 2017 at 14:31, Evan Schwartz <evan@ripple.com> wrote:

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