From: Tamas Blummer <tamas.blummer@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.
Date: Thu, 23 May 2019 19:42:35 +0200 [thread overview]
Message-ID: <42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com> (raw)
In-Reply-To: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
Difficulty change has profound impact on miner’s 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.
The output script may then decide comparing that value with a strike which key can spend it.
The input of the transaction would be a multi-sig escrow of those who entered the bet.
The winner would broadcast.
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’s aim not to introduce 3rd party to do so.
Do you see a fault in this proposal or want to contribute?
Tamas Blummer
next prev parent reply other threads:[~2019-05-23 17:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-20 20:58 [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal Jeremy
2019-05-21 19:41 ` Matt Corallo
2019-05-22 1:47 ` Jeremy
2019-05-22 2:51 ` ZmnSCPxj
2019-05-22 5:11 ` Jeremy
2019-05-22 6:04 ` ZmnSCPxj
2019-05-22 8:10 ` Jeremy
2019-05-23 3:45 ` ZmnSCPxj
2019-05-24 21:15 ` Jeremy
2019-05-25 3:56 ` ZmnSCPxj
2019-05-22 20:49 ` Anthony Towns
2019-05-23 17:42 ` Tamas Blummer [this message]
2019-05-23 19:03 ` [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party Jorge Timón
2019-05-23 19:10 ` Tamas Blummer
2019-05-23 19:05 ` Nathan Cook
2019-05-23 19:18 ` Tamas Blummer
2019-05-23 19:21 ` Nathan Cook
2019-05-23 19:45 ` Tamas Blummer
2019-05-23 19:54 ` Tamas Blummer
2019-05-23 20:07 ` Nathan Cook
2019-05-23 19:45 ` Pieter Wuille
2019-05-23 20:26 ` Tamas Blummer
2019-05-24 8:36 ` Natanael
2019-05-24 16:23 ` Tamas Blummer
2019-05-24 8:15 ` Johnson Lau
2019-05-24 19:12 ` [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal Johnson Lau
2019-05-24 20:36 ` Jeremy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com \
--to=tamas.blummer@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox