diff options
| author | Nathan Cook <nathan.cook@gmail.com> | 2019-05-23 23:07:30 +0300 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-05-23 20:07:50 +0000 |
| commit | bee04f727c534e8b19fb973bc9a46a6eb51b79c4 (patch) | |
| tree | c65906b1a226bfd32fe6df7691e0c21ec823daec | |
| parent | bdade2e65172af39877bd64f772340e9e14fe64f (diff) | |
| download | pi-bitcoindev-bee04f727c534e8b19fb973bc9a46a6eb51b79c4.tar.gz pi-bitcoindev-bee04f727c534e8b19fb973bc9a46a6eb51b79c4.zip | |
Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.
| -rw-r--r-- | 52/1315288d4bffc9821d4b1a060b63fdbdd8da36 | 291 |
1 files changed, 291 insertions, 0 deletions
diff --git a/52/1315288d4bffc9821d4b1a060b63fdbdd8da36 b/52/1315288d4bffc9821d4b1a060b63fdbdd8da36 new file mode 100644 index 000000000..feb797e36 --- /dev/null +++ b/52/1315288d4bffc9821d4b1a060b63fdbdd8da36 @@ -0,0 +1,291 @@ +Return-Path: <nathan.cook@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id D2C6EEE4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 23 May 2019 20:07:50 +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 A8D306C5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 23 May 2019 20:07:49 +0000 (UTC) +Received: by mail-ot1-f41.google.com with SMTP id g18so6584695otj.11 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 23 May 2019 13:07:49 -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=H+8q1EiMFEDvbKddQXIVGCxAjJu41HAm2k6U1hYL5tU=; + b=erS0D09CnXn79USHad29gLjTdbuWyC5XBI8k4o2hRWqfYdBJCqZWgHy9mhtGoezZbv + 6jFMHVc25smqlNqGo58TLTxoO5BN91dTZj6LlISnW9P99hgSkqwgw6YM/iSTF5KyMMLV + 5hiIVzpGNna+vz3IGJthjZxN31dYASYckZCd5LE9Ay/6yEePuWvdyXx3FmjW8nvSpUJa + e/ZFy6n9FSeh40QvNXa/gXKq2n/tan4Je1n5LgPFyievJIao4FdigVqBb1HZVNR5xBDB + sAXeUUq+SIT7n2NlZcInwd22cLYILvtEi0G96r5hociBytKk+UJ5EELVxhiukkfuP4Mz + yu9w== +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=H+8q1EiMFEDvbKddQXIVGCxAjJu41HAm2k6U1hYL5tU=; + b=Ecyv5rg4g33p7+VnZzKH29G3APAIlOoEI/XgNDvhWgfinT1qfI7dVH6jZFhqR5Soac + ARlfVN7+KKHH9OQFDCvltdpZLZzduF3kAB/ZIivuAQ9KwgdQLEBTyZClMk3CmgRDYgHa + /pOSDBJMIdyhA95uthg6KdRblsyDwo99TSQqftk9pYMGmR7gBCtMnE6djNNeuvBCkELx + S+0HadQjA12Jzt/51ZRCANqJjX8n0NReNhfEy77FYoWhzLM0FjRa/qcaH0Yy6XO1fuNM + HzzdLp7aBz/P1CT9+AZI+MjcD46OsivnmWbTcbOvcFQtwcAQIJwc/xi4H/Ss8Ebhr5Sd + F7cw== +X-Gm-Message-State: APjAAAWPrwqIMynQ8lK3AvWKxPW0yT6iixmPAzlsQFHnetOYEcYRLCcc + xuVYXS88IWR04WXlbuQNdBIpy6Nk6UzBGT8V7yAGXv2I +X-Google-Smtp-Source: APXvYqx0xpZZWTIery6Gc6c2NJr5inw5IHICsfyLCnRqkPIvC1q5OCiSBvXy8VfzFznckRkf6HT/KJvOTOwfNvozmYI= +X-Received: by 2002:a9d:d17:: with SMTP id 23mr24437513oti.122.1558642068713; + Thu, 23 May 2019 13:07:48 -0700 (PDT) +MIME-Version: 1.0 +References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com> + <42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com> + <CAGNXQMTLjkC+i7YcVyWC0Z0ixTkwhYR2qF4R0qeMNTT4ntj9oQ@mail.gmail.com> + <C6788578-80D4-44E7-8CF7-82AD15E3F12C@gmail.com> + <CAGNXQMQG4KwAohfENYuUW=uABGshbJMYmdb_71ZtByCuj=14bQ@mail.gmail.com> + <09724852-6971-4E5A-AAB5-3FBAEEA1D995@gmail.com> + <FC1E77CA-929C-40E1-A80E-ADC1CBD65A6E@gmail.com> +In-Reply-To: <FC1E77CA-929C-40E1-A80E-ADC1CBD65A6E@gmail.com> +From: Nathan Cook <nathan.cook@gmail.com> +Date: Thu, 23 May 2019 23:07:30 +0300 +Message-ID: <CAGNXQMQ9z4hOaZctVu6gR14yUd=JzxgyXcaxReYYRJdhauofOw@mail.gmail.com> +To: Tamas Blummer <tamas.blummer@gmail.com> +Content-Type: multipart/alternative; boundary="000000000000d675da058993a2df" +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 20:08:34 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Thu, 23 May 2019 20:07:50 -0000 + +--000000000000d675da058993a2df +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +You're right, I didn't remember the whole procedure. You provide the +80-byte header in the spend script, duplicate it on the stack, hash it, and +compare to what OP_CHECKBLOCKATHEIGHT gives you. Then you do bit masking on +the header with OP_AND to extract the difficulty. You can compare two +compressed difficulties directly by using more bit masking to separate the +exponent and mantissa. + +On Thu, 23 May 2019 at 22:54, Tamas Blummer <tamas.blummer@gmail.com> wrote= +: + +> 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 <tamas.blummer@gmail.com> +> wrote: +> > +> > I see. The uncompressing needs to be done either to compare. How are +> chances for that BIP? +> > +> > 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. +> > +> > Tamas Blummer +> > +> >> On May 23, 2019, at 21:21, Nathan Cook <nathan.cook@gmail.com> wrote: +> >> +> >> 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 <tamas.blummer@gmail.com> +> wrote: +> >> That opcode would not help as it fetches block hash and not the conten= +t +> of the header. +> >> +> >>> On May 23, 2019, at 21:05, Nathan Cook <nathan.cook@gmail.com> wrote: +> >>> +> >>> 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/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 t= +hereby +> 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 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 +> 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 +> >> +> > +> +> + +--000000000000d675da058993a2df +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div dir=3D"ltr">You're right, I didn't remember t= +he whole procedure. You provide the 80-byte header in the spend script, dup= +licate it on the stack, hash it, and compare to what OP_CHECKBLOCKATHEIGHT = +gives you.=C2=A0Then you do bit masking on the header with OP_AND to extrac= +t the difficulty. You can compare two compressed difficulties directly by u= +sing more bit masking to separate the exponent and mantissa.<div><br></div>= +</div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On T= +hu, 23 May 2019 at 22:54, Tamas Blummer <<a href=3D"mailto:tamas.blummer= +@gmail.com">tamas.blummer@gmail.com</a>> wrote:<br></div><blockquote cla= +ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid = +rgb(204,204,204);padding-left:1ex">Block hash can suggest much higher diffi= +culty than what is in effect, so OP_CHECKBLOCKATHEIGHT would not work to de= +cide if difficulty is above the level of the bet.<br> +<br> +> On May 23, 2019, at 21:45, Tamas Blummer <<a href=3D"mailto:tamas.b= +lummer@gmail.com" target=3D"_blank">tamas.blummer@gmail.com</a>> wrote:<= +br> +> <br> +> I see. The uncompressing needs to be done either to compare. How are c= +hances for that BIP?<br> +> <br> +> This BIP would be explicitly offering risk managment of miners biggest= + risk.<br> +> Doing so without relying on external markets or oracle, self cointaine= +d would be an impressive and adequate feature.<br> +> <br> +> Tamas Blummer<br> +> <br> +>> On May 23, 2019, at 21:21, Nathan Cook <<a href=3D"mailto:natha= +n.cook@gmail.com" target=3D"_blank">nathan.cook@gmail.com</a>> wrote:<br= +> +>> <br> +>> It's true that it fetches the block hash; the idea is to compa= +re the block hash's numeric value to the desired (uncompressed) difficu= +lty directly, using a 256-bit version of OP_LESSTHAN.<br> +>> <br> +>> Nathan Cook<br> +>> <br> +>> <br> +>> On Thu, 23 May 2019 at 22:18, Tamas Blummer <<a href=3D"mailto:= +tamas.blummer@gmail.com" target=3D"_blank">tamas.blummer@gmail.com</a>> = +wrote:<br> +>> That opcode would not help as it fetches block hash and not the co= +ntent of the header.<br> +>> <br> +>>> On May 23, 2019, at 21:05, Nathan Cook <<a href=3D"mailto:n= +athan.cook@gmail.com" target=3D"_blank">nathan.cook@gmail.com</a>> wrote= +:<br> +>>> <br> +>>> You can get the same effect with OP_CHECKBLOCKATHEIGHT as prop= +osed by Luke Dashjr (<a href=3D"https://github.com/luke-jr/bips/blob/bip-cb= +ah/bip-cbah.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.= +com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki</a>) if you also re-enabl= +e/extend certain opcodes like OP_AND and OP_LESSTHAN. See <a href=3D"https:= +//lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.htm= +l" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/p= +ipermail/bitcoin-dev/2016-September/013149.html</a> and the ensuing thread.= +<br> +>>> <br> +>>> Nathan Cook<br> +>>> <br> +>>> <br> +>>> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev &l= +t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank= +">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> +>>> Difficulty change has profound impact on miner=E2=80=99s produ= +ction thereby introduce the biggest risk while considering an investment.<b= +r> +>>> Commodity markets offer futures and options to hedge risks on = +traditional trading venues. Some might soon list difficulty futures.<br> +>>> <br> +>>> I think we could do much better than them natively within Bitc= +oin.<br> +>>> <br> +>>> A better solution could be a transaction that uses nLocktime d= +enominated in block height, such that it is valid after the difficulty adju= +sted block in the future.<br> +>>> A new OP_DIFFICULTY opcode would put onto stack the value of d= +ifficulty for the block the transaction is included into.<br> +>>> The output script may then decide comparing that value with a = +strike which key can spend it.<br> +>>> The input of the transaction would be a multi-sig escrow of th= +ose who entered the bet.<br> +>>> The winner would broadcast.<br> +>>> <br> +>>> Once signed by both the transaction would not carry any counte= +rparty risk and would not need an oracle to settle according to the bet.<br= +> +>>> <br> +>>> I plan to draft a BIP for this as I think this opcode would se= +rve significant economic interest of Bitcoin economy, and is compatible wit= +h Bitcoin=E2=80=99s aim not to introduce 3rd party to do so.<br> +>>> <br> +>>> Do you see a fault in this proposal or want to contribute?<br> +>>> <br> +>>> Tamas Blummer<br> +>>> <br> +>>> _______________________________________________<br> +>>> bitcoin-dev mailing list<br> +>>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe= +t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br> +>>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/= +bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfounda= +tion.org/mailman/listinfo/bitcoin-dev</a><br> +>> <br> +> <br> +<br> +</blockquote></div></div> + +--000000000000d675da058993a2df-- + |