Blogs & Articles: Virtual HTLCs 🔗 4 years ago

The Lightning Network/Protocol has been a massive gravitational well of development attention over the last 2–3 years. I’d speculate that there is just as much if not more developer mind share concerning themselves with the ins and outs of Lightning Protocol issues as there are concerning themselves with the core Bitcoin Protocol. Most of the “Network” side of Lightning revolves around the use of Hash Time Lock Contracts(HTLCs) to enforce atomicity of outcome in outputs across many individual Lightning channels.

HTLCs have shown to be a massive potential DoS vector in general for nodes participating on the network to route payments. Each individual individual HTLC requires its own output, with a maximum limit of 483 HTLCs that can exist in one channel. Ultimately the issue is transactions get more expensive the more inputs or outputs, and that transactions themselves are bounded by maximum size. This allows griefing channels by saturating their HTLC limit, and by refusing to cooperate and forcing things on chain can result in massive costs incurred for the griefed channel operator. And in some cases can even allow theft of some % of funds locked in HTLCs.

This requires effectively limiting the amount of HTLCs in flight far below the maximum limit to protect yourself as a channel operator from these types of griefing attacks and outright theft attacks. These kinds of limitations inherently layer on additional scarcity for Lightning Network throughput which has negative long term consequences for the viability of micropayments natively on the Lightning Network.

I’d like to propose a rough intuition for a solution to this. This is by no means a fully fleshed out idea, and there are definitely some pain points and outstanding issues I’m not quite sure how to solve in an airtight way, but I want to put the general idea out there and delineate these issues to see what others may think about possible solutions to those and the general concept.

Virtualize HTLCs many HTLCs in one UTXO using Smart Contracts Unchained in a structure similar to a DLC. In principle there is no reason in theory why you can’t emulate an infinite amount of virtual HTLCs on top of a single Multi-HTLC output with the cooperation of escrow(s). Think about what an HTLC is, its simply an output with a script that can be resolved by two different transactions: a success transaction and a refund transaction.

Single HTLC Spend: Either one party produces the preimage, or the other party can claim after timelock.

Each HTLC requires its own output, its own script with different preimages, and its own pair of potential settlement transactions (success and refund). The whole use case of a DLC is being able to encompass much more possible outcomes than a binary succeed/fail with the aid of oracle(s). So let’s construct this Multi-HTLC along similar lines to a DLC, using escrow agents instead of oracles:

Multi-HTLC Spend: Either both parties cooperate, or one party plus the escrow can settle.

What if we just have a single DLC-like Multi-HTLC output with these two emulated HTLCs on it? The potential settlement states of the Multi-HTLC output are all the possible outcomes of the emulated HTLCs being settled in net. ‘x’ satoshis flow one direction in the channel for all the virtual HTLCs that succeeded, ‘y’ satoshis flow in the opposite direction for all the virtual HTLCs that fail. All of this can be hosted in a single output, with the haslocks/preimages being used interactively with an escrow(s) to prove which settlement transaction they should sign off on. Optimally channel participants would just cooperatively sign off on the appropriate settlement transactions for the Multi-HTLC, and in the event of non-cooperation (whether innocent or malicious) a single channel member can go to the escrow and provide the preimages they have obtained to settle the Multi-HTLC honestly.

Now here is where the problems creep in. Namely the timelocks and the individual preimages. Firstly the preimages: this presents a problem because the entire purpose of a preimage being revealed explicitly during on chain settlement is what allows anyone involved in that routed payment who is dealing with non-cooperative peers to guarantee they can claim that money on chain settling out the HTLC. Without giving back a lot of gained efficiency of a “virtual HTLC” like this by explicitly revealing individual HTLC preimages on chain during Multi-HTLC settlement, adoption of a contract like this would draw into question that assumption that is part of the HTLC security model. The way I see it, there’s no way out of giving back some of the efficiency gain, or adapting the security model to off chain mechanisms for learning individual preimages in different failure scenarios.

The timelocks: a routed HTLC is structured to specifically have decrementing time locks that grow the further back from a payment destination to allow for prior hops to learn a preimage if it was revealed before their HTLC timeout allows the forwarding party to take their funds back. Bundling virtual HTLCs on top of a Multi-HTLC requires that every virtual HTLC be locked up under a single timelock period set by the Multi-HTLC they are hosted on. I’m really not quite sure how to make the general timelock assumptions for HTLCs work in this context. Hopefully something is possible that would allow virtual HTLCs to atomically interact with native ones, but so far I am at a loss here. Without a solution here routing would be limited and only possible between virtual HTLCs roughly in sync together with their Multi-HTLC timeout periods.

So, there is the general idea pain points and all. Hopefully some of the issues here are things smarter people than myself can come up with solutions for.

Virtual HTLCs was originally published in Block Digest Mempool on Medium, where people are continuing the conversation by highlighting and responding to this story.