Author: Nathan Cook 2019-05-23 19:21:39
Published on: 2019-05-23T19:21:39+00:00
On the Bitcoin-dev mailing list, Tamas Blummer proposed a new opcode called OP_DIFFICULTY that would put the value of difficulty for the block the transaction is included into on the stack. He suggested that this could be used to create 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, and once signed by both parties, the transaction would not carry any counterparty risk and would not need an oracle to settle according to the bet. This proposal would serve significant economic interest of Bitcoin economy, and is compatible with Bitcoin’s aim not to introduce 3rd party to do so.Nathan Cook responded to Tamas Blummer's proposal, suggesting that another way to achieve a similar effect would be to use OP_CHECKBLOCKATHEIGHT as proposed by Luke Dashjr, along with re-enabling/extending certain opcodes like OP_AND and OP_LESSTHAN. Cook also provided links to relevant discussions on the topic.However, Blummer pointed out that the proposed opcode OP_LESSTHAN would not work as it fetches block hash and not the content of the header. He emphasized the importance of finding a better solution than traditional commodity markets' futures and options to hedge risks associated with difficulty changes, which have a profound impact on miner’s production and introduce the biggest risk while considering an investment.Blummer plans to draft a BIP for his proposal and invited others to contribute or point out faults in the proposal.
Updated on: 2023-06-13T19:06:30.027777+00:00