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
|
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 952D0AC7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Oct 2019 05:03:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com
[209.85.160.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DAAB714D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Oct 2019 05:03:13 +0000 (UTC)
Received: by mail-qt1-f176.google.com with SMTP id c17so12444135qtn.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Oct 2019 22:03:13 -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:date:subject:message-id
:references:in-reply-to:to;
bh=TLpej3y7tTcbdWdqJpd/4RBUv1lx8T3iTEApkBGJcc0=;
b=iIgfLtKnt/AraXIJPjywKFgmloy+37OxCR15k3BU61RqV7fL+cerM9fcTQy3Qd+ung
IwUJ+i7ES2zmMX8gJwgigIepBLf3Eejb1lM2+gVouEdUpHhZEeoQkqxn/m6XkOkUjeA1
CjRKG4QmNVsMdaLejkyqOQ6USddDz+i9wV4SSvBC5ECblVbyeoLeao0zx6+7suqbO6Ln
cD5xAnIKJ89BKgkDX0W/9qRwQBcxGz2tsKV+nfW/AJvGJFzNjZagbg22RKldzgnQxJZa
jfcNBZvEOVece7xsqUK7ZenjzwsodjSO4xLcPcKgrPihp+d3/uvgYEL8MDzF/qcP8LNm
+45A==
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:date
:subject:message-id:references:in-reply-to:to;
bh=TLpej3y7tTcbdWdqJpd/4RBUv1lx8T3iTEApkBGJcc0=;
b=Y6L9uz1OhbX+rQRhuaAw9qpYZw8hxm+eRwraEGH1iFcSCbQ3pdYY7+xr9JjfjwAtvR
cUodU2/+3L+EM5D8QucSe2E+z4MidloVTYxobm7N+GXwz+ro+fRGMKo5exFbZCQh1vln
spbXHshh4vXPeHXdjEYg7iOurz0LCOF5DbINXv7Xeq19Dx6B/wHu9cAx/l/5Ykls0JvG
wosX0x1uVfWElrSXWJkekIqsF0DilujSZyDMwcTnbb4KNXQgHQYpwRIz01X3f/rYbR+6
wTrwIWBfMovUD/uD5dvuBOxPRoXyG1cDU9IcwTL4yMGYVULRwf7RrjpXdU9tEsL/aMgZ
pM+A==
X-Gm-Message-State: APjAAAVPzBVgKnz25y2LE9knA9rcVsAcIodKdDFcNOvg8NKZYXRmwXOU
M+RSyevWrmnTbzHzm0KwJDXsXg==
X-Google-Smtp-Source: APXvYqy4vHKHExJf7s7+wUoxJVRfx21hE6UE4K2L5fy4gjDhZ2y1n0vAgxQ910zq4dbN8RiI7O7RVw==
X-Received: by 2002:ac8:1207:: with SMTP id x7mr18338319qti.255.1571547792759;
Sat, 19 Oct 2019 22:03:12 -0700 (PDT)
Received: from [10.8.63.70] (mobile-166-172-60-47.mycingular.net.
[166.172.60.47]) by smtp.gmail.com with ESMTPSA id
n42sm7749420qta.31.2019.10.19.22.03.11
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sat, 19 Oct 2019 22:03:11 -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 01:03:09 -0400
Message-Id: <ED2B169F-9548-4EBF-AEA0-270EBA4A4502@voskuil.org>
References: <CAHa=hJVuOdSyPhzu+cGHumw-94yAfxPE_1CkMYRBqxPsyjYBKA@mail.gmail.com>
In-Reply-To: <CAHa=hJVuOdSyPhzu+cGHumw-94yAfxPE_1CkMYRBqxPsyjYBKA@mail.gmail.com>
To: Lucas H <lucash.dev@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Sun, 20 Oct 2019 08:36:24 +0000
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 05:03:14 -0000
Hi Lucas,
I would question the assumption inherent in the problem statement. Setting a=
side variance discount, proximity premium, and questions of relative efficie=
ncy, as these are presumably already considered by the miner upon the purcha=
se of new equipment, it=E2=80=99s not clear why a loss is assumed in the cas=
e of subsequently increasing hash rate.=20
The assumption of increasing hash rate implies an expectation of increasing r=
eturn on investment. There are certainly speculative errors, but a loss on n=
ew equipment implies *all miners* are operating at a loss, which is not a su=
stainable 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 pre=
cipitated by older equipment going offline.
Best,
Eric
> On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev <bitcoin-dev@lists.linu=
xfoundation.org> wrote:
>=20
> =EF=BB=BF
> Hi,
>=20
> This is my first post to this list -- even though I did some tiny contribu=
tions to bitcoin core I feel quite a beginner -- so if my idea is stupid, al=
ready known, or too off-topic, just let me know.
>=20
> TL;DR: a trustless contract that guarantees minimum profitability of a min=
ing operation -- in case Bitcoin/hash price goes too low. It can be trustles=
s bc we can use the assumption that the price of hashing is low to unlock fu=
nds.
>=20
> The problem:
>=20
> A miner invests in new mining equipment, but if the hash-rate goes up too m=
uch (the price he is paid for a hash goes down by too much) he will have a l=
oss.
>=20
> Solution: trustless hash-price insurance contract (or can we call it an op=
tion to sell hashes at a given price?)
>=20
> An insurer who believes that it's unlikely the price of a hash will go dow=
n a lot negotiates a contract with the miner implemented as a Bitcoin transa=
ction:
>=20
> 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 produc=
es a hash within certain difficulty constraints**
>=20
> The thing that makes it a hash-price insurance (or option, pardon my lack o=
f precise financial jargon), is that if hashing becomes cheap enough, it bec=
omes 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 actual=
ly spending these resources -- so the miner can still mine Bitcoin and compe=
nsate 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 i=
nsurer gets his deposit back.
> It's basically an instrument for guaranteeing a minimum profitability of t=
he mining operation.
>=20
> Implementation issues: unfortunately we can't do arithmetic comparison wit=
h long integers >32bit in the script, so implementation of the difficulty re=
quirement needs to be hacky. I think we can use the hashes of one or more pr=
e-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.
>=20
> 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
|
