path: root/ba/090f5db45ed2337a31089ca6b88762868fec48

Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 94767B5F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 20 Oct 2019 16:17:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com
	[209.85.160.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D2F0014D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 20 Oct 2019 16:16:59 +0000 (UTC)
Received: by mail-qt1-f177.google.com with SMTP id m15so16948833qtq.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 20 Oct 2019 09:16:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=voskuil-org.20150623.gappssmtp.com; s=20150623;
	h=content-transfer-encoding:from:mime-version:subject:date:message-id
	:references:cc:in-reply-to:to;
	bh=LY8lQts/iGMKiQyRGUK3SFU6QOuYy61iMSzsrA4pqr0=;
	b=AKEVPe1e3CHunmEb1bDAZy+TvoKC4ylpG00bSzlItSCFKKc7Gd92CLpsMgbaPKlpve
	zTJtugRKyKox5jHCimF1g7Fu2LEE5ozvpuSnmz1PeoYl7zXjDSqQXoTzmpFI0Y16koxS
	tL9cEuhrXmlM9/gFMK7hLh06YlQ9kXD7eEIP3BniSeg1Er6D5Nrw0FEgyPgNXum58hE7
	WRUDE+7OlLV3mSlU+JEpW8iGyhsEuGw3KHSWdW6qH/k6jopDyRyQspVcBuFQvtNoI2cB
	ceHhfZYaCUWF37YNVXx8OUC35UgdL6w2Q+WvM65JrQBvFHmnEMgOY8BtZxPm20QIlc0q
	6CnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:content-transfer-encoding:from:mime-version
	:subject:date:message-id:references:cc:in-reply-to:to;
	bh=LY8lQts/iGMKiQyRGUK3SFU6QOuYy61iMSzsrA4pqr0=;
	b=uDiZfUe+QR5Yl2UGFDHhUNhLbMPCan0YM2s70sGXrr+FFdeSvjmUFtJNdKPm6RZvrT
	xMCuJ6E7a5fDalzfj14/ZAxVjAsy+uEq9WRZXD0vKFN5wKGUV1rRRr0sBWZ4FKGvMR9h
	kbdplapyZr7w2xhc6sy/qytAv2KSBWqRX48AopVLEpRXKrNtWuy6qvZzX8LbDyWEq6eq
	BgFHnSDsQRONffwSi5rElw9/JPLE7Ko535JhaZJUQTPXhAV/tEnjgJwcckBqOdQMff5w
	TOwtcbG6RSsjYfpyI400n2DbgTqoDVo0nPS6gxW2WVWCFvDFllWchabQSeaNpX2aFXjq
	TDzQ==
X-Gm-Message-State: APjAAAW4gGlbtLFW5o+EgN7YpiPSXkGv7o1uZEVVO7a1G4uIC+/B0sD5
	vWSCuDnbKDv89n+h2eYSLRUGew==
X-Google-Smtp-Source: APXvYqwTZvUhilzbgopPJBYEPrWwlwJYDNlpPKLMVLwJNZTyHTHFYmnZt91gBgCycLHr+Zi8AoO+nw==
X-Received: by 2002:ac8:2c45:: with SMTP id e5mr7912239qta.256.1571588218704; 
	Sun, 20 Oct 2019 09:16:58 -0700 (PDT)
Received: from ?IPv6:2600:380:bc23:b42c:9489:8da7:15fc:4cdf?
	([2600:380:bc23:b42c:9489:8da7:15fc:4cdf])
	by smtp.gmail.com with ESMTPSA id
	i10sm6371546qki.27.2019.10.20.09.16.58
	(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
	Sun, 20 Oct 2019 09:16:58 -0700 (PDT)
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>
X-Mailer: iPhone Mail (17A860)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, MIME_QP_LONG_LINE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 21 Oct 2019 05:00:55 +0000
Cc: Lucas H <lucash.dev@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Trustless hash-price insurance contracts
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Oct 2019 16:17:02 -0000

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