Author: Pieter Wuille 2019-05-23 19:45:37
Published on: 2019-05-23T19:45:37+00:00
In a recent message on bitcoin-dev, Tamas Blummer discussed the impact of difficulty changes on miners' production and how it creates the biggest risk when considering investment. He suggested that Bitcoin could do much better than traditional trading venues that offer futures and options to hedge risks in commodity markets. A possible solution would be a transaction that uses nLocktime denominated in block height, which is valid after the difficulty-adjusted block in the future. To implement this, a new OP_DIFFICULTY opcode would put onto stack the value of difficulty for the block the transaction is included in. However, if the difficulty can be directly observed by the script language, there would be complications in implementing mempools and reasoning about the validity of unconfirmed transactions. To solve this problem, similar constructions are needed for observing block difficulty as for observing block time/height. One way to achieve this is to have an opcode that "posts" an assertion (e.g. "difficulty at block height X is at least Y") as a side effect of execution instead of putting the difficulty on the stack. Alternatively, the assertion could be part of the transaction structure, and an opcode could observe the difficulty assertion inside script. The supported assertions should also be restricted in such a way that they are true within a particular block and any descendant, removing the complexity of reasoning about validity. Pieter Wuille, who wrote the message, does not have a strong opinion on the usefulness of having difficulty-dependent transactions/scripts.
Updated on: 2023-05-20T20:31:30.625862+00:00