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 94767B5F for ; 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 ; Sun, 20 Oct 2019 16:16:59 +0000 (UTC) Received: by mail-qt1-f177.google.com with SMTP id m15so16948833qtq.2 for ; 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 Mime-Version: 1.0 (1.0) Date: Sun, 20 Oct 2019 12:16:57 -0400 Message-Id: References: In-Reply-To: To: JW Weatherman 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 , Bitcoin Protocol Discussion 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 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 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 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