From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5F4ECF58 for ; Thu, 23 May 2019 19:54:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BB69D6C5 for ; Thu, 23 May 2019 19:54:48 +0000 (UTC) Received: by mail-wr1-f52.google.com with SMTP id d18so7570198wrs.5 for ; Thu, 23 May 2019 12:54:48 -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=JZdOcsx/F3e/goXVhqUG0L7jTgUGZgiV027lVw84QIQ=; b=MdseNGNN14dyMyP2S18yUsXpDAj7Z10GQRsO/O8jErhLWpgoL8HOvOm3CcWxmXisaJ cNa671dUEGTQcSLPaN/vg73wo/sG6VWj/soa3GWiwoBzroCuyxa4FKbsDAPVzL73INCp 24ArjF/QVZVL2gEwxWxIaiy6t58PAyAlnpJc3Bywht9lMUYojuuRoTLOnPbHRckQ/HA4 iw7ryxKZhUzFidf2/150Dbd3oyPTzlcLXRCa/0oobXi2eBwVSad5HZJB3xoksSR1yfSy eRJK4SmODce7W/U3jtEjSkeJesZSbiHqGWGInsvd/D1Pp+ZajObjD/RvNXS8AvJIhsba 4IYA== 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=JZdOcsx/F3e/goXVhqUG0L7jTgUGZgiV027lVw84QIQ=; b=Kn58uLXcY6oj5JA0W8IiUWOHsxhIyS3rL+fThBbZQ3X4O4pS9se8CXr48AVfvNnBaz eLsLI/sOhHvHDTIx5p/OItDglUgilEP4ZgEBALxv4DDQlfSw7EoAzs+MxUi4vG4ADMCU jYZpdh5/iHXWRcuvJtcZt5l17E0wY/8RQU6qkWKw7krQXk+U5lf4ZwfSqXPlxIvEShTK jU/nuMM0OHxddA458rU79mjMB56b3ztTZm/wTE20FeVFW/dct72hS12P+73+eNABM3Vu j83nvYmkwL/boq8BSd37TCQoCyeJ9hNOzxE1SveSI4j+BvS41bGqn7afvwcMgpfAyy3l Zzag== X-Gm-Message-State: APjAAAV4Nj1zH5pyIROIrQNcttK1B/ZcmrWF9avikfczuHb+iMtY/LxE sx95RXpCxxg4LbCzJz6+Gm8= X-Google-Smtp-Source: APXvYqxgwknkgow4/3byCX0s7ay79sA30JF2ckFZUlA6rni4RvOMmUS1R4ucREIhorqrSq4R5pZewA== X-Received: by 2002:adf:cf0c:: with SMTP id o12mr52461069wrj.182.1558641287411; Thu, 23 May 2019 12:54:47 -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 o8sm139407wrx.50.2019.05.23.12.54.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 May 2019 12:54:46 -0700 (PDT) From: Tamas Blummer Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6003DAEB-20B2-46A2-BBCD-F6C46C9BC731"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 23 May 2019 21:54:43 +0200 In-Reply-To: <09724852-6971-4E5A-AAB5-3FBAEEA1D995@gmail.com> To: Nathan Cook References: <42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com> <09724852-6971-4E5A-AAB5-3FBAEEA1D995@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, 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:57:54 +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:54:49 -0000 --Apple-Mail=_6003DAEB-20B2-46A2-BBCD-F6C46C9BC731 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Block hash can suggest much higher difficulty than what is in effect, so = OP_CHECKBLOCKATHEIGHT would not work to decide if difficulty is above = the level of the bet. > On May 23, 2019, at 21:45, Tamas Blummer = wrote: >=20 > I see. The uncompressing needs to be done either to compare. How are = chances for that BIP? >=20 > This BIP would be explicitly offering risk managment of miners biggest = risk. > Doing so without relying on external markets or oracle, self = cointained would be an impressive and adequate feature. >=20 > Tamas Blummer >=20 >> On May 23, 2019, at 21:21, Nathan Cook wrote: >>=20 >> It's true that it fetches the block hash; the idea is to compare the = block hash's numeric value to the desired (uncompressed) difficulty = directly, using a 256-bit version of OP_LESSTHAN. >>=20 >> Nathan Cook >>=20 >>=20 >> On Thu, 23 May 2019 at 22:18, Tamas Blummer = wrote: >> That opcode would not help as it fetches block hash and not the = content of the header. >>=20 >>> 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 >>=20 >=20 --Apple-Mail=_6003DAEB-20B2-46A2-BBCD-F6C46C9BC731 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----- iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAlzm+oMACgkQ9nKRxRdx ORws9wf9Hl5Za/aLc7afInndiCl4ykLhHp9gG0xLz2rRIiOcwXYVy+YDmqPy6cbx TNy5yRjgLsHkW0hHWOd0tH74Vuz+agkRdDB3HCh+O7fx/gHJ4F98dJreiQ5VGitG PPtCM08HFfwyKjgAUnA2mU/07H0kxTENeKp95WnfHlN64Z3Z+KLL9DcA5Mlwj2jw 1045Pbq7umhADEg6k3poXEiHunz6vcbBAxlyp62YqUeBeFNUKWnsPh3Snfnf7gv6 brAD9ne1XLVS5bptZHYAZti4EvEozQsCELMr/zc2y8YtecFzEEMvuCV21d6qF85N 1XyZ0TRMnrV2DWsjJmHVDrGx7aOxxw== =ckXh -----END PGP SIGNATURE----- --Apple-Mail=_6003DAEB-20B2-46A2-BBCD-F6C46C9BC731--