Re: Are next claims true about ILP?

>  Are you also going to send them a condition and timeout?

The condition needs to get to the peer somehow but that doesn't mean the
peer needs to do anything with it except pass it on. It could just be in an
opaque packet of data.

> What happens if you don't get the fulfillment before the timeout?

That's for the two nodes to decide between them. Obviously the sending node
has a timeout so it needs to consider that but it may agree with the
receiving node that it simply has a cancel function it can call when it
wants to cancel the transfer.

The point I am trying to make is that the relationship between two peers is
up to them including the decisions about any risk they may take on in
having a transfer protocol that doesn't support conditions or expiry. The
Interledger protocol itself places no requirement on these relationships
even though an HTLA is the most likely way to structure them.

> That is an HTLA.

Yes, what you have described is an HTLA but that's not exactly what I had
described.

> Now the question is would you ever do ILP *not* over an HTLA.

Actually, I would phrase it differently. We are designing a technical
protocol. i.e. Rules. So we need to word things in normative language in a
way that ensures the protocol is not compromised. The protocol definition
doesn't care about the business decisions of participants. It defines rules
that create an environment where economic incentives will drive certain
behaviour but it doesn't mandate that behaviour.

You may ask why that is important but I think it is if we are going to
understand how ILP fits into the real world today where conditional
payments and HTLAs are almost non-existent.

So I'd ask the question: Is the end-to-end ILP payment compromised if any
of the transfers are not based upon an HTLA?

The answer to that is, no. Which is good, because it means we have designed
a good internetworking protocol.

> But if you are a connector in an internetworked system where all the
other connectors are using HTLAs, you would lose all of your money so
quickly if you weren't using an HTLA yourself (someone would just send
payments through you and cause the others to roll back and you wouldn't get
your money back).

This is oversimplifying things in my opinion. As I said before, there are
millions of payments being made today without HTLAs. I agree that it's
quite likely two peers using a traditional non-conditional rail for a
transfer will have some side-channel HTLA but if that's the case we
shouldn't design for that in the protocol stack. From the perspective of
the ledger layer protocol all that is happening is messages and transfers
that always occur in pairs of requests and replies.

> This is an interesting point, but I don't think it makes sense to define
ILP that way. Let's think about it coming from the perspective of someone
who wants to use ILP to connect to the rest of the Interledger.

I don't follow this, sorry. How would you connect to the Interledger any
other way. "Connecting to the Interledger", by definition means finding a
peer that is already connected and sending transfers to them with an ILP
packet attached.

> If all connectors in the network will only forward payments for you if
the transfer uses some type of HTLA with a sha256 hashlock condition, then
you have to use that as well.
That's not your concern. All you need to do is agree on the terms with your
peer for forwarding on an ILP packet. The agreement of the condition is
actually with the receiver not your peer. Obviously if you and the receiver
agree on a condition that is not a SHA-256 hash it's unlikely your payment
will get forwarded.

> So we could say that ILP theoretically doesn't require sha256 HTLAs but
practically you need them, but I think that's close to a meaningless
distinction. Not sure this is a good analogy but you could think of this as
similar to IP's requirement that the underlying networks be able to forward at
least 68 bytes without fragmentation
<https://en.wikipedia.org/wiki/Maximum_transmission_unit#cite_note-5>.

Actually I would say ILP does require the end-to-end condition to be a
sha256 hash digest and for the pre-image to be 32 bytes. Those are
requirements of the protocol. But the protocol doesn't require that each
local transfer uses those. However if they don't, then they have no way of
binding their own outcome to the outcome of the end-to-end payment (which
is the goal for most of them).

So, we can think of ILP as defining two things:
1. A new address space which is well suited to routing payments.
(Technically we could have used IPv6 addresses but that overloading would
have been a disaster)
2. A standard for the condition and fulfillment of a payment (a sha-256
hash and a 32 byte pre-image).

All end-to-end payments that use that address space and the standard
condition and fulfillment are likely to succeed because:
1. The nodes on the network will know how to route them (they also
understand the address space)
2. The nodes on the network will be incentivized to forward them (they are
able to use the same condition and fulfillment to protect the local
transfer they will make between them and their upstream peer).

This way of looking at ILP is very useful if you want to break an
end-to-end payment down into federated hops. This is hard to explain
without a diagram but imagine Alice sends $10 to Bob via ILP who receives
EUR12.
You could break this down into two hops:

Alice pays Chloe via some domestic network in USD.
Chloe pays Bob via some domestic network in EUR.

But you could also break down those hops into hops:

Alice transfers USD on her bank ledger to her bank.
Her bank transfers USD on the central clearing house ledger to another bank.
The other bank transfers USD on their ledger to Chloe.

> I very much agree with Enrique that it makes sense to include whatever
information in the spec is useful to help developers implement it
correctly. Since you will need to use at least sha256-based HTLAs in order
to join the Interledger and participate safely, I see no upside and only
downside to pretending that you don't need to use HTLAs to use ILP.

I agree with having some implementation guidance but I don't agree that
HTLAs are a requirement. I think that has emerged as a result of how we
have architected the stack but I think if I can make the case for this then
the discussion about where the condition etc fit into the stack is easier
so let's come to ground on this first.



On 29 August 2017 at 11:34, Evan Schwartz <evan@ripple.com> wrote:

> > 1. Send PayPal payment to peer
> > 2. Send message to peer with id of payment and ILP packet
>
> Are you also going to send them a condition and timeout?
>
> > 3. Get response from peer containing fulfillment
>
> What happens if you don't get the fulfillment before the timeout?
>
> > 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.
>
> All of the statements I've quoted above define a Hash Timelocked
> Agreement. The agreement you've defined is: "I'll send you an unconditional
> transfer and then let you know through another communication channel we've
> agreed upon about the associated ILP packet, condition, and timeout. The
> agreement is that if you give me a valid fulfillment for the condition
> before the timeout, you keep the money. If you don't, you should send me a
> refund. If you don't send me a refund I'll either stop doing business with
> you, take you to court, etc."
>
> That is an HTLA.
>
> Now the question is would you ever do ILP *not* over an HTLA. You can
> certainly send local transfers without a condition. But if you are a
> connector in an internetworked system where all the other connectors are
> using HTLAs, you would lose all of your money so quickly if you weren't
> using an HTLA yourself (someone would just send payments through you and
> cause the others to roll back and you wouldn't get your money back).
>
> > ILP doesn't care if senders, receivers and connectors use HTLAs or not.
> Those entities will choose to use them for their own benefit. Whether they
> do or not has no impact on the end-to-end payment.
>
> This is an interesting point, but I don't think it makes sense to define
> ILP that way. Let's think about it coming from the perspective of someone
> who wants to use ILP to connect to the rest of the Interledger. If all
> connectors in the network will only forward payments for you if the
> transfer uses some type of HTLA with a sha256 hashlock condition, then you
> have to use that as well. Also, if you want to send a transfer that uses an
> HTLA with some other type of condition and connectors won't forward it for
> you, then that doesn't work. So we could say that ILP theoretically doesn't
> require sha256 HTLAs but practically you need them, but I think that's
> close to a meaningless distinction. Not sure this is a good analogy but you
> could think of this as similar to IP's requirement that the underlying
> networks be able to forward at least 68 bytes without fragmentation
> <https://en.wikipedia.org/wiki/Maximum_transmission_unit#cite_note-5>.
>
> > As I think this thread proves, there is still a belief that all
> transfers in an end-to-end ILP payment MUST be secured using the same
> condition and that is not true.
>
> You can add additional conditions, as in the case with atomic mode, but I
> don't think you can avoid securing your transfers with at least the same
> sha256 condition as everyone else.
>
> I very much agree with Enrique that it makes sense to include whatever
> information in the spec is useful to help developers implement it
> correctly. Since you will need to use at least sha256-based HTLAs in order
> to join the Interledger and participate safely, I see no upside and only
> downside to pretending that you don't need to use HTLAs to use ILP.
>
> On Tue, Aug 29, 2017 at 12:14 PM Adrian Hope-Bailie <adrian@hopebailie.com>
> wrote:
>
>> > As I see it, the RFC describing the protocol must be free (actually is
>> encouraged)
>>  to choose any detail implementation that helps in designing proper
>> working
>>  implementations (even if such details are not mandated but just
>> suggested).
>>
>> This is fine but we must get away from the assumption that our
>> implementations are the only way that a ledger layer protocol can work. In
>> my opinion this has impacted the design of the protocol stack negatively.
>> As I think this thread proves, there is still a belief that all transfers
>> in an end-to-end ILP payment MUST be secured using the same condition and
>> that is not true.
>>
>> If we continue to design things on the back of false assumptions then I
>> expect we will have big problems down the line.
>>
>> On 29 August 2017 at 08:44, Adrian Hope-Bailie <adrian@hopebailie.com>
>> wrote:
>>
>>> > What you're describing *is* a Hash Timelocked Agreement.
>>>
>>> Not at all. I'm talking about a transfer that ignores the condition
>>> completely and had no concept of a timeout so how can it be an HTLA?
>>>
>>> > 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.
>>>
>>> Please point out where the HTLA fits into this set of functions:
>>> - Send a message (data)
>>> - Send a transfer (value + data)
>>> - Send a reply (linked to original message/transfer)
>>>
>>> > 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).
>>>
>>> No it doesn't! ILP makes ZERO assumptions about the lower layers with
>>> regard to conditions and fulfillments.
>>>
>>> > All senders, receivers, and connectors SHOULD be using HTLAs. If they
>>> don't they're going to have a bad time.
>>>
>>> You are mixing end-to-end concerns with host-to-host concerns. ILP
>>> doesn't care if senders, receivers and connectors use HTLAs or not. Those
>>> entities will choose to use them for their own benefit. Whether they do or
>>> not has no impact on the end-to-end payment.
>>>
>>> > That is what I mean by the layer below ILP including HTLAs.
>>>
>>> It does include HTLAs but that is not a requirement. You can argue that
>>> it would be foolish for any peers to not use an HTLA and maybe you'd be
>>> right but that still doesn't make it a requirement :)
>>>
>>>
>>> On 29 August 2017 at 06:32, Enrique Arizon Benito <
>>> enrique.arizon.benito@everis.com> wrote:
>>>
>>>>
>>>> Interledger Community Group ‎[public-interledger@w3.org]‎
>>>>
>>>> > 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.
>>>>
>>>> IMHO, this is just about pure-abstractions versus pragmatic-abstractions
>>>>  on how the RFC describing the protocol must be written.
>>>>
>>>> As I see it, the RFC describing the protocol must be free (actually is
>>>> encouraged)
>>>>  to choose any detail implementation that helps in designing proper
>>>> working
>>>>  implementations (even if such details are not mandated but just
>>>> suggested).
>>>>
>>>> While it's perfectly possible to describe the protocol just around
>>>> communication
>>>>  semantics, ignoring how the state must be kept in the host (that is,
>>>> what minimum
>>>>  data-structures are expected to be handled by the software
>>>> implementation)
>>>>   makes the job harder for anyone interested in implementing the spec.
>>>> In practice,
>>>>  any software implementation is supposed to keep an internal
>>>> state-machine
>>>> . The state  and time transitions  will be driven by the
>>>> incomming/outgoing (ILP)
>>>>  protocol messages. Ignoring such internal state-machine in the RFC
>>>> just hurts
>>>>  developers interested in implementations with no advantage for anyone
>>>> else.
>>>>
>>>> A pure abstraction with no hints on implementation details can be great
>>>> for pure
>>>> mathematicians, but I'm not so sure that would be ideal for software
>>>> developers.
>>>>
>>>>  Taking for example the original TCP RFC,
>>>>  the paper is full of references detailing how the host is supposed to
>>>> implement
>>>>  the TCP stack, with state buffers and input/output queues. It could
>>>> have been
>>>>  perfectly possible to ignore such details, but for sure TCP  would
>>>> have not been
>>>>  that much easier to understand and port to different platforms.
>>>> Note that actually the RFC does NOT "requires" but actually "imagine"
>>>> some pieces in
>>>>  places on the host.
>>>> ( Actually those "imagined" pieces exists in 100% of TCP real
>>>> implementations)
>>>>
>>>> Extracted from https://tools.ietf.org/rfc/rfc793.txt
>>>> _____________________________________________________________
>>>>
>>>>       To store this information we imagine that there
>>>>       is a data structure called a Transmission Control Block (TCB).
>>>>       ...
>>>>       Before we can discuss very much about the operation of the TCP we
>>>> need
>>>>       to introduce some detailed terminology. Among the variables
>>>> stored in
>>>>       the TCB are the local and remote socket numbers, the security and
>>>>       precedence of the connection, pointers to the user's send and
>>>> receive
>>>>       buffers, pointers to the retransmit queue and to the current
>>>> segment.
>>>>       In addition several variables relating to the send and receive
>>>>       sequence numbers are stored in the TCB."""
>>>>      ...
>>>>       TCPs consume sequence number space each time a segment is formed
>>>> and
>>>>         entered into the network output queue at a source host.
>>>>      ...
>>>> _____________________________________________________________
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Enrique
>>>>
>>>>
>>>> De: Adrian Hope-Bailie [adrian@hopebailie.com]
>>>>
>>>> Enviado: lunes, 28 de agosto de 2017 23:25
>>>>
>>>> Para: Evan Schwartz
>>>>
>>>> CC: Enrique Arizon Benito; Interledger Community Group
>>>>
>>>> Asunto: 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ________________________________
>>>>
>>>> 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
>