From: Tamas Blummer <tamas.blummer@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 23 May 2019 19:42:35 +0200
References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
Message-Id: <42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com>
Subject: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets)
 without an oracle and 3rd party.
Precedence: list

Difficulty change has profound impact on miner=E2=80=99s production =
thereby 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 =
for the block the transaction is included into.=20
The output script may then decide comparing that value with a strike =
which key can spend it.=20
The input of the transaction would be a multi-sig escrow of those who =
entered the bet.=20
The winner would broadcast.=20

Once signed by both the transaction would not carry any counterparty =
risk and would not need an oracle to settle according to the bet.

I plan to draft a BIP for this as I think this opcode would serve =
significant economic interest of Bitcoin economy, and is compatible with =
Bitcoin=E2=80=99s aim not to introduce 3rd party to do so.

Do you see a fault in this proposal or want to contribute?

Tamas Blummer=20