From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2E21EC07FF for ; Sun, 16 Aug 2020 22:29:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 2468D87D8B for ; Sun, 16 Aug 2020 22:29:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUEna5gC-MqX for ; Sun, 16 Aug 2020 22:29:33 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by whitealder.osuosl.org (Postfix) with ESMTPS id 635F887D0C for ; Sun, 16 Aug 2020 22:29:33 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian)) id 1k7R9c-0000SF-LU; Mon, 17 Aug 2020 08:29:30 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Mon, 17 Aug 2020 08:29:23 +1000 Date: Mon, 17 Aug 2020 08:29:23 +1000 From: Anthony Towns To: Thomas Hartman , Bitcoin Protocol Discussion Message-ID: <20200816222923.zf47qrmqdiuv6yfp@erisian.com.au> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Score-int: -18 X-Spam-Bar: - Subject: Re: [bitcoin-dev] reviving op_difficulty X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 22:29:34 -0000 On Sun, Aug 16, 2020 at 11:41:30AM -0400, Thomas Hartman via bitcoin-dev wrote: > My understanding is that adding a single op_difficulty operation as > proposed would enable not true difficulty futures but binary options > on difficulty. An alternative approach for this might be to use taproot's annex concept. https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-5 The idea would be to add an annex restriction that's only valid if the difficulty is a given value (or within a given range). Protocol design could be: Alice, Bob, Carol, Dave want to make bets on difficulty futures They each deposit a,b,c,d into a UTXO of value a+b+c+d payable to a 4-4 of multisig of their keys (eg MuSig(A,B,c,D)) They construct signed payouts spending that UTXO, all timelocked for the future date; one spending to Alice with the annex locking in the difficulty to Alice's predicted range, one spending to Bob with the annex locking in the difficulty to Bob's predicted range, etc When the future date arrives, whoever was right can immediately broadcast their payout transaction. (If they don't, then someone else might be able to when the difficulty next retargets) (Specifying an exact value for the difficulty rather than a range might be better; it's smaller/simpler on the blockchain, and doesn't reveal the ranges of your predictions giving traders slightly better privacy. The cost to doing that is if Alice predicts difficulty could be any of 100 different values, she needs 100 different signatures for her pre-signed payout, one for each possible difficulty value that would be encoded in the annex) Cheers, aj