Published on: 2019-09-20T12:22:20+00:00
In a recent discussion on Bitcoin development, various aspects of the pre-signed nlocktime transaction double spend technique were explored. It was noted that this technique only works with locktime (absolute time locks) and not with sequence numbers (relative time locks). However, Antoine Riard argued that relative locktimes already function as expected, according to BIP68, and suggested that once Schnorr is implemented, it would be possible to do lightning on Bitcoin without any script. There was also a discussion about the "magic shrinking blockchain" property in implementing relative locktimes. It was observed that this property does not apply to kernels, as all the kernels need to be validated to validate the current UTXO set. It was proposed that if Schnorr-like signatures were used, the signatures and the Pedersen-commitment-to-0 could be aggregated into a single signature and Pedersen-commitment-to-0. However, it was mentioned that sinking signatures or partial aggregation of signatures for absolute-locktime kernels does not seem possible with relative locktime kernels. The Grin "Elder channel" design was discussed as being similar to eltoo but offering some bandwidth savings compared to the Poon-Dryja design.In another post on the bitcoin-dev mailing list, ZmnSCPxj discussed the challenges of implementing Lightning and similar off-chain protocols on MimbleWimble. While MimbleWimble's "magical shrinking blockchain" eliminates the need to validate already-spent outputs, it creates a problem for validating relative locktimes necessary for off-chain updates and indefinite-lifetime channel constructions. ZmnSCPxj suggests that while 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, the lack of OP_CHECKSEQUENCEVERIFY makes enforcing them difficult. Furthermore, the lack of relative locktime in MimbleWimble poses challenges for practical off-chain updateable cryptocurrency systems, as timeout mechanisms are necessary. ZmnSCPxj acknowledges that the inclusion of relative lock heights is possible in MimbleWimble, as demonstrated by Grin and Beam, but notes that this would contribute to blockchain size and affect pruneability. Despite these challenges, ZmnSCPxj believes that a MimbleWimble blockchain can still support offchain updateable cryptocurrency systems.Overall, the lack of relative locktime, rather than the absence of SCRIPT, is identified as the main obstacle preventing Lightning-over-MimbleWimble. The post provides links to relevant proposals and designs related to the incorporation of relative lock heights in MimbleWimble.
Updated on: 2023-08-02T01:21:16.863413+00:00