- From: Michiel de Jong <michiel@unhosted.org>
- Date: Wed, 21 Jun 2017 12:31:52 +0200
- To: Adrian Hope-Bailie <adrian@hopebailie.com>
- Cc: Evan Schwartz <evan@ripple.com>, Interledger Community Group <public-interledger@w3.org>
- Message-ID: <CA+aD3u3CMhrnSZ_oiZNydaXVnCGOZPY-rERPjsBh=b64HxaK5A@mail.gmail.com>
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 >> > >
Received on Wednesday, 21 June 2017 10:32:26 UTC