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
|
Return-Path: <lucash.dev@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DE5D4B8E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Oct 2019 22:02:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com
[209.85.217.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 436915D3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Oct 2019 22:02:08 +0000 (UTC)
Received: by mail-vs1-f52.google.com with SMTP id y129so5039477vsc.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Oct 2019 15:02:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=XFkCKKg2u2i0Ayaz758keECQjmztAy+cyFXSELWpwU4=;
b=VeIz4L1f70YoIZvt1t5yJoeIluFzvQY9S/NvVrDb+XL09oUkR/ChIyt9Vw7Ehe21JB
zBHnf/GjkOfuZpsHNyv01OUzV6twAiurvZnC/B7PUgfA+O7Nd6C4HGUIB7cgS8qMbuW0
y8BdlpnZiDL8oY7cMrcWJ6sEAS0AF4wTNXXh62Br6Pp6uynhFGuFBGgWOes+Q7ugPK9d
zfnpVlZerMceFGLnVZFbdVc6IAIWukj/eZIZ+KPCK1rAi6uEcXCsKSpjY7/+Icj3rg6/
f5KsDUVcptuhpIb5SqLUxF2l73/zbyiu4LLF7CWowj4eKVa0IiqErci15fhVeUEkqeXG
bAcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=XFkCKKg2u2i0Ayaz758keECQjmztAy+cyFXSELWpwU4=;
b=L5jStqbCIi+xnoH57jwuy/1h0Td+bua6cboULSaQFAK4cxU9x0Ff+9sdq/jFAiT8c/
zf//LjfVCCKlKCOYCueLm/bylC5v5qzHMmP64Ys9amQSBKZma/oJYHX5hBVlBQK4ICvw
JqueuEcT4n6bySYTKYHJhng34TKpQMdFm//z3qT5lZrK6FtOEDTdT8wS+OWgToESJKsm
vg6ULFenD04KS/q1SO4DgeGNZeuM7XeXZqTMRSc6ALB/bKAcuTuwwMmlA3El3S25uxtt
tGEZ7ZJm/TVetGPnVLiI0MPY9ZPzLtZGwAPEKVDcFFpypVJRQdqSUSPrcjLp4ZcRCQpy
bc8g==
X-Gm-Message-State: APjAAAWSpltD24tTlFxVKwm4hdM2W2mplRumQwmD4pMVj2X0y6LwVoPQ
3QD85M+w4fgt7pSYp/luwZ7NzUnFSU4U9yPcwuY3M2yWPcM=
X-Google-Smtp-Source: APXvYqz8Jy9Y29AJH2xx0UaobhfH2kuEOTytWmtueGnzr46dOvn3nYBE4gS7mEHaRj6cpQ7ZKFGcQvKms9NNWeZpAQU=
X-Received: by 2002:a05:6102:246:: with SMTP id
a6mr6733727vsq.19.1571436126931;
Fri, 18 Oct 2019 15:02:06 -0700 (PDT)
MIME-Version: 1.0
From: Lucas H <lucash.dev@gmail.com>
Date: Fri, 18 Oct 2019 15:01:54 -0700
Message-ID: <CAHa=hJVuOdSyPhzu+cGHumw-94yAfxPE_1CkMYRBqxPsyjYBKA@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="000000000000220e8e0595367c94"
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: Sun, 20 Oct 2019 04:30:58 +0000
Subject: [bitcoin-dev] Trustless hash-price insurance contracts
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: Fri, 18 Oct 2019 22:02:09 -0000
--000000000000220e8e0595367c94
Content-Type: text/plain; charset="UTF-8"
Hi,
This is my first post to this list -- even though I did some tiny
contributions to bitcoin core I feel quite a beginner -- so if my idea is
stupid, already known, or too off-topic, just let me know.
TL;DR: a trustless contract that guarantees minimum profitability of a
mining operation -- in case Bitcoin/hash price goes too low. It can be
trustless bc we can use the assumption that the price of hashing is low to
unlock funds.
The problem:
A miner invests in new mining equipment, but if the hash-rate goes up too
much (the price he is paid for a hash goes down by too much) he will have a
loss.
Solution: trustless hash-price insurance contract (or can we call it an
option to sell hashes at a given price?)
An insurer who believes that it's unlikely the price of a hash will go down
a lot negotiates a contract with the miner implemented as a Bitcoin
transaction:
Inputs: a deposit from the insurer and a premium payment by the miner
Output1: simply the premium payment to the insurer
Output2 -- that's the actual insurance
There are three OR'ed conditions for paying it:
A. After expiry date (in blocks) insurer can spend
B. Both miner and insurer can spend at any time by mutual agreement
C. Before expiry, miner can spend by providing **a pre-image that
produces a hash within certain difficulty constraints**
The thing that makes it a hash-price insurance (or option, pardon my lack
of precise financial jargon), is that if hashing becomes cheap enough, it
becomes profitable to spend resources finding a suitable pre-image, rather
than mining Bitcoin.
Of course, both parties can reach an agreement that doesn't require
actually spending these resources -- so the miner can still mine Bitcoin
and compensate for the lower-than-expected reward with part of the
insurance deposit.
If the price doesn't go down enough, the miner just mines Bitcoin and the
insurer gets his deposit back.
It's basically an instrument for guaranteeing a minimum profitability of
the mining operation.
Implementation issues: unfortunately we can't do arithmetic comparison with
long integers >32bit in the script, so implementation of the difficulty
requirement needs to be hacky. I think we can use the hashes of one or more
pre-images with a given short length, and the miner has to provide the
exact pre-images. The pre-images are chosen by the insurer, and we would
need a "honesty" deposit or other mechanism to punish the insurer if he
chooses a hash that doesn't correspond to any short-length pre-image. I'm
not sure about this implementation though, maybe we actually need new
opcodes.
What do you guys think?
Thanks for reading it all! Hope it was worth your time!
--000000000000220e8e0595367c94
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>This is my first post to=
this list -- even though I did some tiny contributions to bitcoin core I f=
eel quite a beginner -- so if my idea is stupid, already known, or too off-=
topic, just let me know.</div><div><br></div><div>TL;DR: a trustless contra=
ct that guarantees minimum profitability of a mining operation -- in case B=
itcoin/hash price goes too low. It can be trustless bc we can use the assum=
ption that the price of hashing is low to unlock funds.<br></div><div><br><=
/div><div>The problem:</div><div><br></div><div>A miner invests in new mini=
ng equipment, but if the hash-rate goes up too much (the price he is paid f=
or a hash goes down by too much) he will have a loss.</div><div><br></div><=
div>Solution: trustless hash-price insurance contract (or can we call it an=
option to sell hashes at a given price?)<br></div><div><br></div><div>An i=
nsurer who believes that it's unlikely the price of a hash will go down=
a lot negotiates a contract with the miner implemented as a Bitcoin transa=
ction:</div><div><br></div><div>Inputs: a deposit from the insurer and a pr=
emium payment by the miner</div><div>Output1: simply the premium payment to=
the insurer</div><div>Output2 -- that's the actual insurance</div><div=
>=C2=A0 There are three OR'ed conditions for paying it:</div><div>=C2=
=A0 A. After expiry date (in blocks) insurer can spend</div><div>=C2=A0 B. =
Both miner and insurer can spend at any time by mutual agreement</div><div>=
=C2=A0 C. Before expiry, miner can spend by providing **a pre-image that pr=
oduces a hash within certain difficulty constraints**</div><div><br></div><=
div>The thing that makes it a hash-price insurance (or option, pardon my la=
ck of precise financial jargon), is that if hashing becomes cheap enough, i=
t becomes profitable to spend resources finding a suitable pre-image, rathe=
r than mining Bitcoin.</div><div>Of course, both parties can reach an agree=
ment that doesn't require actually spending these resources -- so the m=
iner can still mine Bitcoin and compensate for the lower-than-expected rewa=
rd with part of the insurance deposit.</div><div>If the price doesn't g=
o down enough, the miner just mines Bitcoin and the insurer gets his deposi=
t back.<br></div><div>It's basically an instrument for guaranteeing a m=
inimum profitability of the mining operation.</div><div><br></div><div>Impl=
ementation issues: unfortunately we can't do arithmetic comparison with=
long integers >32bit in the script, so implementation of the difficulty=
requirement needs to be hacky. I think we can use the hashes of one or mor=
e pre-images with a given short length, and the miner has to provide the ex=
act pre-images. The pre-images are chosen by the insurer, and we would need=
a "honesty" deposit or other mechanism to punish the insurer if =
he chooses a hash that doesn't correspond to any short-length pre-image=
. I'm not sure about this implementation though, maybe we actually need=
new opcodes.<br></div><div><br></div><div>What do you guys think?</div><di=
v>Thanks for reading it all! Hope it was worth your time!</div></div>
--000000000000220e8e0595367c94--
|
