diff options
| author | Jeremy <jlrubin@mit.edu> | 2018-02-08 23:42:52 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-02-09 07:43:20 +0000 |
| commit | ce5cf13035164415ae171a5cb1a4163f31ebbf17 (patch) | |
| tree | 5076ff64cdbeb8482564393fa8d78941e7b955de | |
| parent | 168715eb8aee47438ceed4b89c92aada7aac9f4d (diff) | |
| download | pi-bitcoindev-ce5cf13035164415ae171a5cb1a4163f31ebbf17.tar.gz pi-bitcoindev-ce5cf13035164415ae171a5cb1a4163f31ebbf17.zip | |
Re: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption
| -rw-r--r-- | 26/9c4e203955169c14b87a59a803b375f4535b78 | 225 |
1 files changed, 225 insertions, 0 deletions
diff --git a/26/9c4e203955169c14b87a59a803b375f4535b78 b/26/9c4e203955169c14b87a59a803b375f4535b78 new file mode 100644 index 000000000..b3951da43 --- /dev/null +++ b/26/9c4e203955169c14b87a59a803b375f4535b78 @@ -0,0 +1,225 @@ +Return-Path: <jlrubin@mit.edu> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id E99DC137A + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 9 Feb 2018 07:43:20 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu + [18.7.68.36]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 05BE3F6 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 9 Feb 2018 07:43:19 +0000 (UTC) +X-AuditID: 12074424-cc9ff700000034a6-8e-5a7d5115ea0c +Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) + (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) + (Client did not present a certificate) + by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP + id 7F.05.13478.5115D7A5; Fri, 9 Feb 2018 02:43:18 -0500 (EST) +Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) + by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w197hFnq000973 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 9 Feb 2018 02:43:15 -0500 +Received: from mail-yw0-f170.google.com (mail-yw0-f170.google.com + [209.85.161.170]) (authenticated bits=0) + (User authenticated as jlrubin@ATHENA.MIT.EDU) + by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w197hDLx006790 + (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 9 Feb 2018 02:43:14 -0500 +Received: by mail-yw0-f170.google.com with SMTP id b129so4508263ywa.8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 08 Feb 2018 23:43:14 -0800 (PST) +X-Gm-Message-State: APf1xPBdKZjsjiAF5HyrV6vcXoeseNQqWllqd1sp3pWPiN1MiA3TUkRS + SvAA2k6PvCP0uFcN0L52/JYYu4XxmiOYCBdO6dc= +X-Google-Smtp-Source: AH8x226GTwWZbuaCNCtb8ON9nUssWyrcvZC1FCF1l8IGrkHoIBEiCvkclmiBOfRYNI3weM9aD6DJAcqEK2Uszfqtp3s= +X-Received: by 10.37.133.133 with SMTP id x5mr1066255ybk.367.1518162192894; + Thu, 08 Feb 2018 23:43:12 -0800 (PST) +MIME-Version: 1.0 +Received: by 10.13.235.138 with HTTP; Thu, 8 Feb 2018 23:42:52 -0800 (PST) +In-Reply-To: <CAD5xwhiqcHjy2bFcCzNue+M92z3_QHZra801c6Kx7OBf=68sRw@mail.gmail.com> +References: <CAAS2fgSnfd++94+40vnSRxQfi9fk8N6+2-DbjVpssHxFvYveFQ@mail.gmail.com> + <CAMnpzfphzviN9CqZaFa3P-U2OnHn56LYEtWtMktT1D37bPqvcQ@mail.gmail.com> + <CAAS2fgSVHfh2++JLCTOWVmMiwfqSkGgj4O+HR4wTYTXaZr6n9Q@mail.gmail.com> + <CAD5xwhiqcHjy2bFcCzNue+M92z3_QHZra801c6Kx7OBf=68sRw@mail.gmail.com> +From: Jeremy <jlrubin@mit.edu> +Date: Thu, 8 Feb 2018 23:42:52 -0800 +X-Gmail-Original-Message-ID: <CAD5xwhgYAN9RFWBfJjr7BMeZM1SWbKtuTEknzBqZnpaR-ihsGg@mail.gmail.com> +Message-ID: <CAD5xwhgYAN9RFWBfJjr7BMeZM1SWbKtuTEknzBqZnpaR-ihsGg@mail.gmail.com> +To: Jeremy <jlrubin@mit.edu> +Content-Type: multipart/alternative; boundary="089e0832c24838160d0564c2ae5c" +X-Brightmail-Tracker: H4sIAAAAAAAAA01SbUhTURjm7G7ubO7acX7saBq1JCrRjNRKSoT6IZXkRCuWUFd3c6PtKvfO + T5JMyB+aKUiigzAVCz/K0FIzV7J+KWRaEAVzioWZklmaWAZ2jxe1Pw/PeZ/nfd6Xcw6ktOOK + YGjh7CzPMVa9l1quVQWERwQaio1REx0BR0rnjieAxNWVGpAMjOpjJtZqyWP5A/GX1ebupVZF + zpu4gol3v+Ul4O6hcqCCGEXjha5mRTlQQy1qluGBtl5KOrgBfljpAMSlRYsy3DRtkIRGgAee + TwKpPR93Oj1KifP4Z/sKJXEBV4zWeRFOI188VP9ZLgWdwr+GK2SEq5ABV/XMyzZHT8w9EJsh + 9EI78MKfGOKRozBc6n4pI2WMGOz+foFQGiXjwQmGOPyQFd9wflqf6o9C8Ot5z3oihRoAbl97 + ryR+Cp3Bna+Kq4G/47+FHFsKKVNoH77Zu6qU+F58z/0CSDwc32+co+4BRRsINdmKImyMxSqw + mRFCJsNxLB9xONJmsUeyptwuQN5DeTKsD1TcOu0CCAK9hq5Ov2bUKpg8odDmAkFQpg+guyvF + kk9GtqnQzAjmS3yulRVcAENK70+PJhUbtbSJKSxi+ewNaTuU63V0YnS4UYuyGDt7lWVzWH5D + DYFQj+ndyWKjL89msQVXLFb7liyDKhKuEcOPEg8t5DA2wZIl6cPgPFxY9JRRcNkxKWJ1A8Fp + J8Hl2i8iPpn6KuLgOn6YmSujtHIum2ODdbSOxCESZ87lNieSXzmW1tg2C3TiBfjR18+KLo34 + ZzdnzorryMR1xhPW17EzW1JwCbBE0QH2ztjK1EB5lLezyrcmP2vKPjlaPtJdyj1b80QvXfTZ + 5ixTnAvLUO480f+2W43jAn+glMZHPWuhvZqMINhhjedG0ltvN4WMZ8yYak2uQptjjzIl7fFI + zOxfmBD/0eVOrKuPxan9+WO7vq21qA1Dfpl9LXeGvZ8mtTQU6eWCmTm4n+IF5h9MVc+VcAMA + AA== +X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE, + RCVD_IN_DNSWL_MED,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Graftroot: Private and efficient surrogate + scripts under the taproot assumption +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +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: Fri, 09 Feb 2018 07:43:21 -0000 + +--089e0832c24838160d0564c2ae5c +Content-Type: text/plain; charset="UTF-8" + +I'm also highly interested in the case where you sign a delegate +conditional on another delegate being signed, e.g. a bilateral agreement. + +In order for this to work nicely you also need internally something like +segwit so that you can refer to one side's delegation by a signature-stable +identity. + +I don't have a suggestion of a nice way to do this at this time, but will +stew on it. + +-- +@JeremyRubin <https://twitter.com/JeremyRubin> +<https://twitter.com/JeremyRubin> + +On Thu, Feb 8, 2018 at 11:29 PM, Jeremy <jlrubin@mit.edu> wrote: + +> This might be unpopular because of bad re-org behavior, but I believe the +> utility of this construction can be improved if we introduce functionality +> that makes a script invalid after a certain time (correct me if I'm +> wrong, I believe all current timelocks are valid after a certain time and +> invalid before, this is the inverse). +> +> Then you can exclude old delegates by timing/block height arguments, or +> even pre-sign delegates for different periods of time (e.g., if this +> happens in the next 100 blocks require y, before the next 1000 blocks but +> after the first 100 require z, etc). +> +> +> +> -- +> @JeremyRubin <https://twitter.com/JeremyRubin> +> <https://twitter.com/JeremyRubin> +> +> On Mon, Feb 5, 2018 at 11:58 AM, Gregory Maxwell via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> +>> On Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant <bitcoin-dev@rgrant.org> +>> wrote: +>> > Am I reading correctly that this allows unilateral key rotation (to a +>> > previously unknown key), without invalidating the interests of other +>> > parties in the existing multisig (or even requiring any on-chain +>> > transaction), at the cost of storing the signed delegation? +>> +>> Yes, though I'd avoid the word rotation because as you note it doesn't +>> invalidate the interests of any key, the original setup remains able +>> to sign. You could allow a new key of yours (plus everyone else) to +>> sign, assuming the other parties agree... but the old one could also +>> still sign. +>> _______________________________________________ +>> bitcoin-dev mailing list +>> bitcoin-dev@lists.linuxfoundation.org +>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>> +> +> + +--089e0832c24838160d0564c2ae5c +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he= +lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I'm also highly in= +terested in the case where you sign a delegate conditional on another deleg= +ate being signed, e.g. a bilateral agreement.</div><div class=3D"gmail_defa= +ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:= +rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:ari= +al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">In order for this= + to work nicely you also need internally something like segwit so that you = +can refer to one side's delegation by a signature-stable identity.<br><= +/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans= +-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_defa= +ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:= +rgb(0,0,0)">I don't have a suggestion of a nice way to do this at this = +time, but will stew on it.<br></div></div><div class=3D"gmail_extra"><br cl= +ear=3D"all"><div><div class=3D"gmail_signature" data-smartmail=3D"gmail_sig= +nature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" = +target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubi= +n" target=3D"_blank"></a></div></div></div> +<br><div class=3D"gmail_quote">On Thu, Feb 8, 2018 at 11:29 PM, Jeremy <spa= +n dir=3D"ltr"><<a href=3D"mailto:jlrubin@mit.edu" target=3D"_blank">jlru= +bin@mit.edu</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl= +e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di= +r=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,helvetica= +,sans-serif;font-size:small;color:rgb(0,0,0)">This might be unpopular becau= +se of bad re-org behavior, but I believe the utility of this construction c= +an be improved if we introduce functionality that makes a script<i> </i>inv= +alid after a certain time (correct me if I'm wrong, I believe all curre= +nt timelocks are valid after a certain time and invalid before, this is the= + inverse).</div><div class=3D"gmail_default" style=3D"font-family:arial,hel= +vetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D= +"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s= +mall;color:rgb(0,0,0)">Then you can exclude old delegates by timing/block h= +eight arguments, or even pre-sign delegates for different periods of time (= +e.g., if this happens in the next 100 blocks require y, before the next 100= +0 blocks but after the first 100 require z, etc).</div><div class=3D"gmail_= +default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co= +lor:rgb(0,0,0)"><br></div></div><div class=3D"gmail_extra"><br clear=3D"all= +"><div><br clear=3D"all"><div><div class=3D"m_-5054630071886368334gmail_sig= +nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href= +=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a h= +ref=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div><= +/div> +</div><div><div class=3D"h5"> +<br><div class=3D"gmail_quote">On Mon, Feb 5, 2018 at 11:58 AM, Gregory Max= +well via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@li= +sts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoun= +dation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= +=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On= + Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant <<a href=3D"mailto:bitcoin-dev@= +rgrant.org" target=3D"_blank">bitcoin-dev@rgrant.org</a>> wrote:<br> +> Am I reading correctly that this allows unilateral key rotation (to a<= +br> +> previously unknown key), without invalidating the interests of other<b= +r> +> parties in the existing multisig (or even requiring any on-chain<br> +> transaction), at the cost of storing the signed delegation?<br> +<br> +</span>Yes, though I'd avoid the word rotation because as you note it d= +oesn't<br> +invalidate the interests of any key, the original setup remains able<br> +to sign.=C2=A0 You could allow a new key of yours (plus everyone else) to<b= +r> +sign, assuming the other parties agree... but the old one could also<br> +still sign.<br> +<div class=3D"m_-5054630071886368334HOEnZb"><div class=3D"m_-50546300718863= +68334h5">______________________________<wbr>_________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= +/mailman/listinfo/bitcoin-d<wbr>ev</a><br> +</div></div></blockquote></div><br></div></div></div> +</blockquote></div><br></div> + +--089e0832c24838160d0564c2ae5c-- + |