path: root/34/02200d6640e3c08e976275a959475d57339adf

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 36DE0C03
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 May 2019 19:22:02 +0000 (UTC)
Received: by mail-ot1-f41.google.com with SMTP id r7so6495405otn.6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <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>
In-Reply-To: <C6788578-80D4-44E7-8CF7-82AD15E3F12C@gmail.com>
From: Nathan Cook <nathan.cook@gmail.com>
Date: Thu, 23 May 2019 22:21:39 +0300
Message-ID: <CAGNXQMQG4KwAohfENYuUW=uABGshbJMYmdb_71ZtByCuj=14bQ@mail.gmail.com>
To: Tamas Blummer <tamas.blummer@gmail.com>
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 <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 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 <tamas.blummer@gmail.com> 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 <nathan.cook@gmail.com> 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

<div dir=3D"ltr"><div dir=3D"ltr">It&#39;s true that it fetches the block h=
ash; the idea is to compare the block hash&#39;s numeric value to the desir=
ed (uncompressed) difficulty directly, using a 256-bit version of OP_LESSTH=
AN.</div><div dir=3D"ltr"><br clear=3D"all"><div><div dir=3D"ltr" class=3D"=
m_-660591142197038773gmail_signature" data-smartmail=3D"gmail_signature">Na=
than Cook</div></div><br></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Thu, 23 May 2019 at 22:18, Tamas Blummer &lt;<a=
 href=3D"mailto:tamas.blummer@gmail.com" target=3D"_blank">tamas.blummer@gm=
ail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><div><div>That opcode would not help as it fetches block hash and no=
t the content of the header.</div><br><div><blockquote type=3D"cite"><div>O=
n May 23, 2019, at 21:05, Nathan Cook &lt;<a href=3D"mailto:nathan.cook@gma=
il.com" target=3D"_blank">nathan.cook@gmail.com</a>&gt; wrote:</div><br cla=
ss=3D"m_-660591142197038773gmail-m_6837987650471914851Apple-interchange-new=
line"><div><div dir=3D"ltr">You can get the same effect with OP_CHECKBLOCKA=
THEIGHT as proposed by Luke Dashjr (<a href=3D"https://github.com/luke-jr/b=
ips/blob/bip-cbah/bip-cbah.mediawiki" target=3D"_blank">https://github.com/=
luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki</a>) if you also re-enable/ex=
tend certain opcodes like OP_AND and OP_LESSTHAN. See=C2=A0<a href=3D"https=
://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.ht=
ml" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-d=
ev/2016-September/013149.html</a>=C2=A0and the ensuing thread.<div><br clea=
r=3D"all"><div><div dir=3D"ltr" class=3D"m_-660591142197038773gmail-m_68379=
87650471914851m_403880825204588202m_-2348348040253356886gmail_signature">Na=
than Cook</div></div><br></div></div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr">On Thu, 23 May 2019 at 21:33, Tamas Blummer =
via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex">Difficulty change =
has profound impact on miner=E2=80=99s production thereby introduce the big=
gest risk while considering an investment.<br>
Commodity markets offer futures and options to hedge risks on traditional t=
rading venues. Some might soon list difficulty futures.<br>
<br>
I think we could do much better than them natively within Bitcoin.<br>
<br>
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.<br>
A new OP_DIFFICULTY opcode would put onto stack the value of difficulty 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 those who enter=
ed the bet. <br>
The winner would broadcast. <br>
<br>
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.<br>
<br>
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.<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" target=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.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</div></blockquote></div><br></div></blockquote></div></div>

--00000000000019e2a8058992ffa7--