Re: Hashed Timelock Agreements (HTLAs)

I think it would be useful to explain the "Unconditional Payment Channels"
a little more.

I assume this means that there is a ledger and the ledger is responsible
for tracking completed payments (where completed means the preimage has
been presented before expiry) but the actual transfer of funds between the
two peer accounts on the ledger only occurs occasionally (i.e. not for each
payment).

The difference between this and the other two is nuanced and not obvious,
especially for those unfamiliar with systems like Lightning. Are there any
networks other than XRP Ledger and Lightning where these are possible?

On 21 June 2017 at 15:17, Evan Schwartz <evan@ripple.com> wrote:

> This time with the picture (inline and as an attachment, hopefully one
> goes through):
>
> [image: IMG_20170621_151002.jpg]
>
>
> On Wed, Jun 21, 2017 at 3:13 PM Evan Schwartz <evan@ripple.com> wrote:
>
>> This is the way I would draw the spectrum of possible agreements:
>>
>> [image: IMG_20170621_151002.jpg]
>>
>> There's a tradeoff between complexity / ledger support required and
>> simplicity + bilateral risk. Not sure which one will end up being the most
>> used but I think it's very cool that Interledger supports all of these
>> equally well.
>>
>> On Wed, Jun 21, 2017 at 12:31 PM Michiel de Jong <michiel@unhosted.org>
>> wrote:
>>
>>> I also like the term HTLA, it really explains the *per-hop* decision to
>>> use on-ledger, off-ledger (payment channel), or "no ledger" (just trust).
>>>
>>> On Wed, Jun 21, 2017 at 12:22 PM, Adrian Hope-Bailie <
>>> adrian@hopebailie.com> wrote:
>>>
>>>> I like it. Based on your description it sounds like there are 3 types
>>>> of agreement, it would make sense to probabaly define each and also
>>>> document the differences:
>>>>
>>>> 1. Agreement enforced by ledger
>>>> 2. Agreement by sender to complete transfer upon receipt of preimage
>>>> 3. Agreement by receiver to reverse transfer upon expiry
>>>>
>>>> I'd discourage use of 3 unless under specific circumstances because
>>>> there are usually fees involved in a reversed transfer which complicates
>>>> things a lot.
>>>>
>>>> On 21 June 2017 at 12:09, Evan Schwartz <evan@ripple.com> wrote:
>>>>
>>>>> What do you think about the term "Hashed Timelock Agreements (HTLAs)"?
>>>>>
>>>>> An HTLA is a generalization of the idea of a Hashed Timelock Contract
>>>>> (HTLC), which is the Bitcoin/Lightning Network term for conditional
>>>>> transfers where the conditions and timeouts are enforced by the ledger.
>>>>>
>>>>> In Interledger, you don't need all transfers to be enforced by the
>>>>> ledger, because two parties can treat an unconditional transfer on a ledger
>>>>> or through a simple payment channel as conditional. Basically, the two
>>>>> parties are using an agreement based upon a hashlock and a timeout where
>>>>> they say "if you give me the preimage to the hash before the timeout, I'll
>>>>> send you the corresponding payment". In that case the recipient takes the
>>>>> risk, but you could set up the agreement the other way where the sender
>>>>> must send the amount upfront and the recipient will send the money back if
>>>>> the transfer times out. Both parties can limit the amount of risk their
>>>>> peer poses simply by capping the amount they are willing to have unsettled
>>>>> or inflight.
>>>>>
>>>>> A key point about the security model is that if you use HTLAs to
>>>>> secure multi-hop transfers (like both Interledger and Lightning do) it's up
>>>>> to each pair of participants what type of agreement they want to use. If
>>>>> they have very little trust and their ledger supports more complicated
>>>>> features, maybe they want to use ledger-enforced HTLCs. If they are friends
>>>>> or have a business relationship or their ledger doesn't support enforcing
>>>>> HTLCs then a different type of HTLA would work just fine.
>>>>>
>>>>> What do you think? Does HTLA get the point across? (If this idea seems
>>>>> interesting or could use more explanation I could write up a full blog post
>>>>> about it)
>>>>> --
>>>>>
>>>>> 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
>