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
|
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 EB19DB7A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Oct 2019 14:11:01 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 800C814D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Oct 2019 14:11:00 +0000 (UTC)
Date: Sun, 20 Oct 2019 14:10:55 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mathbot.com;
s=protonmail; t=1571580658;
bh=/XgfiKu+/dCVs6BoR+UPjYbN9hM31werjToo0rMP33w=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=M7Uc82SojshQXNUHXLmMizDBtkJcG8Gw56cvT7sH11Eu35ktCucP54+yiDZK6jFoX
wKKyxg4tkG8YOY7ZFNrQi1Ti8pzL7k/MWhlJ3itM9KLIWwEuyURpN7/UrXeY6kUpng
U/8siZJNyywcNZZv4ifoUKS7KcSdhv2QwbYKp/D8=
To: Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: JW Weatherman <jw@mathbot.com>
Reply-To: JW Weatherman <jw@mathbot.com>
Message-ID: <5vCX5TKGwYMITwx_jp3BuX9nDr_DIez5kDPkF9ATAh_XYrQ4Y2rUGNU7qEkcy54BIEuNLB8TyznoOVBypNRWu0mTnqX4_D1oNK6ZT2fudQA=@mathbot.com>
In-Reply-To: <ED2B169F-9548-4EBF-AEA0-270EBA4A4502@voskuil.org>
References: <CAHa=hJVuOdSyPhzu+cGHumw-94yAfxPE_1CkMYRBqxPsyjYBKA@mail.gmail.com>
<ED2B169F-9548-4EBF-AEA0-270EBA4A4502@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>
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:11:02 -0000
I think the assumption is not that all miners are unprofitable, but that a =
single miner could make an investment that becomes unprofitable if the hash=
rate increases more than he expected.
Depending on the cost of the offered insurance it would be prudent for a mi=
ner to decrease his potential loss by buying insurance for this possibility=
.
And the existence of attractive insurance contracts would lower the barrier=
to entry for new competitors in mining and this would increase bitcoins se=
curity.
-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 1:03 AM, Eric Voskuil via bitcoin-dev <bitcoin-=
dev@lists.linuxfoundation.org> wrote:
> Hi Lucas,
>
> I would question the assumption inherent in the problem statement. Settin=
g aside variance discount, proximity premium, and questions of relative eff=
iciency, as these are presumably already considered by the miner upon the p=
urchase of new equipment, it=E2=80=99s not clear why a loss is assumed in t=
he case of subsequently increasing hash rate.
>
> The assumption of increasing hash rate implies an expectation of increasi=
ng 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, and if=
he is not, hash rate will drop until he is. This drop is most likely to be=
precipitated by older equipment going offline.
>
> Best,
> Eric
>
> > 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 contr=
ibutions 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 trus=
tless bc we can use the assumption that the price of hashing is low to unlo=
ck funds.
> > The problem:
> > A miner invests in new mining equipment, but if the hash-rate goes up t=
oo much (the price he is paid for a hash goes down by too much) he will hav=
e 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 tr=
ansaction:
> > 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 produce=
s a hash within certain difficulty constraints
> > 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.
> > Of course, both parties can reach an agreement that doesn't require act=
ually spending these resources -- so the miner can still mine Bitcoin and c=
ompensate for the lower-than-expected reward with part of the insurance dep=
osit.
> > If the price doesn't go down enough, the miner just mines Bitcoin and t=
he insurer gets his deposit back.
> > It's basically an instrument for guaranteeing a minimum profitability o=
f the mining operation.
> > Implementation issues: unfortunately we can't do arithmetic comparison =
with long integers >32bit in the script, so implementation of the difficult=
y requirement needs to be hacky. I think we can use the hashes of one or mo=
re pre-images with a given short length, and the miner has to provide the e=
xact pre-images. The pre-images are chosen by the insurer, and we would nee=
d a "honesty" deposit or other mechanism to punish the insurer if he choose=
s a hash that doesn't correspond to any short-length pre-image. I'm not sur=
e 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!
> >
> > 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
|
