RSM Contracts

Bitcoin has contracts, it always did. A contract is just a small script (program) that gets executed when an output is being spent.
The spender must provide an input for the script (contract), then the script is executed, if it returns TRUE, then the UTXO can be spent, otherwise it cannot.

A contract is usually (but not always) agreed between two parties. The party that spends the funds (Alice) and the party that receives the funds (Bob).

A Revocable Sequence Maturity Contract (RSMC) has two main characteristics:

1. it can be spent by the owner (Alice) only after it has reached maturity (some time has passed)
2. it can be spent immediately by the other party (Bob) if he previously obtained from Alice a Revocation Key

The reason for a Contract (C1) to be revocable is that the two parties negotiate and agree on a new Contract (C2). As part of the negotiation they want to cancel the effects of the old contract. Bob cannot simply trust that Alice will delete the old transaction (where she has more funds) and that she will never broadcast it. Instead Bob asks for a Revocation Key that will allow him to penalize Alice if she breaks the deal and tries to enforce the deprecated contract (C1) on the main-chain.

Commitment Transactions

RSM Contracts are useful for the construction of payment channels in Lightning Network. In a payment channel, the two parties make bidirectional payments and update the balance multiple times using what is called Commitment Transactions. Each time the balance is updated, the old state (old Commitment Transaction) must be revoked. Commitment Transactions are intended for off-chain use (second layer), but they can be broadcast to the main-chain if one of the parties desires so.

When a new Commitment Transaction is agreed then the old Commitment Transaction must be Revoked

A Commitment Transaction:

• spends from a 2–of-2 multisig (wrapped in a P2WSH), therefore it requires signatures from both parties (Alice and Bob) in order to unlock the funds
• sends funds to both participants (except when the amount is below the dust limit)

Commitment Transaction

This is from the BOLT 03 specification for Commitment Transaction Outputs:

To allow an opportunity for penalty transactions, in case of a revoked commitment transaction, all outputs that return funds to the owner of the commitment transaction (a.k.a. the “local node”) must be delayed for to_self_delay blocks.

A RSM Contract is what allows the “opportunity for penalty transactions, in case of a revoked commitment transaction”. The flow for a RSM Contract is of this form:

Alice (the owner) is delayed in getting the funds, giving Bob time to penalize her if he has a Revocation Key

Alice is the Owner

What exactly does it mean that “Alice is the owner” and why isn’t Bob also the owner since he is part of this transaction too?

Alice can call herself the owner of the Commitment Transaction if she has received from Bob a signature that allows her to spend the Input(s) of this transaction. Remember that the Commitment Transactions spend from a 2-of-2 multisig (wrapped in a P2WSH). The party that is able to broadcast the Commitment Transaction is considered the owner.

Bob is not able to spend the Inputs for the Commitment Transaction since he does not have Alice’s signature. He is not the owner.

But Bob has the Revocation Key

What does it mean that “Bob has the Revocation Key” and how comes he can use it, but Alice cannot? The code inside “Pay Bob” box is (was):

2 <AlicePublicKey01> <BobPublicKey01> 2 OP_CHECKMULTISIG

For details on OP_CHECKMULTISIG you can read more here and here.

Alice has the AlicePrivateKey01 that corresponds to AlicePublicKey01.
Bob has the BobPrivateKey01 that corresponds to BobPublicKey01.
Signatures from both Private Keys are required in order to pass the multisig check.

When the two parties agree to revoke the current Commitment Transaction, Alice gives Bob the Private Key (AlicePrivateKey01) that corresponds to AlicePublicKey01. Now we can say that “Bob has the Revocation Key”. Alice cannot spend the funds using the “Pay Bob” box since she does not know Bob’s Private Key (BobPrivateKey01).

Long Story Short

Alice can broadcast, but Bob can revoke.
Alice cannot revoke and Bob cannot broadcast.

Revocation Improvements

The initial Lighting Network Paper specified a 2-of-2 multisig as the revocation mechanism. However, it was later replaced with a more efficient technique that uses elliptic curve point multiplication. The updated version is of the form:

<revocationpubkey> OP_CHECKSIG

where

revocationpubkey = AlicePublicKey01 + BobPublicKey01

You can find more details here on the Revocation — Keys and More Keys section.

Script

The Bitcoin Script for the RSM Contract is quite simple, and it is easy to observe the two possible paths:

OP_IF
    <revocationpubkey>
OP_ELSE
    `to_self_delay` OP_CHECKSEQUENCEVERIFY OP_DROP
    <local_delayedpubkey>
OP_ENDIF
OP_CHECKSIG

The revoke path has just a public key (revocationpubkey).
The maturity path uses the OP_CHECKSEQUENCEVERIFY operator to check if sufficient time has passed, hence the “Sequence Maturity” part of the RSMC name.

At the end, an OP_CHECKSIG is performed either against <revocationpubkey> or against <local_delayedpubkey> depending on the taken path. The updated diagram looks like this:

For details on OP_CHECKSEQUENCEVERIFY you can read more here and here.

Spending the Output

As specified in the BOLT 03 spec:

The output is spent by an input with nSequence field set to to_self_delay (which can only be valid after that duration has passed) and witness:

<local_delayedsig> <>

If a revoked commitment transaction is published, the other party can spend this output immediately with the following witness:

<revocation_sig> 1

Final Note

When we say that an Output that pays Alice is restricted by a RSM Contract it means that:

• Alice is the owner of the Commitment Transaction and she can broadcast it
• Alice can only spend the funds after a certain period (maturity)
• Alice can revoke the Commitment Transaction by offering Bob a Revocation Key
• Alice can be penalized (lose the funds) if she tries to spend a revoked transaction

Notes and References