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 002C2F10 for ; Thu, 23 May 2019 20:26:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 567C983A for ; Thu, 23 May 2019 20:26:55 +0000 (UTC) Received: by mail-wm1-f45.google.com with SMTP id c77so7156258wmd.1 for ; Thu, 23 May 2019 13:26:55 -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=n0WYodHlp+uLx7+PB4hhnAfo4n3UhqJPrv5aKN+RkLA=; b=klt5kXDFyFhIkM0BTrTnUe+DqWwoosorSXtaxd8qEoI8wxLELnyxJlGeJKmvYj5lzI IdpknvpsGZtOSUuKSiZ11IJIDPQHhtErBdzFSty59ctrYF7xpUhAyeC2K/qDYsiAGxhl hBY/H4aM7VK/gwc+koGo49PyPoqiQ5JOmsFGW7xyifcritmzODfCTgdkATuNgVD7Nl/4 MkK3FTPiP8FL0PQyRthJO4pGMyKZhJrx0hqiGHsPVeawkSz9UYyRudiXLQ6HaakZ+BNz mJpcynRwuWUfNE6Ngi5f0nCgMnUjyQME2/2FcP0br5+z41+8TUtQt99kToydphQYYqWo ohEw== 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=n0WYodHlp+uLx7+PB4hhnAfo4n3UhqJPrv5aKN+RkLA=; b=RFQFi1zekG/iZBh83vWlC30ZkUld6Jn5T8R7na3CMefxsP52tFo57bpuiCSpgatCMq E32H8+4kBaVaxxgP8qIQ1tVA0DRcA4xUA3bCJXMQpMn+6HFFppRflrRwqoCyS0EtZRgO NarOod0aIXgMo7WKjiIw85qxXPT6+AVfSGrPVrmzPUHsglRKCdN4xWnm31x65WnHGdYw vAY5Gj9gB1pCWeoMt0FrcWRDjKFIHGoCQzBZTucfnTWEnTLmlfe+idTNI5wPOtR3bLl4 y+pdg31MPs0SwwuRqMIS9KjrW82qvAoVx9IDoStR02MruhAM7YU2iO+ikoc7cCUctinW DZZw== X-Gm-Message-State: APjAAAW3GqS4eesMxT0F2MfK9e4aOVFDBiRyiYuEsMbO0QLuRXi78geH GQJWTRfJuGifshwD4vXeIEs= X-Google-Smtp-Source: APXvYqzofabWcJEhLEGnIQMzucuXaXM71jaQ54shDbfvoqOptbxIFBnH9dXQ5Aa0ouLNG8Vfvj7keA== X-Received: by 2002:a7b:ce1a:: with SMTP id m26mr12297015wmc.137.1558643213957; Thu, 23 May 2019 13:26:53 -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 o8sm184769wrx.50.2019.05.23.13.26.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 May 2019 13:26:53 -0700 (PDT) From: Tamas Blummer Message-Id: <8870AC4C-B5E4-491C-8973-8962DEBD39CE@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7F17239D-5AE2-459C-AE09-9943EFE71A80"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 23 May 2019 22:26:49 +0200 In-Reply-To: To: Pieter Wuille 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, 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 20:29:27 +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 20:26:56 -0000 --Apple-Mail=_7F17239D-5AE2-459C-AE09-9943EFE71A80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 23, 2019, at 21:45, Pieter Wuille = wrote: >=20 > On Thu, 23 May 2019 at 11:33, Tamas Blummer via bitcoin-dev > wrote: >>=20 >> 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 > If the difficulty can be directly observed by the script language, you > would need to re-evaluate all scripts in unconfirmed transactions > whenever the difficulty changes. This complicates implementation of > mempools, but it also makes reasoning about validity of (chains of) > unconfirmed transactions harder, as an unconfirmed predecessor may > have conditions that change over time. >=20 > For things like block time/height, this is solved by not having the > script itself observe the context state directly, but instead having > an assertion on the state outside of script (nLockTime for absolute > time/height and nSequence for relative), and then having opcodes > inside script that observe the assertion (OP_CLTV and OP_CSV). By > doing so, script validity is a single context-free yes or not that can > be evaluated once, and the variable part is just transaction-level > reasoning that doesn't involve a full script interpreter. > Additionally, the supported assertions are restricted in such a way > that if they are true within a particular block, they're also true in > any descendant, removing the complexity of reasoning about validity > (apart from the inevitable reasoning about possible double-spend > before confirmation). >=20 > I feel a similar construction is needed for observing block > difficulty. This can be done by either having an opcode that as a side > effect of execution "posts" an assertion (e.g. "difficulty at block > height X is at least Y"), instead of putting the difficulty on the > stack. An alternative is having the assertion be part of the > transaction structure (for example in the annex we propose in > bip-taproot), and having an opcode that observes the difficulty > assertion inside script. Thanks for these suggestions I will follow up while preparing the BIP. >=20 > I don't have a strong opinion either way on the usefulness of having > difficulty-dependent transaction/scripts. >=20 This is the best reception I could have hoped for :) > Cheers, >=20 > -- > Pieter --Apple-Mail=_7F17239D-5AE2-459C-AE09-9943EFE71A80 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----- iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAlznAgoACgkQ9nKRxRdx ORy8zAf/YVsBFCLraoMx8gid3xqdsdv0upBdj6tv9bIYonwEdjlUNorHJDvQD6Pm 0L7xrm8cNcY1kc350y+fAdnIhfA1CS/zKuCCwNeFch4Uf189Q5WrfXVrP/zLYW24 a6eKfkhWW0Rf0pkyyFazU5qY5Fk3Vw490ExuKhSMRmtYYH3Rvei21tEw3HK6NuNK mbqevrD7nOmny62ApbTOaUYzf+jHrX4henai8xLzkEMoPaVF/keXfeB1Q8pFkrPp tqJpl2rmdZsGHT6IGkAwO3xekebID2QHqWmuewD/w9ep0/cH1ODSCpIVA57fNAfC EytZyEbF4SUE2I06dSTJktk5EoPArQ== =qZJx -----END PGP SIGNATURE----- --Apple-Mail=_7F17239D-5AE2-459C-AE09-9943EFE71A80--