Return-Path: <tier.nolan@gmail.com> Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3D1DEC0051 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 16 Aug 2020 19:00:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 240D687847 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 16 Aug 2020 19:00:04 +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 hbpmiKItEenl for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 16 Aug 2020 19:00:03 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by whitealder.osuosl.org (Postfix) with ESMTPS id BEBEA877E0 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 16 Aug 2020 19:00:02 +0000 (UTC) Received: by mail-wr1-f47.google.com with SMTP id r4so12775452wrx.9 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 16 Aug 2020 12:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DSXBJ5k3fWj4LHqxIMTsp/kHjCV0tdBFYmG+F2s22SA=; b=FbxjzaCBJ+G+x4v7UlBh3IlCtDDMNhE/0Xv/PN2Shur+e7GaSDz9kmOZtzC9cWu7a8 ZM82WLRhuS3s0HVYVmojabrqVgBmD6ZBZ3Q9bOK4FRkGfXtbt4JReg6YY5IN4evvhOL9 rBSfXlVkblWGgAEjzRW2WkEwOGqiDnGfTwOoIdMQTkWSG2vte7p6pLuSk9jUiQWjWDLf l2jHflmB29OzZ/2qySfll2OoX5f8CWvOHT+y9JaYVh9NA8WiYupGATyGGE2OtFWmNog8 iS1KtvOywhivp8oCLNH1ch9iDnYvBgseWGgyLQfa/aqEtH4mHhpDijLWt5G67S5XfQ8s 8Dag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DSXBJ5k3fWj4LHqxIMTsp/kHjCV0tdBFYmG+F2s22SA=; b=lLpMa4UJ0kchdXIpsNhSX7MN1j3A84F/uXHovVtGFnioJ0gpMcUNzWYNCgpLYFLt27 yeiicocVfVc31fb2AEY7ayZr2oRg/AbmX1XuMs1lQvfwpUfo+jitGF1j8dfwqd+AxpCI riYA7dnafLWUV1O73Uwe9dRvYwvYc7vBmCk9kjVDB3+eKwiT+yklEKam4w5PK6csyHde 1B8fX8A2AS77DVduLQZWgWvY2mhBeJFYxKK+mfbQVD9nQzGfa5BLpaBUZ7JZl9T8H0WF RpFJPTSCZprjFo1nLQ3tBagjYnvvtuEpaZ3mWG7cndY9Zmw2MJKN15/OHrhx72EIKHBE sHmg== X-Gm-Message-State: AOAM532wkeEfwhLKNIzQnbgHMvp4uhqL3T5X8F3gpUejG2wFaz8q5M1M 1VnS+2+JOLKnpjCqCiI6Q8o8m2qR/FjxI3aZrdUoSdlJblw= X-Google-Smtp-Source: ABdhPJwhPUGPqaD54/Xja4UWDxg2D69TEyZ83Z+/+gDbdylWMufOFi2mZyJrg8RIhYO5uCg+YxyC4UAZzFtybjQ/Kxk= X-Received: by 2002:a05:6000:1203:: with SMTP id e3mr11955824wrx.324.1597604400903; Sun, 16 Aug 2020 12:00:00 -0700 (PDT) MIME-Version: 1.0 References: <CAHAXnDXhAFQHiBCJ=H=1ZGHdHWhgLh1rG3pCPR5o48ziZzV+zQ@mail.gmail.com> In-Reply-To: <CAHAXnDXhAFQHiBCJ=H=1ZGHdHWhgLh1rG3pCPR5o48ziZzV+zQ@mail.gmail.com> From: Tier Nolan <tier.nolan@gmail.com> Date: Sun, 16 Aug 2020 19:59:25 +0100 Message-ID: <CAE-z3OVCcAL2x39TswA8zrZ+yjSqdx4hccTWn9Ug8MQ5=k-Pgg@mail.gmail.com> To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> Content-Type: multipart/alternative; boundary="000000000000cebef405ad0342b3" 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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Sun, 16 Aug 2020 19:00:04 -0000 --000000000000cebef405ad0342b3 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 16, 2020 at 4:50 PM Thomas Hartman via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> 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. Either the output can be spent or it can't. You could get a pseudo-continuous future by having lots of outputs with different thresholds. Alice and Bob create a transaction with 100 outputs and each having 1% of the future's value. Output 0: Pay Alice if diff < 1.00 trillion else Bob Output 1: Pay Alice if diff < 1.01 trillion else Bob .... Output 98: Pay Alice if diff < 1.98 trillion else Bob Output 99: 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. The future has a tick size of 1%. It isn't very efficient though It would be good to have the option to specify a block height for the future too. If it triggered on block time, then miners have an incentive to give false block times. I am not clear if there is a way to solve the accounting for the > payouts, but perhaps there is a way to do this with covenants. > I agree you would need covenants or something similar. There needs to be a way to check the outputs (value and script) of the spending transaction. You also need a way for Alice and Bob to create their spending transaction in sequence. Output 0: Pay Alice if [output value 0] <= Diff / 1 trillion AND [output value 1] >= (2 trillion - diff) / (1 trillion) AND [output 1 pays to Bob] To spend her output, Alice has to create a transaction which pays Bob and assigns the coins in the right ratio. [output value x] means the output value of the spending transaction for output x. To get it to work Alice creates a transaction with these restrictions Output 0: Script: Anything (Alice gets it to pay herself) Value: <= Diff / 1 trillion Output 1: Script: Must pay to Bob Value: >= (2 trillion - Diff) / 1 trillion You also need to handle overflows with the calculations. Bob can then spend output 1 and get his money. There is a hold-up risk if Alice doesn't spend her money. You can make the output script so either of them can spend their coins to avoid that. Output 0: Pay Alice if [output value 0] <= Diff / 1 trillion AND [output value 1] >= (2 trillion - diff) / (1 trillion) AND [output 1 pays to Bob] OR Pay Bob if [output value 0] <= (2 trillion - Diff) / 1 trillion AND [output value 1] >= Diff / (1 trillion) AND [output 1 pays to Alice] You would need a covenant-like instruction to check the output values and scripts and the diff opcode to get the difficulty. --000000000000cebef405ad0342b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Sun, Aug 16, 2020 at 4:50 PM Thoma= s Hartman via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoun= dation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">My understanding is that a= dding a single op_difficulty operation as<br> proposed would enable not true difficulty futures but binary options<br> on difficulty.<br> <br> <a href=3D"https://en.wikipedia.org/wiki/Binary_option" rel=3D"noreferrer" = target=3D"_blank">https://en.wikipedia.org/wiki/Binary_option</a></blockquo= te><div><br></div><div>Any kind of opcode is a binary option.=C2=A0 Either = the output can be spent or it can't.</div><div><br></div><div>You could= get a pseudo-continuous future by having lots of outputs with different th= resholds.</div><div><br></div><div>Alice and Bob create a transaction with = 100 outputs and each having 1% of the future's value.<br></div><div><br= ></div> <div class=3D"gmail_quote"><div>Output 0:=C2=A0 Pay Alice if diff < 1.00= trillion else Bob<br></div>Output 1:=C2=A0 Pay Alice if diff < 1.01 tri= llion else Bob</div> <div class=3D"gmail_quote"><div>....<br></div><div>Output 98:=C2=A0 Pay Ali= ce if diff < 1.98 trillion else Bob<br></div>Output 99:=C2=A0 Pay Alice = if diff < 1.99 trillion else Bob</div><div class=3D"gmail_quote"><br></d= iv><div class=3D"gmail_quote">If the difficulty is 1.25 trillion, then Alic= e 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</div><div class=3D"gm= ail_quote"><br></div><div class=3D"gmail_quote">It would be good to have th= e option to specify a block height for the future too.=C2=A0 If it triggere= d on block time, then miners have an incentive to give false block times.<b= r></div><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0= .8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I am not clear if there is a way to solve the accounting for the<br> payouts, but perhaps there is a way to do this with covenants.<br></blockqu= ote><div><br></div><div>I agree you would need covenants or something simil= ar.</div><div><br></div><div>There needs to be a way to check the outputs (= value and script) of the spending transaction.=C2=A0 You also need a way fo= r Alice and Bob to create their spending transaction in sequence.</div><div= ><br></div><div>Output 0:=20 Pay Alice if [output value 0] <=3D Diff / 1 trillion AND [output value = 1] >=3D (2 trillion - diff)=C2=A0 / (1 trillion) AND [output 1 pays to B= ob]</div><div><br></div><div>To spend her output, Alice has to create a tra= nsaction which pays Bob and assigns the coins in the right ratio.=C2=A0 [ou= tput value x] means the output value of the spending transaction for output= x.</div><div><br></div><div>To get it to work Alice creates a transaction = with these restrictions</div><div><br></div><div>Output 0:</div><div>Script= : Anything (Alice gets it to pay herself)</div><div>Value:=20 <=3D Diff / 1 trillion <br></div><div><br></div><div>Output 1:</div><di= v>Script: Must pay to Bob</div><div>Value: >=3D (2 trillion - Diff) / 1 = trillion<br></div><div><br></div><div>You also need to handle overflows wit= h the calculations.</div><div><br></div><div>Bob can then spend output 1 an= d get his money.</div><div><br></div><div>There is a hold-up risk if Alice = doesn't spend her money.=C2=A0 You can make the output script so either= of them can spend their coins to avoid that.</div><div><br></div><div> Output 0: <br></div><div>=C2=A0=C2=A0=C2=A0 Pay Alice if [output value 0] &= lt;=3D Diff / 1 trillion AND [output value 1] >=3D (2 trillion - diff)= =C2=A0 / (1 trillion) AND [output 1 pays to Bob] </div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OR</div><div>=C2=A0=C2=A0=C2=A0 P= ay Bob if [output value 0] <=3D (2 trillion - Diff) / 1 trillion AND [ou= tput value 1] >=3D Diff / (1 trillion) AND [output 1 pays to Alice] <br>= </div><div><br></div><div>You would need a covenant-like instruction to che= ck the output values and scripts and the diff opcode to get the difficulty.= <br></div></div></div> --000000000000cebef405ad0342b3--