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
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
|
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 71843255
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Oct 2019 21:33:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com
[209.85.217.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6314214D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Oct 2019 21:33:36 +0000 (UTC)
Received: by mail-vs1-f53.google.com with SMTP id l2so7571377vsr.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Oct 2019 14:33:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=9ToC/V8jhg5W/tVCpND35yjoP3lnw3eXIZhva7WnSKo=;
b=Hh0RB7OoQG2cHxLoSA7ZTZC8fAOeWDp4OlT4ApEDV886u1s4hnVlHOJTJ5rsHmS7hX
R1eM1PsDmw99BGLPrwtE51U6L3CYV+rMAiLsG+0YdnQC5tbogOOCYzATYpffbkwYTsJh
eO6v0ofIYs9SNeiqSip+ODibJtYr/IE3s+HZd4tMuG8bB7y+TH3lJoKgd4SvhiyhImvF
lRqNU4xq2A2SwMRsE/bu9Hu6Mimq+vn+NEBwo54RAGPCD0fVrKSe5hvrSBG3hlizEHtA
pg9ucT94Mp2gZmBT3/3gcIZINgiPh1WbMcmNlmRPb/B5Y2F+Pqm6ZJODA/Hp/FQBh/48
6rZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=9ToC/V8jhg5W/tVCpND35yjoP3lnw3eXIZhva7WnSKo=;
b=NZkseIwDyE0TP8M5IU8oyXPrNxIVBFWxdzKfJytUpBxESVrScH8+zkuQZSAMgMU3JH
j1DsTOFIH0Hetss+26mwx8v0zkUaAx8RLAfKJ8ZrbAtrEwb6G3QzqtbvRO9hwDzJAP1G
7tQPoUgfO7bTH553dZJfSjQ7YGVBwX8Lr+SwhbRRZlni5pjg6SJzf9jVCIRbbsse0QAh
FTGPfWL8gEKhuPhN22jHIOtkRvmlc8t3gheXgAJMMR5kqUZKEX24epYWr7dG5NJDJ969
fbsKbEfrPL938dz/cY6wA1vj6MuPuS01racCdH0B/38pPHXlpMbkE4gwVjrtOWVEazvj
R/Sw==
X-Gm-Message-State: APjAAAXKpGA7Rw3/1h2/P3ldxwp+WfGxu+v6LgLGg38W9P2eYMlT2ijS
XVdq3fChblfGbg1nmFeonmSNhAYFvTa27JWe39k=
X-Google-Smtp-Source: APXvYqwi4YwKvIHaw5ZPjbKtQLSHOhc4YrmyepgBrj9QgBhMoP9YYC3j2qGhMk/ix27EWJIQLhlXQplGEnpH9hT77r0=
X-Received: by 2002:a05:6102:246:: with SMTP id
a6mr11239675vsq.19.1571607215349;
Sun, 20 Oct 2019 14:33:35 -0700 (PDT)
MIME-Version: 1.0
References: <CAHa=hJVLp5=ao1p5kooE=4Fo9_jh6WVtG1uF0T_vAP7r=9zjww@mail.gmail.com>
<9C06A36D-C0A7-4C15-ACDB-63FF3572B079@voskuil.org>
In-Reply-To: <9C06A36D-C0A7-4C15-ACDB-63FF3572B079@voskuil.org>
From: Lucas H <lucash.dev@gmail.com>
Date: Sun, 20 Oct 2019 14:33:24 -0700
Message-ID: <CAHa=hJVG9J2uzb84Be2OoSG1j3S4cWzkps8hXYmL7o-hVmEhgw@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary="000000000000cc254205955e513c"
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: Mon, 21 Oct 2019 05:01:31 +0000
Cc: 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 21:33:38 -0000
--000000000000cc254205955e513c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sorry, Eric, but I think you're completely missing the point.
It has nothing to do with sunken cost -- but the fact that the mining
equipment is good for nothing else other than performing hashing operations=
.
As long as someone can get paid more than they spend to keep the equipment
running, i.e. P>0, it will keep running.
Your argument only makes sense in an ASIC-free world.
Let's assume you decide to just shut down your whole operation. In that
scenario, it doesn't make sense *not* to sell your equipment, even at a
loss. Just destroying it makes no economic sense: your loss would be much
worse. So you'll sell it -- at a loss -- to someone who will buy it at a
price that will make *their* ROI>0 for keeping the equipment running --
and the equipment *will* be again running, and *will* keep the hashrate
high. Only consequence of you shutting down your operation is you taking a
loss.
Even if you sell it to someone who will run it exactly as efficiently as
you, or even at lower efficiency (as long as P>0), they'll just pay less
for the equipment than you did, their ROI will be >0 and you'll bear the
loss. No drop in hashrate.
Hashrate can only respond to mining being unprofitable in the sense "P" --
not in the sense "ROI". But a miner can still go bankrupt even if P>0.
Please note that none of the above breaks the economic assumptions of the
protocol. The problem I'm talking about isn't a problem in the protocol,
but a problem for miners -- and it's the same as in many kinds of economic
activity.
Consider investing in building an oil refinery -- if the price of the
refined products get lower than expected to pay for the capital, but still
high enough to pay for operating costs, you'd rather keep it running (or
sell to someone who will keep it running) than just sell the parts as scrap
metal. In that case you might want to protect yourself against the price of
the refined products going too low.
Of course miners can (and maybe already do) hedge against these scenarios
using other kinds of instruments -- most likely facilitated by a trusted
3rd party. I'm just interested in the possibility of a new, trustless
instrument.
*Anyway* I'm far more interested in the technical feasibility of the
contract, given the economic assumptions, than it's economic practicality
in the present.
On Sun, Oct 20, 2019 at 1:17 PM Eric Voskuil <eric@voskuil.org> wrote:
> Hi Lucas,
>
> This can all be inferred from the problem statement. In other words this
> doesn=E2=80=99t change the assumptions behind my comments. However this i=
s an
> unsupportable assumption:
>
> =E2=80=9CDifficulty would only go down in this case at the end of life of=
these
> equipment, if there isn't a new wave of even more efficient equipment bei=
ng
> adopted before that.=E2=80=9D
>
> Operating at a loss would only be justifiable in the case of expected
> future returns, not due to sunk costs.
>
> e
>
> On Oct 20, 2019, at 15:46, Lucas H <lucash.dev@gmail.com> wrote:
>
> =EF=BB=BF
> Hi, guys.
>
> Thanks a lot for taking the time to read and discuss my post.
>
> I definitely wasn't clear enough about the problem statement -- so let me
> try to clarify my thinking.
>
> First, the main uncertainty the miner is trying to protect against isn't
> the inefficiency of his new equipment, but how much new mining equipment =
is
> being deployed world-wide, which he can't know in advance (as the system =
is
> permissionless).
>
> Second, there are two different metrics that can mean "profitable" that I
> think are getting confused (probably my fault for lack of using the right
> terms).
>
> - Let's call it "operational profitability", and use "P" to denote it,
> where P =3D [bitcoin earned]/time - [operational cost of running
> equipment]/time.
> Obviously if P < 0, the miner will just shut down his equipment.
> - Return on investment (ROI). A positive ROI requires not just that P > 0=
,
> but that it is enough to compensate for the initial investment of buying =
or
> building the equipment. As long as P > 0, a miner will keep his equipment
> running, even at a negative ROI, as the alternative would be an even wors=
e
> negative ROI. Sure he can sell it, but however buys it will also keep it
> running, otherwise the equipment is worthless.
>
> The instrument I describe above protects against the scenario where P > 0=
,
> but ROI < 0.
> (it's possible it could be useful in some cases to protect against P < 0,
> but that's not my main motivator and isn't an assumption)
>
> If too many miners are deploying too much new equipment at the same time,
> it's possible that your ROI becomes negative, while nobody shuts down the=
ir
> equipment and the difficulty still keeps going up. In fact, it is possibl=
e
> for all miners to have negative ROI for a while without a reduction in
> difficulty. Difficulty would only go down in this case at the end of life
> of these equipment, if there isn't a new wave of even more efficient
> equipment
> being adopted before that.
>
> Let's see a simplified scenario in which the insurance becomes useful.
> This is just one example, and other scenarios could also work.
>
> - Bitcoin price relatively constant, that is, it's not the main driver of
> P during this period.
> - Approximately constant block rewards.
> - New equipment comes to market with much higher efficiency than all old
> equipment. So the old stock of old equipment becomes irrelevant after a
> short while.
> - All miners decide to deploy new equipment, but none knows how much the
> others are deploying, or when, or at what price or P.
> - Let's just assume P>0 for all miners using the new equipment.
> - Let's assume every unit of the new equipment runs at the same maximum
> hashrate it's capable of.
>
> Let's say miner A buys Na units of the new equipment and the total number
> deployed by all miners is N.
>
> A's share of the block rewards will be Na / N.
>
> If N is much higher than A's initial estimate, his ROI might well become
> negative, and the insurance would help him prevent a loss.
>
> Hope this makes the problem a bit clearer.
>
> Thanks!
> @lucash-dev
>
> On Sun, Oct 20, 2019 at 9:16 AM Eric Voskuil <eric@voskuil.org> wrote:
>
>> So we are talking about a miner insuring against his own inefficiency.
>>
>> Furthermore a disproportionate increase in hash rate is based on the
>> expectation of higher future return (investment leads returns). So the
>> insurance could end up paying out against realized profit.
>>
>> Generally speaking, insuring investment is a zero sum game.
>>
>> e
>>
>> > On Oct 20, 2019, at 12:10, JW Weatherman <jw@mathbot.com> wrote:
>> >
>> > =EF=BB=BFOh, 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 optimal electricity and labor costs probably wouldn't be interested =
in
>> purchasing insurance for a high price, but if it was cheap enough it wou=
ld
>> 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 (decreased risk).
>> >
>> > An analogy would be car insurance. If you are an excellent driver you
>> wouldn'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 that are unwilling to take the risk of a damaged car that refrain
>> from becoming drivers until insurance allows them to lower the worst cas=
e
>> 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 Origin=
al 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 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
>> that a single miner could make an investment that becomes unprofitable i=
f
>> 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 profitabl=
e.
>> >>
>> >> 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 miner 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 security.
>> >>> -JW
>> >>> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Orig=
inal 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
>> bitcoin-dev@lists.linuxfoundation.org wrote:
>> >>>> Hi Lucas,
>> >>>> I would question the assumption inherent in the problem statement.
>> Setting aside variance discount, proximity premium, and questions of
>> relative efficiency, as these are presumably already considered by the
>> miner upon the purchase of new equipment, it=E2=80=99s not clear why a l=
oss is
>> assumed in the case of subsequently increasing hash rate.
>> >>>> The assumption of increasing hash rate implies an expectation of
>> increasing 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 lik=
ely
>> 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.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 i=
s
>> 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 goe=
s
>> up too much (the price he is paid for a hash goes down by too much) he w=
ill
>> 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 agreeme=
nt
>> >>>>>> 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 t=
he
>> 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 has=
hes
>> of one or more pre-images with a given short length, and the miner has t=
o
>> 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 insur=
er
>> if he chooses a hash that doesn't correspond to any short-length pre-ima=
ge.
>> I'm not sure about this implementation though, maybe we actually need ne=
w
>> 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
>> >
>> >
>>
>
--000000000000cc254205955e513c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Sorry, Eric, but I think you're completely missin=
g the point.</div><div><br></div><div>It has nothing to do with sunken cost=
-- but the fact that the mining equipment is good for nothing else other t=
han performing hashing operations.</div><div>As long as someone can get pai=
d more than they spend to keep the equipment running, i.e. P>0,=C2=A0 it=
will keep running.</div><div><div>Your argument only makes sense in an ASI=
C-free world.</div></div><div><br></div><div>Let's assume you decide to=
just shut down your whole operation. In that scenario, it doesn't make=
sense *not* to sell your equipment, even at a loss. Just destroying it mak=
es no economic sense: your loss would be much worse. So you'll sell it =
-- at a loss -- to someone who will buy it at a price that will make *their=
* ROI>0 for keeping the equipment running --=C2=A0 and the equipment *wi=
ll* be again running, and *will* keep the hashrate high. Only consequence o=
f you shutting down your operation is you taking a loss. <br></div><div><br=
></div><div>Even if you sell it to someone who will run it exactly as effic=
iently as you, or even at lower efficiency (as long as P>0), they'll=
just pay less for the equipment than you did, their ROI will be >0 and =
you'll bear the loss. No drop in hashrate.<br></div><div><br></div><div=
>Hashrate can only respond to mining being unprofitable in the sense "=
P" -- not in the sense "ROI". But a miner can still go bankr=
upt even if P>0.<br></div><div><br></div><div>Please note that none of t=
he above breaks the economic assumptions of the protocol. The problem I'=
;m talking about isn't a problem in the protocol, but a problem for min=
ers -- and it's the same as in many kinds of economic activity.</div><d=
iv><br></div><div>Consider investing in building an oil refinery -- if the =
price of the refined products get lower than expected to pay for the capita=
l, but still high enough to pay for operating costs, you'd rather keep =
it running (or sell to someone who will keep it running) than just sell the=
parts as scrap metal. In that case you might want to protect yourself agai=
nst the price of the refined products going too low.<br></div><div><br></di=
v><div>Of course miners can (and maybe already do) hedge against these scen=
arios using other kinds of instruments -- most likely facilitated by a trus=
ted 3rd party. I'm just interested in the possibility of a new, trustle=
ss instrument.<br></div><div><br></div><div>*Anyway* I'm far more inter=
ested in the technical feasibility of the contract, given the economic assu=
mptions, than it's economic practicality in the present.<br></div><div>=
<br></div><div><br></div><div><br></div><div><br></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Oct 20, 2019=
at 1:17 PM Eric Voskuil <<a href=3D"mailto:eric@voskuil.org">eric@vosku=
il.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"auto"><div dir=3D"ltr">Hi Lucas,</div><div dir=3D"ltr"><b=
r></div><div dir=3D"ltr">This can all be inferred from the problem statemen=
t. In other words this doesn=E2=80=99t change the assumptions behind my com=
ments. However this is an unsupportable assumption:</div><div dir=3D"ltr"><=
br></div><div dir=3D"ltr"><div>=E2=80=9CDifficulty would only go down in th=
is case at the end of life of these equipment, if there isn't a new wav=
e of even more efficient equipment being adopted before that.=E2=80=9D</div=
><div><br></div><div>Operating at a loss would only be justifiable in the c=
ase of expected future returns, not due to sunk costs.</div><div><br></div>=
<div>e</div></div><div dir=3D"ltr"><br><blockquote type=3D"cite">On Oct 20,=
2019, at 15:46, Lucas H <<a href=3D"mailto:lucash.dev@gmail.com" target=
=3D"_blank">lucash.dev@gmail.com</a>> wrote:<br><br></blockquote></div><=
blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div dir=3D"ltr"><div>Hi=
, guys.</div><div><br></div><div>Thanks a lot for taking the time to read a=
nd discuss my post.</div><div><br></div><div>I definitely wasn't clear =
enough about the problem statement -- so let me try to clarify my thinking.=
</div><div><br></div><div>First, the main uncertainty the miner is trying t=
o protect against isn't the inefficiency of his new equipment, but how =
much new mining equipment is being deployed world-wide, which he can't =
know in advance (as the system is permissionless).</div><div><br></div><div=
>Second, there are two different metrics that can mean "profitable&quo=
t; that I think are getting confused (probably my fault for lack of using t=
he right terms).</div><div><br></div><div>- Let's call it "operati=
onal profitability", and use "P" to denote it, where P =3D [=
bitcoin earned]/time - [operational cost of running equipment]/time.</div><=
div>=C2=A0=C2=A0 Obviously if P < 0, the miner will just shut down his e=
quipment.</div><div>- Return on investment (ROI). A positive ROI requires n=
ot just that P > 0, but that it is enough to compensate for the initial =
investment of buying or building the equipment. As long as P > 0, a mine=
r will keep his equipment running, even at a negative ROI, as the alternati=
ve would be an even worse negative ROI. Sure he can sell it, but however bu=
ys it will also keep it running, otherwise the equipment is worthless.</div=
><div><br></div><div>The instrument I describe above protects against the s=
cenario where P > 0, but ROI < 0.</div><div>(it's possible it cou=
ld be useful in some cases to protect against P < 0, but that's not =
my main motivator and isn't an assumption)<br></div><div><br></div><div=
>If too many miners are deploying too much new equipment at the same time, =
it's possible that your ROI becomes negative, while nobody shuts down t=
heir equipment and the difficulty still keeps going up. In fact, it is poss=
ible for all miners to have negative ROI for a while without a reduction in=
difficulty. Difficulty would only go down in this case at the end of life =
of these equipment, if there isn't a new wave of even more efficient eq=
uipment</div><div>being adopted before that.<br></div><div><br></div><div>L=
et's see a simplified scenario in which the insurance becomes useful. T=
his is just one example, and other scenarios could also work.</div><div><br=
></div><div>- Bitcoin price relatively constant, that is, it's not the =
main driver of P during this period.</div><div>- Approximately constant blo=
ck rewards.<br></div><div>- New equipment comes to market with much higher =
efficiency than all old equipment. So the old stock of old equipment become=
s irrelevant after a short while. <br></div><div>- All miners decide to dep=
loy new equipment, but none knows how much the others are deploying, or whe=
n, or at what price or P. <br></div><div>- Let's just assume P>0 for=
all miners using the new equipment.</div><div>- Let's assume every uni=
t of the new equipment runs at the same maximum hashrate it's capable o=
f.<br></div><div><br></div><div>Let's say miner A buys Na units of the =
new equipment and the total number deployed by all miners is N.</div><div><=
br></div><div>A's share of the block rewards will be Na / N. <br></div>=
<br><div>If N is much higher than A's initial estimate, his ROI might w=
ell become negative, and the insurance would help him prevent a loss.</div>=
<div><br></div><div>Hope this makes the problem a bit clearer.</div><div><b=
r></div><div>Thanks!</div><div><a class=3D"gmail_plusreply" id=3D"gmail-m_-=
5009458702983007232plusReplyChip-1">@lucash-dev</a><br></div></div><br><div=
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Oct 20=
, 2019 at 9:16 AM Eric Voskuil <<a href=3D"mailto:eric@voskuil.org" targ=
et=3D"_blank">eric@voskuil.org</a>> wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">So we are talking about a miner insuring agai=
nst his own inefficiency.<br>
<br>
Furthermore a disproportionate increase in hash rate is based on the expect=
ation of higher future return (investment leads returns). So the insurance =
could end up paying out against realized profit.<br>
<br>
Generally speaking, insuring investment is a zero sum game.<br>
<br>
e<br>
<br>
> On Oct 20, 2019, at 12:10, JW Weatherman <<a href=3D"mailto:jw@math=
bot.com" target=3D"_blank">jw@mathbot.com</a>> wrote:<br>
> <br>
> =EF=BB=BFOh, I see your point.<br>
> <br>
> However the insurance contract would protect the miner even in that ca=
se. A miner with great confidence that he is running optimal hardware and h=
as optimal electricity and labor costs probably wouldn't be interested =
in purchasing insurance for a high price, but if it was cheap enough it wou=
ld 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 (decreased risk).<br>
> <br>
> An analogy would be car insurance. If you are an excellent driver you =
wouldn'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 that are unwilling to take the risk of a damaged car that refrain f=
rom becoming drivers until insurance allows them to lower the worst case sc=
enario of a damaged car.<br>
> <br>
> -JW<br>
> <br>
> <br>
> <br>
> <br>
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origin=
al Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90<=
br>
>> On Sunday, October 20, 2019 10:57 AM, Eric Voskuil <<a href=3D"=
mailto:eric@voskuil.org" target=3D"_blank">eric@voskuil.org</a>> wrote:<=
br>
>> <br>
>> <br>
>> <br>
>>>> On Oct 20, 2019, at 10:10, JW Weatherman <a href=3D"mailto=
:jw@mathbot.com" target=3D"_blank">jw@mathbot.com</a> wrote:<br>
>>> I think the assumption is not that all miners are unprofitable=
, but that a single miner could make an investment that becomes unprofitabl=
e if the hash rate increases more than he expected.<br>
>> <br>
>> This is a restatement of the assumption I questioned. Hash rate in=
crease does not imply unprofitability. The new rig should be profitable.<br=
>
>> <br>
>> What is being assumed is a hash rate increase without a proportion=
al block reward value increase. In this case if the newest equipment is unp=
rofitable, all miners are unprofitable.<br>
>> <br>
>>> Depending on the cost of the offered insurance it would be pru=
dent for a miner to decrease his potential loss by buying insurance for thi=
s possibility.<br>
>>> And the existence of attractive insurance contracts would lowe=
r the barrier to entry for new competitors in mining and this would increas=
e bitcoins security.<br>
>>> -JW<br>
>>> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=
=90 Original Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=
=E2=80=90<br>
>>> <br>
>>>> On Sunday, October 20, 2019 1:03 AM, Eric Voskuil via bitc=
oin-dev <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank">bitcoin-dev@lists.linuxfoundation.org</a> wrote:<br>
>>>> Hi Lucas,<br>
>>>> I would question the assumption inherent in the problem st=
atement. Setting aside variance discount, proximity premium, and questions =
of relative efficiency, as these are presumably already considered by the m=
iner upon the purchase of new equipment, it=E2=80=99s not clear why a loss =
is assumed in the case of subsequently increasing hash rate.<br>
>>>> The assumption of increasing hash rate implies an expectat=
ion of increasing return on investment. There are certainly speculative err=
ors, but a loss on new equipment implies all miners are operating at a loss=
, which is not a sustainable situation.<br>
>>>> If any miner is profitable it is the miner with the new eq=
uipment, and if he is not, hash rate will drop until he is. This drop is mo=
st likely to be precipitated by older equipment going offline.<br>
>>>> Best,<br>
>>>> Eric<br>
>>>> <br>
>>>>>> On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev@lists.linuxfoundation.org</a> wrote:<br>
>>>>>> Hi,<br>
>>>>>> 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.<b=
r>
>>>>>> TL;DR: a trustless contract that guarantees minimu=
m profitability of a mining operation -- in case Bitcoin/hash price goes to=
o low. It can be trustless bc we can use the assumption that the price of h=
ashing is low to unlock funds.<br>
>>>>>> The problem:<br>
>>>>>> A miner invests in new mining equipment, but if th=
e hash-rate goes up too much (the price he is paid for a hash goes down by =
too much) he will have a loss.<br>
>>>>>> Solution: trustless hash-price insurance contract =
(or can we call it an option to sell hashes at a given price?)<br>
>>>>>> An insurer who believes that it's unlikely the=
price of a hash will go down a lot negotiates a contract with the miner im=
plemented as a Bitcoin transaction:<br>
>>>>>> Inputs: a deposit from the insurer and a premium p=
ayment by the miner<br>
>>>>>> Output1: simply the premium payment to the insurer=
<br>
>>>>>> Output2 -- that's the actual insurance<br>
>>>>>> There are three OR'ed conditions for paying it=
:<br>
>>>>>> A. After expiry date (in blocks) insurer can spend=
<br>
>>>>>> B. Both miner and insurer can spend at any time by=
mutual agreement<br>
>>>>>> C. Before expiry, miner can spend by providing a p=
re-image that produces a hash within certain difficulty constraints<br>
>>>>>> The thing that makes it a hash-price insurance (or=
option, pardon my lack of precise financial jargon), is that if hashing be=
comes cheap enough, it becomes profitable to spend resources finding a suit=
able pre-image, rather than mining Bitcoin.<br>
>>>>>> Of course, both parties can reach an agreement tha=
t 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.<br>
>>>>>> If the price doesn't go down enough, the miner=
just mines Bitcoin and the insurer gets his deposit back.<br>
>>>>>> It's basically an instrument for guaranteeing =
a minimum profitability of the mining operation.<br>
>>>>>> Implementation issues: unfortunately we can't =
do arithmetic comparison with long integers >32bit in the script, so imp=
lementation 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 th=
e miner has to provide the exact pre-images. The pre-images are chosen by t=
he insurer, and we would need a "honesty" deposit or other mechan=
ism 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 t=
hough, maybe we actually need new opcodes.<br>
>>>>>> What do you guys think?<br>
>>>>>> Thanks for reading it all! Hope it was worth your =
time!<br>
>>>>> <br>
>>>>> bitcoin-dev mailing list<br>
>>>>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
>>>>> <a href=3D"https://lists.linuxfoundation.org/mailman/l=
istinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.lin=
uxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
>>>> <br>
>>>> bitcoin-dev mailing list<br>
>>>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
>>>> <a href=3D"https://lists.linuxfoundation.org/mailman/listi=
nfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfo=
undation.org/mailman/listinfo/bitcoin-dev</a><br>
> <br>
> <br>
</blockquote></div>
</div></blockquote></div></blockquote></div>
--000000000000cc254205955e513c--
|