# 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:** 34

<div class="post-metadata">

**Author:** ![ZmnSCPxj](https://delvingbitcoin.org/letter_avatar_proxy/v4/letter/z/ee7513/32.png) [@ZmnSCPxj](https://delvingbitcoin.org/u/ZmnSCPxj)\
**Post date:** [February 13, 2026, 4:29pm UTC](https://delvingbitcoin.org/t/superscalar-laddered-timeout-tree-structured-decker-wattenhofer-factories/1143/34 "2026-02-13T16:29:45Z")

</div>

To my knowledge this is not being worked on by anyone else anywhere, not even myself, so feel free to continue implementing this.

A thing I would suggest would be to remove shachain completely, in favor of simply storing all the revocation keys. The issue is that to my knowledge, there is no multi-participant method of creating shachain (by which I mean, one channel endpoint or the other may be composed of multiple signers, and, without having to reveal this information that the endpoint may or may not be composed of multiple signers, can we calculate a single shachain for one endpoint (actually has multiple signers) without losing the important part of multisig: multiple devices must be compromised for financial loss to occur (so that, for example, having a single device perform the shachain in full is not truly multisignature in this sense)).

---

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