Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CFF6DF4B for ; 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 ; Thu, 23 May 2019 19:18:10 +0000 (UTC) Received: by mail-wr1-f41.google.com with SMTP id f8so7501249wrt.1 for ; 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 Message-Id: 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: To: Nathan Cook References: <42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 = ) 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 = and the ensuing thread. >=20 > Nathan Cook >=20 >=20 > On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev = > 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 = > 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
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:

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.mediawik= i) if you also re-enable/extend certain opcodes like OP_AND and = OP_LESSTHAN. See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-Se= ptember/013149.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 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=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<= /a>

= --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--