path: root/91/7aaaccec9e64a3e9d2754343fe9bc2b9f08db1

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 41CEAD49
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 21 Oct 2019 03:34:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com
	[209.85.210.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 18FC9896
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 21 Oct 2019 03:34:20 +0000 (UTC)
Received: by mail-pf1-f173.google.com with SMTP id a2so7499656pfo.10
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 20 Oct 2019 20:34:20 -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
	:cc:to; bh=b7yc47U0D7XrYnqkQcvBbdnbteWq4LntzlGVdN6+No4=;
	b=OFqk7WcN/Eu0GcHLg+Ihp6Kp41hJjMdgrQQA3mPZWCRw8DaLFlmXnvfKtW6Oa8qt5I
	d3dZJbFMn6h70CxeSUrW/mvKkO24oCCg6wefpmyTIwyrleHWRHR1VGpQ4vkk6JMn66j8
	YTMP9vLimjue3/OqQ474A87AGIH8jGgvpz7wpj1sc63vmBMKi8xrmue+KmPxOyx5xV08
	Lxt7azEXn7SwBP3nZ+rWnKYZmDLuEQvN8pXiJxV0vnJGyU6qU734z5eABiQT/vZI3D0e
	YfqkmmllIJPuYP11BBQ2uAdkPHs7VCU7vN2ujKFPFembSajR6TRJvKZ0HRD1Rd3k4eIb
	wdNQ==
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:cc:to;
	bh=b7yc47U0D7XrYnqkQcvBbdnbteWq4LntzlGVdN6+No4=;
	b=HkGpOWTlVPNJ5FC/uyxXoOCBLJnAM9C6zZ/xr4mfxkOTQLrzcwazbVSQTeCJO7WwEj
	MOCB8clKEvCL3AoKQKJUyzxYCPl/8aNgFUgGZTfcs1ZWWywwo14QG9vVmNweo8BfMoNv
	JQWiIzQ7piFeD3J7u17VnB9YD/5O9/ZiyOIdylJ6xOAHCqt7n1Qjv0qyjruM3Vi6GEuY
	6AoO7QQqglMcKZhH4MJF7xpX8EXQ9NcHjFoAPezFqBvFj2e7og02xbvfz1MkcQbeUP0W
	3+FfNBTvKn5UYkej0WCxm+6VpAz/bGMiJ4G+0yd5z2oQ6HLrF8ZQbkhlpc4XHwdHZj8o
	XOWQ==
X-Gm-Message-State: APjAAAUv9bWiuuhrPSz8/Ixjs7jjS6xO/1IfSzdMDSC0tASn+7AC6w8a
	J6Y2dOlKvqU6aU7wQxjw6DFf6g==
X-Google-Smtp-Source: APXvYqx3DnqmxNv0r0+VhSJtSRMw7qGhggY8Zsr/wvO74B1yKbpnun8Es28u7WWPPjVn+KRXKyj5Aw==
X-Received: by 2002:a63:c748:: with SMTP id v8mr23515221pgg.348.1571628859407; 
	Sun, 20 Oct 2019 20:34:19 -0700 (PDT)
Received: from [172.19.248.77] ([38.98.37.135])
	by smtp.gmail.com with ESMTPSA id
	d14sm20024903pfh.36.2019.10.20.20.34.17
	(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
	Sun, 20 Oct 2019 20:34:18 -0700 (PDT)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-73C458BA-D1F2-4FAB-A00B-3911CC658467
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Sun, 20 Oct 2019 20:34:12 -0700
Message-Id: <DA5B30F2-4553-4A8F-BB37-F8F3DC67A260@voskuil.org>
To: Lucas H <lucash.dev@gmail.com>
X-Mailer: iPhone Mail (17A860)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, HTML_MESSAGE, 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: Mon, 21 Oct 2019 05:00:55 +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: Mon, 21 Oct 2019 03:34:22 -0000


--Apple-Mail-73C458BA-D1F2-4FAB-A00B-3911CC658467
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Lucas,

You are assuming that all miners operate at equal efficiency. The least effi=
cient miners are expected to drop offline first. Even with identical hardwar=
e and operational efficiency, the necessary variance discount and proximity p=
remium create a profitability spread. The relation between hash rate and rew=
ard value is not only predictable, it is easily observed.

There is an error in your sold hardware scenario. When equipment is sold at a=
 loss, the remaining operating miners have a reduced capital cost, which mea=
ns, despite higher hash rate, miners are profitable. The least efficient min=
ers have written down their expected losses and hash rate becomes consistent=
 with market returns despite being higher.

With respect to the contract, I don=E2=80=99t yet see this working, but ther=
e are several gaps and I don=E2=80=99t want to make assumptions. More detail=
ed specification would be helpful. Even a full scenario with numbers and jus=
tifications would be something.

e

> On Oct 20, 2019, at 14:33, Lucas H <lucash.dev@gmail.com> wrote:
>=20
> Sorry, Eric, but I think you're completely missing the point.
>=20
> It has nothing to do with sunken cost -- but the fact that the mining equi=
pment 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.
>=20
> Let's assume you decide to just shut down your whole operation. In that sc=
enario, it doesn't make sense *not* to sell your equipment, even at a loss. J=
ust 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 w=
ill make *their* ROI>0 for keeping the equipment running --  and the equipme=
nt *will* be again running, and *will* keep the hashrate high. Only conseque=
nce of you shutting down your operation is you taking a loss.=20
>=20
> Even if you sell it to someone who will run it exactly as efficiently as y=
ou, or even at lower efficiency (as long as P>0), they'll just pay less for t=
he equipment than you did, their ROI will be >0 and you'll bear the loss. No=
 drop in hashrate.
>=20
> 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.
>=20
> Please note that none of the above breaks the economic assumptions of the p=
rotocol. 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 activi=
ty.
>=20
> Consider investing in building an oil refinery -- if the price of the refi=
ned products get lower than expected to pay for the capital, but still high e=
nough to pay for operating costs, you'd rather keep it running (or sell to s=
omeone 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 refin=
ed products going too low.
>=20
> Of course miners can (and maybe already do) hedge against these scenarios u=
sing other kinds of instruments -- most likely facilitated by a trusted 3rd p=
arty. I'm just interested in the possibility of a new, trustless instrument.=

>=20
> *Anyway* I'm far more interested in the technical feasibility of the contr=
act, given the economic assumptions, than it's economic practicality in the p=
resent.
>=20
>=20
>=20
>=20
>=20
>>> On Sun, Oct 20, 2019 at 1:17 PM Eric Voskuil <eric@voskuil.org> wrote:
>>> Hi Lucas,
>>>=20
>>> 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 is a=
n unsupportable assumption:
>>>=20
>>> =E2=80=9CDifficulty would only go down in this case at the end of life o=
f these equipment, if there isn't a new wave of even more efficient equipmen=
t being adopted before that.=E2=80=9D
>>>=20
>>> Operating at a loss would only be justifiable in the case of expected fu=
ture returns, not due to sunk costs.
>>>=20
>>> e
>>>=20
>>>> On Oct 20, 2019, at 15:46, Lucas H <lucash.dev@gmail.com> wrote:
>>>>=20
>>> =EF=BB=BF
>>> Hi, guys.
>>>=20
>>> Thanks a lot for taking the time to read and discuss my post.
>>>=20
>>> I definitely wasn't clear enough about the problem statement -- so let m=
e try to clarify my thinking.
>>>=20
>>> 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).
>>>=20
>>> 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 t=
erms).
>>>=20
>>> - Let's call it "operational profitability", and use "P" to denote it, w=
here P =3D [bitcoin earned]/time - [operational cost of running equipment]/t=
ime.
>>>    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 o=
r building the equipment. As long as P > 0, a miner will keep his equipment r=
unning, even at a negative ROI, as the alternative would be an even worse ne=
gative ROI. Sure he can sell it, but however buys it will also keep it runni=
ng, otherwise the equipment is worthless.
>>>=20
>>> 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)
>>>=20
>>> 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 thei=
r equipment and the difficulty still keeps going up. In fact, it is possible=
 for all miners to have negative ROI for a while without a reduction in diff=
iculty. Difficulty would only go down in this case at the end of life of the=
se equipment, if there isn't a new wave of even more efficient equipment
>>> being adopted before that.
>>>=20
>>> Let's see a simplified scenario in which the insurance becomes useful. T=
his is just one example, and other scenarios could also work.
>>>=20
>>> - Bitcoin price relatively constant, that is, it's not the main driver o=
f 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 sho=
rt while.=20
>>> - All miners decide to deploy new equipment, but none knows how much the=
 others are deploying, or when, or at what price or P.=20
>>> - 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 h=
ashrate it's capable of.
>>>=20
>>> Let's say miner A buys Na units of the new equipment and the total numbe=
r deployed by all miners is N.
>>>=20
>>> A's share of the block rewards will be Na / N.=20
>>>=20
>>> 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.
>>>=20
>>> Hope this makes the problem a bit clearer.
>>>=20
>>> Thanks!
>>> @lucash-dev
>>>=20
>>>> 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.
>>>>=20
>>>> Furthermore a disproportionate increase in hash rate is based on the ex=
pectation of higher future return (investment leads returns). So the insuran=
ce could end up paying out against realized profit.
>>>>=20
>>>> Generally speaking, insuring investment is a zero sum game.
>>>>=20
>>>> e
>>>>=20
>>>> > On Oct 20, 2019, at 12:10, JW Weatherman <jw@mathbot.com> wrote:
>>>> >=20
>>>> > =EF=BB=BFOh, I see your point.
>>>> >=20
>>>> > However the insurance contract would protect the miner even in that c=
ase. 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 pu=
rchasing insurance for a high price, but if it was cheap enough it would sti=
ll be worth it. And any potential new entrants on the edge of jumping in wou=
ld enter when they otherwise would not have because of the decreased costs (=
decreased risk).
>>>> >=20
>>>> > 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 even=
t of an accident, but if it is cheap enough you would. And there may be peop=
le that are unwilling to take the risk of a damaged car that refrain from be=
coming drivers until insurance allows them to lower the worst case scenario o=
f a damaged car.
>>>> >=20
>>>> > -JW
>>>> >=20
>>>> >=20
>>>> >=20
>>>> >=20
>>>> > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origi=
nal 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:
>>>> >>=20
>>>> >>=20
>>>> >>=20
>>>> >>>> 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 if t=
he hash rate increases more than he expected.
>>>> >>=20
>>>> >> This is a restatement of the assumption I questioned. Hash rate incr=
ease does not imply unprofitability. The new rig should be profitable.
>>>> >>=20
>>>> >> What is being assumed is a hash rate increase without a proportional=
 block reward value increase. In this case if the newest equipment is unprof=
itable, all miners are unprofitable.
>>>> >>=20
>>>> >>> Depending on the cost of the offered insurance it would be prudent f=
or a miner to decrease his potential loss by buying insurance for this possi=
bility.
>>>> >>> And the existence of attractive insurance contracts would lower the=
 barrier to entry for new competitors in mining and this would increase bitc=
oins security.
>>>> >>> -JW
>>>> >>> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Ori=
ginal Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=

>>>> >>>=20
>>>> >>>> On Sunday, October 20, 2019 1:03 AM, Eric Voskuil via bitcoin-dev b=
itcoin-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 relati=
ve 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 i=
n the case of subsequently increasing hash rate.
>>>> >>>> The assumption of increasing hash rate implies an expectation of i=
ncreasing return on investment. There are certainly speculative errors, but a=
 loss on new equipment implies all miners are operating at a loss, which is n=
ot 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
>>>> >>>>=20
>>>> >>>>>> On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev bitcoin-dev@l=
ists.linuxfoundation.org wrote:
>>>> >>>>>> Hi,
>>>> >>>>>> This is my first post to this list -- even though I did some tin=
y contributions to bitcoin core I feel quite a beginner -- so if my idea is s=
tupid, already known, or too off-topic, just let me know.
>>>> >>>>>> TL;DR: a trustless contract that guarantees minimum profitabilit=
y 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 to=
 unlock funds.
>>>> >>>>>> The problem:
>>>> >>>>>> A miner invests in new mining equipment, but if the hash-rate go=
es 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 cal=
l it an option to sell hashes at a given price?)
>>>> >>>>>> An insurer who believes that it's unlikely the price of a hash w=
ill 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 agreem=
ent
>>>> >>>>>> 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, pardo=
n 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, r=
ather than mining Bitcoin.
>>>> >>>>>> Of course, both parties can reach an agreement that doesn't requ=
ire actually spending these resources -- so the miner can still mine Bitcoin=
 and compensate for the lower-than-expected reward with part of the insuranc=
e deposit.
>>>> >>>>>> If the price doesn't go down enough, the miner just mines Bitcoi=
n and the insurer gets his deposit back.
>>>> >>>>>> It's basically an instrument for guaranteeing a minimum profitab=
ility of the mining operation.
>>>> >>>>>> Implementation issues: unfortunately we can't do arithmetic comp=
arison 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 o=
r more pre-images with a given short length, and the miner has to provide th=
e exact pre-images. The pre-images are chosen by the insurer, and we would n=
eed a "honesty" deposit or other mechanism to punish the insurer if he choos=
es 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!
>>>> >>>>>=20
>>>> >>>>> bitcoin-dev mailing list
>>>> >>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>> >>>>=20
>>>> >>>> bitcoin-dev mailing list
>>>> >>>> bitcoin-dev@lists.linuxfoundation.org
>>>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>> >=20
>>>> >

--Apple-Mail-73C458BA-D1F2-4FAB-A00B-3911CC658467
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"><p class=3D"p1" style=3D"-=
webkit-text-size-adjust: auto; margin: 0px; font-stretch: normal; line-heigh=
t: normal; color: rgb(220, 220, 220);"><span class=3D"s1">Hi Lucas,</span></=
p><p class=3D"p2" style=3D"-webkit-text-size-adjust: auto; margin: 0px; font=
-stretch: normal; line-height: normal; color: rgb(220, 220, 220); min-height=
: 27.4px;"><span class=3D"s1"></span><br></p><p class=3D"p1" style=3D"-webki=
t-text-size-adjust: auto; margin: 0px; font-stretch: normal; line-height: no=
rmal; color: rgb(220, 220, 220);"><span class=3D"s1">You are assuming that a=
ll miners operate at equal efficiency. The least efficient miners are expect=
ed to drop offline first. Even with identical hardware and operational effic=
iency, the necessary variance discount and proximity premium create a profit=
ability spread. The relation between hash rate and reward value is not only p=
redictable, it is easily observed.</span></p><p class=3D"p2" style=3D"-webki=
t-text-size-adjust: auto; margin: 0px; font-stretch: normal; line-height: no=
rmal; color: rgb(220, 220, 220); min-height: 27.4px;"><span class=3D"s1"></s=
pan><br></p><p class=3D"p1" style=3D"-webkit-text-size-adjust: auto; margin:=
 0px; font-stretch: normal; line-height: normal; color: rgb(220, 220, 220);"=
><span class=3D"s1">There is an error in your sold hardware scenario. When e=
quipment is sold at a loss, the remaining operating miners have a reduced ca=
pital cost, which means, despite higher hash rate, miners are profitable. Th=
e least efficient miners have written down their expected losses and hash ra=
te becomes consistent with market returns despite being higher.</span></p><p=
 class=3D"p2" style=3D"-webkit-text-size-adjust: auto; margin: 0px; font-str=
etch: normal; line-height: normal; color: rgb(220, 220, 220); min-height: 27=
.4px;"><span class=3D"s1"></span><br></p><p class=3D"p1" style=3D"-webkit-te=
xt-size-adjust: auto; margin: 0px; font-stretch: normal; line-height: normal=
; color: rgb(220, 220, 220);"><span class=3D"s1">With respect to the contrac=
t, I don=E2=80=99t yet see this working, but there are several gaps and I do=
n=E2=80=99t want to make assumptions. More detailed specification would be h=
elpful. Even a full scenario with numbers and justifications would be someth=
ing.</span></p><p class=3D"p2" style=3D"-webkit-text-size-adjust: auto; marg=
in: 0px; font-stretch: normal; line-height: normal; color: rgb(220, 220, 220=
); min-height: 27.4px;"><span class=3D"s1"></span><br></p><p class=3D"p1" st=
yle=3D"-webkit-text-size-adjust: auto; margin: 0px; font-stretch: normal; li=
ne-height: normal; color: rgb(220, 220, 220);"><span class=3D"s1">e</span></=
p></div><div dir=3D"ltr"><br><blockquote type=3D"cite">On Oct 20, 2019, at 1=
4:33, Lucas H &lt;lucash.dev@gmail.com&gt; wrote:<br><br></blockquote></div>=
<blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"ltr"><div>Sorry, Eric=
, but I think you're completely missing the point.</div><div><br></div><div>=
It has nothing to do with sunken cost -- but the fact that the mining equipm=
ent is good for nothing else other than performing hashing operations.</div>=
<div>As long as someone can get paid more than they spend to keep the equipm=
ent running, i.e. P&gt;0,&nbsp; it will keep running.</div><div><div>Your ar=
gument only makes sense in an ASIC-free world.</div></div><div><br></div><di=
v>Let's assume you decide to just shut down your whole operation. In that sc=
enario, it doesn't make sense *not* to sell your equipment, even at a loss. J=
ust 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 w=
ill make *their* ROI&gt;0 for keeping the equipment running --&nbsp; and the=
 equipment *will* be again running, and *will* keep the hashrate high. Only c=
onsequence of you shutting down your operation is you taking a loss. <br></d=
iv><div><br></div><div>Even if you sell it to someone who will run it exactl=
y as efficiently as you, or even at lower efficiency (as long as P&gt;0), th=
ey'll just pay less for the equipment than you did, their ROI will be &gt;0 a=
nd you'll bear the loss. No drop in hashrate.<br></div><div><br></div><div>H=
ashrate can only respond to mining being unprofitable in the sense "P" -- no=
t in the sense "ROI". But a miner can still go bankrupt even if P&gt;0.<br><=
/div><div><br></div><div>Please note that none of the above breaks the econo=
mic assumptions of the protocol. The problem I'm talking about isn't a probl=
em in the protocol, but a problem for miners -- and it's the same as in many=
 kinds of economic activity.</div><div><br></div><div>Consider investing in b=
uilding an oil refinery -- if the price of the refined products get lower th=
an expected to pay for the capital, but still high enough to pay for operati=
ng costs, you'd rather keep it running (or sell to someone who will keep it r=
unning) 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=
.<br></div><div><br></div><div>Of course miners can (and maybe already do) h=
edge against these scenarios using other kinds of instruments -- most likely=
 facilitated by a trusted 3rd party. I'm just interested in the possibility o=
f a new, trustless instrument.<br></div><div><br></div><div>*Anyway* I'm far=
 more interested in the technical feasibility of the contract, given the eco=
nomic assumptions, 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 c=
lass=3D"gmail_quote"><blockquote type=3D"cite" __apple_fixed_attribute=3D"tr=
ue"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Oct 20, 2019 at 1:17 PM Er=
ic Voskuil &lt;<a href=3D"mailto:eric@voskuil.org">eric@voskuil.org</a>&gt; w=
rote:<br></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margi=
n: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"><br></di=
v><div dir=3D"ltr">This can all be inferred from the problem statement. In o=
ther words this doesn=E2=80=99t change the assumptions behind my comments. H=
owever 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 this case at=
 the end of life of these equipment, if there isn't a new wave of even more e=
fficient equipment being adopted before that.=E2=80=9D</div><div><br></div><=
div>Operating at a loss would only be justifiable in the case of expected fu=
ture 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, Luc=
as H &lt;<a href=3D"mailto:lucash.dev@gmail.com" target=3D"_blank">lucash.de=
v@gmail.com</a>&gt; wrote:<br><br></blockquote></div><blockquote type=3D"cit=
e"><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 and discuss my post.</div=
><div><br></div><div>I definitely wasn't clear enough about the problem stat=
ement -- so let me try to clarify my thinking.</div><div><br></div><div>Firs=
t, the main uncertainty the miner is trying to protect against isn't the ine=
fficiency of his new equipment, but how much new mining equipment is being d=
eployed world-wide, which he can't know in advance (as the system is permiss=
ionless).</div><div><br></div><div>Second, there are two different metrics t=
hat can mean "profitable" that I think are getting confused (probably my fau=
lt for lack of using the right terms).</div><div><br></div><div>- Let's call=
 it "operational profitability", and use "P" to denote it, where P =3D [bitc=
oin earned]/time - [operational cost of running equipment]/time.</div><div>&=
nbsp;&nbsp; Obviously if P &lt; 0, the miner will just shut down his equipme=
nt.</div><div>- Return on investment (ROI). A positive ROI requires not just=
 that P &gt; 0, but that it is enough to compensate for the initial investme=
nt of buying or building the equipment. As long as P &gt; 0, a miner will ke=
ep his equipment running, even at a negative ROI, as the alternative would b=
e an even worse negative ROI. Sure he can sell it, but however buys it will a=
lso keep it running, otherwise the equipment is worthless.</div><div><br></d=
iv><div>The instrument I describe above protects against the scenario where P=
 &gt; 0, but ROI &lt; 0.</div><div>(it's possible it could be useful in some=
 cases to protect against P &lt; 0, but that's not my main motivator and isn=
't an assumption)<br></div><div><br></div><div>If too many miners are deploy=
ing too much new equipment at the same time, it's possible that your ROI bec=
omes negative, while nobody shuts down their equipment and the difficulty st=
ill keeps going up. In fact, it is possible for all miners to have negative R=
OI for a while without a reduction in difficulty. Difficulty would only go d=
own in this case at the end of life of these equipment, if there isn't a new=
 wave of even more efficient equipment</div><div>being adopted before that.<=
br></div><div><br></div><div>Let's see a simplified scenario in which the in=
surance becomes useful. This is just one example, and other scenarios could a=
lso 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>- Approxima=
tely constant block rewards.<br></div><div>- New equipment comes to market w=
ith much higher efficiency than all old equipment. So the old stock of old e=
quipment becomes irrelevant after a short while. <br></div><div>- All miners=
 decide to deploy new equipment, but none knows how much the others are depl=
oying, or when, or at what price or P. <br></div><div>- Let's just assume P&=
gt;0 for all miners using the new equipment.</div><div>- Let's assume every u=
nit of the new equipment runs at the same maximum hashrate it's capable of.<=
br></div><div><br></div><div>Let's say miner A buys Na units of the new equi=
pment 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 i=
s much higher than A's initial estimate, his ROI might well become negative,=
 and the insurance would help him prevent a loss.</div><div><br></div><div>H=
ope this makes the problem a bit clearer.</div><div><br></div><div>Thanks!</=
div><div><a class=3D"gmail_plusreply" id=3D"gmail-m_-5009458702983007232plus=
ReplyChip-1">@lucash-dev</a><br></div></div><br><div class=3D"gmail_quote"><=
blockquote type=3D"cite" __apple_fixed_attribute=3D"true"><div dir=3D"ltr" c=
lass=3D"gmail_attr">On Sun, Oct 20, 2019 at 9:16 AM Eric Voskuil &lt;<a href=
=3D"mailto:eric@voskuil.org" target=3D"_blank">eric@voskuil.org</a>&gt; wrot=
e:<br></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So=
 we are talking about a miner insuring against his own inefficiency.<br>
<br>
Furthermore a disproportionate increase in hash rate is based on the expecta=
tion of higher future return (investment leads returns). So the insurance co=
uld 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@mathb=
ot.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 cas=
e. A miner with great confidence that he is running optimal hardware and has=
 optimal electricity and labor costs probably wouldn't be interested in purc=
hasing 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 (de=
creased risk).<br>
&gt; <br>
&gt; An analogy would be car insurance. If you are an excellent driver you w=
ouldn't be willing to spend a ton of money to protect your car in the event o=
f 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 becomi=
ng drivers until insurance allows them to lower the worst case scenario 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 Origina=
l 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"m=
ailto: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 unprofitable i=
f 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 inc=
rease 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 proportiona=
l block reward value increase. In this case if the newest equipment is unpro=
fitable, all miners are unprofitable.<br>
&gt;&gt; <br>
&gt;&gt;&gt; Depending on the cost of the offered insurance it would be prud=
ent for a miner to decrease his potential loss by buying insurance for this p=
ossibility.<br>
&gt;&gt;&gt; And the existence of attractive insurance contracts would lower=
 the barrier to entry for new competitors in mining and this would increase b=
itcoins 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 bitco=
in-dev <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">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 sta=
tement. Setting aside variance discount, proximity premium, and questions of=
 relative efficiency, as these are presumably already considered by the mine=
r upon the purchase of new equipment, it=E2=80=99s not clear why a loss is a=
ssumed in the case of subsequently increasing hash rate.<br>
&gt;&gt;&gt;&gt; The assumption of increasing hash rate implies an expectati=
on of increasing return on investment. There are certainly speculative error=
s, but a loss on new equipment implies all miners are operating at a loss, w=
hich is not a sustainable situation.<br>
&gt;&gt;&gt;&gt; If any miner is profitable it is the miner with the new equ=
ipment, 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.<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">bi=
tcoin-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 i=
f my idea is stupid, already known, or too off-topic, just let me know.<br>
&gt;&gt;&gt;&gt;&gt;&gt; TL;DR: a trustless contract that guarantees minimum=
 profitability of a mining operation -- in case Bitcoin/hash price goes too l=
ow. It can be trustless bc we can use the assumption that the price of hashi=
ng 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 the=
 hash-rate goes up too much (the price he is paid for a hash goes down by to=
o 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's unlikely the pric=
e of a hash will go down a lot negotiates a contract with the miner implemen=
ted as a Bitcoin transaction:<br>
&gt;&gt;&gt;&gt;&gt;&gt; Inputs: a deposit from the insurer and a premium pa=
yment 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's the actual insurance<br>
&gt;&gt;&gt;&gt;&gt;&gt; There are three OR'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 m=
utual agreement<br>
&gt;&gt;&gt;&gt;&gt;&gt; C. Before expiry, miner can spend by providing a pr=
e-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 o=
ption, pardon my lack of precise financial jargon), is that if hashing becom=
es cheap enough, it becomes profitable to spend resources finding a suitable=
 pre-image, rather than mining Bitcoin.<br>
&gt;&gt;&gt;&gt;&gt;&gt; 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=
 the insurance deposit.<br>
&gt;&gt;&gt;&gt;&gt;&gt; If the price doesn't go down enough, the miner just=
 mines Bitcoin and the insurer gets his deposit back.<br>
&gt;&gt;&gt;&gt;&gt;&gt; It's basically an instrument for guaranteeing a min=
imum profitability of the mining operation.<br>
&gt;&gt;&gt;&gt;&gt;&gt; Implementation issues: unfortunately we can't do ar=
ithmetic comparison with long integers &gt;32bit in the script, so implement=
ation of the difficulty requirement needs to be hacky. I think we can use th=
e hashes of one or more pre-images with a given short length, and the miner h=
as to 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 ins=
urer if he chooses a hash that doesn't correspond to any short-length pre-im=
age. I'm not sure about this implementation though, maybe we actually need n=
ew 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 t=
ime!<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.org=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt;&gt;&gt;&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/li=
stinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.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" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt;&gt;&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listin=
fo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoun=
dation.org/mailman/listinfo/bitcoin-dev</a><br>
&gt; <br>
&gt; </blockquote></div></div></blockquote></div></blockquote></div></div></=
blockquote></body></html>=

--Apple-Mail-73C458BA-D1F2-4FAB-A00B-3911CC658467--