Author: Nathan Cook 2019-05-23 20:07:30
Published on: 2019-05-23T20:07:30+00:00
Tamas Blummer has proposed a new opcode, OP_DIFFICULTY, that would put onto the stack the value of difficulty for the block the transaction is included into. He suggests using a transaction that uses nLocktime denominated in block height, such that it is valid after the difficulty adjusted block in the future. The output script may then decide 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. The winner would broadcast. The proposal is aimed at serving significant economic interest of Bitcoin economy and is compatible with Bitcoin's aim not to introduce 3rd party to do so. Tamas plans to draft a BIP for this. Difficulty change has profound impact on miner's production thereby introducing the biggest risk while considering an investment. Commodity markets offer futures and options to hedge risks on traditional trading venues. However, some might soon list difficulty futures. OP_CHECKBLOCKATHEIGHT was suggested by Nathan Cook as a solution to compare the block hash's numeric value to the desired (uncompressed) difficulty directly, using a 256-bit version of OP_LESSTHAN. Tamas points out that the opcode would not help as it fetches block hash and not the content of the header. Block hash can suggest much higher difficulty than what is in effect, so OP_CHECKBLOCKATHEIGHT would not work to decide if difficulty is above the level of the bet. To compare two compressed difficulties directly, more bit masking is required to separate the exponent and mantissa.
Updated on: 2023-06-13T19:06:02.197711+00:00