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 EB19DB7A for ; Sun, 20 Oct 2019 14:11:01 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 800C814D for ; Sun, 20 Oct 2019 14:11:00 +0000 (UTC) Date: Sun, 20 Oct 2019 14:10:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mathbot.com; s=protonmail; t=1571580658; bh=/XgfiKu+/dCVs6BoR+UPjYbN9hM31werjToo0rMP33w=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=M7Uc82SojshQXNUHXLmMizDBtkJcG8Gw56cvT7sH11Eu35ktCucP54+yiDZK6jFoX wKKyxg4tkG8YOY7ZFNrQi1Ti8pzL7k/MWhlJ3itM9KLIWwEuyURpN7/UrXeY6kUpng U/8siZJNyywcNZZv4ifoUKS7KcSdhv2QwbYKp/D8= To: Eric Voskuil , Bitcoin Protocol Discussion From: JW Weatherman Reply-To: JW Weatherman Message-ID: <5vCX5TKGwYMITwx_jp3BuX9nDr_DIez5kDPkF9ATAh_XYrQ4Y2rUGNU7qEkcy54BIEuNLB8TyznoOVBypNRWu0mTnqX4_D1oNK6ZT2fudQA=@mathbot.com> In-Reply-To: References: Feedback-ID: 06WE2TD3pl3nzC7QfAH2qr5LpZ25gVcyyzXUIYQj0HZLgktVjK3WV4DgnthPbH0VVmnpGZwYV2mfC_kynz7XVA==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW 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:01:09 +0000 Cc: Lucas H 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 14:11:02 -0000 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 hash= rate increases more than he expected. Depending on the cost of the offered insurance it would be prudent for a mi= ner to decrease his potential loss by buying insurance for this possibility= . And the existence of attractive insurance contracts would lower the barrier= to entry for new competitors in mining and this would increase bitcoins se= curity. -JW =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =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 1:03 AM, Eric Voskuil via bitcoin-dev wrote: > Hi Lucas, > > I would question the assumption inherent in the problem statement. Settin= g aside variance discount, proximity premium, and questions of relative eff= iciency, 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 t= he case of subsequently increasing hash rate. > > The assumption of increasing hash rate implies an expectation of increasi= ng return on investment. There are certainly speculative errors, but a loss= 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 if= 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 > > > On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev bitcoin-dev@lists.li= nuxfoundation.org wrote: > > Hi, > > This is my first post to this list -- even though I did some tiny contr= ibutions to bitcoin core I feel quite a beginner -- so if my idea is stupid= , 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 unlo= ck funds. > > The problem: > > A miner invests in new mining equipment, but if the hash-rate goes up t= oo much (the price he is paid for a hash goes down by too much) he will hav= e a loss. > > Solution: trustless hash-price insurance contract (or can we call it an= option to sell hashes at a given price?) > > An insurer who believes that it's unlikely the price of a hash will go = down a lot negotiates a contract with the miner implemented as a Bitcoin tr= ansaction: > > 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 produce= s a hash within certain difficulty constraints > > The thing that makes it a hash-price insurance (or option, pardon my la= ck of precise financial jargon), is that if hashing becomes cheap enough, i= t becomes profitable to spend resources finding a suitable pre-image, rathe= r than mining Bitcoin. > > Of course, both parties can reach an agreement that doesn't require act= ually spending these resources -- so the miner can still mine Bitcoin and c= ompensate for the lower-than-expected reward with part of the insurance dep= osit. > > If the price doesn't go down enough, the miner just mines Bitcoin and t= he insurer gets his deposit back. > > It's basically an instrument for guaranteeing a minimum profitability o= f the mining operation. > > Implementation issues: unfortunately we can't do arithmetic comparison = with long integers >32bit in the script, so implementation of the difficult= y 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 e= xact pre-images. The pre-images are chosen by the insurer, and we would nee= d a "honesty" deposit or other mechanism to punish the insurer if he choose= s a hash that doesn't correspond to any short-length pre-image. I'm not sur= e about 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! > > > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev