path: root/37/0b45a366849950a4843c06d50a76ddb70e197a

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 47E91B0B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 20 Oct 2019 20:17:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com
	[209.85.160.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6097014D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 20 Oct 2019 20:17:06 +0000 (UTC)
Received: by mail-qt1-f180.google.com with SMTP id r5so17568644qtd.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 20 Oct 2019 13:17:06 -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:subject:date:message-id
	:references:cc:in-reply-to:to;
	bh=9G5iLkeJJdlyuFB+ogv5C1gu/KDNzPN+rab81QAP2ow=;
	b=YLHj64pSAunpot5eEMZQwwlh5/eqaFHeBeg/st4JL8yrPNGrjd+wS2KmhgjjNi3WGp
	NGzS/W5zOmu88oxdRfW+2O5TZELLJucAvubR2579200oqvPmRzVmUvatblG6WUG+VEDz
	i43viv3y+UGFkb1mvhrbHWUkSHZiZ+WJY3H5XBqgXF/m7O9PC7rXczGJO/cYyDjd+0G8
	VgY+zRuuLeLs4M7PNtiM9iWu3nK2EXbQ1NHvmEAzOu4jzGBuo8xFLJnFtmzo1ONRYB17
	uWOpgY7W8eTgn0V7LUrg0AYMz0GbDZcVEszw0OWuyBte4q7waz3o2Z3unL7iAkiYZZrj
	3Txw==
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
	:subject:date:message-id:references:cc:in-reply-to:to;
	bh=9G5iLkeJJdlyuFB+ogv5C1gu/KDNzPN+rab81QAP2ow=;
	b=Qx0QC5jXPkaz/086GvvI434YvTvZezIC/cP5bLAKRayMG4ztXD2nuLGfi+rfr25xV9
	5+Ny90mrA4DmUeiPtZDVxGTJXqSxCRhXmYYbgcyeTuTy/2hL5jURXjkmsVJDDWCB2gCu
	ZG7EZqDcKHz+l/TFO3BO20vGNP/4g5esEwPOE+SiCrUmZmiUh1RC8c7HM8RJj5hBV5PC
	lvaJMEfoTbv/ZoMT8TBYm5A+VIuON5sY/9s0X3g5QLykN7PFFeaxahmfandHQaKslWej
	cpNqm6Y4VTfklccDrm++NNZVo3V3t5lzobtmV/jxvAEcnZjFtYzm2+wSKcRcy0Yh7aK8
	6/ug==
X-Gm-Message-State: APjAAAWhM8E1xDcvojduV+g5Q4UIWnhVBrvEOuBcVhWzCJoyxf/FWmf+
	d7lc7Rkxo3yB0zf/2kVg5GU9Vw==
X-Google-Smtp-Source: APXvYqyGxiTdVlUyUuqMy5cgfSmr9q5Azs+l2rBNvXaae8DMwwXNq3bpSS886+pLN0OIhcszi0SpyA==
X-Received: by 2002:aed:3fc4:: with SMTP id w4mr3334482qth.120.1571602625309; 
	Sun, 20 Oct 2019 13:17:05 -0700 (PDT)
Received: from ?IPv6:2600:380:bc23:b42c:b41d:66cc:c3a3:5201?
	([2600:380:bc23:b42c:b41d:66cc:c3a3:5201])
	by smtp.gmail.com with ESMTPSA id
	d39sm1825169qtc.23.2019.10.20.13.17.04
	(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
	Sun, 20 Oct 2019 13:17:04 -0700 (PDT)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-113C930F-A5AF-4D17-9698-1617FE8D21E0
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Sun, 20 Oct 2019 16:17:03 -0400
Message-Id: <9C06A36D-C0A7-4C15-ACDB-63FF3572B079@voskuil.org>
References: <CAHa=hJVLp5=ao1p5kooE=4Fo9_jh6WVtG1uF0T_vAP7r=9zjww@mail.gmail.com>
In-Reply-To: <CAHa=hJVLp5=ao1p5kooE=4Fo9_jh6WVtG1uF0T_vAP7r=9zjww@mail.gmail.com>
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: Sun, 20 Oct 2019 20:17:08 -0000


--Apple-Mail-113C930F-A5AF-4D17-9698-1617FE8D21E0
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Lucas,

This can all be inferred from the problem statement. In other words this doe=
sn=E2=80=99t change the assumptions behind my comments. However this is an u=
nsupportable assumption:

=E2=80=9CDifficulty would only go down in this case at the end of life of th=
ese equipment, if there isn't a new wave of even more efficient equipment be=
ing 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:
>=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 me t=
ry to clarify my thinking.
>=20
> First, the main uncertainty the miner is trying to protect against isn't t=
he inefficiency of his new equipment, but how much new mining equipment is b=
eing deployed world-wide, which he can't know in advance (as the system is p=
ermissionless).
>=20
> Second, there are two different metrics that can mean "profitable" that I t=
hink are getting confused (probably my fault for lack of using the right ter=
ms).
>=20
> - Let's call it "operational profitability", and use "P" to denote it, whe=
re P =3D [bitcoin earned]/time - [operational cost of running equipment]/tim=
e.
>    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 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, b=
ut 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, i=
t's possible that your ROI becomes negative, while nobody shuts down their e=
quipment and the difficulty still keeps going up. In fact, it is possible fo=
r all miners to have negative ROI for a while without a reduction in difficu=
lty. Difficulty would only go down in this case at the end of life of these e=
quipment, 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. Thi=
s is just one example, and other scenarios could also work.
>=20
> - 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 e=
quipment. So the old stock of old equipment becomes irrelevant after a short=
 while.=20
> - All miners decide to deploy new equipment, but none knows how much the o=
thers 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 ha=
shrate it's capable of.
>=20
> Let's say miner A buys Na units of the new equipment and the total number d=
eployed 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 n=
egative, 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 expe=
ctation of higher future return (investment leads returns). So the insurance=
 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 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).
>> >=20
>> > 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.
>> >=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 Origina=
l 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> w=
rote:
>> >>=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 t=
hat a single miner could make an investment that becomes unprofitable if the=
 hash rate increases more than he expected.
>> >>=20
>> >> This is a restatement of the assumption I questioned. Hash rate increa=
se does not imply unprofitability. The new rig should be profitable.
>> >>=20
>> >> What is being assumed is a hash rate increase without a proportional b=
lock reward value increase. In this case if the newest equipment is unprofit=
able, all miners are unprofitable.
>> >>=20
>> >>> Depending on the cost of the offered insurance it would be prudent fo=
r a miner to decrease his potential loss by buying insurance for this possib=
ility.
>> >>> And the existence of attractive insurance contracts would lower the b=
arrier to entry for new competitors in mining and this would increase bitcoi=
ns security.
>> >>> -JW
>> >>> =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
>> >>>=20
>> >>>> On Sunday, October 20, 2019 1:03 AM, Eric Voskuil via bitcoin-dev bi=
tcoin-dev@lists.linuxfoundation.org wrote:
>> >>>> Hi Lucas,
>> >>>> I would question the assumption inherent in the problem statement. S=
etting aside variance discount, proximity premium, and questions of relative=
 efficiency, as these are presumably already considered by the miner upon th=
e purchase of new equipment, it=E2=80=99s not clear why a loss is assumed in=
 the case of subsequently increasing hash rate.
>> >>>> The assumption of increasing hash rate implies an expectation of inc=
reasing return on investment. There are certainly speculative errors, but a l=
oss on new equipment implies all miners are operating at a loss, which is no=
t a sustainable situation.
>> >>>> If any miner is profitable it is the miner with the new equipment, a=
nd if he is not, hash rate will drop until he is. This drop is most likely t=
o be precipitated by older equipment going offline.
>> >>>> Best,
>> >>>> Eric
>> >>>>=20
>> >>>>>> On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev bitcoin-dev@lis=
ts.linuxfoundation.org wrote:
>> >>>>>> Hi,
>> >>>>>> This is my first post to this list -- even though I did some tiny c=
ontributions to bitcoin core I feel quite a beginner -- so if my idea is stu=
pid, already known, or too off-topic, just let me know.
>> >>>>>> TL;DR: a trustless contract that guarantees minimum profitability o=
f a mining operation -- in case Bitcoin/hash price goes too low. It can be t=
rustless bc we can use the assumption that the price of hashing is low to un=
lock funds.
>> >>>>>> The problem:
>> >>>>>> 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 too much) he will=
 have a loss.
>> >>>>>> Solution: trustless hash-price insurance contract (or can we call i=
t an option to sell hashes at a given price?)
>> >>>>>> An insurer who believes that it's unlikely the price of a hash wil=
l go down a lot negotiates a contract with the miner implemented as a Bitcoi=
n transaction:
>> >>>>>> Inputs: a deposit from the insurer and a premium payment by the mi=
ner
>> >>>>>> 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 agreemen=
t
>> >>>>>> C. Before expiry, miner can spend by providing a pre-image that pr=
oduces a hash within certain difficulty constraints
>> >>>>>> The thing that makes it a hash-price insurance (or option, pardon m=
y lack of precise financial jargon), is that if hashing becomes cheap enough=
, it becomes profitable to spend resources finding a suitable pre-image, rat=
her than mining Bitcoin.
>> >>>>>> Of course, both parties can reach an agreement that doesn't requir=
e actually spending these resources -- so the miner can still mine Bitcoin a=
nd compensate for the lower-than-expected reward with part of the insurance d=
eposit.
>> >>>>>> If the price doesn't go down enough, the miner just mines Bitcoin a=
nd the insurer gets his deposit back.
>> >>>>>> It's basically an instrument for guaranteeing a minimum profitabil=
ity of the mining operation.
>> >>>>>> Implementation issues: unfortunately we can't do arithmetic compar=
ison with long integers >32bit in the script, so implementation of the diffi=
culty requirement needs to be hacky. I think we can use the hashes of one or=
 more pre-images with a given short length, and the miner has to provide the=
 exact pre-images. The pre-images are chosen by the insurer, and we would ne=
ed a "honesty" deposit or other mechanism to punish the insurer if he choose=
s a hash that doesn't correspond to any short-length pre-image. I'm not sure=
 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
>> >=20

--Apple-Mail-113C930F-A5AF-4D17-9698-1617FE8D21E0
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">Hi Lucas,</div><div dir=3D=
"ltr"><br></div><div dir=3D"ltr">This can all be inferred from the problem s=
tatement. In other words this doesn=E2=80=99t change the assumptions behind m=
y comments. However this is an unsupportable assumption:</div><div dir=3D"lt=
r"><br></div><div dir=3D"ltr"><div style=3D"-webkit-text-size-adjust: auto;"=
>=E2=80=9CDifficulty would only go down in this case at the end of life of t=
hese equipment, if there isn't a new wave of even more efficient equipment b=
eing adopted before that.=E2=80=9D</div><div style=3D"-webkit-text-size-adju=
st: auto;"><br></div><div style=3D"-webkit-text-size-adjust: auto;">Operatin=
g at a loss would only be justifiable in the case of expected future returns=
, not due to sunk costs.</div><div style=3D"-webkit-text-size-adjust: auto;"=
><br></div><div style=3D"-webkit-text-size-adjust: auto;">e</div></div><div d=
ir=3D"ltr"><br><blockquote type=3D"cite">On Oct 20, 2019, at 15:46, Lucas H &=
lt;lucash.dev@gmail.com&gt; wrote:<br><br></blockquote></div><blockquote typ=
e=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div dir=3D"ltr"><div>Hi, guys.</div><d=
iv><br></div><div>Thanks a lot for taking the time to read and discuss my po=
st.</div><div><br></div><div>I definitely wasn't clear enough about the prob=
lem statement -- so let me try to clarify my thinking.</div><div><br></div><=
div>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).</div><div><br></div><div>Second, there are two different m=
etrics that can mean "profitable" that I think are getting confused (probabl=
y my fault for lack of using the right terms).</div><div><br></div><div>- Le=
t's call it "operational profitability", and use "P" to denote it, where P =3D=
 [bitcoin earned]/time - [operational cost of running equipment]/time.</div>=
<div>&nbsp;&nbsp; Obviously if P &lt; 0, the miner will just shut down his e=
quipment.</div><div>- Return on investment (ROI). A positive ROI requires no=
t just that P &gt; 0, but that it is enough to compensate for the initial in=
vestment of buying or building the equipment. As long as P &gt; 0, a miner w=
ill keep his equipment running, even at a negative ROI, as the alternative w=
ould be an even worse negative ROI. Sure he can sell it, but however buys it=
 will also keep it running, otherwise the equipment is worthless.</div><div>=
<br></div><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 ar=
e deploying too much new equipment at the same time, it's possible that your=
 ROI becomes negative, while nobody shuts down their equipment and the diffi=
culty still keeps going up. In fact, it is possible for all miners to have n=
egative ROI for a while without a reduction in difficulty. Difficulty would o=
nly 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</div><div>being adopted befor=
e that.<br></div><div><br></div><div>Let's see a simplified scenario in whic=
h the insurance becomes useful. This is just one example, and other scenario=
s could also work.</div><div><br></div><div>- Bitcoin price relatively const=
ant, that is, it's not the main driver of P during this period.</div><div>- A=
pproximately constant block rewards.<br></div><div>- New equipment comes to m=
arket with much higher efficiency than all old equipment. So the old stock o=
f old equipment becomes irrelevant after a short while. <br></div><div>- All=
 miners decide to deploy new equipment, but none knows how much the others a=
re deploying, or when, or at what price or P. <br></div><div>- Let's just as=
sume P&gt;0 for all miners using the new equipment.</div><div>- Let's assume=
 every unit of the new equipment runs at the same maximum hashrate it's capa=
ble of.<br></div><div><br></div><div>Let's say miner A buys Na units of the n=
ew 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><di=
v>If N is much higher than A's initial estimate, his ROI might well become n=
egative, and the insurance would help him prevent a loss.</div><div><br></di=
v><div>Hope this makes the problem a bit clearer.</div><div><br></div><div>T=
hanks!</div><div><a class=3D"gmail_plusreply" id=3D"plusReplyChip-1">@lucash=
-dev</a><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Sun, Oct 20, 2019 at 9:16 AM Eric Voskuil &lt;<a href=3D=
"mailto:eric@voskuil.org">eric@voskuil.org</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">So we are talking about a miner insu=
ring 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; <br>
</blockquote></div>
</div></blockquote></body></html>=

--Apple-Mail-113C930F-A5AF-4D17-9698-1617FE8D21E0--