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
|
Return-Path: <tamas.blummer@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 002C2F10
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 May 2019 20:26:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com
[209.85.128.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 567C983A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 May 2019 20:26:55 +0000 (UTC)
Received: by mail-wm1-f45.google.com with SMTP id c77so7156258wmd.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 May 2019 13:26:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:message-id:mime-version:subject:date:in-reply-to:cc:to
:references; bh=n0WYodHlp+uLx7+PB4hhnAfo4n3UhqJPrv5aKN+RkLA=;
b=klt5kXDFyFhIkM0BTrTnUe+DqWwoosorSXtaxd8qEoI8wxLELnyxJlGeJKmvYj5lzI
IdpknvpsGZtOSUuKSiZ11IJIDPQHhtErBdzFSty59ctrYF7xpUhAyeC2K/qDYsiAGxhl
hBY/H4aM7VK/gwc+koGo49PyPoqiQ5JOmsFGW7xyifcritmzODfCTgdkATuNgVD7Nl/4
MkK3FTPiP8FL0PQyRthJO4pGMyKZhJrx0hqiGHsPVeawkSz9UYyRudiXLQ6HaakZ+BNz
mJpcynRwuWUfNE6Ngi5f0nCgMnUjyQME2/2FcP0br5+z41+8TUtQt99kToydphQYYqWo
ohEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:message-id:mime-version:subject:date
:in-reply-to:cc:to:references;
bh=n0WYodHlp+uLx7+PB4hhnAfo4n3UhqJPrv5aKN+RkLA=;
b=RFQFi1zekG/iZBh83vWlC30ZkUld6Jn5T8R7na3CMefxsP52tFo57bpuiCSpgatCMq
E32H8+4kBaVaxxgP8qIQ1tVA0DRcA4xUA3bCJXMQpMn+6HFFppRflrRwqoCyS0EtZRgO
NarOod0aIXgMo7WKjiIw85qxXPT6+AVfSGrPVrmzPUHsglRKCdN4xWnm31x65WnHGdYw
vAY5Gj9gB1pCWeoMt0FrcWRDjKFIHGoCQzBZTucfnTWEnTLmlfe+idTNI5wPOtR3bLl4
y+pdg31MPs0SwwuRqMIS9KjrW82qvAoVx9IDoStR02MruhAM7YU2iO+ikoc7cCUctinW
DZZw==
X-Gm-Message-State: APjAAAW3GqS4eesMxT0F2MfK9e4aOVFDBiRyiYuEsMbO0QLuRXi78geH
GQJWTRfJuGifshwD4vXeIEs=
X-Google-Smtp-Source: APXvYqzofabWcJEhLEGnIQMzucuXaXM71jaQ54shDbfvoqOptbxIFBnH9dXQ5Aa0ouLNG8Vfvj7keA==
X-Received: by 2002:a7b:ce1a:: with SMTP id m26mr12297015wmc.137.1558643213957;
Thu, 23 May 2019 13:26:53 -0700 (PDT)
Received: from p200300dd67196b11c120770d4d53396f.dip0.t-ipconnect.de
(p200300DD67196B11C120770D4D53396F.dip0.t-ipconnect.de.
[2003:dd:6719:6b11:c120:770d:4d53:396f])
by smtp.gmail.com with ESMTPSA id o8sm184769wrx.50.2019.05.23.13.26.53
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 23 May 2019 13:26:53 -0700 (PDT)
From: Tamas Blummer <tamas.blummer@gmail.com>
Message-Id: <8870AC4C-B5E4-491C-8973-8962DEBD39CE@gmail.com>
Content-Type: multipart/signed;
boundary="Apple-Mail=_7F17239D-5AE2-459C-AE09-9943EFE71A80";
protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 23 May 2019 22:26:49 +0200
In-Reply-To: <CAPg+sBged=ivVLj9tAM6zZdvWdYnG5pj4gozac5EupFPLtwyfA@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
<42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com>
<CAPg+sBged=ivVLj9tAM6zZdvWdYnG5pj4gozac5EupFPLtwyfA@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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:29:27 +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:26:56 -0000
--Apple-Mail=_7F17239D-5AE2-459C-AE09-9943EFE71A80
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
> On May 23, 2019, at 21:45, Pieter Wuille <pieter.wuille@gmail.com> =
wrote:
>=20
> On Thu, 23 May 2019 at 11:33, Tamas Blummer via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>=20
>> Difficulty change has profound impact on miner=E2=80=99s production =
thereby 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.
>>=20
>> I think we could do much better than them natively within Bitcoin.
>>=20
>> 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.
>=20
> If the difficulty can be directly observed by the script language, you
> would need to re-evaluate all scripts in unconfirmed transactions
> whenever the difficulty changes. This complicates implementation of
> mempools, but it also makes reasoning about validity of (chains of)
> unconfirmed transactions harder, as an unconfirmed predecessor may
> have conditions that change over time.
>=20
> For things like block time/height, this is solved by not having the
> script itself observe the context state directly, but instead having
> an assertion on the state outside of script (nLockTime for absolute
> time/height and nSequence for relative), and then having opcodes
> inside script that observe the assertion (OP_CLTV and OP_CSV). By
> doing so, script validity is a single context-free yes or not that can
> be evaluated once, and the variable part is just transaction-level
> reasoning that doesn't involve a full script interpreter.
> Additionally, the supported assertions are restricted in such a way
> that if they are true within a particular block, they're also true in
> any descendant, removing the complexity of reasoning about validity
> (apart from the inevitable reasoning about possible double-spend
> before confirmation).
>=20
> I feel a similar construction is needed for observing block
> difficulty. This can be done by either having an opcode that as a side
> effect of execution "posts" an assertion (e.g. "difficulty at block
> height X is at least Y"), instead of putting the difficulty on the
> stack. An alternative is having the assertion be part of the
> transaction structure (for example in the annex we propose in
> bip-taproot), and having an opcode that observes the difficulty
> assertion inside script.
Thanks for these suggestions I will follow up while preparing the BIP.
>=20
> I don't have a strong opinion either way on the usefulness of having
> difficulty-dependent transaction/scripts.
>=20
This is the best reception I could have hoped for :)
> Cheers,
>=20
> --
> Pieter
--Apple-Mail=_7F17239D-5AE2-459C-AE09-9943EFE71A80
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAlznAgoACgkQ9nKRxRdx
ORy8zAf/YVsBFCLraoMx8gid3xqdsdv0upBdj6tv9bIYonwEdjlUNorHJDvQD6Pm
0L7xrm8cNcY1kc350y+fAdnIhfA1CS/zKuCCwNeFch4Uf189Q5WrfXVrP/zLYW24
a6eKfkhWW0Rf0pkyyFazU5qY5Fk3Vw490ExuKhSMRmtYYH3Rvei21tEw3HK6NuNK
mbqevrD7nOmny62ApbTOaUYzf+jHrX4henai8xLzkEMoPaVF/keXfeB1Q8pFkrPp
tqJpl2rmdZsGHT6IGkAwO3xekebID2QHqWmuewD/w9ep0/cH1ODSCpIVA57fNAfC
EytZyEbF4SUE2I06dSTJktk5EoPArQ==
=qZJx
-----END PGP SIGNATURE-----
--Apple-Mail=_7F17239D-5AE2-459C-AE09-9943EFE71A80--
|
