Hi Lucas, This can all be inferred from the problem statement. In other words this doesn’t change the assumptions behind my comments. However this is an unsupportable assumption:
“Difficulty 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 efficient equipment being adopted before that.” 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 <[email protected]> wrote: > > > Hi, guys. > > Thanks a lot for taking the time to read and discuss my post. > > I definitely wasn't clear enough about the problem statement -- so let me try > to clarify my thinking. > > 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 metrics that can mean "profitable" that I > think are getting confused (probably my fault for lack of using the right > terms). > > - Let's call it "operational profitability", and use "P" to denote it, where > P = [bitcoin earned]/time - [operational cost of running equipment]/time. > 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 > running, even at a negative ROI, as the alternative would 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 are 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 difficulty still keeps going up. In fact, it is possible > for all miners to have negative ROI for a while without a reduction in > difficulty. Difficulty 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 efficient equipment > being adopted before that. > > Let's see a simplified scenario in which the insurance becomes useful. This > is just one example, and other scenarios could also work. > > - 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 > equipment. So the old stock of old equipment becomes irrelevant after a short > while. > - All miners decide to deploy new equipment, but none knows how much the > others are deploying, or when, or at what price or P. > - 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 > hashrate it's capable of. > > Let's say miner A buys Na units of the new 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 > negative, and the insurance would help him prevent a loss. > > Hope this makes the problem a bit clearer. > > Thanks! > @lucash-dev > >> On Sun, Oct 20, 2019 at 9:16 AM Eric Voskuil <[email protected]> wrote: >> 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
