# SuperScalar: Laddered Timeout-Tree-Structured Decker-Wattenhofer Factories

**URL:** <https://delvingbitcoin.org/t/superscalar-laddered-timeout-tree-structured-decker-wattenhofer-factories/1143>\
**Category:** Protocol Design\
**Tags:** lightning\
**Created:** [September 16, 2024, 8:08pm UTC](https://delvingbitcoin.org/t/superscalar-laddered-timeout-tree-structured-decker-wattenhofer-factories/1143 "2024-09-16T20:08:19Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![ariard](https://delvingbitcoin.org/letter_avatar_proxy/v4/letter/a/c67d28/32.png) [@ariard](https://delvingbitcoin.org/u/ariard)\
**Post date:** [September 17, 2024, 7:28am UTC](https://delvingbitcoin.org/t/superscalar-laddered-timeout-tree-structured-decker-wattenhofer-factories/1143/4 "2024-09-17T07:28:54Z")

</div>

> [@ZmnSCPxj](#):
>
> The timeout condition forces all clients to come online before the timeout and exit the mechanism. Exit can be unilateral or with cooperation of the LSP.

This does not seems to works well if you have mass off-chain force-closure as more or less described in the “Forced Expiration Spam” section of the lightning paper: [https://lightning.network/lightning-network-paper.pdf](https://lightning.network/lightning-network-paper.pdf)

Timeout condition only gonna provoke a mass on-chain fallout of unilateral exit competing for scarce blockspace, and no guarantee that the LSP is online when timeout matures for batching, at least at the protocol-level.

---

_[View the full topic](https://delvingbitcoin.org/t/superscalar-laddered-timeout-tree-structured-decker-wattenhofer-factories/1143)._