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 AADECF58 for ; Thu, 23 May 2019 19:45:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 235FD821 for ; Thu, 23 May 2019 19:45:50 +0000 (UTC) Received: by mail-oi1-f169.google.com with SMTP id w9so5291877oic.9 for ; Thu, 23 May 2019 12:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=iRD/rumXY6Km6gazx4y83mQsQVienDPSax0A68Pgx+c=; b=A4/adCC7oXUSyLuBrgqaOqGzjI8Slp/WYLbPgr26Q9MKCZsz88gWwF4KLxwnz0CEhQ 7YQe5MfWy6n0UPtnzTOIyqXMvm4ZcMb7o10KuR8dg542sleugLo0ork1kku8fGpTjHeu xO7wG8FtoNz/giLvfNibgEEs9gpWUi579NQ8KlNxkLZ09jA/AeDRuRrRIO3NX94ccVZe 9mSwj/WUfdDA5Jl+Rl8BNaG1dvyf3Oy3jgJstyZ5RF1AtNmUYAgw3loSmp1SObf7VEOf uLQbXK62Ve3QeKp6CJPVQD3H/M4PaxP4JEm18bSd/qXv6yE3phCcUQdSA1ki8eWT0Oau dLaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=iRD/rumXY6Km6gazx4y83mQsQVienDPSax0A68Pgx+c=; b=D4tB2Wl0nextwrS38GK+7McORoVsI1nPnneRktK+csbh0+93IoRTeLJxTBzxirmQ/w VgX9e6/ZxSwKuENvJICOPxO0yCADFZCUkokSDA0XGokBRKrFwyzJYNwLyKdxUURqvg3t I37qh0BsFWwjNdD8x1qMSDeI/jLiuX2LMfM5B3c3UcBmQlZMVO0b3sKFo0AMSse2ZKmp CaEpHuSHYZJs4c6y4sVPGySZmjl0JgPNiEbj2yIBsNioKSor3GgDkoiu6wv3CxkMs7hs dVCPyefH5FxFOVQE/RyxyMePGdEazKw4TQSsfLQQi8/BOQ7FQsQZA2O9IJvHXteWyKd5 hXxw== X-Gm-Message-State: APjAAAUQRfW4Hn6KaSCVK9J0v6Wt3OIbGg4D7ns715IiOvTAqQ2MUr+v Foc/txaGEFwR6oCSIFrI4kjXMMI+o8VK6nm+Pm8= X-Google-Smtp-Source: APXvYqz6ww1tziRQQazSOtCgL60XPMRtie5r7Rhh9B4EVFTOmrlh9GMdCf5YqAzPsoHk8QX7bpaPg65jgTzJvf4EmXA= X-Received: by 2002:a05:6808:98a:: with SMTP id a10mr69317oic.57.1558640749923; Thu, 23 May 2019 12:45:49 -0700 (PDT) MIME-Version: 1.0 References: <42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com> In-Reply-To: <42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com> From: Pieter Wuille Date: Thu, 23 May 2019 12:45:37 -0700 Message-ID: To: Tamas Blummer , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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:45:51 -0000 On Thu, 23 May 2019 at 11:33, Tamas Blummer via bitcoin-dev 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 block = in the future. > A new OP_DIFFICULTY opcode would put onto stack the value of difficulty f= or 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 ent= ered the bet. > The winner would broadcast. 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. 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). 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. I don't have a strong opinion either way on the usefulness of having difficulty-dependent transaction/scripts. Cheers, --=20 Pieter