Tamas Blummer [ARCHIVE] on Nostr: 📅 Original date posted:2019-05-24 📝 Original message:yes, log2work is already ...
📅 Original date posted:2019-05-24
📝 Original message: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 <natanael.l at gmail.com> wrote:
>
> On Thu, May 23, 2019 at 9:58 PM Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190524/5d92fa56/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190524/5d92fa56/attachment.sig>;
📝 Original message: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 <natanael.l at gmail.com> wrote:
>
> On Thu, May 23, 2019 at 9:58 PM Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190524/5d92fa56/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190524/5d92fa56/attachment.sig>;