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: Nathan Cook <nathan.cook@gmail.com>
Date: Thu, 23 May 2019 22:05:02 +0300
Message-ID: <CAGNXQMTLjkC+i7YcVyWC0Z0ixTkwhYR2qF4R0qeMNTT4ntj9oQ@mail.gmail.com>
To: Tamas Blummer <tamas.blummer@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000091e78b058992c308"
Subject: Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets)
 without an oracle and 3rd party.
Precedence: list

--00000000000091e78b058992c308
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke
Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki)
if you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN.
See
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/0131=
49.html
and
the ensuing thread.

Nathan Cook


On Thu, 23 May 2019 at 21: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 bloc=
k
> 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 whic=
h
> 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=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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">You can get the same effect with OP_CHECKBLOCKATHEIGHT as =
proposed by Luke Dashjr (<a href=3D"https://github.com/luke-jr/bips/blob/bi=
p-cbah/bip-cbah.mediawiki" target=3D"_blank">https://github.com/luke-jr/bip=
s/blob/bip-cbah/bip-cbah.mediawiki</a>) if you also re-enable/extend certai=
n opcodes like OP_AND and OP_LESSTHAN. See=C2=A0<a href=3D"https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html">https:/=
/lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html=
</a>=C2=A0and the ensuing thread.<div><br clear=3D"all"><div><div dir=3D"lt=
r" class=3D"m_403880825204588202m_-2348348040253356886gmail_signature" data=
-smartmail=3D"gmail_signature">Nathan Cook</div></div><br></div></div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, 23 =
May 2019 at 21:33, Tamas Blummer via bitcoin-dev &lt;<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linu=
xfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">Difficulty change has profound impact on miner=E2=80=99s pro=
duction thereby introduce the biggest risk while considering an investment.=
<br>
Commodity markets offer futures and options to hedge risks on traditional t=
rading venues. Some might soon list difficulty futures.<br>
<br>
I think we could do much better than them natively within Bitcoin.<br>
<br>
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.<br>
A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for=
 the block the transaction is included into. <br>
The output script may then decide comparing that value with a strike which =
key can spend it. <br>
The input of the transaction would be a multi-sig escrow of those who enter=
ed the bet. <br>
The winner would broadcast. <br>
<br>
Once signed by both the transaction would not carry any counterparty risk a=
nd would not need an oracle to settle according to the bet.<br>
<br>
I plan to draft a BIP for this as I think this opcode would serve significa=
nt economic interest of Bitcoin economy, and is compatible with Bitcoin=E2=
=80=99s aim not to introduce 3rd party to do so.<br>
<br>
Do you see a fault in this proposal or want to contribute?<br>
<br>
Tamas Blummer <br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000091e78b058992c308--