> On May 23, 2019, at 21:45, Pieter Wuille <pieter.wui...@gmail.com> wrote: > > 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.
Thanks for these suggestions I will follow up while preparing the BIP. > > I don't have a strong opinion either way on the usefulness of having > difficulty-dependent transaction/scripts. > This is the best reception I could have hoped for :) > Cheers, > > -- > Pieter
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
