1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
|
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 918EEF0C
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 May 2019 19:05:23 +0000 (UTC)
Received: by mail-oi1-f172.google.com with SMTP id u199so5206667oie.5
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
<42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com>
In-Reply-To: <42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com>
From: Nathan Cook <nathan.cook@gmail.com>
Date: Thu, 23 May 2019 22:05:02 +0300
Message-ID: <CAGNXQMTLjkC+i7YcVyWC0Z0ixTkwhYR2qF4R0qeMNTT4ntj9oQ@mail.gmail.com>
To: Tamas Blummer <tamas.blummer@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: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
<div dir=3D"ltr">You can get the same effect with OP_CHECKBLOCKATHEIGHT as =
proposed by Luke Dashjr (<a href=3D"https://github.com/luke-jr/bips/blob/bi=
p-cbah/bip-cbah.mediawiki" target=3D"_blank">https://github.com/luke-jr/bip=
s/blob/bip-cbah/bip-cbah.mediawiki</a>) if you also re-enable/extend certai=
n opcodes like OP_AND and OP_LESSTHAN. See=C2=A0<a href=3D"https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html">https:/=
/lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html=
</a>=C2=A0and the ensuing thread.<div><br clear=3D"all"><div><div dir=3D"lt=
r" class=3D"m_403880825204588202m_-2348348040253356886gmail_signature" data=
-smartmail=3D"gmail_signature">Nathan Cook</div></div><br></div></div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, 23 =
May 2019 at 21:33, Tamas Blummer via bitcoin-dev <<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linu=
xfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">Difficulty change has profound impact on miner=E2=80=99s pro=
duction thereby introduce the biggest 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>
--00000000000091e78b058992c308--
|
