Hard or flexible timeouts - what's better?

[Michiel de Jong]

Hi, and thanks again for joining this list!

There are a number of topics in Network Ledger Technology for which I think a cross-project discussion is particularly interesting, and that's one purpose this list can serve.

One such topic I think is how to behave when a node along the path neither completes, nor rejects a multi-hop hashlocked transaction.

In Lightning, Interledger, and the hypothetical Ripple protocol, staggered hard timeouts are used. This means that node i assumes the risk of node  i+1 becoming unresponsive. The advantage is that node i-1 is only affected in a limited way by unresponsiveness down the line.

But of course, if the timeouts are long (which they are especially for Lightning), this limit may not be as meaningful as it seems. A  timeout of several hours assures that your money is not tied up in a limbo state for more than that, but it's still long enough to be annnoying, because as long as money is locked up in pending transactions, it cannot be used as liquidity in other transaction opportunities.

And it's even more annoying in a multi-currency network, where exchange rate fluctuation could shift significantly during such a time span, leading not only to lock-up of liquidity, but also to the free option problem, which an attacker could use to extract money from the network, if no roll-back fees are charged.

There are also Network Money projects, particularly SettleNetwork and LedgerLoops, that don't define timeouts on multi-hop transactions. This doesn't  mean that time bound expectations don't exist, and node i can still choose to take responsibility (responding to node i-1 with a reject) when node i+1 is unreachable. One reason I think this arrangement makes more sense for the governance of a trustline between nodes i and  i+1 is that a communications  outage between two parties should probably not affect the ledger between them.

To me, it's similar to a real-life situation where maybe I sold you something via ebay, but the postal service is very slow in delivering it. By the time the package arrives, you no longer need it, and you wish to send it back. I as a seller would count that as an exceptional circumstance, and allow you to undo the whole transaction. Or maybe you don't mind so much that the item arrived late, and still want to pay me for it. Those would normally be the only two ways a sale could be finalized (successfully, or amicably cancelled).

It would be less common (although not unheard of) for the transporter to pay me for the package first, temporarily "hold the hot potato", and then get paid by you if they manage to deliver it on time. Such constructions do exist in real life, but they mean the transporter service runs a risk of getting stuck in the middle when unexpected delays happen.

In the case of ledger-backed ('layer 2') payment channels as used in projects like Lightning and Raiden, hard timeouts do make more sense because they can be ledger-enforced, giving the sender their money back on-ledger in case of a dispute.

So maybe we could say that for a purely trustline-based money network, timeouts on hashlocks make less sense than for a ledger-backed layer-2 network?

Interested to hear other people's thoughts on this topic!

Cheers,

Michiel