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
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
|
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 5BAA9255
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Jun 2019 18:59:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com
[209.85.221.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6F823711
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Jun 2019 18:59:13 +0000 (UTC)
Received: by mail-wr1-f52.google.com with SMTP id x4so2624528wrt.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 08 Jun 2019 11:59:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:mime-version:subject:message-id:date:cc:to;
bh=4VpOP6eRmLZDcTDAggbob19bBb754kNa/TORvlCIjPo=;
b=FRM1RALXLBROqU3anJ3oCWFIDGSZdW1fevvmkiXQWa4HaQcXRuG5SHzwPA32kIkfz+
wHQUfp9OI2+JRvbMKtHG3R4AH1lcpgL1Oau+/eJyVyPeZIh5wmOOQbbQ/c7n9glc7uTM
imm8kwU2i2EBPAtRYGnyTHipy6M1E2NnSVaQ9wc5Q8489uLtnwzbDuS4Vprf+osfDsYW
a1aCKOU3CiCVi9hElQIc0pSGbZnSq8Bl6Z6oxNNbmgbdVovIzkZQwc/3iYk50j7rm8v6
VluVC8X33Uieo/OJr6YpRbkz9UXLHLoWRWYRYkfUZ1j2RJ/5QKDP+HEVoowLtVQvgiCD
UvUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to;
bh=4VpOP6eRmLZDcTDAggbob19bBb754kNa/TORvlCIjPo=;
b=MPTutC5YdnKux2TcPgvPCG2lqv9Ta/o/To7gbZBCqUVKMtL8RQuZVOMJJOuRS1SRv7
oCVUda7vsTVG2GaRyxKlTrIYJ4YsNFt/mhp5UpglSR1Br2uCpNCoONxUuYc85UH+IBct
mzadxnTPThrfrb/yJXCBRgfIMY6sU2M/hwaM5td57Arx3kqkLU4RWPkX7dFd4g5QxaI9
y//qe48EjL/HBpC+A7aF8r+yFanc2cNq/vVpwOopm0TAYOz6OY95rPSP5v7v6n1vArNj
/8T4jYzTz30enXdSPWTgYXmsLelVgJbxx16JpNIDwNHrnlVFG35KffVZv3bypE/mMgfh
agAQ==
X-Gm-Message-State: APjAAAVAMctWAcGZwI7zNZUTKiWULwMapHzlbnqDSC41ylM3Z+dKLYrY
7iK7DRBcG6wIXGSPrJBbvH3FAVcf
X-Google-Smtp-Source: APXvYqzeij0WItgWPt0ilcRO6fdJnJdOiHtD1BFcUPbU6juXhZsTbVxKa6D4YjUB13Gr3RLV9FdEyA==
X-Received: by 2002:adf:ecca:: with SMTP id s10mr21769031wro.168.1560020351723;
Sat, 08 Jun 2019 11:59:11 -0700 (PDT)
Received: from p200300dd67196b3001e4ab7e7184621e.dip0.t-ipconnect.de
(p200300DD67196B3001E4AB7E7184621E.dip0.t-ipconnect.de.
[2003:dd:6719:6b30:1e4:ab7e:7184:621e])
by smtp.gmail.com with ESMTPSA id q9sm9555593wmq.9.2019.06.08.11.59.10
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 08 Jun 2019 11:59:10 -0700 (PDT)
From: Tamas Blummer <tamas.blummer@gmail.com>
Content-Type: multipart/signed;
boundary="Apple-Mail=_2D92696C-D95F-4E94-93D4-09B965BFB70F";
protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <CD8B22E6-6A8C-414B-86F2-D993475FE386@gmail.com>
Date: Sat, 8 Jun 2019 20:59:09 +0200
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Sun, 09 Jun 2019 08:19:34 +0000
Cc: Pieter Wuille <pieter.wuille@gmail.com>
Subject: [bitcoin-dev] WORKVERIFY: uncensorable contracts hedging biggest
risk of mining without 3rd party or oracle
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: Sat, 08 Jun 2019 18:59:14 -0000
--Apple-Mail=_2D92696C-D95F-4E94-93D4-09B965BFB70F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
In an earlier post [1] I suggested an approach to create native Bitcoin =
contracts that reduce mining's income volatility and received very =
helpful comments on implementation from Pieter Wuille [2] and Natanael =
[3]
After processing those comments I instead suggest the following =
restricted interpretation of nSequence and a new opcode WORKVERIFY that =
in combination is easier to implement and reason about as it follows the =
implementation pattern of CHECKSEQUENCEVERIFY[5]
Accumulated work on the blockchain is strictly increasing, therefore =
transaction eligibility rule with a >=3D condition on it would need no =
re-evaluation for descendant blocks, in mempool or at re-org, since =
additional blocks or re-org can only increase the accumulated work. =
Accumulated work is just like time, it is actually an alternate measure =
of time through computation[6], therefore analogous to MTP based =
restriction implemented with BIP68 [4].
=3D=3D=3D (the implementation proposal) =3D=3D=3D
(needs soft fork for two reasons, activation logic tbd.)
I. Stricter interpretation of nSequence to optionally refer accumulated =
work:
Only if bit 31 AND bit 30 is set in nSequence can the transaction be =
included into any block. This is a restricting a rule of BIP68 [4] that =
only required bit 31 to be set for unrestricted inclusion into blocks. =
Otherwise nSequence refers to accumulated work (see encoding later) and =
it is only viable to include the transaction into a block if the block =
has >=3D work accumulated. This would define the meaning of one =
additional bit in nSequence, but leave all other freedom of later =
improvement left by BIP68.
II. New WORKVERIFY opcode redefining a NOPx in transaction script as:
Terminate script with false for any reason described in BIP112 or if bit =
31 is set but bit 30 is not set and 256 bit unsigned integer on stack is =
higher than (nSequence &0xffff)>> 6 * 2^((nSequence & 0x3f) + 84)
=3D=3D=3D (end proposal) =3D=3D=3D
Notes on the work encoding:
Total accumulated work as of now is > 2^90 and if we assume that mining =
capacity keeps increasing with Moore=E2=80=99s law (double every year) =
for the next 50 years, then it could sum up to 2^140. We have much less =
bits available in nSequence therefore we have to encode accumulated work =
in a floating point number with sufficient precision.
The work accumulated during the current difficulty adjustment cycle is > =
2016 * 2^74 which is > 2^84. It is rather unlikely that accumulated work =
in a difficulty adjustment period drops below 2^80 ever again in future =
which means we need not be more precise than 2^80/2^90 or 2^-10 to =
allow for contracts that reference increment until the next adjustment. =
Therefore a mantissa of 10 bits should be sufficient. Using 6 bits of =
exponent and an offset of 2^84 we can express the range of [2^84, 2^148) =
that should be sufficient now and for foreseeable future. Please let me =
know if the approach is not optimal or future proof in your opinion.
Why, should we build this into Bitcoin ?
The most influential risk factor in miners' investment decision is the =
anticipated change of difficulty over the time horizon of the mining =
equipment's expected lifetime. Their investments secure the network. The =
ability to create contracts that reduce income volatility would lead to =
additional investment into mining.
A native Bitcoin contract is far superior to alternatives that could be =
offered on traditional markets as:
a native Bitcoin contract would be:
- uncensorable: It requires only the agreement to terms between those =
financially involved
- fully collaterized: no counterparty risk which means Miner could buy =
hedging contracts from any unkown and un-trusted actor that is able to =
commit collateral
- no oracle is needed
- no disagreement on the settlement
- publicly observable: allow to observe market opinion on future =
difficulty
- the length of the contract could match miner's investment horizon =
extending over several difficulty adjustments.
Why not on a side-chain ?
Work is fundamental and intrinsic to the base layer. A contract that =
reduces earnings volatility helps to attract more capital for mining and =
therefore increase security on the base layer.
How would this be used?
Miner and Speculator sign a transaction that has an nLockTime of S in =
the future. This gives both parties the option to alternatively spend =
committed output in case the other would not follow through and publish =
committing the collateral until S.
Speculators contribution to collateral is higher than that of the Miner. =
Miner=E2=80=99s collateral is the premium for the insurance provided by =
Speculator.
The single output of the transaction has following script:
IF
<maturity> CHECKLOCKTIMEVERIFY DROP
<speculator=E2=80=99s key> CHECKSIGVERIFY
ELSE
<sufficient work> WORKVERIFY DROP
<miner=E2=80=99s key> CHECKSIGVERIFY
ENDIF
This allows the speculator to take back its collateral plus the option =
premium after the maturity time point, which would however only be =
possible if it was not taken earlier by Miner as sufficient work was =
reached.
The contract in finance terms is an american digital call option with =
maturity and sufficient work as strike. The Miner profits of the =
contract if work accumulated is more than contracted in which case he =
would also have lower mining income, hence the contract would reduce =
earnings shortcome. The Speculator would earn the option premium if the =
contracted work was not required until maturity. In this case higher =
mining income through higher market share compensates Miner for the loss =
of option premium. In both cases Miner=E2=80=99s income volatility is =
reduced. The Speculator may find it attractive to enter the contract if =
the probability weighted option premium represents an attractive =
interest on the capital committed.
Contracted work would reflect the consenus of expected difficulty =
increase over future time horizons. Observing above contracts on the =
blockchain would allow calculation of market implied forward curve of =
mining difficulty and its implied volatility which again would help =
evaluating investment proposals into mining.
An alternate more flexible setup would be a Lightning Network like =
re-allocation of total collateral. Which would allo parties to mark the =
option to market (observed work and volatility) as time passes and allow =
for cooperative unwind.
Tamas Blummer
[1] =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016952.ht=
ml
[2] =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016958.ht=
ml
[3] =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016969.ht=
ml
[4] https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
[5] https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
[6] =
https://medium.com/@tamas.blummer/measuring-time-with-chain-of-blocks-893a=
38cc06bb
--Apple-Mail=_2D92696C-D95F-4E94-93D4-09B965BFB70F
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-----
iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAlz8BX0ACgkQ9nKRxRdx
ORxSkgf+JzDoNo6hEpRZzDyGVkyCDwcanm+qS2NeDrXGLkrnHiXS9GykfYnS1wkv
oSwCgdPYgXwICwByJ3mEfaSBxHUTqhW2ZTebmU4j/NwUgStUQwFfiIiFWCGsLVOV
qfZTh/FtI9dXFRt+TEPPcsPlUVbFRAHv6DmFFTnbcezWUOYQ/qOZB8AR1KgADzsg
CWmPnKq/npuSKcxtpaRW8HyDX6L9Td/Llb9kVh4krn1n2fPVcfVI4ABY7n6LpLlh
ZGXnOY/+erf+3lxO6RDxaQ7nB5+j5Bl5izFJnUErEl0ipXoMetef4CFxw3q2jjJv
9EhfQN+7oq0joLV8VU8OmwjlQ7DjsQ==
=rsYw
-----END PGP SIGNATURE-----
--Apple-Mail=_2D92696C-D95F-4E94-93D4-09B965BFB70F--
|
