Return-Path: <tamas.blummer@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CFF6DF4B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 May 2019 19:18:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com
	[209.85.221.41])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 048006C5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 May 2019 19:18:10 +0000 (UTC)
Received: by mail-wr1-f41.google.com with SMTP id f8so7501249wrt.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 May 2019 12:18:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=from:message-id:mime-version:subject:date:in-reply-to:cc:to
	:references; bh=PMaoad+7z6M55I+D3h9Utyhc5tUtIqj690CnI3YAAQY=;
	b=T3GCLcI7jze+No48ekqiFJIpIY7KVmcUZ/dkeu+2IiAFkQg0+Y97mgWmccSP464wuc
	m0STUUTQlZ3v/Y259/baqVtMiLIJ4N6g7WmcdVy09kUQEHi2Ye4vkT+8fUOGe5sfpWzH
	oKDXqx7NmpPzSwwK7yU/OM1qXkA+E8qqKR1odVwhLJT8ORlbJB3Us+emXygaP5TRMO/o
	uoCbt1nJpiegwOdxTmAL/snEBzUgxhLtdDgHPIEBdJnHjtPyBSb1cj4yPsaU7aE/Wh3O
	kyZ1pDJA6xr2DwDUMC4fM5n3hY577+r78sLtLgxBsGuuT+fL4upFem8m6Bm0AcAbEaH7
	Avvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:from:message-id:mime-version:subject:date
	:in-reply-to:cc:to:references;
	bh=PMaoad+7z6M55I+D3h9Utyhc5tUtIqj690CnI3YAAQY=;
	b=Lkw7tOpvuSsiXcfti+VjgQANhA8PHB2deBFwgzBiQoC4yTgkefqz8gDynbwhPWXlht
	1zuyIdIDrvcUYp1tae/N2pHxalZPjytRH4iBEsF/Be5sSEfR8cMrWZ0bqWTwE8CIt8iT
	sI6oEPVWNFL0svgvgbRCE2U4+Uh69gdfOAmZ0iT/VLlzsRsJk6EF1Fk6DsFQWXFcSdx+
	NsqgH9cnXdEZgVq8l40q+y66+JaUPSgmdS1mXz7gPcQPT9xv+9JU100favOfjh5gYc0h
	q2Vuu2HrrAWLaResAU8WrC1AP2NeJcp2AX1hC3h4N6rhFfjByQD9xCR24S4ojgv5Ca1p
	WTlg==
X-Gm-Message-State: APjAAAXg6l5fPgfXH8i0IfYw3TOtw9oHpGCv+My1gcIc2sRGbIb+hcPA
	6PeMqyhmzXLpXxfwnW9L3bM=
X-Google-Smtp-Source: APXvYqyc0jd0zZFAJt7IGn1CctcIdKGT4zukPlBMcnVcv5xpwxoVLcpazXR3hjDOy5zvZs3ygeEHWQ==
X-Received: by 2002:a5d:4109:: with SMTP id l9mr39052637wrp.204.1558639089613; 
	Thu, 23 May 2019 12:18:09 -0700 (PDT)
Received: from p200300dd67196b11c120770d4d53396f.dip0.t-ipconnect.de
	(p200300DD67196B11C120770D4D53396F.dip0.t-ipconnect.de.
	[2003:dd:6719:6b11:c120:770d:4d53:396f])
	by smtp.gmail.com with ESMTPSA id
	g185sm239235wmf.30.2019.05.23.12.18.08
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 23 May 2019 12:18:08 -0700 (PDT)
From: Tamas Blummer <tamas.blummer@gmail.com>
Message-Id: <C6788578-80D4-44E7-8CF7-82AD15E3F12C@gmail.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_7B697A29-5C77-475C-8946-268A2A770519";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 23 May 2019 21:18:06 +0200
In-Reply-To: <CAGNXQMTLjkC+i7YcVyWC0Z0ixTkwhYR2qF4R0qeMNTT4ntj9oQ@mail.gmail.com>
To: Nathan Cook <nathan.cook@gmail.com>
References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
	<42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com>
	<CAGNXQMTLjkC+i7YcVyWC0Z0ixTkwhYR2qF4R0qeMNTT4ntj9oQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 23 May 2019 19:19:23 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets)
 without an oracle and 3rd party.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 23 May 2019 19:18:11 -0000


--Apple-Mail=_7B697A29-5C77-475C-8946-268A2A770519
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F71135CE-75A2-4347-A9C9-B6CBB049574F"


--Apple-Mail=_F71135CE-75A2-4347-A9C9-B6CBB049574F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

That opcode would not help as it fetches block hash and not the content =
of the header.

> On May 23, 2019, at 21:05, Nathan Cook <nathan.cook@gmail.com> wrote:
>=20
> 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 =
<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/013=
149.html =
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/01=
3149.html> and the ensuing thread.
>=20
> Nathan Cook
>=20
>=20
> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 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.
>=20
> I think we could do much better than them natively within Bitcoin.
>=20
> 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.
>=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.
>=20
> 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.
>=20
> Do you see a fault in this proposal or want to contribute?
>=20
> Tamas Blummer
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>


--Apple-Mail=_F71135CE-75A2-4347-A9C9-B6CBB049574F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D"">That opcode would not help as it fetches =
block hash and not the content of the header.</div><br =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
May 23, 2019, at 21:05, Nathan Cook &lt;<a =
href=3D"mailto:nathan.cook@gmail.com" =
class=3D"">nathan.cook@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D"">You can get the same effect with OP_CHECKBLOCKATHEIGHT as =
proposed by Luke Dashjr (<a =
href=3D"https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki" =
target=3D"_blank" =
class=3D"">https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawik=
i</a>) if you also re-enable/extend certain opcodes like OP_AND and =
OP_LESSTHAN. See&nbsp;<a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-Septe=
mber/013149.html" =
class=3D"">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-Se=
ptember/013149.html</a>&nbsp;and the ensuing thread.<div class=3D""><br =
clear=3D"all" class=3D""><div class=3D""><div dir=3D"ltr" =
class=3D"m_403880825204588202m_-2348348040253356886gmail_signature" =
data-smartmail=3D"gmail_signature">Nathan Cook</div></div><br =
class=3D""></div></div><br class=3D""><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:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br =
class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">Difficulty change has profound impact =
on miner=E2=80=99s production thereby introduce the biggest risk while =
considering an investment.<br class=3D"">
Commodity markets offer futures and options to hedge risks on =
traditional trading venues. Some might soon list difficulty futures.<br =
class=3D"">
<br class=3D"">
I think we could do much better than them natively within Bitcoin.<br =
class=3D"">
<br class=3D"">
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 class=3D"">
A new OP_DIFFICULTY opcode would put onto stack the value of difficulty =
for the block the transaction is included into. <br class=3D"">
The output script may then decide comparing that value with a strike =
which key can spend it. <br class=3D"">
The input of the transaction would be a multi-sig escrow of those who =
entered the bet. <br class=3D"">
The winner would broadcast. <br class=3D"">
<br class=3D"">
Once signed by both the transaction would not carry any counterparty =
risk and would not need an oracle to settle according to the bet.<br =
class=3D"">
<br class=3D"">
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.<br class=3D"">
<br class=3D"">
Do you see a fault in this proposal or want to contribute?<br class=3D"">
<br class=3D"">
Tamas Blummer <br class=3D"">
<br class=3D"">
_______________________________________________<br class=3D"">
bitcoin-dev mailing list<br class=3D"">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
 class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"=
 rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br class=3D"">
</blockquote></div>
</div></blockquote></div><br class=3D""></body></html>=

--Apple-Mail=_F71135CE-75A2-4347-A9C9-B6CBB049574F--

--Apple-Mail=_7B697A29-5C77-475C-8946-268A2A770519
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAlzm8e4ACgkQ9nKRxRdx
ORwogggAxR/l5L/EEY9cNtG9gpV0geVOzkyZdazKxrrObGyZOaZVarh+AkLZula8
FRfLqBYg8X0k0sxGRibxYpzx2XukGU/jNcYOBm4PY6GNfGH0TNxWVyBiZwieEMe0
wfNvanHEoCLzMvTCtwmXM75h+Ph4rnnULYUZbr/qVhnT1czDoBvBwEBpJyaY3wuB
/ankH3Xj4GYdNssH806mTv8UWXrI6RAV8Ua25TKzoh5okolvEAQ9FriAPG2DFT9q
cPCtlY/8AQu0IZfxtvBf6PI64hc9WSKH+61+OdiPxdw5Nuqxp8/rpF9zytxQ6duX
T8sxqcDCybs/vZvc8Vb5GGkWX2yXxA==
=M4JO
-----END PGP SIGNATURE-----

--Apple-Mail=_7B697A29-5C77-475C-8946-268A2A770519--