W3C home > Mailing lists > Public > public-interledger@w3.org > June 2017

Re: Hashed Timelock Agreements (HTLAs)

From: Evan Schwartz <evan@ripple.com>
Date: Wed, 21 Jun 2017 13:13:45 +0000
Message-ID: <CAONA2jVjXZPMnMmZz_CRoYew5oyQr=TLioT5n+LV+d7z_TqOyA@mail.gmail.com>
To: Michiel de Jong <michiel@unhosted.org>, Adrian Hope-Bailie <adrian@hopebailie.com>
Cc: Interledger Community Group <public-interledger@w3.org>
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>

> 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
<http:> <http:>
Received on Wednesday, 21 June 2017 13:14:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 June 2017 13:14:31 UTC