Bitcoin Forum

I heard about relative CLTV in the context of the lightning network. Can someone explain how it works and how it allows payment channels to stay open without settling them on the blockchain? I understand how normal CLTV works.

Trying with a bump.

It has the benefit of not requiring someone to know exactly when a transaction is included in a block.  Channels could be left open for longer.

Imagine Bob signs the inputs to a transaction which pays to the following output and sends it to Alice.

Input: Must be signed by Alice & Bob
Signature: Just Bob's

Output:

Alice can sign the transaction and submit it, but Bob can't.  If Alice submits the transaction, then she can spend the output after 200 blocks have passed.  Bob can't spend the 2nd branch of the if, since it is a 2 of 2 multisig.

Alice can "cancel" the transaction by giving Bob the private key matching her public key 2.

This doesn't actually cancel the transaction.  Alice can still submit it and it will be accepted by the network.  The point is that if she does, she can't spend it for 200 blocks. 

Since Alice gave Bob her private key 2, he has the 2 private keys for the 2nd branch of the if.  This means that he can spend the output immediately.

By giving Bob the key, Alice is saying "I promise not to submit the transaction, but if I do, you can take all the money".

This cancel scheme (or maybe something similar) is used by the Lightening network system.

Cool! Thanks for the answer. Have some bits.

Is this OP_RELATIVECHECKLOCKTIMEVERIFY a new op code and is it designed to basically replace nLockTime?

Peter Todd is proposing OP_CHECKLOCKTIMEVERIFY as a new opcode and the relative version was been considered too.

The locktime field is still kept.  OP_CHECKLOCKTIMEVERIFY just compares against the locktime.

If you have

400,000 OP_CHECKLOCKTIMEVERIFY

That means "Don't include this in a block unless the transaction's locktime is at least 400000".  There is already a rule that says that you can't include a transaction with a locktime of 400000 until block 400000 already.

This means that the transaction can be tested without needing to know what block it is in.

For example, if the block had two inputs which scriptPubKeys of

"400,000 OP_CHECKLOCKTIMEVERIFY"

"410,000 OP_CHECKLOCKTIMEVERIFY"

and the transaction had a locktime of 420000, then this transaction is valid.

"400,000 OP_CHECKLOCKTIMEVERIFY" means "verify the locktime at the transaction is least 400000"

"410,000 OP_CHECKLOCKTIMEVERIFY" means "verify the locktime of the transaction is at least 410000"

This is true in both cases, so the transction could be included one block 420000 is reached (since that is its locktime).

By checking against locktime, and still using locktime to prevent the transaction getting into a block, it means you don't have to keep checking the tranasction.

If OP_CHECKLOCKTIMEVERIFY checked the block height directly, then the transactions would need to be checked after every block is created.

So a tx that uses these new op codes (assuming both are adopted) will still be "non-standard" if the nLockTime is in the future?

A transaction with a locktime is the future cannot be included in a block.  It makes the block invalid. 

The opcode looks the transactions locktime field, rather than looking at the block height.

The relative version would have to look at the block height though.

I understand that but am just wondering if the tx will be relayed (my understanding is that currently txs that have future nLockTime values are not relayed to prevent attacks).

Right, transactions aren't relayed until they are spendable as they are relayed when added to the memory pool. 

The transaction with the OP_CHECKLOCKTIMEVERIFY in the output would be relayed, since it doesn't have a locktime at all.

The spending transaction would be relayed as long as the locktime has arrived, or the transaction doesn't use the branch of the if that contains the OP_CHECKTIMEVERIFY.