MIME-Version: 1.0
References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
	<42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com>
	<CAPg+sBged=ivVLj9tAM6zZdvWdYnG5pj4gozac5EupFPLtwyfA@mail.gmail.com>
In-Reply-To: <CAPg+sBged=ivVLj9tAM6zZdvWdYnG5pj4gozac5EupFPLtwyfA@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
Date: Fri, 24 May 2019 10:36:14 +0200
Message-ID: <CAAt2M1_PKnJ5tR3VHgUg-=ibNVVp-Yocqa9KeUQhVj0X2PstGA@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000963cfd05899e181c"
Subject: Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets)
 without an oracle and 3rd party.
Precedence: list

--000000000000963cfd05899e181c
Content-Type: text/plain; charset="UTF-8"

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

--000000000000963cfd05899e181c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, May 23, 2019 at 9:58 PM Pieter Wu=
ille via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If t=
he difficulty can be directly observed by the script language, you<br>
would need to re-evaluate all scripts in unconfirmed transactions<br>
whenever the difficulty changes. This complicates implementation of<br>
mempools, but it also makes reasoning about validity of (chains of)<br>
unconfirmed transactions harder, as an unconfirmed predecessor may<br>
have conditions that change over time.</blockquote><div><br></div><div>To d=
eal with potentially wildly varying difficulty, could the value exposed be =
the sum of accumulated PoW, or in other words the sum of each block&#39;s d=
ifficulty 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).</div><div><br></div><div>This mimics=
 the effect of the block number which only grows. So if you&#39;re starting=
 at time A with difficulty X, then you&#39;d estimate what you think the ac=
cumulated 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.</div>=
</div></div>

--000000000000963cfd05899e181c--