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 178BEB5F for ; Sun, 20 Oct 2019 16:11:01 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 12915831 for ; Sun, 20 Oct 2019 16:10:59 +0000 (UTC) Date: Sun, 20 Oct 2019 16:10:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mathbot.com; s=protonmail; t=1571587857; bh=06+9sQQjwxyFNLz4X+fgNjm86IvUTJnxr3tCqTrIlfg=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=lozwTXdkEAmHaoVoypnCU0DrIj3531aAEoOUN8jALxfTjHTBfNqGPgp3D56jombu0 thUKb82nd2EXmqNakK/XYmId/Caf9ja8SNxmbgKl3Iz6U/Widn6jCNesV5ngE/iPX7 cVERbfgeJLgsSDhKSuFWl9BWEd1C9jyu6QxJge1M= To: Eric Voskuil From: JW Weatherman Reply-To: JW Weatherman Message-ID: In-Reply-To: <90A19D12-D964-41AE-A27F-AB99B66936D1@voskuil.org> References: <5vCX5TKGwYMITwx_jp3BuX9nDr_DIez5kDPkF9ATAh_XYrQ4Y2rUGNU7qEkcy54BIEuNLB8TyznoOVBypNRWu0mTnqX4_D1oNK6ZT2fudQA=@mathbot.com> <90A19D12-D964-41AE-A27F-AB99B66936D1@voskuil.org> 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 , 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:11:01 -0000 Oh, I see your point. 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 op= timal electricity and labor costs probably wouldn't be interested in purcha= sing insurance for a high price, but if it was cheap enough it would still = be worth it. And any potential new entrants on the edge of jumping in would= enter when they otherwise would not have because of the decreased costs (d= ecreased risk). An analogy would be car insurance. If you are an excellent driver you would= n't be willing to spend a ton of money to protect your car in the event of = an accident, but if it is cheap enough you would. And there may be people t= hat are unwilling to take the risk of a damaged car that refrain from becom= ing drivers until insurance allows them to lower the worst case scenario of= a damaged car. -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 10:57 AM, Eric Voskuil wrote= : > > > > 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 tha= t a single miner could make an investment that becomes unprofitable if the = hash rate increases more than he expected. > > This is a restatement of the assumption I questioned. Hash rate increase = does not imply unprofitability. The new rig should be profitable. > > 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 unprofitab= le, all miners are unprofitable. > > > 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 possibi= lity. > > And the existence of attractive insurance contracts would lower the bar= rier to entry for new competitors in mining and this would increase bitcoin= s security. > > -JW > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origina= l Message =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 bit= coin-dev@lists.linuxfoundation.org wrote: > > > Hi Lucas, > > > I would question the assumption inherent in the problem statement. Se= tting aside variance discount, proximity premium, and questions of relative= efficiency, as these are presumably already considered by the miner upon t= he purchase of new equipment, it=E2=80=99s not clear why a loss is assumed = in the case of subsequently increasing hash rate. > > > The assumption of increasing hash rate implies an expectation of incr= easing 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, an= d if he is not, hash rate will drop until he is. This drop is most likely t= o be precipitated by older equipment going offline. > > > Best, > > > Eric > > > > > > > > On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev bitcoin-dev@li= sts.linuxfoundation.org wrote: > > > > > Hi, > > > > > This is my first post to this list -- even though I did some tiny= contributions 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 b= e trustless bc we can use the assumption that the price of hashing is low t= o unlock funds. > > > > > The problem: > > > > > A miner invests in new mining equipment, but if the hash-rate goe= s up too much (the price he is paid for a hash goes down by too much) he wi= ll have 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 wi= ll go down a lot negotiates a contract with the miner implemented as a Bitc= oin transaction: > > > > > Inputs: a deposit from the insurer and a premium payment by the m= iner > > > > > 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 agreeme= nt > > > > > C. Before expiry, miner can spend by providing a pre-image that p= roduces a hash within certain difficulty constraints > > > > > The thing that makes it a hash-price insurance (or option, pardon= my lack of precise financial jargon), is that if hashing becomes cheap eno= ugh, it 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 requi= re actually spending these resources -- so the miner can still mine Bitcoin= and compensate for the lower-than-expected reward with part of the insuran= ce deposit. > > > > > 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 profitabi= lity of the mining operation. > > > > > Implementation issues: unfortunately we can't do arithmetic compa= rison with long integers >32bit in the script, so implementation of the dif= ficulty requirement needs to be hacky. I think we can use the hashes of one= or more pre-images with a given short length, and the miner has to provide= the exact pre-images. The pre-images are chosen by the insurer, and we wou= ld need a "honesty" 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 n= ot sure about this implementation though, maybe we actually need new opcode= s. > > > > > 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