Author: Tamas Blummer 2019-05-23 20:26:49
Published on: 2019-05-23T20:26:49+00:00
During a discussion on bitcoin-dev, Tamas Blummer suggested that the introduction of futures and options to hedge risks on traditional trading venues could soon be listed for difficulty changes. He proposed that Bitcoin could do better than commodity markets by devising a transaction using nLocktime denominated in block height, which is valid after the difficulty adjusted block in the future. A new OP_DIFFICULTY opcode would be put onto the stack with the value of difficulty for the block the transaction is included into. The output script may then decide by comparing that value with a strike which key can spend it. The input of the transaction would be a multi-sig escrow of those who entered the bet. Pieter Wuille responded to this suggestion with concerns about the implementation of mempools and the reasoning about the validity of (chains of) unconfirmed transactions if the difficulty can be directly observed by the script language. He believes a similar construction is needed for observing block difficulty, either by having an opcode that posts an assertion or having the assertion be part of the transaction structure. This way, script validity is a single context-free yes or no that can be evaluated once, and the variable part is just transaction-level reasoning that doesn't involve a full script interpreter. Finally, Pieter stated that he does not have a strong opinion on the usefulness of having difficulty-dependent transaction/scripts.
Updated on: 2023-06-13T19:04:25.390369+00:00