I think this violates the unspoken but strict no-reevaluation policy of op codes. The value of this changes depending on blockchain state, specifically reorgs.
That means every transaction using this or descended from a transaction using this has to be re-evaluated continuously. That’s no bueno for scaling.
Or have I missed something?
You’re correct, but you did miss that we have a class of outputs that “violate” it: coinbase outputs & their descendants.
This is why we have the maturity coinbase rule: they’re unspendable before they mature, so it can’t really happen that their validity changes as it would require a 100-deep reorg.
This is why the idea here is to push / verify only the matured headers. If it’s not matured yet, the opcode would fail and TX would be invalid. Once it would become valid - it would become due to header becoming mature, and flipping back to invalid would require 100-deep reorg.
Some of the functionality is possible in a roundabout way btw: convince some hash-rate to include a covenant as a coinbase output, such that requires CashTokens genesis and allows anyone to clone NFTs. Each such NFT would have categoryID of a coinbase TX, and “unpacking” the hash would reveal the coinbase TX. From there, the user could extract the height + add the other merkle node hash and verify it against a header produced by a chain of covenants. This could pin the height, but I think it’d still allow alternative covenant states by replaying the same coinbase TX on an alternative chain so still we can’t 100% prove a header to some contract.
Side-note, this high-level idea would allow Drivechain-like hash-rate voting:
Hashrate would opt in by using a simple one-time vote covenant (OTVC) address that requires bridge DAO input as sibling.
Bridge DAO could then burn and tally these one-time vote covenants and accumulate them in NFT’s commitment. By “unpacking” the TXID of the vote covenant’s input, the DAO can verify the vote is indeed coming from a coinbase TX, and extract the height from the input to verify belongs in the voting window.
I guess so. Same order of magnitude issue as checking descendants of coinbase.
Flipping back to immature requires “only” a reorg of m blocks replacing n, where m<n, right? Not 100. I don’t know how / how efficiently nodes handle that.
It’s a nice idea. It would be nice to have for a very slow-reacting chainwork oracle which could potentially be incredibly valuable.
Indeed, I have encountered the same problem when designing OP_LOTTERY [temp name].
To prevent infinite reevaluation due to reorgs, the 100-block maturity rule has to be used there as well.
Oh yeah you’re right, wait but how do nodes handle the same happening to coinbase outputs? I’d guess that once it becomes mature it’s considered mature even if one block gets popped. The hypothetical opcode should behave the same. Once the TX using it becomes 100 deep, it’s considered valid even if some reorg should happen to shorten the chain and make it 99 deep.
I think the “unspoken” rule does not apply on reorgs, on reorgs we pull all transactions out of the mempool then try to reapply them.
But I still think the “unspoken” rule would apply for this op code, because you could code something like this into the contract
require(int(OP_BLOCKHASHMATURED) < 2^10)
so all mempool transactions (with the opcode) would need to be reevaluated when a new tip appears
I think there are 2 thresholds for coinbase outputs. The output is spendable after 100 blocks, but clients don’t actually add the transactions to the memory pool until 120 blocks have passed.
Essentially, the protocol rule is 100 blocks, but the mining node rule is 120 blocks.
That way a re-evaluation would only need to occur if a 20 block re-org happened.
A re-org could also cause transactions with locktime to have to be evicted from the memory pool, so the client must have some way to handle that too. Those transactions would be spendable eventually though, so removal but keeping them in a pending store, or similar.