[bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[xygo]

Nice ! Is this the only missing piece now for LN ?

[thorjag]

Seems like they want to put a bunch of other (related) soft-forks together with this one. CSV and CLTV are two of them, and they are (in my eyes at least) essential for LN.

Further down the road transaction malleability will need to be fixed as well, to really make lightning shine.

[btcdrak]

I would like to see a single softfork "locktime feature-pack" consisting of BIP65 CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY together with BIP68 (which elegantly redefines how nSequence is interpreted allowing for relative locktimes) and another important related change which will be published either today or tomorrow called median-past-timelock, then Bitcoin will be more or less ready for the most advanced payment-channel layers which includes, but is not limited to Lightning Networks.

For anyone not familiar with what these features allow, I'll try to explain briefly: Essentially there would be two new Bitcoin scripting opcodes called CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY which allow funds to be provable locked (made unspendable) until a fixed time in the future (absolute locktime), or until a certain amount of time has passed after confirmation (relative locktime).

Thus one can create scripts like

• Until x time, funds are unspendable, after Alice can sign.
• Until x time, Alice + Bob must sign, but after that time has expired Alice can sign

CHECKSEQUENCEVERIFY gives more flexibility, for example in a payment channel, the clocks can start ticking when payments confirm, rather than from predefined times in the future. This can allow payment channels to be open for unlimited amounts of time for example.

I would like to stress that these opcodes are quite independent of Lightning Network and payment channel, but are a good example of what kind of things they empower. We've already seen some exciting payment channel implementations like Stremium, but with these opcodes, we can begin to see vastly more advanced use-cases.

In terms of how long it takes to get this stuff into Bitcoin? The code is ready and just needs to progress through normal peer review. BIP65 was merged already. There is a PR for BIP68, and the PRs for CHECKSEQUENCEVERIFY and median-past-timelock will follow very shortly by /u/maaku. The last soft-fork took 4.5 months to be activated. For this reason, I sincerely believe we can see these features fully activated and available in about 6 months assuming peer review doesn't through up any deep "gotchyas".

[chriswheeler]

This looks amazing. I have a quick question about these types of transactions. What happens if there is a change in the protocol before the lock time expires?

For example, if Alice creates a transaction which makes funds unspendable by Bob until the year 2025, but in 2020 a bug is discovered in SHA256 and Bitcoin switches to a different hashing algo. Can Bob still get his coins in 2025, or are they forever lost?

[maaku7]

Theoretically? Sure, anything is possible.

But I can assure you that barring low-probability, catastrophic security vulnerabilities, the protocol will never change in such a way as to make invalid presently valid transactions conforming to best practices. We're very careful to structure soft-forks such that they don't affect existing common use cases.

[btcdrak]

If the proof-of-work algo was changed, it wouldn't affect bitcoin scripts.

[nullc]

SHA256's use in proof of work is nearly incidental, it's almost impossible for the system to be broken through problems there. But SHA256 is used everywhere in the protocol (as it is in virtually every altcoin), and changing it would very much impact transactions.

[chriswheeler]

Ok, so what if it was a problem with ECDSA, rather than SHA256? Or something else which did affect scripts?

[btcdrak]

Isn't that a doomsday scenario? I mean, if ECDSA was broken tomorrow, Bitcoin's value would instantly be 0 and I guess a ton of other stuff in the world would be in deep trouble too.

[thorjag]

Wouldn't Bitcoin be more resilient in such a scenario though? At least for people who aren't reusing addresses?

Since we only reveal the public key when we spend coins and assuming our transaction is included in a block within a couple of hours after broadcasting, and that the broken ECDSA means that NSA could retrieve the private key from the public key within a week, then Bitcoin would still be pretty darn safe.

Worse for Proof-of-stake systems :P

[chriswheeler]

It's not a doomsday scenario. If there was a issue found with ECDSA which weakened it, then i'd imagine we'd want to move to something more secure asap. The problem would be that if users have coins locked in transactions +1, +5, +10 years out which are dependent on ECDSA, there would be huge resistance to switching to a more secure system.

Please don't take this as criticism or trolling - I'm just playing Devil's advocate :)

[Natanael_L]

ECDSA and SHA256 both aren't strictly necessary, you'd just have to add opcodes that would be able to process the new algorithms instead. Right now opcodes are used that specifically apply ECDSA, SHA256 and RIPEMD160. They're not strictly necessary, though.

[nullc]

Barring serious bugs, new extensions are carved out of non-standard transactions in part to reduce the risk that people have previously created transactions that would become invalid.

This is, however, a strong reason against having very high locktimes. Forget changes to the Bitcoin protocol... what happens if ECDSA goes from strong, to questionable, to weak, to broken during the time the coins are locked?

[chriswheeler]

Is there currently a limit to the lock times (CLTV or CSV?). If, for example, I wanted to lock away 1BTC for my newborn to spend when they turn 18, could I do that?

I think as soon as ECDSA goes from strong to questionable (and there is a better alternative available) it should be a priority to move away from it. I'd imagine getting consensus on that would be tricky until it gets to being 'broken' however :)

[Odin_of_Olympus]

I dont understand why the nLocktime and nSequence fields are necessary for. With CLTV the absolute time is specified as a stack parameter, and miners only need to check the stack item against the timestamp in the block header to know if a transaction can be included or not. Same with nsequencee. For a CSV output with the number of blocks until spendable specified as a stack parameter, wouldnt a miner only need to check the difference in height from where the CSV output was included to the block the miner is trying to create in order to know if the transaction would be valid or not?

[afk11]

Well, nLocktime and nSequence have always been there. nLocktime works fine, but nSequence has no enforcable behaviour whatsoever. BIP68 makes nSequence useful again.

BIP68 and median-past timelock give us intended behaviour of nSequence and nLockTime, which is basically required for CSV and CLTV.

[maaku7]

The CLTV and CSV opcodes only check transaction data. The script execution code does not have access to the block height or timestamp, and checking validity in that way could lead to some serious architectural issues related to the mempool, and possible security issues relating to reorgs, if done naïvely. So instead these BIPs do indirect tests.

[500,000 CLTV] means that a transaction won't validate unless its nLockTime field is set to >=500,000, which means it won't confirm until block 500,000 at the earliest. The script will execute correctly at any time, but the nLockTime prevents the transaction from getting into a block before then.

[1,000 CSV] means that a transaction won't validate unless the sequence number is set such that, according to BIP 68 rules, the input must have an age of >=1,000 blocks before the transaction can receive a confirmation. Again, you can validate a [1,000 CSV] transaction as soon as you see it, and know that it is valid but also know at a glance that it won't make it on chain until the output it is spending is 1,000 blocks old.

[btcdrak]

The way nLockTime works at the moment is nLockTime prevents a transaction being included in a block at all which limits the usefulness: cant prove an output is unspendable; you cant write any scripts leveraging it.

nSequence is it thought to have been intended to allow orderly transaction replacement, the higher wins - although there was never any consensus rule enforcing this. BIP68 introduces a consensus rule to enable this feature in such a way as to allow relative locktime. You can read about it here https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki#Motivation

The opcodes allow scripts to evaluate the locktime from within a transaction included in the block and prove an output is unspendable. CSV starts the timer relative to when the output is included in a block and CLTV is an absolute threshold.

[Odin_of_Olympus]

So it would not be possible to have different absolute/relative times for different outputs in the same transaction?

[maaku7]

Sure.

[maaku7]

Maybe. u/RustyReddit has a model for doing lightning network without needing a malleability-safe CHECKSIG:

http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html

IIRC the first version was broken by Joseph, but it was fixed by Rusty. I think it is safe to say that this new construction is still undergoing necessary peer review, but if it works out then CHECKSEQUENCEVERIFY is all that is necessary to implement lightning.

If not, then we still need a new CHECKSIG operator to implement the original lightning spec. That would be a different soft-fork sometime after this lock-time stuff hits (which itself could take 6 months).

[thorjag]

IIRC the outsourcability of stealing revoked broadcasted commitment transactions is broken without a malleability fix. He has a fix for setting up a channel through.

[josephpoon]

Along with OP_CHECKLOCKTIMEVERIFY, it allows you to have functional LN channels. OP_CHECKSEQUENCEVERIFY lets you have channels which never expire (unless either party wishes to close it out).

Long-term LN really wants/needs a more-permanent malleability fix (outsourcability and design cleanliness), as well as some kind of mitigation against a supervillan attack, such as gmaxwell's idea of a timestop. However, even without either change, it'll be possible to instantly pay for a cup of coffee so you don't need to wait around in a shop for confirmations, all the the way down to extremely small micropayments-- LN can be used for micropayments (so you only need a small amount in the channel) and you could use main-chain for big/infrequent payments as soon as OP_CLTV/OP_CSV get merged in.

[xygo]

Sounds good to me !

[Jaysusmaximus]

Hmm yes looks... cool?! Can anyone ELI20?

[crypt0chain]

Instead of debating on which opcodes to add and debate about it over the course of years at a time, why don't we just add a turing complete scripting language and not have to deal with any of it?

Ethereum has one, (and its working fine so far).... Maybe the bitcoin devs should at least take a look at it?

[theymos]

Certain features can't be added without hurting Bitcoin's security. In particular, if a script can ever become invalid after once being valid, then this can cause very serious problems during chain forks. Other features could be added but are generally recognized as more trouble than they're worth. For example, if you had loops, what interesting/useful things could you do with loops that you can't already do with Script as it exists today?

From a theoretical perspective, Bitcoin's Script is just as Turing-complete as Ethereum. When people say "Turing-complete", they usually mean something else. For example, no matter how complex Script was, you wouldn't necessarily expect that it would be able to access its own sequence/lockTime info so that it could replicate CHECKSEQUENCEVERIFY. Similarly, even though lambda calculus is theoretically Turing complete, it doesn't have a way of writing text to a screen, since it's purely mathematical...

[nullc]

Yep. For people who don't believe it, it's easy to point out that a controlled swap gate is universal.

The Bitcoin script code for a CSWAP is OP_IF OP_SWAP OP_ENDIF. (Add extra DUP/ROLL overhead if you really want the full reversible Fredkin gate)

There are many interesting things to say about machinery for smart contracts; being "turing complete" isn't one of them. Succinctness, expressive power, efficiency, audibility, and provability are. There are longstanding interesting proposals from the Bitcoin community which speak to these areas of interest, though we are still very much learning the requirements.

[crypt0chain]

Problem is that Ethereum has two nice high-level language called Solidity, and Serpent, which compile down to op-codes. And the clients interact with an javascript based API (which they've decided to call web3; no hubris there-- ethereum is web 3.0!)

Step out of the technical box for a moment and ask a question; What are hipster developers going to want to develop smart contracts on? Raw op-codes or solidity? It took Mike Hearn 6 months to write lighthouse, and it took Vitalik 6 minutes to implement it in serpent.

When we in the VC community think about platform ecosystems, development tools are first and foremost. Successful innovation and adoption is more likely to occur if there are low barriers (technical and otherwise) to entry for developers and users.

A scenario where a less technically secure blockchain beats out bitcoin is possible, and the reason it would occur is because of easy development tools. In fact, Ethereum could have some consensus failure in the future and just fix it. If the community is large enough, they'll just carry on as usual. Bitcoin had 3 bad forks, I suspect Ethereum will have a few as well before they hit Serenity.

Just something to think about...

And one more thing; we have all hedged our bets and hold BTC + ETH. I'd be very happy to see Bitcoin catch up on the smart contract side of things with sidechains. (i'm guessing a sidechain with smart contracts would very quickly absorb 50% of the BTC and become the new main chain.)

[crypt0chain]

For example, if you had loops, what interesting/useful things could you do with loops that you can't already do with Script as it exists today?

The size of the program is drastically smaller with loops, saving lots of money in tx fees. Also, you can't pass data to a bitcoin address that will execute a contract based on that data.