diff options
| author | Eric Voskuil <eric@voskuil.org> | 2019-10-20 01:03:09 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-10-20 05:03:14 +0000 |
| commit | 6e5015ad39676cf2139a2bcad8ee462b9e71c895 (patch) | |
| tree | 84b431bab92edae91969cd8847053563a71b9434 | |
| parent | fd99ae1454aac5d30d8d8cb8845c630b4a8857fd (diff) | |
| download | pi-bitcoindev-6e5015ad39676cf2139a2bcad8ee462b9e71c895.tar.gz pi-bitcoindev-6e5015ad39676cf2139a2bcad8ee462b9e71c895.zip | |
Re: [bitcoin-dev] Trustless hash-price insurance contracts
| -rw-r--r-- | 21/3d72b84b623e59e4725ff0b1389adb7c7ddc7f | 164 |
1 files changed, 164 insertions, 0 deletions
diff --git a/21/3d72b84b623e59e4725ff0b1389adb7c7ddc7f b/21/3d72b84b623e59e4725ff0b1389adb7c7ddc7f new file mode 100644 index 000000000..3e16b4efb --- /dev/null +++ b/21/3d72b84b623e59e4725ff0b1389adb7c7ddc7f @@ -0,0 +1,164 @@ +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 952D0AC7 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 20 Oct 2019 05:03:14 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com + [209.85.160.176]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DAAB714D + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 20 Oct 2019 05:03:13 +0000 (UTC) +Received: by mail-qt1-f176.google.com with SMTP id c17so12444135qtn.8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 19 Oct 2019 22:03:13 -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:date:subject:message-id + :references:in-reply-to:to; + bh=TLpej3y7tTcbdWdqJpd/4RBUv1lx8T3iTEApkBGJcc0=; + b=iIgfLtKnt/AraXIJPjywKFgmloy+37OxCR15k3BU61RqV7fL+cerM9fcTQy3Qd+ung + IwUJ+i7ES2zmMX8gJwgigIepBLf3Eejb1lM2+gVouEdUpHhZEeoQkqxn/m6XkOkUjeA1 + CjRKG4QmNVsMdaLejkyqOQ6USddDz+i9wV4SSvBC5ECblVbyeoLeao0zx6+7suqbO6Ln + cD5xAnIKJ89BKgkDX0W/9qRwQBcxGz2tsKV+nfW/AJvGJFzNjZagbg22RKldzgnQxJZa + jfcNBZvEOVece7xsqUK7ZenjzwsodjSO4xLcPcKgrPihp+d3/uvgYEL8MDzF/qcP8LNm + +45A== +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:date + :subject:message-id:references:in-reply-to:to; + bh=TLpej3y7tTcbdWdqJpd/4RBUv1lx8T3iTEApkBGJcc0=; + b=Y6L9uz1OhbX+rQRhuaAw9qpYZw8hxm+eRwraEGH1iFcSCbQ3pdYY7+xr9JjfjwAtvR + cUodU2/+3L+EM5D8QucSe2E+z4MidloVTYxobm7N+GXwz+ro+fRGMKo5exFbZCQh1vln + spbXHshh4vXPeHXdjEYg7iOurz0LCOF5DbINXv7Xeq19Dx6B/wHu9cAx/l/5Ykls0JvG + wosX0x1uVfWElrSXWJkekIqsF0DilujSZyDMwcTnbb4KNXQgHQYpwRIz01X3f/rYbR+6 + wTrwIWBfMovUD/uD5dvuBOxPRoXyG1cDU9IcwTL4yMGYVULRwf7RrjpXdU9tEsL/aMgZ + pM+A== +X-Gm-Message-State: APjAAAVPzBVgKnz25y2LE9knA9rcVsAcIodKdDFcNOvg8NKZYXRmwXOU + M+RSyevWrmnTbzHzm0KwJDXsXg== +X-Google-Smtp-Source: APXvYqy4vHKHExJf7s7+wUoxJVRfx21hE6UE4K2L5fy4gjDhZ2y1n0vAgxQ910zq4dbN8RiI7O7RVw== +X-Received: by 2002:ac8:1207:: with SMTP id x7mr18338319qti.255.1571547792759; + Sat, 19 Oct 2019 22:03:12 -0700 (PDT) +Received: from [10.8.63.70] (mobile-166-172-60-47.mycingular.net. + [166.172.60.47]) by smtp.gmail.com with ESMTPSA id + n42sm7749420qta.31.2019.10.19.22.03.11 + (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); + Sat, 19 Oct 2019 22:03:11 -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 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> +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: Sun, 20 Oct 2019 08:36:24 +0000 +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 05:03:14 -0000 + +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 + |