Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 41CEAD49 for ; 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 ; Mon, 21 Oct 2019 03:34:20 +0000 (UTC) Received: by mail-pf1-f173.google.com with SMTP id a2so7499656pfo.10 for ; 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 Mime-Version: 1.0 (1.0) Date: Sun, 20 Oct 2019 20:34:12 -0700 Message-Id: To: Lucas H 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 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 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 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 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

Hi Lucas,


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.


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.


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.


e


On Oct 20, 2019, at 1= 4:33, Lucas H <lucash.dev@gmail.com> wrote:

=
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 equipm= ent is good for nothing else other than performing hashing operations.
=
As long as someone can get paid more than they spend to keep the equipm= ent running, i.e. P>0,  it will keep running.
Your ar= gument only makes sense in an ASIC-free world.

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= 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.

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>0), th= ey'll just pay less for the equipment than you did, their ROI will be >0 a= nd you'll bear the loss. No drop in hashrate.

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>0.
<= /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.

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= .

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.

*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.
=





On Sun, Oct 20, 2019 at 1:17 PM Er= ic Voskuil <eric@voskuil.org> w= rote:
Hi Lucas,

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:

=
=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>Operating at a loss would only be justifiable in the case of expected fu= ture returns, not due to sunk costs.

e
<= div dir=3D"ltr">
On Oct 20, 2019, at 15:46, Luc= as H <lucash.de= v@gmail.com> wrote:

=EF=BB=BF
Hi, guys.

<= /div>
Thanks a lot for taking the time to read and discuss my post.

I definitely wasn't clear enough about the problem stat= ement -- so let me try to clarify my thinking.

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).

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).

- 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.
&= nbsp;  Obviously if P < 0, the miner will just shut down his equipme= nt.
- Return on investment (ROI). A positive ROI requires not just= that P > 0, but that it is enough to compensate for the initial investme= nt of buying or building the equipment. As long as P > 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.

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 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
being adopted before that.<= br>

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.

- Bitcoin price relatively constant, that= is, it's not the main driver of P during this period.
- Approxima= tely constant block rewards.
- 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.
- 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.
- Let's just assume P&= gt;0 for all miners using the new equipment.
- Let's assume every u= nit of the new equipment runs at the same maximum hashrate it's capable of.<= br>

Let's say miner A buys Na units of the new equi= pment and the total number deployed by all miners is N.

=
A's share of the block rewards will be Na / N.

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.

H= ope this makes the problem a bit clearer.


<= blockquote type=3D"cite" __apple_fixed_attribute=3D"true">
On Sun, Oct 20, 2019 at 9:16 AM Eric Voskuil <eric@voskuil.org> wrot= e:
So= we are talking about a miner insuring against his own inefficiency.

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.

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 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).
>
> 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.
>
> -JW
>
>
>
>
> =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> 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 inc= rease does not imply unprofitability. The new rig should be profitable.
>>
>> 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.
>>
>>> 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.
>>> 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.
>>> -JW
>>> =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
>>>
>>>> On Sunday, October 20, 2019 1:03 AM, Eric Voskuil via bitco= in-dev bitcoin-dev@lists.linuxfoundation.org wrote:
>>>> Hi Lucas,
>>>> 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.
>>>> 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.
>>>> 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.
>>>> Best,
>>>> Eric
>>>>
>>>>>> 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 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 i= f my idea is 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 l= ow. It can be trustless bc we can use the assumption that the price of hashi= ng is low to unlock 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 to= o much) he will 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 pric= e of a hash will go down a lot negotiates a contract with the miner implemen= ted as a Bitcoin transaction:
>>>>>> Inputs: a deposit from the insurer and a premium pa= yment by the miner
>>>>>> Output1: simply the premium payment to the insurer<= br> >>>>>> Output2 -- that's the actual insurance
>>>>>> There are three OR'ed conditions for paying it:
= >>>>>> A. After expiry date (in blocks) insurer can spend<= br> >>>>>> B. Both miner and insurer can spend at any time by m= utual agreement
>>>>>> C. Before expiry, miner can spend by providing a pr= e-image that produces a hash within certain difficulty constraints
>>>>>> 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.
>>>>>> 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.
>>>>>> 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 min= imum profitability of the mining operation.
>>>>>> Implementation issues: unfortunately we can't do ar= ithmetic comparison with long integers >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.
>>>>>> What do you guys think?
>>>>>> Thanks for reading it all! Hope it was worth your t= ime!
>>>>>
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>> https://lists.linux= foundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoun= dation.org/mailman/listinfo/bitcoin-dev
>
>
= --Apple-Mail-73C458BA-D1F2-4FAB-A00B-3911CC658467--