Timelocks and Lightning on MimbleWimble



Summary:

In a recent bitcoin-dev mailing list post, ZmnSCPxj discusses Lightning and similar off-chain protocols on MimbleWimble. While the "magical shrinking blockchain" of MimbleWimble eliminates the need to validate already-spent outputs, this creates a problem for validating relative locktimes necessary for off-chain updates and indefinite-lifetime channel constructions. Thus, it is not the lack of SCRIPT that prevents Lightning-over-MimbleWimble, but rather the lack of relative locktime. All practical off-chain updateable cryptocurrency systems require some kind of timeout, which could be implemented as either absolute or relative lock time, but an absolute locktime would limit the lifetime of the channel. MimbleWimble supports 2-of-2 with Schnorr and other homomorphic signatures, which can be used to implement HTLC-like constructs and impose relative locktimes using simple nSequence. MimbleWimble also supports the two-transactions construct for HTLCs hosted inside indefinite-lifetime Spilman channels and Decker-Russell-Osuntokun. While sequence numbers enforce relative timelocks and are described as an independent constraint in BIP68, OP_CHECKSEQUENCEVERIFY is required to enforce them. An alternative presigned nlocktime transaction double spend technique was proposed, but it requires the ability to aggregate signatures across transactions.


Updated on: 2023-06-13T21:23:50.116641+00:00