Sidepools For Improving Payment Reliability At Scale



Summary:

In the email, ZmnSCPxj discusses the implementation of a sidepool using the Decker-Wattenhofer mechanism. They mention that if this implementation is deployed with decrementing-nSequence mechanisms, several numbers need to be considered. These numbers include the number of stages, steps per stage, and blocks per step. However, ZmnSCPxj notes that these numbers have some limitations.The number of stages plus one represents the number of transactions that need to be confirmed in case of a unilateral close. The "plus one" is due to the "kickoff transaction" that initiates the unilateral close and starts the relative nSequence timers. Steps per stage raised to the number of stages represents the maximum number of updates possible. Once the mechanism saturates, an on-chain operation becomes necessary. This can be a "no-op splice" where the current funding txout is spent into a new funding txout with a refreshed mechanism starting from state 0.Blocks per step represents the maximum amount of time a participant can safely be offline during a unilateral close. If a participant is offline for longer than this period, other participants may present an older state where the offline participant has less money. The longest time a unilateral close can take is calculated by multiplying the number of stages, steps per stage minus 1, and blocks per step.ZmnSCPxj provides an example to illustrate these calculations. If number_of_stages is set to 8, steps_per_stage to 2, and blocks_per_step to 144 (1 day), then a unilateral close will lock up funds for a maximum of 8 days. Participants cannot be offline for longer than 144 blocks. The mechanism can support a maximum of 256 updates, and the number of swaps is half the number of updates.ZmnSCPxj also discusses the purpose of the sidepools mechanism, which is to provide another settlement layer on top of the blockchain layer. In case the channels become imbalanced, participants can initiate a "swap party" on the sidepool to move their imbalanced channels back to balance. During a swap party, participants offer HTLCs on the sidepool, which are then bundled into a single update. The channels put a "reverse" HTLC in the opposite direction, and the preimages are sent in the channel. Once the channel side HTLCs are fulfilled or failed, the claims and failures on the sidepool side can be bundled in a second update.After a swap party, the sidepool enters a "moratorium" period during which another swap party cannot be initiated. Alternatively, swap parties can be scheduled at fixed regular intervals, such as once per day at 00:00 UTC. ZmnSCPxj suggests that a 256-update mechanism can last for approximately 128 days, slightly more than 3 months. They consider this a reasonable deal compared to performing daily on-chain transactions for each channel that needs updating.Overall, ZmnSCPxj provides detailed information about implementing a sidepool using the Decker-Wattenhofer mechanism, including calculations for various numbers and the purpose of the sidepools mechanism in balancing channels.


Updated on: 2023-09-21T01:54:51.591449+00:00