Date: Sun, 20 Oct 2019 16:10:53 +0000
To: Eric Voskuil <eric@voskuil.org>
From: JW Weatherman <jw@mathbot.com>
Reply-To: JW Weatherman <jw@mathbot.com>
Message-ID: <E8cgzgpxhsuivizcjW9yAo2lsv8LmR2kXjBvqm0bA4i0HXa11o-X2ntYXcmjlZ5iCOCS6OzNze-RHIZkqCLHMjtBTan4VnxskFmC-8NX850=@mathbot.com>
In-Reply-To: <90A19D12-D964-41AE-A27F-AB99B66936D1@voskuil.org>
References: <5vCX5TKGwYMITwx_jp3BuX9nDr_DIez5kDPkF9ATAh_XYrQ4Y2rUGNU7qEkcy54BIEuNLB8TyznoOVBypNRWu0mTnqX4_D1oNK6ZT2fudQA=@mathbot.com>
	<90A19D12-D964-41AE-A27F-AB99B66936D1@voskuil.org>
Feedback-ID: 06WE2TD3pl3nzC7QfAH2qr5LpZ25gVcyyzXUIYQj0HZLgktVjK3WV4DgnthPbH0VVmnpGZwYV2mfC_kynz7XVA==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Lucas H <lucash.dev@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Trustless hash-price insurance contracts
Precedence: list

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 op=
timal electricity and labor costs probably wouldn't be interested in purcha=
sing 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 (d=
ecreased risk).

An analogy would be car insurance. If you are an excellent driver you would=
n'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 t=
hat are unwilling to take the risk of a damaged car that refrain from becom=
ing drivers until insurance allows them to lower the worst case scenario of=
 a damaged car.

-JW


=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Sunday, October 20, 2019 10:57 AM, Eric Voskuil <eric@voskuil.org> wrote=
:

>
>
> > On Oct 20, 2019, at 10:10, JW Weatherman jw@mathbot.com wrote:
> > I think the assumption is not that all miners are unprofitable, but tha=
t 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 bloc=
k reward value increase. In this case if the newest equipment is unprofitab=
le, 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 possibi=
lity.
> > And the existence of attractive insurance contracts would lower the bar=
rier to entry for new competitors in mining and this would increase bitcoin=
s security.
> > -JW
> > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origina=
l Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=
=90
> >
> > > On Sunday, October 20, 2019 1:03 AM, Eric Voskuil via bitcoin-dev bit=
coin-dev@lists.linuxfoundation.org wrote:
> > > Hi Lucas,
> > > I would question the assumption inherent in the problem statement. Se=
tting aside variance discount, proximity premium, and questions of relative=
 efficiency, as these are presumably already considered by the miner upon t=
he purchase of new equipment, it=E2=80=99s not clear why a loss is assumed =
in the case of subsequently increasing hash rate.
> > > The assumption of increasing hash rate implies an expectation of incr=
easing 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, an=
d if he is not, hash rate will drop until he is. This drop is most likely t=
o be precipitated by older equipment going offline.
> > > Best,
> > > Eric
> > >
> > > > > On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev bitcoin-dev@li=
sts.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 b=
e trustless bc we can use the assumption that the price of hashing is low t=
o unlock funds.
> > > > > The problem:
> > > > > A miner invests in new mining equipment, but if the hash-rate goe=
s up too much (the price he is paid for a hash goes down by too much) he wi=
ll have a loss.
> > > > > Solution: trustless hash-price insurance contract (or can we call=
 it an option to sell hashes at a given price?)
> > > > > An insurer who believes that it's unlikely the price of a hash wi=
ll go down a lot negotiates a contract with the miner implemented as a Bitc=
oin transaction:
> > > > > Inputs: a deposit from the insurer and a premium payment by the m=
iner
> > > > > Output1: simply the premium payment to the insurer
> > > > > Output2 -- that's the actual insurance
> > > > > There are three OR'ed conditions for paying it:
> > > > > A. After expiry date (in blocks) insurer can spend
> > > > > B. Both miner and insurer can spend at any time by mutual agreeme=
nt
> > > > > C. Before expiry, miner can spend by providing a pre-image that p=
roduces a hash within certain difficulty constraints
> > > > > The thing that makes it a hash-price insurance (or option, pardon=
 my lack of precise financial jargon), is that if hashing becomes cheap eno=
ugh, it becomes profitable to spend resources finding a suitable pre-image,=
 rather than mining Bitcoin.
> > > > > Of course, both parties can reach an agreement that doesn't requi=
re actually spending these resources -- so the miner can still mine Bitcoin=
 and compensate for the lower-than-expected reward with part of the insuran=
ce 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 profitabi=
lity of the mining operation.
> > > > > Implementation issues: unfortunately we can't do arithmetic compa=
rison with long integers >32bit in the script, so implementation of the dif=
ficulty requirement needs to be hacky. I think we can use the hashes of one=
 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 wou=
ld 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 n=
ot sure about this implementation though, maybe we actually need new opcode=
s.
> > > > > 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