Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 36DE0C03 for ; Thu, 23 May 2019 19:22:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9531983A for ; Thu, 23 May 2019 19:22:02 +0000 (UTC) Received: by mail-ot1-f41.google.com with SMTP id r7so6495405otn.6 for ; Thu, 23 May 2019 12:22:02 -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 :cc; bh=yhaMG80hJG6VQGwhNG35wZoY4k7Kj6UfRIAZP19/Bes=; b=e5cGEmsoCM+FmP7/sUKpagjNUaMZgWqaisDfOh4B/dTltmt1RpgtDoqCmIs8dDYVow QBGmEq2dMmfuJJ5Yo3sqTD/m6ax0w06TQdevl8G3YtIKLMbyxIO9ijMcVf1LmTWNOBan srWH8Q8ohcu6LwC4mSIrM5i10NP4bmHNbibLLDKT0RXftmlgORTauvE0+oYdwVaVa2V4 uRnnF2Xgg1/B4c+tQ5mM5Vi06JKUI2Z9PMi9n/yxzal9MtliLKxlogUtkIoGuQ+5oVPH i8/nfwQypQdr92kRql/r70W8e/rPOdGmu1AN8HwnL02OMcVckb/0mC6mlBipbqwfv8WI sKsg== 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:cc; bh=yhaMG80hJG6VQGwhNG35wZoY4k7Kj6UfRIAZP19/Bes=; b=Tm/DinLPWMLXHaUxHZATh2L35llIcKQ6J7sK1Fx22ycHP8MtmfHPU5SE8EL4tpclpB 79NCaWjCuAsSqSQLOufkJWxR62Xhib9DwvgG+kDITv8id/TZuRwx/ingkO51o64ZZPqk v2o3geQtECO4RTcAC/Q/dFXXZuyKmEpidBNUuweF4VvcFkD1RSRSDthouZZHWZgzGgmK j5izoD5zWTKpxu4BbXv6h2dQty6TxHZDqgY/dQqtOlrASC0FN8pVlJZz4Xwnp5kLFvpv fcxPgnTcRV4iDIW8rVJ+/LDAQrB00W8RseYuQfZvX7upZUrEjTo07aa9R9xfT8p4/ZsB /4NA== X-Gm-Message-State: APjAAAWCoFKM8hV1wykkFfG+KrO2gyMJ5teRXJm170MYYowoqYEajB/J jzsMBmDVVnrKD3YBIqbqjnWmmM4AvUzxGQD3Sko= X-Google-Smtp-Source: APXvYqw5fr5oE7HkIuZG3IANBeYdwFp6gabIccjh6EvvixgE11fGBBpo1B+3gJKvWM4GgOsgJ0mudxXtkrAT49egz4Y= X-Received: by 2002:a9d:5f04:: with SMTP id f4mr68537oti.240.1558639321669; Thu, 23 May 2019 12:22:01 -0700 (PDT) MIME-Version: 1.0 References: <42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com> In-Reply-To: From: Nathan Cook Date: Thu, 23 May 2019 22:21:39 +0300 Message-ID: To: Tamas Blummer Content-Type: multipart/alternative; boundary="00000000000019e2a8058992ffa7" 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:22:48 +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:22:03 -0000 --00000000000019e2a8058992ffa7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. Nathan Cook 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 o= f > the header. > > On May 23, 2019, at 21:05, Nathan Cook wrote: > > You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luk= e > 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/01= 3149.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 ther= eby >> introduce the biggest risk while considering an investment. >> Commodity markets offer futures and options to hedge risks on traditiona= l >> 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 blo= ck >> 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 ris= k >> 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 >> > > --00000000000019e2a8058992ffa7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's true that it fetches the block h= ash; the idea is to compare the block hash's numeric value to the desir= ed (uncompressed) difficulty directly, using a 256-bit version of OP_LESSTH= AN.

Na= than Cook


On Thu, 23 May 2019 at 22:18, Tamas Blummer <tamas.blummer@gm= ail.com> wrote:
That opcode would not help as it fetches block hash and no= t the content of the header.

O= n May 23, 2019, at 21:05, Nathan Cook <nathan.cook@gmail.com> wrote:

You can get the same effect with OP_CHECKBLOCKA= THEIGHT as proposed by Luke Dashjr (https://github.com/= luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki) if you also re-enable/ex= tend certain opcodes like OP_AND and OP_LESSTHAN. See=C2=A0https://lists.linuxfoundation.org/pipermail/bitcoin-d= ev/2016-September/013149.html=C2=A0and the ensuing thread.

Na= than 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 big= gest 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

--00000000000019e2a8058992ffa7--