SuperScalar: Decker-Wattenhofer channel factory with ladder-based time-delay tree structure

Author: ZmnSCPxj

Source: https://delvingbitcoin.org/t/superscalar-laddered-timeout-tree-structured-decker-wattenhofer-factories/1143

introduction

We define the “last mile” problem of LSP (Lightning Service Provider) as follows:

• New users who receive their first Bitcoin from the Lightning Network must pay for “incoming liquidity (received amount)”.
  • Blockchain operations related to acquiring liquidity must be shared among multiple new users to keep the cost per user low.

In addition to the above issues, our solution must also be subject to the following constraints:

• We must ensure that LSPs cannot steal funds, i.e., simply implementing the security assumption of "only one honest participant" is not enough unless each end user can act as that honest participant for themselves.

• There must be no need to change the consensus of the blockchain.

  • The Bitcoin blockchain protocol is ossified in practice. Because the planned halving every 4 years causes a sudden increase in Bitcoin's return, which in turn causes a sudden increase in interest in Bitcoin, a large number of new users will become entities with a stake in Bitcoin's consensus. When the previous batch of users are convinced to change the consensus, a new batch of users comes in and they must agree to the same consensus change. If a consensus change cannot gain actual consensus in a time shorter than the halving period, it may not happen at all, resulting in the protocol being ossified in practice (smaller, easier to handle changes may still pass, but more complex changes, such as "covenants", may never gain consensus).

• We must be able to handle the situation where a small number of end users are offline when the LSP must reallocate funds.

  • As the number of users sharing the same UTXO increases, the probability of one or more users going offline also increases. Therefore, when covering a large number of end users, the ability to deal with some end users being offline is necessary.
  • It has been proven that software running on mobile devices can be called back online through the Android or iOS application notification mechanism, so in reality, the onlineness of mobile clients is highly guaranteed. However, mobile devices may still occasionally lose network access, so their uptime will still not be as good as non-mobile devices. Therefore, the entire mechanism must still be able to cope with the situation where a small number of users are offline.

The above constraints immediately rule out the Ark and BitVM2 bridges. Without the restriction, both have the “at least one honest participant” assumption, which, according to the reasoning above, will never be activated in reality ( OP_CTV was largely completed in 2020, but has not yet reached consensus today (2024); it is beyond the halving period, so it will never reach consensus; SIGHASH_NOINPUT is even worse). Both can remove the “at least one honest participant” assumption and only have all end users online at the same time when the LSP needs to reallocate funds; this violates the last constraint above.

In this article I will present a construct called "SuperScalar", which is essentially a hierarchical time-delay tree structure of Decker-Wattenhofer channel factories.

formula

First, let me briefly describe the three building blocks that make up this architecture:

1. Decker-Wattenhofer off-chain update mechanism based on decreasing nSequence ;
2. "timeout trees", especially the variant that uses all signatures to simulate OP_CTV , which I call "timeout signature trees";
3. Ladder building method.

Feel free to skip the parts you are already familiar with.

Decker-Wattenhofer

The Decker-Wattenhofer decreasing nSequence mechanism is an off-chain cryptocurrency system that allows a group of interested users to agree on some state changes without every state change being published to the blockchain (which is why it is classified as an "off-chain" mechanism). This sounds very similar to the Poon-Dryja mechanism, but there are the following differences:

• Number of participants:
  • The Poon-Dryja mechanism strictly limits participation to only two parties;
  • The Decker-Wattenhofer decreasing nSequence mechanism can accommodate any number of participants;
• Number of status changes:
  • The Poon-Dryja mechanism can theoretically update the state an unlimited number of times (in real-world deployments, such as the Lightning Network's BOLT specification, the number of state updates is limited, but the upper limit is in billions, so it can be said to be unlimited).
  • The Decker-Wattenhofer decreasing nSequence mechanism allows fewer state updates. A single unchained construction can provide a small number of state updates (less than 100, and in practice only 4 or 2 per chained mechanism). The standard proposal is to chain multiple such constructions, which effectively multiplies the number of state changes that can occur in each chained construction (e.g., chaining 3 constructions, each of which allows 4 changes, allows 4 x 4 x 4 = 64 changes).
• Scale and convenience of unilateral exit:
  • The Poon-Dryja mechanism only requires one commitment transaction to unilaterally exit, and an additional transaction to recover the funds. The delay between initiating a commitment transaction and allowing the funds to be retrieved is a constant.
  • The Decker-Wattenhofer decreasing nSequence mechanism requires a "kickoff" transaction to start the unilateral exit process, and then each layer requires an additional transaction with a delay. If multiple layers of this structure are chained to increase the number of state changes allowed, the number of additional transactions required for unilateral exit will also increase, so the required block space is actually O(log N) where N is the number of state changes supported. Each layer of transactions has a variable delay before the funds can be retrieved.

Both the Decker-Wattenhofer mechanism and the Poon-Dryja mechanism can be implemented in Bitcoin without requiring consensus changes.

Like the Poon-Dryja mechanism, the Decker-Wattenhofer decreasing nSequence mechanism has an on-chain UTXO as a “funding outpoint.” This outpoint is a simple n-of-n multi-signature device consisting of all the signatories who signed the state change.

If it is a single-layer Decker-Wattenhofer decreasing nSequence mechanism, there are only two transactions:

1. A "pop" transaction that spends the funding output and generates an n-of-n multi-signature output
2. A "state" transaction spends the output of the pop transaction and requires a specific relative time lock by nSequence . The output of this transaction is the state agreed upon by all signatories.

For the initial state, nSequence of the "state" transaction is the designed maximum relative time lock. For example, for a design that intends to allow 4 state changes, a reasonable initial state is a relative time lock of 432 blocks.

When changing state, if all signatories agree on a new state, they create a new state transaction that spends the funding output, but with a shorter nSequence relative timelock than the previous state transaction. For example, for a design that allows 4 state updates:

This is why it's called a "decreasing nSequence " mechanism; each time signatories approve a new state, the transaction representing the new state uses a smaller nSequence value until it reaches 0.

Because the latest state always has a shorter relative time lock (compared to any older state), it can always be confirmed faster than earlier states. This mechanism ensures that, assuming the blockchain layer is not congested, the latest state is the transaction that will be confirmed in a single-party exit scenario.

The difference between nSequence and the timelock needs to be large enough so that all parties can reasonably assume that the earliest state can be confirmed before the older state even in a congested state. Therefore, the difference used in the above example is 144 blocks.

As mentioned above, such a set of constructions can only update the state a few times to reach the "final state". Therefore, Decker-Wattenhofer recommends chaining multiple such constructions in practice. The first construction in the whole chain has an output that is the signer's n-of-n multi-signature device; this output is used as an input to the next construction, and so on. Only the last construction has a state transaction (with multiple outputs) that represents the latest state of the funds in the whole system.

In effect, the "status" transaction of the previous construct is cut-through by the "popup" transaction of the next construct.

The chained Decker-Wattenhofer mechanism is like a multi-digit countdown timer. Every time a new state is approved, the last structure in the chain - the one farthest from the funding transaction - counts down once. However, if the last digit has become 0, then count down once on the second-to-last digit and reset the last digit to the maximum nSequence . Similarly, if the second-to-last digit has become 0, count down once on the third-to-last digit and reset all subsequent digits to the maximum nSequence . And so on.

In fact, the last construct in the chain is the most likely to change state (every state update will change it), while the first construct in the chain is the least likely to change.

 Initial state nSequence nSequence +----+------+ +-----+------+ +-----+-----------+funding -->| |n-of-n|-->| 432 |n-of-n|-->| 432 |...state...| +----+------+ +-----+------+ +-----+-----------+ kickoff tx state tx state tx======> nSequence nSequence +----+------+ +-----+------+ +-----+-----------+funding -->| |n-of-n|-->| 432 |n-of-n|-->| 288 |...state...| +----+------+ +-----+------+ +-----+-----------+ kickoff tx state tx state tx======> nSequence nSequence +----+------+ +-----+------+ +-----+-----------+funding -->| |n-of-n|-->| 432 |n-of-n|-->| 144 |...state...| +----+------+ +-----+------+ +-----+-----------+ kickoff tx state tx state tx======> nSequence nSequence +----+------+ +-----+------+ +-----+-----------+funding -->| |n-of-n|-->| 432 |n-of-n|-->| 0 |...state...| +----+------+ +-----+------+ +-----+-----------+ kickoff tx state tx state tx======> nSequence nSequence +----+------+ +-----+------+ +-----+-----------+funding -->| |n-of-n|-->| 288 |n-of-n|-->| 432 |...state...| +----+------+ +-----+------+ +-----+-----------+ kickoff tx state tx state tx

Timeout Tree

The timeout tree is a mechanism that combines the OP_CTV tree and timeouts.

In the absence of OP_CTV , a variant can be used: using the signatures of all participants to enforce OP_CTV restrictions. This variant (which I call "timeout signature tree") is the focus of my explanation. In addition, we also consider the case where a single LSP provides such a mechanism to its own customers.

On a timeout signature tree, an LSP L can provide lightning channels to a group of clients. A single confirmed on-chain UTXO can guarantee multiple channels opened with different clients.

During the initialization phase, the LSP creates a tree of transactions. In the output of non-leaf nodes, the clients in its subtree form an n-of-n multi-signature device with the LSP. This is the standard transaction tree construction, but the timeout tree also adds an alternative spending condition: the LSP can spend the funds alone after a period of time. The same alternative condition also exists in the funding output point.

For example, if LSP L has 8 customers, labeled A to H , then they will form a timeout tree. The conditions at the funding output point (which will be confirmed on the chain) will be:

1. A & B & ... & H & L
2. L & CLTV

So, the whole tree looks like this:

 +--+---+ | |A&L| LN channel +>| +---+ | | |B&L| LN channel +--+----------+ | +--+---+ | | (A&B&L) |-+ | |or(L&CLTV)| +--+---+ +>| +----------+ | |C&L| LN channel +--+----------+ | | | (C&D&L) |-->| +---+ | |(A&..&D&L)| | | |or(L&CLTV)| | |D&L| LN channel | |or(L&CLTV)|-+ +--+----------+ +--+---+funding-->| +----------+ | |(E&..&H&L)|-+ +--+----------+ +--+---+ | |or(L&CLTV)| | | | (E&F&L) | | |E&L| LN channel +--+----------+ | | |or(L&CLTV)|-->| +---+ +>| +----------+ | |F&L| LN channel | | (G&H&L) | +--+---+ | |or(L&CLTV)|-+ +--+----------+ | +--+---+ | | |G&L| LN channel +>| +---+ | |H&L| LN channel +--+---+

(Translator's note: This tree can also be viewed from the leaves to the root. Each leaf is a lightning channel between an LSP and a client; and above the leaf nodes, each node is a multi-signature device for all participants below, plus the LSP's timeout spending device.)

This timeout condition forces all clients to come back online before the timeout and exit the structure. The exit can be unilateral or in cooperation with the LSP.

In the cooperative exit scenario, the client can directly transfer all the funds in its channel on the timeout tree through the Lightning Network. It can be transferred to on-chain funds through the swap service, to a new timeout tree of the same LSP, or to another LSP.

A unilateral exit means that all transactions on the output path from the root of the tree to your own lightning channel must be made public, and then unilaterally exit the lightning channel (expected to be the Poon-Dryja channel).

The advantage of using a tree structure is that the cost of unilateral withdrawal is relatively low; if a customer wants to withdraw, he only needs to issue O(log N) transactions, and then most other customers can stay in the tree. If the tree structure is not used, then a unilateral withdrawal of a customer will cause all customers to unilaterally withdraw.

The benefit of the timeout condition is that it encourages all clients to exit simultaneously, possibly in a cooperative manner, and then the LSP only needs to issue a transaction with only one input (using the L & CLTV conditions in the funding output point) to clear funds from the structure. Even if some clients also want to exit unilaterally, many funds can be retrieved through the L & CLTV conditions of each intermediate output.

Ladder

Many financial institutions offer a financial contract: depositors can deposit some money, but cannot withdraw it for a period of time, even if they want to withdraw part of it; after the expiration of the term, the depositor can withdraw all the original funds plus interest. This contract is also non-transferable. Such contracts have many names:

• Certificate of Deposit (US)
• Guaranteed Investment Certificate (Canada)
• Time Deposit (Other Countries)

Such contracts are inflexible; as mentioned above, you cannot withdraw your funds until they expire. However, savvy investors will spread their available funds over multiple such contracts, staggering their expiration dates by a month or a year. This technique is called "laddering."

For example, an investor may have three such contracts, expiring in December 2024, December 2025, and December 2026. In December 2024, the first contract expires, and the investor can withdraw part of the funds and reinvest the remaining funds in a new contract expiring in December 2027; or, add more funds and invest them in the new contract; or, do not sign a new contract, thus ending the ladder.

Laddering gives investors the ability to change their investment amounts monthly or annually, depending on how wide your ladder is. So even if the underlying contract is inflexible, laddering allows investors to regain a little flexibility while maintaining the benefits of long-term fixed deposits.

SuperScalar Mechanism

The Decker-Wattenhofer channel factory with ladder-based time-out tree structure is a combination of the above three elements.

Decker-Wattenhofer channel factory with timeout tree structure

First, let's demonstrate the combination of the two; we'll add laddering to the mix in a section later in this article.

Assume that an LSP L has 8 customers, numbered from A to H Therefore, the injection output point has the following two spending conditions:

1. A & B & ... & H & L
2. L & CLTV

At initialization, the LSP arranges the following transactions for the client to sign, where the funding transaction is an n-of-n multi-signature transaction (consisting of A...H and L ):

 nSequence +---+---+ | |A&L| LN channel | +---+ +-->|432|B&L| LN channel | | +---+ | | | L | | +---+---+ | | +---+---+ | | |C&L| LN channel +--+-----+ | | +---+ nSequence | |A&B&L|-+ +>|432|D&L| LN channel +---+----------+ +>| +-----+ | | +---+ | |(A&..&D&L)| | | |C&D&L|---+ | | L | +--+---------+ | |or(L&CLTV)|-+ +--+-----+ +---+---+funding->| |A&...&H&L|->|432+----------+ +--+---------+ | |(E&..&H&L)|-+ +--+-----+ +---+---+ kickoff tx | |or(L&CLTV)| | | |E&F&L|---+ | |E&L| LN channel +---+----------+ +>| +-----+ | | +---+ state tx | |G&H&L|-+ +>|432|F&L| LN channel +--+-----+ | | +---+ kickoff | | | L | tx | +---+---+ | | +---+---+ | | |G&L| LN channel | | +---+ +-->|432|H&L| LN channel | +---+ | | L | +---+---+ state tx

Basically, the rules for building a transaction tree from a set of customers use the "from leaf to root" construction order:

1. First, customers are distributed to leaf nodes according to the self-set number of forks (the number of forks in the above example is 2).
   • The outputs of these leaf transactions are LSP L s channels with the corresponding customers, and there is an additional output (an additional amount of funds) held by L
2. Leaf nodes are always state transactions.
   • They have decreasing nSequence .
3. According to the required number of forks, establish the parent nodes of these leaves in the tree.
   • The parent transaction of the state transaction is the pop transaction.
     • Their outputs are simply n-of-n multi-signatures of the owners of the corresponding child transactions.
   • The parent transaction of the pop transaction is the state transaction.
     • In addition to the n-of-n multi-signature spending condition of the owner of its branch transaction, the state transaction output also has an alternative or (L & CLTV) spending condition.
     • The inputs of state transactions have decreasing nSequence .
4. Repeat the previous step until a root node is obtained.
5. If the final root node is a state transaction, then add a single-input, single-output pop-up transaction in front. Otherwise, directly use this root node as the first pop-up transaction.
   • When the number of forks is 2 and the number of customers is 8, the root node happens to be a pop-up transaction.
   • If the number of clients in the example is increased to 16, then the number of transactions required to issue a unilateral exit is 4, in addition to the unilateral exit transaction in the lightning channel.

The reason for alternating between pop transactions and state transactions in the tree hierarchy will be explained later.

Oops, A needs to credit liquidity!

Assume that A has used up all the payment quota in the channel between her and L in the above tree structure. How can L provide liquidity to A without initiating on-chain transactions?

The LSP can wake up B — and only B (assuming A is online when requesting more payment) — to update the leaf node containing the A & L channel and the B & L channel. Because this leaf node only contains the funds of A , B , and L , only these three need to be online; therefore, this mechanism can better cope with the situation where some participants are offline and A needs additional payment.

Of course, if B is not online, then LSP must try other methods, such as initiating transactions on the chain. This may generate on-chain fees that need to be paid, which LSP will charge to A

Assuming B is back online, L can then inject funds into the channel of A & L with his own dedicated funds without requiring the customer C...H to be online.

Of course, it is possible that L own funds in this leaf have been spent, or this leaf has reached the final state (i.e., nSequence = 0 ). At this time, the LSP can go up the tree, find a higher-level state transaction, wake up other customers, transfer the proprietary funds on other leaves to A , and reset nSequence of the nodes below this layer. This increases the number of customers who need to be online at the same time, but still does not require all customers to be online.

In fact, whenever some clients run out of incoming liquidity, the state transactions at the end are the most likely to be updated. However, if the L proprietary funds in a leaf have been exhausted, then the state transactions at the upper level need to be updated so that LSP L can allocate funds to A from other leaves.

Something went wrong, A wants to quit!

Suppose A decides to unilaterally exit. There could be many reasons; the important thing is that any customer of the LSP should be able to unilaterally exit, and the number of transactions that need to be posted should be as small as possible. This guarantee prevents the LSP from running away, and also guarantees the autonomy and fund control of users.

In order for A to exit, we first need to confirm the funding output point of the A & L channels, and then use the standard Poon-Dryja channel unilateral exit procedure to exit completely. Therefore, A must first publicly disclose the transaction from the root of the tree to his own channel funding output point, as shown below:

 nSequence +---+---+ | |A&L| LN channel | +---+ +-->|432|B&L| LN channel | | +---+ | | | L | | +---+---+ | state tx | | +--+-----+ | nSequence | |A&B&L|-+ +---+----------+ +>| +-----+ | |(A&..&D&L)| | | |C&D&L| +--+---------+ | |or(L&CLTV)|-+ +--+-----+funding->| |A&...&H&L|->|432+----------+ kickoff +--+---------+ | |(E&..&H&L)| tx kickoff tx | |or(L&CLTV)| +---+----------+ state tx

However, we should also note that any output of a confirmed pop-up transaction must be spent by a confirmed state transaction. This is because state transactions have nSequence , and transactions with smaller nSequence relative time locks should be confirmed before transactions with larger nSequence , otherwise the Decker-Wattenhofer mechanism breaks down (potentially allowing older states to be confirmed first).

Therefore, in the case where A wants to exit, not only the client ( B ) on the same leaf will inadvertently exit, but also the neighbors C and D in the upper level state transaction will exit.

 nSequence +---+---+ | |A&L| LN channel | +---+ +-->|432|B&L| LN channel | | +---+ | | | L | | +---+---+ | | +---+---+ | | |C&L| LN channel +--+-----+ | | +---+ nSequence | |A&B&L|-+ +>|432|D&L| LN channel +---+----------+ +>| +-----+ | | +---+ | |(A&..&D&L)| | | |C&D&L|---+ | | L | +--+---------+ | |or(L&CLTV)|-+ +--+-----+ +---+---+funding->| |A&...&H&L|->|432+----------+ kickoff state tx +--+---------+ | |(E&..&H&L)| tx kickoff tx | |or(L&CLTV)| +---+----------+ state tx

This also explains why we use "state" transactions and "pop" transactions alternately in the tree, unlike the general Decker-Wattenhofer construction, where only the first transaction is a "pop" transaction. If we imitate the general structure, then as soon as a client needs to exit, all downstream state transactions (which may have different nSequence relative time locks) must be published, otherwise the Decker-Wattenhofer mechanism is at risk of being broken. The interspersed "pop" transactions are just to act as the backend, ensuring that when a participant unilaterally exits, only O(log N) transactions need to be published, rather than O(N) for the entire tree.

This is why the output of a pop-up transaction does not need a timelock branch L & CLTV . The output of a pop-up transaction must be spent by the latest state transaction of that output, and the state transaction already has a timelock branch.

In the example above, B , C and D can still forward HTLCs in their own channels, but can no longer buy additional collection quotas from L cheaply. Instead, L will need to splice additional incoming liquidity on-chain, which will be more expensive. (That is, one participant's exit will not cause all participants to exit; but it will still cause some other participants to partially exit; "partial" means that their channels are still there, but they can no longer obtain collection quotas cheaply.)

However, clients from E to H can still purchase incoming liquidity using the above mechanism, because their tree is not published on-chain and can still be updated off-chain. In addition, when the timeout window is about to end, these clients can initiate a cooperative exit through the Lightning Network (there will be no funds left in their channel with L ), and then L can clean up the funds through the L & CLTV branch of the state transaction to make the funds flow again.

Ladder Construction

Now, add the third element.

From the perspective of LSP L , the above mechanism is an investment. L hopes to earn a return on the investment by:

• Lightning Network Routing Fees
• Selling liquidity cheaper off-chain
• Fees charged for maintaining the entire mechanism

Furthermore, due to the existence of timeout branches, LSPs cannot easily retrieve funds before expiration.

Therefore, a Decker-Wattenhofer instance of a timeout tree structure is very much like a time deposit, from the perspective of the LSP.

And as I mentioned earlier, smart investors will use multiple time deposit contracts to build a ladder to gain some flexibility in fund allocation.

The LSP itself can run multiple Decker-Wattenhofer instances of the timeout tree structure, facing different customers and using different terms, just like the time deposit ladder in traditional finance. When an instance expires, the LSP can start a new instance, invite users from the instance that is about to end to join the new instance, and charge for transfers. The LSP can then recover funds from the instance that is about to end on the chain through the timeout branch. He will receive income from routing fees, sales collection quotas, and the privilege of transferring to new instances, and these proceeds will be retained in the lightning channel.

For example, an LSP can run 30 Decker-Wattenhofer plants at the same time, and one plant will expire every day. When a plant is about to end, he can invite the customers in the plant to enter a new plant. The LSP can put the money from the expired plant into the new plant and create a new 30-day plant. Then, customers can also transfer funds from the expiring plant to the new plant. When all customers have withdrawn from the expiring plant and the contract is completed, the LSP can directly spend the entire UTXO, and the transaction has only one input and one output.

In the specific example below, an LSP builds a ladder of 9 timeout-tree Decker-Wattenhofer factories. Each ladder has a 7-day "active period" and a 2-day "end period". During the end period, customers can join one of the new factories created during those two days and transfer their funds to a new channel in the new factory. This gives users a little wiggle room; if they miss the first day, they still have a chance to transfer on the second day. In a real deployment, I would recommend using a 30-day active period and a 3-day end period; therefore, an LSP would need to maintain 33 factories simultaneously. Ideally, a transaction with only one input and one output would occur every day; although if a customer is not online, the LSP will need to publish a transaction from the root of the tree to the customer's output, which will increase the number of transactions on the chain that need to be published.

 Legend: ===== Active Period ::::: Dying PeriodDay | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 ===================================:::::::::: <---- each of this a factory ===================================:::::::::: ===================================:::::::::: ===================================:::::::::: ===================================:::::::::: ===================================:::::::::: ===================================:::::::::: ===================================:::::::::: Client can move ^ ===================================:::::::::: funds from first -----------+----^ ===================================:::::::::: factory to either of ^ these two new LSP uses the funds of the factories first factory to build this factory

Unfortunately, due to the lack of a restriction, customers need to be online at the same time as the LSP builds the new factory. If they miss this time, they need to try again on the next day of the end period; if they also miss on the last day of the end period, they must quit, paying all the costs. OP_CTV allows LSPs to preemptively add customers to new factories without requiring them to come back online immediately (customers can come back online at any time during the end period, unlike the unlimited clause case where customers need to come online at a specific time during the end period). However, this has the disadvantage that if those customers do quit instead of joining the new factory, the LSP will be forced to lock up funds during the next active period; and, because the customer has left, the LSP cannot obtain his signature and cannot use his signature to reallocate funds off-chain, which will affect neighboring customers in the tree (i.e., other users in the same tree will not be able to buy incoming liquidity cheaply because the LSP preemptively added the customer to the tree, but the customer has quit and (presumably) will no longer have any contact with the LSP).

The requirement to regularly transfer from old to new plants also provides a convenient rhythm for pricing liquidity charges.

The longer the closing period, the more additional funds the LSP needs to invest. These funds also need to have a return, so extending the closing period requires increasing the fees charged to the customer. This is a simple consideration of convenience vs. cost.

To reduce the probability that a client has to unilaterally exit, LSPs can provide a cooperative exit service: clients swap the funds in the factory for on-chain funds (using standard HTLC, which is a very common off-chain-on-chain swap). This allows clients to exit to the chain without issuing a unilateral exit transaction; unilateral exits will result in more UTXO issuance and will also increase the cost of LSPs managing on-chain funds after the relevant factory expires.

Realistic considerations

Hopefully I have explained the concept of the Decker-Wattenhofer channel factory for the laddering timeout tree structure, let's move on to the practical considerations associated with this mechanism.

Why do we need L?

In this proposal, each leaf carries an output that is dedicated to LSP L and can be used to dynamically allocate funds to customers who need to receive payment.

This brings up a question: Can we cancel this L output?

For example, suppose all leaves consist only of channels. So A and B would have a leaf transaction that includes channels A & L and B & L

Assume that A & L has exhausted A 's collection quota, and B & L has collection quota. Then LSP can move funds from the channel with B to the channel with A

The problem is that this is not incentive compatible. B has no incentive to participate in signing this new state: because he will lose something valuable, the amount of money received!

Assume that both A and B are users with a lot of lightning payments in both directions. If B signs a transaction that loses his payment quota, he will have to buy more payment quota from the LSP as long as he encounters a peak in outgoing payments first and a peak in incoming payments later. If A has used up the payment quota that can be obtained from state changes, the LSP will have to move to the upper layer and obtain more liquidity from other customers. This requires more customers to come back on-chain, which also increases the probability that some of them will not be online as needed, which forces the LSP to initiate expensive on-chain payments to allow B to obtain more payment quota. Obviously, the higher expenses will also be passed on to customers by the LSP.

Then, you might suggest that LSP can pay B and purchase the funds in his hands.

The problem is that initially, B bought the collection amount from the LSP. LSP pays B for the liquidity, which is actually equivalent to refunding a paid item. As you can imagine, refunds are always a bad customer experience; as a seller of liquidity, LSP certainly hopes that ideally no one will return to refund all the liquidity that has been sold, just like every merchant hopes.

In practice, if there is a price for each unit of incoming liquidity, and this price is the same for A and B , then the refund from B will be exactly equal to the payment from A In other words, LSPs will have no incentive to set up such a mechanism at all, because there is no way to make money from sales activities; the payment received from A will be used to buy the same amount of liquidity from B

If the LSP pays B less than it received from A , and can pocket the difference, then it forces B into a bad economic relationship. If B later needs to buy back the liquidity, and the LSP does the same thing, charging a higher price, then B loses money on both the sale and the purchase. This will be a zero-sum game, and no one wins.

Therefore, the only way an LSP can actually provide incoming liquidity is by locking up funds in dedicated outputs, which is, in effect, a “stock” of liquidity.

Importantly, B will never engage in a scheme that causes him to lose access to payment.

Another approach is that the LSP does not sell incoming liquidity; that is, instead of the model of "LSP sells incoming liquidity but does not charge customers the Lightning Network routing fee", the model of "LSP charges customers a non-zero Lightning Network routing fee and then decides where to allocate liquidity" is used. The latter is less ideal because it can be assumed that customers always know when they need liquidity better than LSPs do; for example, a merchant may have some promotional activities or a new product is about to be launched, then it can be expected that more collection quotas will be needed; and this information can be clearly reflected in the activity of purchasing collection quotas from LSPs in advance; in this case, the customer can wait for other customers in the tree to come online.

Motivating customers online

Even if there is a dedicated L output as “liquidity inventory for sale”, since B also needs to be online, then B also needs to be compensated to some extent.

The most direct way is that during the participation process, B can get a small part of the liquidity fees charged by LSP to A

In addition, LSP can also provide a small amount of free liquidity directly to B The two methods are largely equivalent, because incoming liquidity is also valuable, but the advantage of doing so is that B can get more liquidity in advance while both he and A are online. Later, A may go offline, leaving B who needs incoming liquidity, with only expensive on-chain operations; therefore, B would prefer to get a small amount of free incoming liquidity now (while A is also online) rather than requesting it later (when A may be offline).

Customer Grouping

Some customers may regularly shut off power during certain times of the day (such as evening local time).

LSPs can monitor the online hours of customers and then group them according to the time they are most likely to be online in a 24-hour period. Then, when constructing a transaction tree for a new plant, LSPs can group customers with similar “most active hours” into the same leaf and adjacent leaves.

This increases the probability that other customers in the same leaf are online when a customer needs to collect payment; even when a leaf node runs out of funds dedicated to L , customers in adjacent leaves are more likely to be online.

In short, if an LSP has customers all over the world, then grouping them by time zone is very beneficial, because customers in adjacent time zones are more likely to be online at the same time.

Tree construction and fork number selection

The optimal number of forks for a leaf node is 2, because this means that only 3 participants need to be online to update a leaf: the two clients on the leaf, and the LSP itself. This makes the state update operation more reliable.

The fork count of a pop transaction can be set to 1. Since all outputs of a pop transaction must be spent (when the pop transaction is confirmed by a block), this reduces the number of clients affected when a client unilaterally exits. It also reduces the number of clients that need to be woken up when a leaf node runs out of L dedicated funds.

Unfortunately, a lower fork number means a larger tree height:

• A larger tree height means more transactions need to be published in the case of a unilateral exit.
• A larger tree height means that in the case of a unilateral withdrawal, the funds must undergo a longer nSequence relative time lock before they can be withdrawn.
  • The relative timelock here also forces the HTLC that ends at the client to set its final CLTV delta floor ( min_final_cltv_expiry_delta in BOLT11) higher than the maximum nSequence latency that would expose its channel, and higher than the latency that this client believes is "safe" to redeem funds. Therefore, it is very important to keep nSequqnce low, because this latency also determines the maximum latency that HTLCs on the public network will lock funds in pending HTLCs and reduce public network capacity.

To alleviate these issues:

• Smaller fork numbers are used in levels close to the leaves, while larger fork numbers are used in higher levels.
  • In any case, if a leaf node can no longer provide additional incoming liquidity to a customer, the LSP will always have to "go back to the previous level" and wake up more customers.
  • “Going back to the previous level” means that the number of clients that need to be online doubles, proportional to the number of forks of the node.
  • If the group that needs to be awakened is large enough, the probability that they are all online will be very low, so that doubling or quadrupling the size of the group will not have any effect - because the probability that they are all online is already very low, so low that you will honestly return to the chain and not count on this mechanism.
• After a few levels away from the leaves, we can completely remove state transactions (i.e. transactions with decrementing nSequence ). In practice, this becomes a root timeout signature tree output that guarantees multiple timeout tree-structured Decker-Wattenhofer factories, which in turn guarantee the client's actual channel.
  • Similarly, if the LSP has to "go back one level" and trace back one to two layers of state transactions from the leaf, the number of customers that need to be awakened will be very large, so many that it is unlikely that they can be online at the same time. Therefore, the latency of unilateral exit can also be reduced by using fewer state transaction layers.
  • Non-stateful transactions have no relative time locks and therefore do not cause additional delays when exiting.
• LSP can group customers with higher online time together and place them in nodes with larger fork number.
  • Such clients will receive better service (they will be grouped with other clients with higher uptime, so people in the same group are more likely to be online when they need to deposit liquidity); and unilateral exits will be cheaper and faster (higher fork count means lower tree height, which means fewer transactions need to be issued).
  • Customers with low online time and new customers will get more nodes with fork numbers of 2 and 1, so the cost of unilateral exit is higher, but they are also better isolated from the impact of neighboring customers going offline.

(over)