Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Sun, 20 Oct 2019 01:03:09 -0400
Message-Id: <ED2B169F-9548-4EBF-AEA0-270EBA4A4502@voskuil.org>
References: <CAHa=hJVuOdSyPhzu+cGHumw-94yAfxPE_1CkMYRBqxPsyjYBKA@mail.gmail.com>
In-Reply-To: <CAHa=hJVuOdSyPhzu+cGHumw-94yAfxPE_1CkMYRBqxPsyjYBKA@mail.gmail.com>
To: 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

Hi Lucas,

I would question the assumption inherent in the problem statement. Setting a=
side variance discount, proximity premium, and questions of relative efficie=
ncy, as these are presumably already considered by the miner upon the purcha=
se of new equipment, it=E2=80=99s not clear why a loss is assumed in the cas=
e of subsequently increasing hash rate.=20

The assumption of increasing hash rate implies an expectation of increasing r=
eturn on investment.  There are certainly speculative errors, but a loss on n=
ew equipment implies *all miners* are operating at a loss, which is not a su=
stainable 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 pre=
cipitated by older equipment going offline.

Best,
Eric

> On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev <bitcoin-dev@lists.linu=
xfoundation.org> wrote:
>=20
> =EF=BB=BF
> Hi,
>=20
> This is my first post to this list -- even though I did some tiny contribu=
tions to bitcoin core I feel quite a beginner -- so if my idea is stupid, al=
ready known, or too off-topic, just let me know.
>=20
> TL;DR: a trustless contract that guarantees minimum profitability of a min=
ing operation -- in case Bitcoin/hash price goes too low. It can be trustles=
s bc we can use the assumption that the price of hashing is low to unlock fu=
nds.
>=20
> The problem:
>=20
> A miner invests in new mining equipment, but if the hash-rate goes up too m=
uch (the price he is paid for a hash goes down by too much) he will have a l=
oss.
>=20
> Solution: trustless hash-price insurance contract (or can we call it an op=
tion to sell hashes at a given price?)
>=20
> An insurer who believes that it's unlikely the price of a hash will go dow=
n a lot negotiates a contract with the miner implemented as a Bitcoin transa=
ction:
>=20
> 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 produc=
es a hash within certain difficulty constraints**
>=20
> The thing that makes it a hash-price insurance (or option, pardon my lack o=
f precise financial jargon), is that if hashing becomes cheap enough, it bec=
omes 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 actual=
ly spending these resources -- so the miner can still mine Bitcoin and compe=
nsate 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 i=
nsurer gets his deposit back.
> It's basically an instrument for guaranteeing a minimum profitability of t=
he mining operation.
>=20
> Implementation issues: unfortunately we can't do arithmetic comparison wit=
h long integers >32bit in the script, so implementation of the difficulty re=
quirement needs to be hacky. I think we can use the hashes of one or more pr=
e-images with a given short length, and the miner has to provide the exact p=
re-images. The pre-images are chosen by the insurer, and we would need a "ho=
nesty" 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 t=
his implementation though, maybe we actually need new opcodes.
>=20
> 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