Re: Hashed Timelock Agreements (HTLAs)

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