1

The locktime opcodes OP_CHECKLOCKTIMEVERIFYand OP_CHECKSEQUENCEVERIFY indirectly allow for an approximate block number check, is there any way to obtain other information such as the previously mined block hash or current difficulty without having to rely on oracles?

Improve this question

1 Answer 1

Reset to default
3

No, by design.

Script evaluation gives an unconditional boolean output: valid or invalid. If script validation could depend on context, that would mean script validity would need to be re-evaluated any time that context changes, complicating reasoning about mempool transactions, the meaning of confirmations, as well just generally causing significant CPU cost to nodes that keep unconfirmed transactions around.

Note that neither OP_CHECKLOCKTIMEVERIFY or OP_CHECKSEQUENCEVERIFY actually let scripts depend on height/time information; they only depend on the locktime/height that's in the transaction itself. Validation of those locktime fields happens outside of script, which does mean that while transaction validity isn't entirely context-free (it can't be, because double-spending!), script validation never needs to be rerun.

Improve this answer
11
  • What do you mean context changes? The context are the already confirmed blocks (aside from temporary forks) and the script validation would only require to take that into consideration in an immutable way
    – Tobias Kienzler
    Commented Feb 27 at 8:50
  • Confirmed blocks can change, that is context, as it is not committed to by the transaction itself. If there was some mechanism for transactions (not scripts) to only be valid in a chain which has a block with a specified hash as ancestor, then information about that block and its ancestry could in theory be made available to the script interpreter too.
    – Pieter Wuille
    Commented Feb 27 at 17:55
  • I'm sorry but I don't understand what you mean, how can a confirmed block change? That would modify (and thus invalidate) its hash after all, so I assume you're meaning something different than I do?
    – Tobias Kienzler
    Commented Feb 27 at 17:57
  • 1
    @TobiasKienzler Both. Script validation is performed when the transaction is relayed across the network already (before being included in a block), and its validity is cached. When transactions are seen in blocks, the scripts are validated again (but the already validated ones can just use the cached value). If all you care about is block validity, then the context is fixed and these concerns matter less. But the network needs to be able to reason about transaction validity before being included in blocks too (how do miners know what to include? what transactions can be built on by wallets?)
    – Pieter Wuille
    Commented Feb 28 at 7:03
  • 1
    @TobiasKienzler None of this means that context dependence is impossible - it just has to be designed such that script doesn't see it. After all, this has already happened with OP_CHECKLOCKTIMEVERIFY etc., by having an indirection through a constraint on the transaction outside of script (nLockTime for OP_CLTV, nSequence for OP_CSV). As a mentioned higher up, it would for example be possible to have a "mandatory block hash" field in transaction, making the transaction only valid in a chain descending from the specified hash, and then make properties of that block available to script.
    – Pieter Wuille
    Commented Feb 29 at 8:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.