Op_get_current_block_height

Hello There

I want to open a discussion on a new op code that retrieves current block height from the global state.

We do have CheckLockTimeVerify and CheckSequenceVerify. Both need block height or block timestamp to operate. And I know these two op codes have a certain characteristic. Once they will become valid in the chain. Their validity does not need verification on the next block.

Now the question is. Does bitcoin’s current implementation takes advantage of this behavior to operate, Meaning once the transaction becomes valid it will no longer check for validity on the next block. If so the implementation of the new opcode will become a big hassle.

Why this opcode is a great thing to have?

At the moment AnyHedge contracts cannot get settled at every block until the contract time is over. With the help of an opcode that retrieves current block height this will be possible to do.

For example lets say we are at block height 501 and the data from OP_CHECKDATASIG shows the price of the hedged asset at block 500. Then we construct a script that will only be valid in that particular block height.

I’ve studied bitcoin code a few years ago. I’m not clueless. But I’d be happy to get educated on this concept.

Please let me know what you think. Is this something bitcoin engine can handle?

Any opcode that can result in an already admitted tx being evicted from mempool again, for any reason other than fees and congestion, will be terrible for scaling (you’ll have to reprocess the entire mempool every block), and so are unlikely to be adopted. It’s the same reason why CLTV can only do “valid after”, but not “valid before”.

Too bad.

Mempool is not part of the consensus rules. A better solution may render it as obsolete.

I really liked this ability. Imagine being able to settle contracts at any time without the need to trust the other peer.

Here’s another idea for accomplishing the same task.

If we can access the block height for parent transaction. This can be done. How is that?

The parent transaction should have a particular characteristic. It will only be spendable when it has been included in a block.

What do you think im_uname?