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 <> wrote:
> On Thu, May 23, 2019 at 9:58 PM Pieter Wuille via bitcoin-dev 
> < 
> <>> 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.

Attachment: signature.asc
Description: Message signed with OpenPGP

bitcoin-dev mailing list

Reply via email to