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
|
Return-Path: <jw@mathbot.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 178BEB5F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Oct 2019 16:11:01 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 12915831
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Oct 2019 16:10:59 +0000 (UTC)
Date: Sun, 20 Oct 2019 16:10:53 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mathbot.com;
s=protonmail; t=1571587857;
bh=06+9sQQjwxyFNLz4X+fgNjm86IvUTJnxr3tCqTrIlfg=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=lozwTXdkEAmHaoVoypnCU0DrIj3531aAEoOUN8jALxfTjHTBfNqGPgp3D56jombu0
thUKb82nd2EXmqNakK/XYmId/Caf9ja8SNxmbgKl3Iz6U/Widn6jCNesV5ngE/iPX7
cVERbfgeJLgsSDhKSuFWl9BWEd1C9jyu6QxJge1M=
To: Eric Voskuil <eric@voskuil.org>
From: JW Weatherman <jw@mathbot.com>
Reply-To: JW Weatherman <jw@mathbot.com>
Message-ID: <E8cgzgpxhsuivizcjW9yAo2lsv8LmR2kXjBvqm0bA4i0HXa11o-X2ntYXcmjlZ5iCOCS6OzNze-RHIZkqCLHMjtBTan4VnxskFmC-8NX850=@mathbot.com>
In-Reply-To: <90A19D12-D964-41AE-A27F-AB99B66936D1@voskuil.org>
References: <5vCX5TKGwYMITwx_jp3BuX9nDr_DIez5kDPkF9ATAh_XYrQ4Y2rUGNU7qEkcy54BIEuNLB8TyznoOVBypNRWu0mTnqX4_D1oNK6ZT2fudQA=@mathbot.com>
<90A19D12-D964-41AE-A27F-AB99B66936D1@voskuil.org>
Feedback-ID: 06WE2TD3pl3nzC7QfAH2qr5LpZ25gVcyyzXUIYQj0HZLgktVjK3WV4DgnthPbH0VVmnpGZwYV2mfC_kynz7XVA==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW 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:01:09 +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 16:11:01 -0000
Oh, I see your point.
However the insurance contract would protect the miner even in that case. A=
miner with great confidence that he is running optimal hardware and has op=
timal electricity and labor costs probably wouldn't be interested in purcha=
sing insurance for a high price, but if it was cheap enough it would still =
be worth it. And any potential new entrants on the edge of jumping in would=
enter when they otherwise would not have because of the decreased costs (d=
ecreased risk).
An analogy would be car insurance. If you are an excellent driver you would=
n't be willing to spend a ton of money to protect your car in the event of =
an accident, but if it is cheap enough you would. And there may be people t=
hat are unwilling to take the risk of a damaged car that refrain from becom=
ing drivers until insurance allows them to lower the worst case scenario of=
a damaged car.
-JW
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =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 10:57 AM, Eric Voskuil <eric@voskuil.org> wrote=
:
>
>
> > On Oct 20, 2019, at 10:10, JW Weatherman jw@mathbot.com wrote:
> > I think the assumption is not that all miners are unprofitable, but tha=
t 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 =
does not imply unprofitability. The new rig should be profitable.
>
> What is being assumed is a hash rate increase without a proportional bloc=
k reward value increase. In this case if the newest equipment is unprofitab=
le, all miners are unprofitable.
>
> > Depending on the cost of the offered insurance it would be prudent for =
a miner to decrease his potential loss by buying insurance for this possibi=
lity.
> > And the existence of attractive insurance contracts would lower the bar=
rier to entry for new competitors in mining and this would increase bitcoin=
s security.
> > -JW
> > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origina=
l Message =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 bit=
coin-dev@lists.linuxfoundation.org wrote:
> > > Hi Lucas,
> > > I would question the assumption inherent in the problem statement. Se=
tting aside variance discount, proximity premium, and questions of relative=
efficiency, as these are presumably already considered by the miner upon t=
he purchase of new equipment, it=E2=80=99s not clear why a loss is assumed =
in the case of subsequently increasing hash rate.
> > > The assumption of increasing hash rate implies an expectation of incr=
easing return on investment. There are certainly speculative errors, but a =
loss on new equipment implies all miners are operating at a loss, which is =
not a sustainable situation.
> > > If any miner is profitable it is the miner with the new equipment, an=
d if he is not, hash rate will drop until he is. This drop is most likely t=
o be precipitated by older equipment going offline.
> > > Best,
> > > Eric
> > >
> > > > > On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev bitcoin-dev@li=
sts.linuxfoundation.org wrote:
> > > > > 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 b=
e trustless bc we can use the assumption that the price of hashing is low t=
o unlock funds.
> > > > > The problem:
> > > > > A miner invests in new mining equipment, but if the hash-rate goe=
s up too much (the price he is paid for a hash goes down by too much) he wi=
ll 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 wi=
ll go down a lot negotiates a contract with the miner implemented as a Bitc=
oin transaction:
> > > > > Inputs: a deposit from the insurer and a premium payment by the m=
iner
> > > > > 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 agreeme=
nt
> > > > > C. Before expiry, miner can spend by providing a pre-image that p=
roduces 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 eno=
ugh, 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 requi=
re actually spending these resources -- so the miner can still mine Bitcoin=
and compensate for the lower-than-expected reward with part of the insuran=
ce 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 profitabi=
lity of the mining operation.
> > > > > Implementation issues: unfortunately we can't do arithmetic compa=
rison with long integers >32bit in the script, so implementation of the dif=
ficulty 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 wou=
ld 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 n=
ot sure about this implementation though, maybe we actually need new opcode=
s.
> > > > > What do you guys think?
> > > > > Thanks for reading it all! Hope it was worth your time!
> > > >
> > > > bitcoin-dev mailing list
> > > > bitcoin-dev@lists.linuxfoundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
