delvingbitcoin

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

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

Original Postby ariard

Posted on: October 17, 2024 22:42 UTC

The discussion begins with a critique of Block Inc's approach to organizing the summit where SuperScalar technology was exclusively presented to selected developers.

This method contrasts sharply with the open-source ethos that has characterized Lightning development since 2016. The lack of communication from Block Inc about the organization of the event raises concerns, especially given the historical emphasis on open and inclusive discussions within the open-source community.

SuperScalar technology, specifically in the context of chain economics and technical details, is explored next. This technology involves an initial transaction with the Lightning Service Provider (LSP) and all users, known as the root transaction. From this point, the Decker-Wattenhofer update mechanism introduces a two-stage process: the kick-off and state transaction phases, both of which spend the root transaction. Each state transaction incorporates a decrementing timelock and is linked to a timeout tree. This tree dictates that after a certain period, users must interact with the LSP to update their status, or else they risk being removed from the tree through a multisignature state transaction executed by the LSP and some users.

A critical aspect of this system is the k-factor, which determines the branching out and fan-out of users in the subtrees. Assuming a k-factor of 2 and a total of 8 users, there would be a requirement for 12 transactions to confirm in a worst-case scenario. This implies that either the user, for a fully non-assisted exit, or the LSP must have sufficient on-chain amounts ready to confirm the four transactions leading up to the safety timelock expiration. The challenge is even greater for the LSP, which must maintain liquidity to cover all possible combinations within the timeout tree, a daunting task when considering potential fullness of mempool networks.

Lastly, doubts are cast on the viability of SuperScalar under scenarios of "Forced Expiration Spam," as outlined in section 9.2 of the lightning whitepaper. Given the current block size of 4 MB and the maximum number of bitcoins available for fee payments, the functionality of SuperScalar under such conditions appears questionable. This criticism reflects broader concerns raised by protocol experts prior to the involvement of the writer in bitcoin development, emphasizing that the critique is not a personal attack but a technical observation.