From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 47E91B0B for ; 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 ; Sun, 20 Oct 2019 20:17:06 +0000 (UTC) Received: by mail-qt1-f180.google.com with SMTP id r5so17568644qtd.0 for ; 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 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: In-Reply-To: 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: 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 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 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 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 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
Hi Lucas,

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:

=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

Operatin= g 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 &= lt;lucash.dev@gmail.com> wrote:

=EF=BB=BF
Hi, guys.

Thanks a lot for taking the time to read and discuss my po= st.

I definitely wasn't clear enough about the prob= lem statement -- so let me try to clarify my thinking.

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

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

- 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.
=
   Obviously if P < 0, the miner will just shut down his e= quipment.
- Return on investment (ROI). A positive ROI requires no= t just that P > 0, but that it is enough to compensate for the initial in= vestment of buying or building the equipment. As long as P > 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.
=
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 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
being adopted befor= e that.

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.

- Bitcoin price relatively const= ant, that is, it's not the main driver of P during this period.
- A= pproximately constant block rewards.
- 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.
- 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.
- Let's just as= sume P>0 for all miners using the new equipment.
- Let's assume= every unit of the new equipment runs at the same maximum hashrate it's capa= ble of.

Let's say miner A buys Na units of the n= ew equipment and the total number deployed by all miners is N.
A's share of the block rewards will be Na / N.

If N is much higher than A's initial estimate, his ROI might well become n= egative, and the insurance would help him prevent a loss.

Hope this makes the problem a bit clearer.

T= hanks!

On Sun, Oct 20, 2019 at 9:16 AM Eric Voskuil <eric@voskuil.org> wrote:
So we are talking about a miner insu= ring 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-113C930F-A5AF-4D17-9698-1617FE8D21E0--