path: root/39/44eaea3b2170c7078ad08bdeea342d254c3efd

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&#39;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&gt;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&#39;s assume you decide to=
 just shut down your whole operation. In that scenario, it doesn&#39;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&#39;ll sell it =
-- at a loss -- to someone who will buy it at a price that will make *their=
* ROI&gt;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&gt;0), they&#39;ll=
 just pay less for the equipment than you did, their ROI will be &gt;0 and =
you&#39;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 &quot;=
P&quot; -- not in the sense &quot;ROI&quot;. But a miner can still go bankr=
upt even if P&gt;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&#39=
;m talking about isn&#39;t a problem in the protocol, but a problem for min=
ers -- and it&#39;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&#39;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&#39;m just interested in the possibility of a new, trustle=
ss instrument.<br></div><div><br></div><div>*Anyway* I&#39;m far more inter=
ested in the technical feasibility of the contract, given the economic assu=
mptions, than it&#39;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 &lt;<a href=3D"mailto:eric@voskuil.org">eric@vosku=
il.org</a>&gt; 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&#39;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 &lt;<a href=3D"mailto:lucash.dev@gmail.com" target=
=3D"_blank">lucash.dev@gmail.com</a>&gt; 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&#39;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&#39;t the inefficiency of his new equipment, but how =
much new mining equipment is being deployed world-wide, which he can&#39;t =
know in advance (as the system is permissionless).</div><div><br></div><div=
>Second, there are two different metrics that can mean &quot;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&#39;s call it &quot;operati=
onal profitability&quot;, and use &quot;P&quot; to denote it, where P =3D [=
bitcoin earned]/time - [operational cost of running equipment]/time.</div><=
div>=C2=A0=C2=A0 Obviously if P &lt; 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 &gt; 0, but that it is enough to compensate for the initial =
investment of buying or building the equipment. As long as P &gt; 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 &gt; 0, but ROI &lt; 0.</div><div>(it&#39;s possible it cou=
ld be useful in some cases to protect against P &lt; 0, but that&#39;s not =
my main motivator and isn&#39;t an assumption)<br></div><div><br></div><div=
>If too many miners are deploying too much new equipment at the same time, =
it&#39;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&#39;t a new wave of even more efficient eq=
uipment</div><div>being adopted before that.<br></div><div><br></div><div>L=
et&#39;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&#39;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&#39;s just assume P&gt;0 for=
 all miners using the new equipment.</div><div>- Let&#39;s assume every uni=
t of the new equipment runs at the same maximum hashrate it&#39;s capable o=
f.<br></div><div><br></div><div>Let&#39;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&#39;s share of the block rewards will be Na / N. <br></div>=
<br><div>If N is much higher than A&#39;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 &lt;<a href=3D"mailto:eric@voskuil.org" targ=
et=3D"_blank">eric@voskuil.org</a>&gt; 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>
&gt; On Oct 20, 2019, at 12:10, JW Weatherman &lt;<a href=3D"mailto:jw@math=
bot.com" target=3D"_blank">jw@mathbot.com</a>&gt; wrote:<br>
&gt; <br>
&gt; =EF=BB=BFOh, I see your point.<br>
&gt; <br>
&gt; 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&#39;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>
&gt; <br>
&gt; An analogy would be car insurance. If you are an excellent driver you =
wouldn&#39;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>
&gt; <br>
&gt; -JW<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; =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>
&gt;&gt; On Sunday, October 20, 2019 10:57 AM, Eric Voskuil &lt;<a href=3D"=
mailto:eric@voskuil.org" target=3D"_blank">eric@voskuil.org</a>&gt; wrote:<=
br>
&gt;&gt; <br>
&gt;&gt; <br>
&gt;&gt; <br>
&gt;&gt;&gt;&gt; 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>
&gt;&gt;&gt; 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>
&gt;&gt; <br>
&gt;&gt; This is a restatement of the assumption I questioned. Hash rate in=
crease does not imply unprofitability. The new rig should be profitable.<br=
>
&gt;&gt; <br>
&gt;&gt; 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>
&gt;&gt; <br>
&gt;&gt;&gt; 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>
&gt;&gt;&gt; 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>
&gt;&gt;&gt; -JW<br>
&gt;&gt;&gt; =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>
&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; 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>
&gt;&gt;&gt;&gt; Hi Lucas,<br>
&gt;&gt;&gt;&gt; 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>
&gt;&gt;&gt;&gt; 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>
&gt;&gt;&gt;&gt; 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>
&gt;&gt;&gt;&gt; Best,<br>
&gt;&gt;&gt;&gt; Eric<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt; 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>
&gt;&gt;&gt;&gt;&gt;&gt; Hi,<br>
&gt;&gt;&gt;&gt;&gt;&gt; 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>
&gt;&gt;&gt;&gt;&gt;&gt; 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>
&gt;&gt;&gt;&gt;&gt;&gt; The problem:<br>
&gt;&gt;&gt;&gt;&gt;&gt; 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>
&gt;&gt;&gt;&gt;&gt;&gt; Solution: trustless hash-price insurance contract =
(or can we call it an option to sell hashes at a given price?)<br>
&gt;&gt;&gt;&gt;&gt;&gt; An insurer who believes that it&#39;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>
&gt;&gt;&gt;&gt;&gt;&gt; Inputs: a deposit from the insurer and a premium p=
ayment by the miner<br>
&gt;&gt;&gt;&gt;&gt;&gt; Output1: simply the premium payment to the insurer=
<br>
&gt;&gt;&gt;&gt;&gt;&gt; Output2 -- that&#39;s the actual insurance<br>
&gt;&gt;&gt;&gt;&gt;&gt; There are three OR&#39;ed conditions for paying it=
:<br>
&gt;&gt;&gt;&gt;&gt;&gt; A. After expiry date (in blocks) insurer can spend=
<br>
&gt;&gt;&gt;&gt;&gt;&gt; B. Both miner and insurer can spend at any time by=
 mutual agreement<br>
&gt;&gt;&gt;&gt;&gt;&gt; C. Before expiry, miner can spend by providing a p=
re-image that produces a hash within certain difficulty constraints<br>
&gt;&gt;&gt;&gt;&gt;&gt; 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>
&gt;&gt;&gt;&gt;&gt;&gt; Of course, both parties can reach an agreement tha=
t doesn&#39;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>
&gt;&gt;&gt;&gt;&gt;&gt; If the price doesn&#39;t go down enough, the miner=
 just mines Bitcoin and the insurer gets his deposit back.<br>
&gt;&gt;&gt;&gt;&gt;&gt; It&#39;s basically an instrument for guaranteeing =
a minimum profitability of the mining operation.<br>
&gt;&gt;&gt;&gt;&gt;&gt; Implementation issues: unfortunately we can&#39;t =
do arithmetic comparison with long integers &gt;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 &quot;honesty&quot; deposit or other mechan=
ism to punish the insurer if he chooses a hash that doesn&#39;t correspond =
to any short-length pre-image. I&#39;m not sure about this implementation t=
hough, maybe we actually need new opcodes.<br>
&gt;&gt;&gt;&gt;&gt;&gt; What do you guys think?<br>
&gt;&gt;&gt;&gt;&gt;&gt; Thanks for reading it all! Hope it was worth your =
time!<br>
&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt;&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt;&gt;&gt;&gt;&gt; <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>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt;&gt;&gt;&gt; <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>
&gt; <br>
&gt; <br>
</blockquote></div>
</div></blockquote></div></blockquote></div>

--000000000000cc254205955e513c--