From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 952D0AC7 for ; 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 ; Sun, 20 Oct 2019 05:03:13 +0000 (UTC) Received: by mail-qt1-f176.google.com with SMTP id c17so12444135qtn.8 for ; 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 Mime-Version: 1.0 (1.0) Date: Sun, 20 Oct 2019 01:03:09 -0400 Message-Id: References: In-Reply-To: To: Lucas H , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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