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
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BD570B6C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Oct 2019 14:57:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com
[209.85.222.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 76E2714D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Oct 2019 14:57:41 +0000 (UTC)
Received: by mail-qk1-f171.google.com with SMTP id f18so9275062qkm.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Oct 2019 07:57:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=content-transfer-encoding:from:mime-version:subject:date:message-id
:references:cc:in-reply-to:to;
bh=XMq6NqRFvp+TDz6m5sY+VQnc0KdkuRkqJm4RplLL/6Q=;
b=JXjcVp8OMC5sxmAT8jwp5DDrb/+iZIwNle88I15fSa5JmcJfAEkMxa2NbI4k4r/SWv
hyzvpLm6L01e+qEGYNlYjomGGkiPHw2qlAfAnSxrHi21Hzu1u9sF7mt3XBmi4hy6D0uy
TIxAF6mgAXoLmnwNx8y2NdRnbXSlU41zIJs57HdZNaD8+HRs5CSVWI4ZATi7x5wM1MFO
uSWdu4dYx7PMe8diEU/RM6B+0uU03DKL7L9Pq5SifUIcu4JM2JRLbjrl1tYDmQHSJqe9
n49jUDfioWGKCijgyYvFFSLz3DOkjjcTr4uV4lkPwdABXZtj7fK8lkJyslMgm4P90n2f
TynA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:content-transfer-encoding:from:mime-version
:subject:date:message-id:references:cc:in-reply-to:to;
bh=XMq6NqRFvp+TDz6m5sY+VQnc0KdkuRkqJm4RplLL/6Q=;
b=V93dz88PZcgsOG7JDn+KRR0B3GQDYmjNTXy7ShwYxhjPzJ5N4l7/6fQeA0YG2dDrOm
eQpn/XJAwPh2SeI4nMXEngu8Rt1vQZzWQNS7FM6P39aYmVKtzjI5k2btBA5EZu9yp9yp
BNYLoBE1QjhDy16hNGXJqoKnvuK3Yd6x32F5L27PFNMtgVJmnm1BXQ2n/GJfdAPPrUwE
gqT8ALVubpj7aRMuCKaVJ0XYmX5IGwSSABxU7YLjZ4s7UerGw1jrJZhSMkPdjXFrQReW
L6+kMOv5UZzIqSMSFU9r6xVFfxJj7+cPjD0cd2T3dJTvac5eMnkGbJD7A0cpFUQiGB7P
39EA==
X-Gm-Message-State: APjAAAVpmdnDFZtMs/a+tPJsoz5C4Kr9UmYREiGlljXOXpgj9REXjvVY
F3XuCG7YuTIOPEzZKL2vjK4cpPZde6s=
X-Google-Smtp-Source: APXvYqww0iZo1ETEh4LH7iDJDQ6WBSRGqITQmO+jLR3x/L8zlTjjtTVY0yB+JNvE+Rau/JFyYWRiGw==
X-Received: by 2002:a37:9a8e:: with SMTP id c136mr16410242qke.0.1571583460258;
Sun, 20 Oct 2019 07:57:40 -0700 (PDT)
Received: from ?IPv6:2600:380:bc23:b42c:9489:8da7:15fc:4cdf?
([2600:380:bc23:b42c:9489:8da7:15fc:4cdf])
by smtp.gmail.com with ESMTPSA id
a190sm6808694qkf.118.2019.10.20.07.57.38
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sun, 20 Oct 2019 07:57:38 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Sun, 20 Oct 2019 10:57:37 -0400
Message-Id: <90A19D12-D964-41AE-A27F-AB99B66936D1@voskuil.org>
References: <5vCX5TKGwYMITwx_jp3BuX9nDr_DIez5kDPkF9ATAh_XYrQ4Y2rUGNU7qEkcy54BIEuNLB8TyznoOVBypNRWu0mTnqX4_D1oNK6ZT2fudQA=@mathbot.com>
In-Reply-To: <5vCX5TKGwYMITwx_jp3BuX9nDr_DIez5kDPkF9ATAh_XYrQ4Y2rUGNU7qEkcy54BIEuNLB8TyznoOVBypNRWu0mTnqX4_D1oNK6ZT2fudQA=@mathbot.com>
To: JW Weatherman <jw@mathbot.com>
X-Mailer: iPhone Mail (17A860)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, MIME_QP_LONG_LINE,
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: Mon, 21 Oct 2019 05:00:55 +0000
Cc: Lucas H <lucash.dev@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [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: Sun, 20 Oct 2019 14:57:42 -0000
> On Oct 20, 2019, at 10:10, JW Weatherman <jw@mathbot.com> wrote:
>=20
> =EF=BB=BFI think the assumption is not that all miners are unprofitable, b=
ut that a single miner could make an investment that becomes unprofitable if=
the hash rate increases more than he expected.
This is a restatement of the assumption I questioned. Hash rate increase doe=
s not imply unprofitability. The new rig should be profitable.
What is being assumed is a hash rate increase *without* a proportional block=
reward value increase. In this case if the newest equipment is unprofitable=
, all miners are unprofitable.
> Depending on the cost of the offered insurance it would be prudent for a m=
iner to decrease his potential loss by buying insurance for this possibility=
.
>=20
> And the existence of attractive insurance contracts would lower the barrie=
r to entry for new competitors in mining and this would increase bitcoins se=
curity.
>=20
> -JW
>=20
>=20
>=20
>=20
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M=
essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
>> On Sunday, October 20, 2019 1:03 AM, Eric Voskuil via bitcoin-dev <bitcoi=
n-dev@lists.linuxfoundation.org> wrote:
>>=20
>> Hi Lucas,
>>=20
>> I would question the assumption inherent in the problem statement. Settin=
g aside variance discount, proximity premium, and questions of relative effi=
ciency, as these are presumably already considered by the miner upon the pur=
chase of new equipment, it=E2=80=99s not clear why a loss is assumed in the c=
ase of subsequently increasing hash rate.
>>=20
>> The assumption of increasing hash rate implies an expectation of increasi=
ng return on investment. There are certainly speculative errors, but a loss o=
n new equipment implies all miners are operating at a loss, which is not a s=
ustainable situation.
>>=20
>> If any miner is profitable it is the miner with the new equipment, and if=
he is not, hash rate will drop until he is. This drop is most likely to be p=
recipitated by older equipment going offline.
>>=20
>> Best,
>> Eric
>>=20
>>>> On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev bitcoin-dev@lists.li=
nuxfoundation.org wrote:
>>> Hi,
>>> This is my first post to this list -- even though I did some tiny contri=
butions to bitcoin core I feel quite a beginner -- so if my idea is stupid, a=
lready known, or too off-topic, just let me know.
>>> TL;DR: a trustless contract that guarantees minimum profitability of a m=
ining operation -- in case Bitcoin/hash price goes too low. It can be trustl=
ess bc we can use the assumption that the price of hashing is low to unlock f=
unds.
>>> The problem:
>>> A miner invests in new mining equipment, but if the hash-rate goes up to=
o 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 o=
ption to sell hashes at a given price?)
>>> An insurer who believes that it's unlikely the price of a hash will go d=
own a lot negotiates a contract with the miner implemented as a Bitcoin tran=
saction:
>>> 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 lac=
k of precise financial jargon), is that if hashing becomes cheap enough, it b=
ecomes profitable to spend resources finding a suitable pre-image, rather th=
an mining Bitcoin.
>>> Of course, both parties can reach an agreement that doesn't require actu=
ally spending these resources -- so the miner can still mine Bitcoin and com=
pensate for the lower-than-expected reward with part of the insurance deposi=
t.
>>> If the price doesn't go down enough, the miner just mines Bitcoin and th=
e 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 w=
ith long integers >32bit in the script, so implementation of the difficulty r=
equirement needs to be hacky. I think we can use the hashes of one or more p=
re-images with a given short length, and the miner has to provide the exact p=
re-images. The pre-images are chosen by the insurer, and we would need a "ho=
nesty" 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 t=
his implementation though, maybe we actually need new opcodes.
>>> What do you guys think?
>>> Thanks for reading it all! Hope it was worth your time!
>>>=20
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>=20
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
>=20
|
