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 10:57:37 -0400
Message-Id: <90A19D12-D964-41AE-A27F-AB99B66936D1@voskuil.org>
References: <5vCX5TKGwYMITwx_jp3BuX9nDr_DIez5kDPkF9ATAh_XYrQ4Y2rUGNU7qEkcy54BIEuNLB8TyznoOVBypNRWu0mTnqX4_D1oNK6ZT2fudQA=@mathbot.com>
In-Reply-To: <5vCX5TKGwYMITwx_jp3BuX9nDr_DIez5kDPkF9ATAh_XYrQ4Y2rUGNU7qEkcy54BIEuNLB8TyznoOVBypNRWu0mTnqX4_D1oNK6ZT2fudQA=@mathbot.com>
To: JW Weatherman <jw@mathbot.com>
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


> On Oct 20, 2019, at 10:10, JW Weatherman <jw@mathbot.com> wrote:
>=20
> =EF=BB=BFI think the assumption is not that all miners are unprofitable, b=
ut 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 doe=
s 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 m=
iner to decrease his potential loss by buying insurance for this possibility=
.
>=20
> And the existence of attractive insurance contracts would lower the barrie=
r to entry for new competitors in mining and this would increase bitcoins se=
curity.
>=20
> -JW
>=20
>=20
>=20
>=20
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M=
essage =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 <bitcoi=
n-dev@lists.linuxfoundation.org> wrote:
>>=20
>> Hi Lucas,
>>=20
>> I would question the assumption inherent in the problem statement. Settin=
g aside variance discount, proximity premium, and questions of relative effi=
ciency, as these are presumably already considered by the miner upon the pur=
chase of new equipment, it=E2=80=99s not clear why a loss is assumed in the c=
ase of subsequently increasing hash rate.
>>=20
>> The assumption of increasing hash rate implies an expectation of increasi=
ng return on investment. There are certainly speculative errors, but a loss o=
n new equipment implies all miners are operating at a loss, which is not a s=
ustainable situation.
>>=20
>> 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 p=
recipitated by older equipment going offline.
>>=20
>> Best,
>> Eric
>>=20
>>>> 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 contri=
butions to bitcoin core I feel quite a beginner -- so if my idea is stupid, a=
lready known, or too off-topic, just let me know.
>>> TL;DR: a trustless contract that guarantees minimum profitability of a m=
ining operation -- in case Bitcoin/hash price goes too low. It can be trustl=
ess bc we can use the assumption that the price of hashing is low to unlock f=
unds.
>>> The problem:
>>> A miner invests in new mining equipment, but if the hash-rate goes up to=
o 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 o=
ption to sell hashes at a given price?)
>>> An insurer who believes that it's unlikely the price of a hash will go d=
own a lot negotiates a contract with the miner implemented as a Bitcoin tran=
saction:
>>> 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 lac=
k of precise financial jargon), is that if hashing becomes cheap enough, it b=
ecomes profitable to spend resources finding a suitable pre-image, rather th=
an mining Bitcoin.
>>> Of course, both parties can reach an agreement that doesn't require actu=
ally spending these resources -- so the miner can still mine Bitcoin and com=
pensate for the lower-than-expected reward with part of the insurance deposi=
t.
>>> If the price doesn't go down enough, the miner just mines Bitcoin and th=
e 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 w=
ith long integers >32bit in the script, so implementation of the difficulty r=
equirement needs to be hacky. I think we can use the hashes of one or more p=
re-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.
>>> What do you guys think?
>>> Thanks for reading it all! Hope it was worth your time!
>>>=20
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>=20
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
>=20