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 12:16:57 -0400
Message-Id: <C54E6D4A-7E74-4169-8D92-1CCD633A6DE3@voskuil.org>
References: <E8cgzgpxhsuivizcjW9yAo2lsv8LmR2kXjBvqm0bA4i0HXa11o-X2ntYXcmjlZ5iCOCS6OzNze-RHIZkqCLHMjtBTan4VnxskFmC-8NX850=@mathbot.com>
In-Reply-To: <E8cgzgpxhsuivizcjW9yAo2lsv8LmR2kXjBvqm0bA4i0HXa11o-X2ntYXcmjlZ5iCOCS6OzNze-RHIZkqCLHMjtBTan4VnxskFmC-8NX850=@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

So we are talking about a miner insuring against his own inefficiency.

Furthermore a disproportionate increase in hash rate is based on the expecta=
tion of higher future return (investment leads returns). So the insurance co=
uld 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:
>=20
> =EF=BB=BFOh, I see your point.
>=20
> 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 opt=
imal electricity and labor costs probably wouldn't be interested in purchasi=
ng insurance for a high price, but if it was cheap enough it would still be w=
orth it. And any potential new entrants on the edge of jumping in would ente=
r when they otherwise would not have because of the decreased costs (decreas=
ed risk).
>=20
> An analogy would be car insurance. If you are an excellent driver you woul=
dn't be willing to spend a ton of money to protect your car in the event of a=
n accident, but if it is cheap enough you would. And there may be people tha=
t 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 d=
amaged car.
>=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 10:57 AM, Eric Voskuil <eric@voskuil.org> wro=
te:
>>=20
>>=20
>>=20
>>>> 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 ha=
sh rate increases more than he expected.
>>=20
>> This is a restatement of the assumption I questioned. Hash rate increase d=
oes not imply unprofitability. The new rig should be profitable.
>>=20
>> 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 unprofitabl=
e, all miners are unprofitable.
>>=20
>>> 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 possibili=
ty.
>>> And the existence of attractive insurance contracts would lower the barr=
ier to entry for new competitors in mining and this would increase bitcoins s=
ecurity.
>>> -JW
>>> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original=
 Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
>>>=20
>>>> On Sunday, October 20, 2019 1:03 AM, Eric Voskuil via bitcoin-dev bitco=
in-dev@lists.linuxfoundation.org wrote:
>>>> Hi Lucas,
>>>> I would question the assumption inherent in the problem statement. Sett=
ing aside variance discount, proximity premium, and questions of relative ef=
ficiency, 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 th=
e case of subsequently increasing hash rate.
>>>> The assumption of increasing hash rate implies an expectation of increa=
sing return on investment. There are certainly speculative errors, but a los=
s 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 i=
f 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
>>>>=20
>>>>>> 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 con=
tributions to bitcoin core I feel quite a beginner -- so if my idea is stupi=
d, 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 unloc=
k 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 ha=
ve a loss.
>>>>>> Solution: trustless hash-price insurance contract (or can we call it a=
n option to sell hashes at a given price?)
>>>>>> An insurer who believes that it's unlikely the price of a hash will g=
o down a lot negotiates a contract with the miner implemented as a Bitcoin t=
ransaction:
>>>>>> 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 produ=
ces a hash within certain difficulty constraints
>>>>>> The thing that makes it a hash-price insurance (or option, pardon my l=
ack of precise financial jargon), is that if hashing becomes cheap enough, i=
t 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 a=
ctually spending these resources -- so the miner can still mine Bitcoin and c=
ompensate for the lower-than-expected reward with part of the insurance depo=
sit.
>>>>>> 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 compariso=
n with long integers >32bit in the script, so implementation of the difficul=
ty 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 ex=
act 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 h=
ash that doesn't correspond to any short-length pre-image. I'm not sure abou=
t 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!
>>>>>=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