Re: Hashed Timelock Agreements (HTLAs)

Lightning actually fits into the Conditional Payment Channel category.
Unconditional Payment Channels are things like Bitcoin/Litecoin CLTV
channels
<https://bitcoinmagazine.com/articles/checklocktimeverify-or-how-a-time-lock-patch-will-boost-bitcoin-s-potential-1446658530/>
 and XRP PayChan <https://ripple.com/build/amendments/#paychan>.

In general, a simple payment channel is something that allows two parties
to pay one another by exchanging signed messages that update the amount of
money each can claim from a shared temporary account. Then the ledger is
only involved in the payment flow when the channel is opened or closed.
This enables more efficient payments over ledgers that are slow, have
limited throughput, or high fees.

The difference between conditional and unconditional payment channels is
whether each update to the channel is based upon the hashlock +
preimage/fulfillment. As far as I know, Lightning uses only conditional
channels, which is why deployment is blocked on SegWit. Simple payment
channels work on Bitcoin today (that was what we demoed with
ilp-plugin-bitcoin-paychan
<https://github.com/interledgerjs/ilp-plugin-bitcoin-paychan>).

The way you use simple, unconditional channels for HTLAs are as you
describe. Either:

   - *Postpay*: for every fulfillment (or every couple) a connector gives a
   sender, the sender must send the corresponding value over the payment
   channel. If they don't, the connector will stop processing the sender's
   payments. Connectors limit their risk by capping the amount of unsettled
   balance the customer is allowed to have.
   - *Prepay*: to prepare a payment, the sender must send a payment over
   the payment channel. If the Interledger payment times out, the connector
   must send the payment back. If the connector fails to return a payment like
   they should, the sender limits their risk by closing the channel and using
   a different connector.


On Wed, Jun 21, 2017 at 5:53 PM Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

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

Evan Schwartz
Software Engineer
Managing Director of Ripple Luxembourg
<http:> <http:>