Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 918EEF0C for ; Thu, 23 May 2019 19:05:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0E8047FB for ; Thu, 23 May 2019 19:05:23 +0000 (UTC) Received: by mail-oi1-f172.google.com with SMTP id u199so5206667oie.5 for ; Thu, 23 May 2019 12:05:23 -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; bh=LCjjjizwY5WHHsFxwS4sNF2O0aCJC4gT8fo6WBs+SLQ=; b=NanHQeQulHv2oAi8b/mSYpx3JIm09KgKATGHKDBQ5/qX44DdblWDopPcwbAN4bJuS5 JNrXmq4XI6SZqIeToR5m5mDyjINi3y84J57/B2gOfC+uPo/7rTcwn9iGthIWefa24OBg B0hjODUTtX9YvWVz7Q/wCbCVETCerLBzQxCEiwXw+1utk2pMRS3Jo9xN07kq6OtKb/0J OoJ03d5q89L3d511tqJnJYTFU2EeoQyvkEx1TImdrBmqMGH6GU144/BmKGS8PRBkVvug RXUp0rvY6eUjHY2iWATZ8j9Pm9JMi3QsmuPEzXX9ygifbfdnNaEEQSU1Kvd8sgguPHkv TzWA== 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; bh=LCjjjizwY5WHHsFxwS4sNF2O0aCJC4gT8fo6WBs+SLQ=; b=OpJnSL3dM8nKhSAlWR5i1+YIVtcc4iJs/tA8t3hoRmz3nftkunvEYkRAYSPLopLYi8 5dpXEsQPFXpUgnNhg0mucPQMzzRyMbOsIWFs1oi2wnu1lcx8CawYmPpw4/YBcwAGh1RX CAaXzTJhXbKwFf7Rh5cjh78uFTsWGQgZ8Uxzg3RCFEegvWXUr3nCkp8iDPi+y4sWRKFC Tx84qT3fx51mAN6E4G+OSpFPsjYc6RwNmNThk4GF6e9QbIZP3G3ViXfKw56w2wf/X+pW JX7aFrlPW99yY93d8Pnj5QiuMHdC1bGyAi4V5+NJJII17ZLGYLV8hEQKAc0D/ZSp9xe0 parQ== X-Gm-Message-State: APjAAAUHnlgaLcTYPTOiTTruy7iLb8f4YXA586K/W7n9ZwU+un3AwYHS XU4rj6XEa6vJZM1LZAN3/0b+iaH9uEll9WuBUIg= X-Google-Smtp-Source: APXvYqwgE0mo0iXbAnbzS2sjiajrAbl2rP2XpSrvTif7HCUmiDZrIIV2E9eZJuYh3iH+Owop0ZTDCLTGFoy3LfhEQbg= X-Received: by 2002:aca:5209:: with SMTP id g9mr89370oib.35.1558638322901; Thu, 23 May 2019 12:05:22 -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: Nathan Cook Date: Thu, 23 May 2019 22:05:02 +0300 Message-ID: To: Tamas Blummer , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000091e78b058992c308" 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:06:44 +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:05:24 -0000 --00000000000091e78b058992c308 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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/0131= 49.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 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 bloc= k > 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 whic= h > 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 > --00000000000091e78b058992c308 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You can get the same effect with OP_CHECKBLOCKATHEIGHT as = proposed by Luke Dashjr (https://github.com/luke-jr/bip= s/blob/bip-cbah/bip-cbah.mediawiki) if you also re-enable/extend certai= n opcodes like OP_AND and OP_LESSTHAN. See=C2=A0https:/= /lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html= =C2=A0and the ensuing thread.

Nathan Cook


<= div class=3D"gmail_quote">
On Thu, 23 = May 2019 at 21:33, Tamas Blummer via bitcoin-dev <bitcoin-dev@lists.linu= xfoundation.org> wrote:
Difficulty change has profound impact on miner=E2=80=99s pro= duction thereby introduce the biggest risk while considering an investment.=
Commodity markets offer futures and options to hedge risks on traditional t= rading 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 enter= ed the bet.
The winner would broadcast.

Once signed by both the transaction would not carry any counterparty risk a= nd 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 significa= nt 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/mail= man/listinfo/bitcoin-dev
--00000000000091e78b058992c308--