Re: Are next claims true about ILP?

What you're describing *is* a Hash Timelocked Agreement. You're talking
about sending a transfer that is conditional upon the hash preimage being
delivered before a timeout and an agreement that the money will be returned
if not. ILP doesn't care how you implement this agreement but it does
assume that it's riding on top of an HTLA (rather than plain transfers).
All senders, receivers, and connectors SHOULD be using HTLAs. If they don't
they're going to have a bad time. That is what I mean by the layer below
ILP including HTLAs.

I still think most of this discussion is coming from confusion caused by
multiple uses of the word "ledger". The "Ledger Layer" in the Interledger
stack = HTLA + request/response messaging. Even if most transfers don't go
through large multi-account ledgers like blockchains or bank ledgers, I
think it still makes sense to think of the layer that handles the transfer
of value and information as the ledger layer.

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

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

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