Trustless hash-price insurance contracts

Trustless hash-price insurance contracts
2019-10-20  5:03 ` Eric Voskuil
  
From: Lucas H @ 2019-10-18 22:01 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 2684 bytes --]

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!

[-- Attachment #2: Type: text/html, Size: 3126 bytes --]

 permalink raw reply	[|nested]
2019-10-18 22:01 [bitcoin-dev] Trustless hash-price insurance contracts Lucas H

  2019-10-20 14:10   ` JW Weatherman
  
From: Eric Voskuil @ 2019-10-20  5:03 UTC (permalink / raw)
  To: Lucas H, Bitcoin Protocol Discussion

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 <bitcoin-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 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
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


 permalink raw reply	[|nested]
2019-10-20  5:03 ` Eric Voskuil

  2019-10-20 14:57     ` Eric Voskuil
  
From: JW Weatherman @ 2019-10-20 14:10 UTC (permalink / raw)
  To: Eric Voskuil, Bitcoin Protocol Discussion;  Lucas H

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.

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 <bitcoin-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 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 bitcoin-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 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
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev




 permalink raw reply	[|nested]
2019-10-20 14:10   ` JW Weatherman

  2019-10-20 16:10       ` JW Weatherman
  
From: Eric Voskuil @ 2019-10-20 14:57 UTC (permalink / raw)
  To: JW Weatherman;  Lucas H, Bitcoin Protocol Discussion


> 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 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 <bitcoin-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 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 bitcoin-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 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
>>> bitcoin-dev@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 


 permalink raw reply	[|nested]
2019-10-20 14:57     ` Eric Voskuil

  2019-10-20 16:16         ` Eric Voskuil
  
From: JW Weatherman @ 2019-10-20 16:10 UTC (permalink / raw)
  To: Eric Voskuil;  Lucas H, Bitcoin Protocol Discussion

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 <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 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 bitcoin-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 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 bitcoin-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 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
> > > > bitcoin-dev@lists•linuxfoundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists•linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev




 permalink raw reply	[|nested]
2019-10-20 16:10       ` JW Weatherman

  2019-10-20 19:45           ` Lucas H
  
From: Eric Voskuil @ 2019-10-20 16:16 UTC (permalink / raw)
  To: JW Weatherman;  Lucas H, Bitcoin Protocol Discussion

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 <jw@mathbot•com> 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 <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 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 bitcoin-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 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 bitcoin-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 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
>>>>> bitcoin-dev@lists•linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>> 
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists•linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 


 permalink raw reply	[|nested]
2019-10-20 16:16         ` Eric Voskuil

  2019-10-20 20:17             ` Eric Voskuil
  
From: Lucas H @ 2019-10-20 19:45 UTC (permalink / raw)
  To: Eric Voskuil;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 10168 bytes --]

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 <eric@voskuil•org> 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 <jw@mathbot•com> 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 <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 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
> bitcoin-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
> 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
> bitcoin-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 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
> >>>>> bitcoin-dev@lists•linuxfoundation.org
> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>>
> >>>> bitcoin-dev mailing list
> >>>> bitcoin-dev@lists•linuxfoundation.org
> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
>

[-- Attachment #2: Type: text/html, Size: 12523 bytes --]

 permalink raw reply	[|nested]
2019-10-20 19:45           ` Lucas H

  2019-10-20 21:33               ` Lucas H
  
From: Eric Voskuil @ 2019-10-20 20:17 UTC (permalink / raw)
  To: Lucas H;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 10696 bytes --]

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 <lucash.dev@gmail•com> 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 <eric@voskuil•org> 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 <jw@mathbot•com> 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 <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 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 bitcoin-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 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 bitcoin-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 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
>> >>>>> bitcoin-dev@lists•linuxfoundation.org
>> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>>> 
>> >>>> bitcoin-dev mailing list
>> >>>> bitcoin-dev@lists•linuxfoundation.org
>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> > 
>> > 

[-- Attachment #2: Type: text/html, Size: 13534 bytes --]

 permalink raw reply	[|nested]
2019-10-20 20:17             ` Eric Voskuil

  
From: Lucas H @ 2019-10-20 21:33 UTC ( / )
  To: Eric Voskuil;  Bitcoin Protocol Discussion



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

Let's assume you decide to just shut down your whole operation. In that
scenario, it doesn't make sense *not* to sell your equipment, even at a
loss. Just 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 will make *their* ROI>0 for keeping the equipment running --
and the equipment *will* be again running, and *will* keep the hashrate
high. Only consequence of you shutting down your operation is you taking a
loss.

Even if you sell it to someone who will run it exactly as efficiently as
you, or even at lower efficiency (as long as P>0), they'll just pay less
for the equipment than you did, their ROI will be >0 and you'll bear the
loss. No drop in hashrate.

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.

Please note that none of the above breaks the economic assumptions of the
protocol. 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
activity.

Consider investing in building an oil refinery -- if the price of the
refined products get lower than expected to pay for the capital, but still
high enough to pay for operating costs, you'd rather keep it running (or
sell to someone 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 refined products going too low.

Of course miners can (and maybe already do) hedge against these scenarios
using other kinds of instruments -- most likely facilitated by a trusted
3rd party. I'm just interested in the possibility of a new, trustless
instrument.

*Anyway* I'm far more interested in the technical feasibility of the
contract, given the economic assumptions, than it's economic practicality
in the present.





On Sun, Oct 20, 2019 at 1:17 PM Eric Voskuil <eric@voskuil•org> wrote:

> 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 <lucash.dev@gmail•com> 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 <eric@voskuil•org> 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 <jw@mathbot•com> 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 <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 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
>> bitcoin-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
>> 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
>> bitcoin-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 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
>> >>>>> bitcoin-dev@lists•linuxfoundation.org
>> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>>>
>> >>>> bitcoin-dev mailing list
>> >>>> bitcoin-dev@lists•linuxfoundation.org
>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>> >
>>
>
From: Eric Voskuil @ 2019-10-21  3:34 UTC (permalink / raw)
  To: Lucas H;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 14516 bytes --]

Hi Lucas,

You are assuming that all miners operate at equal efficiency. The least efficient miners are expected to drop offline first. Even with identical hardware and operational efficiency, the necessary variance discount and proximity premium create a profitability spread. The relation between hash rate and reward 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 means, despite higher hash rate, miners are profitable. The least efficient miners have written down their expected losses and hash rate becomes consistent with market returns despite being higher.

With respect to the contract, I don’t yet see this working, but there are several gaps and I don’t want to make assumptions. More detailed specification would be helpful. Even a full scenario with numbers and justifications would be something.

e

> On Oct 20, 2019, at 14: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 equipment 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.
> 
> Let's assume you decide to just shut down your whole operation. In that scenario, it doesn't make sense *not* to sell your equipment, even at a loss. Just 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 will make *their* ROI>0 for keeping the equipment running --  and the equipment *will* be again running, and *will* keep the hashrate high. Only consequence of you shutting down your operation is you taking a loss. 
> 
> Even if you sell it to someone who will run it exactly as efficiently as you, or even at lower efficiency (as long as P>0), they'll just pay less for the equipment than you did, their ROI will be >0 and you'll bear the loss. No drop in hashrate.
> 
> 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.
> 
> Please note that none of the above breaks the economic assumptions of the protocol. 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 activity.
> 
> Consider investing in building an oil refinery -- if the price of the refined products get lower than expected to pay for the capital, but still high enough to pay for operating costs, you'd rather keep it running (or sell to someone 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 refined products going too low.
> 
> Of course miners can (and maybe already do) hedge against these scenarios using other kinds of instruments -- most likely facilitated by a trusted 3rd party. I'm just interested in the possibility of a new, trustless instrument.
> 
> *Anyway* I'm far more interested in the technical feasibility of the contract, given the economic assumptions, than it's economic practicality in the present.
> 
> 
> 
> 
> 
>>> On Sun, Oct 20, 2019 at 1:17 PM Eric Voskuil <eric@voskuil•org> wrote:
>>> 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 <lucash.dev@gmail•com> 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 <eric@voskuil•org> 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 <jw@mathbot•com> 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 <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 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 bitcoin-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 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 bitcoin-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 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
>>>> >>>>> bitcoin-dev@lists•linuxfoundation.org
>>>> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>> >>>> 
>>>> >>>> bitcoin-dev mailing list
>>>> >>>> bitcoin-dev@lists•linuxfoundation.org
>>>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>> > 
>>>> >

[-- Attachment #2: Type: text/html, Size: 19366 bytes --]

 permalink raw reply	[|nested]