Nov 8 - Nov 8, 2023
This structure is adequate when dealing with the splicing of funds in a single channel. However, challenges arise when considering the simultaneous splicing of multiple channels within a single batched transaction. Such scenarios might include a node desiring to transfer funds out of one channel and into another.
A significant issue with the current design becomes apparent during theft attempts. Specifically, if an attacker publishes a revoked commitment transaction for one channel, it might block the confirmation of the splice transaction for all other involved channels. This potential vulnerability is exacerbated in situations where the cost of attempting theft is minimal or non-existent. For instance, channels that were opened with funds from only one party and have never facilitated incoming transactions for the attacker pose little to no risk for attempting theft. In these cases, the victim has a strong incentive to remove their funds from the compromised channel through splicing.
This overview highlights critical considerations for enhancing the security and functionality of splice transactions within the Lightning Network, especially when managing funds across multiple channels simultaneously. The need for a design that can accommodate the complexities of batched splice transactions without exposing users to increased risks of theft is evident.
TLDR
We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project?
Give Feedback