MIME-Version: 1.0
References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
	<42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com>
In-Reply-To: <42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Thu, 23 May 2019 12:45:37 -0700
Message-ID: <CAPg+sBged=ivVLj9tAM6zZdvWdYnG5pj4gozac5EupFPLtwyfA@mail.gmail.com>
To: Tamas Blummer <tamas.blummer@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets)
 without an oracle and 3rd party.
Precedence: list

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=E2=80=99s production there=
by 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 f=
or the block the transaction is included into.
> The output script may then decide comparing that value with a strike whic=
h key can spend it.
> The input of the transaction would be a multi-sig escrow of those who ent=
ered 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.

I don't have a strong opinion either way on the usefulness of having
difficulty-dependent transaction/scripts.

Cheers,

--=20
Pieter