delvingbitcoin

Contract-level Relative Timelocks

Contract-level Relative Timelocks

Original Postby JeremyRubin

Posted on: January 3, 2025 17:32 UTC

The discussion revolves around the novel application of MUON in transaction processes, providing a detailed explanation of how it operates within a specific protocol to ensure the integrity and non-malleability of transactions.

The mechanism employs a series of transactions including Tx Open, Tx Kickoff, Tx Update[i], Tx Ratchet i, and Tx Exit, each playing a crucial role in the sequence of events that safeguard the transaction process.

In the beginning, the Tx Open transaction is initiated with specific inputs and outputs, where outputs include variables such as V_O representing the number of Satoshis (sats) and V_O.program, which incorporates a multi-signature and a conditional transfer value hash (CTVHASH) indicating the kickoff condition. Following this, the Tx Kickoff transaction takes place, accepting V_O as its input and generating outputs like R[0] set to a minimal value (dust) and V_K, which holds a certain number of sats without specifying a program, thus setting up for subsequent updates.

For updates, Tx Update[i] transactions are structured with a two-week sequence, taking V_K as inputs and resulting in outputs divided between parties (Alice and Bob) based on a predefined key N. These transactions involve MUON X_i, ensuring that any spend must be exited through the protocol. Parallelly, Tx Ratchet i transactions are designed to facilitate the progression from one update to the next by using a locktime mechanism and generating a new R[i+1] with each iteration, incorporating a program that supports both ratcheting and cospend paths.

Finally, the Tx Exit transaction marks the end of the cycle with a minimum sequence time of one day, requiring inputs from the last Ratchet and MUON X_i transactions. Its output includes an OP_RETURN command and details necessary for reconstructing muon X_i.program, reinforcing the non-malleable nature of the transaction updates by ensuring no update can proceed without the correct recursive proofs being established within R.

This entire process underscores the importance of MUON in maintaining transactional integrity, through a sophisticated setup of inputs, outputs, and programmable conditions that collectively prevent unauthorized or maligned modifications to the transaction sequence. For further details on the interplay of MUON within these transactions, Jeremy Rubin's insights can be explored through the provided link.

Bitcoin Logo

TLDR

Join Our Newsletter

We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.

Explore all Products

ChatBTC imageBitcoin searchBitcoin TranscriptsSaving SatoshiBitcoin Transcripts Review
Built with 🧡 by the Bitcoin Dev Project
View our public visitor count

We'd love to hear your feedback on this project?

Give Feedback