On Thu, 23 May 2019 at 11:33, Tamas Blummer via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > > Difficulty change has profound impact on miner’s production thereby introduce > the biggest risk while considering an investment. > Commodity markets offer futures and options to hedge risks on traditional > trading venues. Some might soon list difficulty futures. > > I think we could do much better than them natively within Bitcoin. > > A better solution could be a transaction that uses nLocktime denominated in > block height, such that it is valid after the difficulty adjusted block in > the future. > A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for > the block the transaction is included into. > 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.
If the difficulty can be directly observed by the script language, you would need to re-evaluate all scripts in unconfirmed transactions whenever the difficulty changes. This complicates implementation of mempools, but it also makes reasoning about validity of (chains of) unconfirmed transactions harder, as an unconfirmed predecessor may have conditions that change over time. For things like block time/height, this is solved by not having the script itself observe the context state directly, but instead having an assertion on the state outside of script (nLockTime for absolute time/height and nSequence for relative), and then having opcodes inside script that observe the assertion (OP_CLTV and OP_CSV). By doing so, script validity is a single context-free yes or not that can be evaluated once, and the variable part is just transaction-level reasoning that doesn't involve a full script interpreter. Additionally, the supported assertions are restricted in such a way that if they are true within a particular block, they're also true in any descendant, removing the complexity of reasoning about validity (apart from the inevitable reasoning about possible double-spend before confirmation). I feel a similar construction is needed for observing block difficulty. This can be done by either having an opcode that as a side effect of execution "posts" an assertion (e.g. "difficulty at block height X is at least Y"), instead of putting the difficulty on the stack. An alternative is having the assertion be part of the transaction structure (for example in the annex we propose in bip-taproot), and having an opcode that observes the difficulty assertion inside script. I don't have a strong opinion either way on the usefulness of having difficulty-dependent transaction/scripts. Cheers, -- Pieter _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
