Good morning again list, particularly cdecker who is the "Decker" in
Decker-Wattenhofer,
Below is some numbers for implementing a sidepool using Decker-Wattenhofer, in
case `SIGHASH_NOINPUT` so we can do Decker-Russell-Osuntokun takes two more
years.
First, I should note that ***if*** we deploy something like this using
Decker-Wattenhofer decrementing-`nSequence` mechanisms, we need the following
numbers:
number_of_stages: The number of nested decrementing-nSequence stages
steps_per_stage: The number of steps from the starting nSequence of one
stage to the lowest nSequence=0, inclusive
blocks_per_step: The number of blocks from one step to the next.
These numbers all kind-of suck in the following ways:
`number_of_stages` plus 1 is the number of transactions that need to be
confirmed in case of a unilateral close.
The "plus 1" here is due to the "kickoff transaction" which initiates the
unilateral close and start the relative `nSequence` timers, and cannot itself
be one of the stages of the nested decrementing-`nSequence` mechanisms.
`steps_per_stage` raised to the `number_of_stages` is the maximum number of
updates.
Once the mechanism saturates, we *need* to do an onchain operation.
This can just be a "no-op splice" where we just spend the current funding txout
into a new funding txout with a refreshed mechanism starting from state 0.
`blocks_per_step` is the maximum amount of time that a participant can safely
be offline during a unilateral close.
If a participant is offline for longer than this period, the other participants
may present an older state where the offline participant has less money.
`number_of_stages` times (`steps_per_stage` minus 1) times `blocks_per_step` is
the longest time that a unilateral close will take.
Due to the number of updates being `steps_per_stage` ***raised*** to
`number_of_stages`, if we halve the number of stages (to reduce onchain
footprint in the unilateral close case) we need to *square* `steps_per_stage`,
which greatly increases the longest time the unilateral close will take.
For example, suppose we set:
number_of_stages = 8
steps_per_stage = 2
blocks_per_step = 144 (1 day)
Then:
* The worst case is that a unilateral close will lock up funds for 8 days (8 *
144 blocks).
Unilateral closes *may* take shorter than that.
* A participant cannot be offline for longer than 144 blocks
* The mechanism can only support 256 (2 to the 8) updates.
* Note that a swap requires two updates: one to offer the HTLC, the second to
claim or reject it.
However, a single update can service multiple swaps in parallel; they just
have to all happen simultaneously.
* The above implies that number of swaps is half of the number of updates.
Now, for the specific case of `steps_per_stage = 2`, if we halve the
`number_of_stages` we need to square `steps_per_stage`, and squaring that is
just `steps_per_stage = 4`.
Thus the halving of the `number_of_stages` is cancelled out by the squaring of
`steps_per_stage`, implying that `steps_per_stage = 4` is optimal.
Beyond that, further halvings of the `number_of_stages` will cause squarings of
the `steps_per_stage` to retain the small number of updates and greatly
increase the worst-case lock-up time in a unilateral close.
--
The point of the sidepools mechanism is that it is another settlement layer on
top of the blockchain layer, which we hope is cheaper than just using the
blockchain.
Then we have direct-on-blockchain published channels, and if the channels
become grossly imbalanced, participants can initiate a "swap party" on the
sidepool.
In a "swap party" the participants then try to move their imbalanced channels
back to balance by offering HTLCs on the sidepool.
All of the sidepool-offerred HTLCs are then bundled into a single update of the
sidepool.
Then, 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 participants can then
bundle all the claims and failures on the sidepool side in a second update.
(Each is basically a peerswap with your counterparties, except that the "other
side" of the peerswap is inside the sidepool instead of in a blockchain layer.
This is also amenable to "forwardable peerswaps" as well, and should be
designed as such)
Then, the sidepool enters a "moratorium" period during which another swap party
cannot be initiated.
Alternatively, swap parties can be scheduled at fixed regular intervals, which
might be easier for institutional nodes --- maintenance actions such as updates
and regular shutdowns can be scheduled so that they do not coincide with swap
parties.
For example, swap parties might be scheduled at 00:00 UTC every day.
If swap parties are done once per day, then a 256-update mechanism can last for
128 days, which is just slightly more than 3 months.
Having to do one onchain tranaction per 3 months in order to "reset" the
mechanism sounds like a reasonable deal to me; the alternative is to perform
HTLCs about once a day on the blockchain layer for each channel you want to
update at the same rate.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
