So we are talking about a miner insuring against his own inefficiency. Furthermore a disproportionate increase in hash rate is based on the expectation of higher future return (investment leads returns). So the insurance could end up paying out against realized profit.
Generally speaking, insuring investment is a zero sum game. e > On Oct 20, 2019, at 12:10, JW Weatherman <[email protected]> wrote: > > Oh, I see your point. > > However the insurance contract would protect the miner even in that case. A > miner with great confidence that he is running optimal hardware and has > optimal electricity and labor costs probably wouldn't be interested in > purchasing insurance for a high price, but if it was cheap enough it 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 > (decreased risk). > > An analogy would be car insurance. If you are an excellent driver you > wouldn't be willing to spend a ton of money to protect your car in the event > of an accident, but if it is cheap enough you would. And there may be people > that are unwilling to take the risk of a damaged car that refrain from > becoming drivers until insurance allows them to lower the worst case scenario > of a damaged car. > > -JW > > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >> On Sunday, October 20, 2019 10:57 AM, Eric Voskuil <[email protected]> wrote: >> >> >> >>>> On Oct 20, 2019, at 10:10, JW Weatherman [email protected] 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 the hash >>> rate increases more than he expected. >> >> This is a restatement of the assumption I questioned. Hash rate increase >> does not imply unprofitability. The new rig should be profitable. >> >> What is being assumed is a hash rate increase without a proportional block >> reward value increase. In this case if the newest equipment is unprofitable, >> all miners are unprofitable. >> >>> Depending on the cost of the offered insurance it would be prudent for a >>> miner to decrease his potential loss by buying insurance for this >>> possibility. >>> And the existence of attractive insurance contracts would lower the barrier >>> to entry for new competitors in mining and this would increase bitcoins >>> security. >>> -JW >>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>> >>>> On Sunday, October 20, 2019 1:03 AM, Eric Voskuil via bitcoin-dev >>>> [email protected] wrote: >>>> Hi Lucas, >>>> I would question the assumption inherent in the problem statement. Setting >>>> aside variance discount, proximity premium, and questions of relative >>>> efficiency, as these are presumably already considered by the miner upon >>>> the purchase of new equipment, it’s 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 >>>> increasing return on investment. There are certainly speculative errors, >>>> but a loss on new equipment implies all miners are operating at a loss, >>>> which is not a sustainable situation. >>>> If any miner is profitable it is the miner with the new equipment, and if >>>> he is not, hash rate will drop until he is. This drop is most likely to be >>>> precipitated by older equipment going offline. >>>> Best, >>>> Eric >>>> >>>>>> On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev >>>>>> [email protected] wrote: >>>>>> Hi, >>>>>> This is my first post to this list -- even though I did some tiny >>>>>> contributions to bitcoin core I feel quite a beginner -- so if my idea >>>>>> 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 low. It can be >>>>>> trustless bc we can use the assumption that the price of hashing is low >>>>>> to unlock funds. >>>>>> The problem: >>>>>> A miner invests in new mining equipment, but if the hash-rate 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 it an >>>>>> option to sell hashes at a given price?) >>>>>> An insurer who believes that it's unlikely the price of a hash will go >>>>>> down a lot negotiates a contract with the miner implemented as a Bitcoin >>>>>> transaction: >>>>>> Inputs: a deposit from the insurer and a premium payment by the miner >>>>>> Output1: simply the premium payment to the insurer >>>>>> Output2 -- that's the actual insurance >>>>>> There are three OR'ed conditions for paying it: >>>>>> A. After expiry date (in blocks) insurer can spend >>>>>> B. Both miner and insurer can spend at any time by mutual agreement >>>>>> C. Before expiry, miner can spend by providing a pre-image that produces >>>>>> a hash within certain difficulty constraints >>>>>> The thing that makes it a hash-price insurance (or option, pardon my >>>>>> lack of precise financial jargon), is that if hashing becomes cheap >>>>>> enough, it becomes profitable to spend resources finding a suitable >>>>>> pre-image, rather than mining Bitcoin. >>>>>> Of course, both parties can reach an agreement that doesn't require >>>>>> actually spending these resources -- so the miner can still mine Bitcoin >>>>>> and compensate for the lower-than-expected reward with part of 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 minimum profitability of >>>>>> the mining operation. >>>>>> Implementation issues: unfortunately we can't do arithmetic comparison >>>>>> with long integers >32bit in the script, so implementation of the >>>>>> difficulty requirement needs to be hacky. I think we can use the 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 need a "honesty" deposit or other mechanism to >>>>>> punish the insurer if he chooses 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! >>>>> >>>>> bitcoin-dev mailing list >>>>> [email protected] >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>>> bitcoin-dev mailing list >>>> [email protected] >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
