yes, log2work is already computed and would be a strictly increasing value, like time. Thank you for this suggestion. I think attempting an implementation will give further clues it this more suitable to express the same.
Tamas Blummer > On May 24, 2019, at 10:36, Natanael <[email protected]> wrote: > > On Thu, May 23, 2019 at 9:58 PM Pieter Wuille via bitcoin-dev > <[email protected] > <mailto:[email protected]>> wrote: > 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. > > To deal with potentially wildly varying difficulty, could the value exposed > be the sum of accumulated PoW, or in other words the sum of each block's > difficulty value in the entire chain? This should be a value that will only > rise unless a reorg happens after a difficulty drop happens (only likely to > be the result of users manually blacklisting an otherwise valid block that is > several blocks back in the chain). > > This mimics the effect of the block number which only grows. So if you're > starting at time A with difficulty X, then you'd estimate what you think the > accumulated PoW ought to be at time B with expected difficulty Y (as compared > to the current value at time A), and put that value into the script.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
