From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 92A0FC07FF for ; Mon, 17 Aug 2020 05:04:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 7541820494 for ; Mon, 17 Aug 2020 05:04:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YO3f3aYTCTzz for ; Mon, 17 Aug 2020 05:04:55 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) by silver.osuosl.org (Postfix) with ESMTPS id F4222204B2 for ; Mon, 17 Aug 2020 05:04:54 +0000 (UTC) Date: Mon, 17 Aug 2020 05:04:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1597640692; bh=kr4jljk0qKtKjRo8Y7LgKs7BEUrmva+G9kLH/9XuZuM=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=Gl1wqljOCHF6wSeC9t+rvIvm9T4iZ2k5ZL80lb8D2+y2SsljAos2aPT8lJ4VO+a5P roevmcffFxU1dBKcqri53FBe/YcvkXD/OGvZgrbhY2wvVHb4wjONps++NgLbwgGV1D VvGcAyd6uZ/Wm1DU/NGWnjdym2xVESnZ53BF1+vY= To: Tier Nolan , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Mon, 17 Aug 2020 05:04:57 -0000 Good morning Tier, Thomas, and aj, > On Sun, Aug 16, 2020 at 4:50 PM 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. > > > > https://en.wikipedia.org/wiki/Binary_option > > Any kind of opcode is a binary option.=C2=A0 Either the output can be spe= nt or it can't. > > You could get a pseudo-continuous future by having lots of outputs with d= ifferent thresholds. > > Alice and Bob create a transaction with 100 outputs and each having 1% of= the future's value. > > Output 0:=C2=A0 Pay Alice if diff < 1.00 trillion else Bob > Output 1:=C2=A0 Pay Alice if diff < 1.01 trillion else Bob > .... > Output 98:=C2=A0 Pay Alice if diff < 1.98 trillion else Bob > Output 99:=C2=A0 Pay Alice if diff < 1.99 trillion else Bob > > If the difficulty is 1.25 trillion, then Alice gets outputs 0-24 and Bob = gets outputs 25-99.=C2=A0 The future has a tick size of 1%.=C2=A0 It isn't = very efficient though Taproot MAST to the rescue. * Alice and Bob agree on the number of ticks N and payout schedule. * Alice and Bob generate N fresh keypairs and share them. * Alice and Bob generate tapleaf scripts of the form: * script[i] =3D Alice[i] && Bob[i] && diff < 1.00 trillion + i * tick_siz= e && CLTV(deadline) * Alice and Bob generate the taproot MAST for the above scripts. * Alice and Bob generate, but do ***NOT*** sign, a funding transaction payi= ng out to the generated taproot MAST. * Bob generates partial signatures for N payout transactions, with lower-di= fficulty-targets paying out less to Alice and more to Bob, and higher-diffi= culty-targets paying out more to Alice and less to Bob. * This requires spending the [i]th tapleaf script with the appropriate di= fficulty target. * Alice saves all the Bob signatures. * At deadline, Alice rationally selects the highest-paying version that is = still acceptable, based on the actual difficulty target at the time. This requires publishing only O(log N) data (the merkle path to the selecte= d tapleaf). This translates to the 100-tick example requiring only one TXO, 1 scripthas= h, and 7 or so Merkle-tree-path hashes, compared to the above example which= requires 100 TXOs and 100 script hashes. The same scheme can be used with `OP_CTV` and without keypairs being involv= ed, but basically anything `OP_CTV` can do, signing keypairs with pre-gener= ated signatures from all participants can do just as well, with higher stor= age and setup costs. Regards, ZmnSCPxj