Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E99DC137A for ; 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 ; 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 ; 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 ; Fri, 9 Feb 2018 02:43:14 -0500 Received: by mail-yw0-f170.google.com with SMTP id b129so4508263ywa.8 for ; 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: References: From: Jeremy Date: Thu, 8 Feb 2018 23:42:52 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Jeremy 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 On Thu, Feb 8, 2018 at 11:29 PM, Jeremy 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 > > > 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 >> 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
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.

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.
<= /div>

I don't have a suggestion of a nice way to do this at this = time, but will stew on it.


On Thu, Feb 8, 2018 at 11:29 PM, Jeremy <jlru= bin@mit.edu> wrote:
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 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).

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>

On Mon, Feb 5, 2018 at 11:58 AM, Gregory Max= well via bitcoin-dev <bitcoin-dev@lists.linuxfoun= dation.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<= br> > 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 d= oesn't
invalidate the interests of any key, the original setup remains able
to sign.=C2=A0 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--