Date: Sun, 20 Oct 2019 14:10:55 +0000
To: Eric Voskuil <eric@voskuil.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: JW Weatherman <jw@mathbot.com>
Reply-To: JW Weatherman <jw@mathbot.com>
Message-ID: <5vCX5TKGwYMITwx_jp3BuX9nDr_DIez5kDPkF9ATAh_XYrQ4Y2rUGNU7qEkcy54BIEuNLB8TyznoOVBypNRWu0mTnqX4_D1oNK6ZT2fudQA=@mathbot.com>
In-Reply-To: <ED2B169F-9548-4EBF-AEA0-270EBA4A4502@voskuil.org>
References: <CAHa=hJVuOdSyPhzu+cGHumw-94yAfxPE_1CkMYRBqxPsyjYBKA@mail.gmail.com>
	<ED2B169F-9548-4EBF-AEA0-270EBA4A4502@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>
Subject: Re: [bitcoin-dev] Trustless hash-price insurance contracts
Precedence: list

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 mi=
ner 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 se=
curity.

-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 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. Settin=
g aside variance discount, proximity premium, and questions of relative eff=
iciency, as these are presumably already considered by the miner upon the p=
urchase of new equipment, it=E2=80=99s not clear why a loss is assumed in t=
he case of subsequently increasing hash rate.
>
> The assumption of increasing hash rate implies an expectation of increasi=
ng 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.li=
nuxfoundation.org wrote:
> > Hi,
> > This is my first post to this list -- even though I did some tiny contr=
ibutions 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 trus=
tless bc we can use the assumption that the price of hashing is low to unlo=
ck funds.
> > The problem:
> > A miner invests in new mining equipment, but if the hash-rate goes up t=
oo much (the price he is paid for a hash goes down by too much) he will hav=
e 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 tr=
ansaction:
> > 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 produce=
s a hash within certain difficulty constraints
> > The thing that makes it a hash-price insurance (or option, pardon my la=
ck of precise financial jargon), is that if hashing becomes cheap enough, i=
t becomes profitable to spend resources finding a suitable pre-image, rathe=
r than mining Bitcoin.
> > Of course, both parties can reach an agreement that doesn't require act=
ually spending these resources -- so the miner can still mine Bitcoin and c=
ompensate for the lower-than-expected reward with part of the insurance dep=
osit.
> > If the price doesn't go down enough, the miner just mines Bitcoin and t=
he insurer gets his deposit back.
> > It's basically an instrument for guaranteeing a minimum profitability o=
f the mining operation.
> > Implementation issues: unfortunately we can't do arithmetic comparison =
with long integers >32bit in the script, so implementation of the difficult=
y requirement needs to be hacky. I think we can use the hashes of one or mo=
re pre-images with a given short length, and the miner has to provide the e=
xact pre-images. The pre-images are chosen by the insurer, and we would nee=
d a "honesty" deposit or other mechanism to punish the insurer if he choose=
s a hash that doesn't correspond to any short-length pre-image. I'm not sur=
e 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