Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id A1667C000A for ; Tue, 16 Mar 2021 06:16:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 7AFF983938 for ; Tue, 16 Mar 2021 06:16:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjLQFBqexmB8 for ; Tue, 16 Mar 2021 06:16:37 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp1.osuosl.org (Postfix) with ESMTPS id 3215983926 for ; Tue, 16 Mar 2021 06:16:36 +0000 (UTC) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12G6GZFc029856 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 16 Mar 2021 02:16:35 -0400 Received: by mail-io1-f46.google.com with SMTP id u20so35931830iot.9 for ; Mon, 15 Mar 2021 23:16:35 -0700 (PDT) X-Gm-Message-State: AOAM530QufiLS0dmzkTb7Wo+2+UfgJ4e2aY5LHMWboMadHb8KHmZRN9s VtzUrgtfzLol5FS1vDIJ/0Ksj6M23/oApTtKWyc= X-Google-Smtp-Source: ABdhPJwEhix5zWiAq69dj6dFnWFu4K4LJJ3kOlzRJwg4rQgvXw+UhhfPLe1nIZ9jzXdxXoPmlERTPremrDuFe4X7zDQ= X-Received: by 2002:a5d:8d12:: with SMTP id p18mr2346371ioj.31.1615875394876; Mon, 15 Mar 2021 23:16:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Mon, 15 Mar 2021 23:16:23 -0700 X-Gmail-Original-Message-ID: Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="000000000000e9b82705bda14e09" Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Delegated signatures in Bitcoin within existing rules, no fork required 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: Tue, 16 Mar 2021 06:16:38 -0000 --000000000000e9b82705bda14e09 Content-Type: text/plain; charset="UTF-8" inline responses -- @JeremyRubin On Mon, Mar 15, 2021 at 11:10 PM ZmnSCPxj wrote: > Good morning Jeremy, > > This is a very cool idea! > > > Multiple Delegates: By signing a txn with several delegate outputs, it > is possible to enforce multiple disparate conditions. Normally this is > superfluous -- why not just concatenate S1 and S2? The answer is that you > may have S1 require a relative height lock and S2 require a relative time > lock (this was one of the mechanisms investigated for powswap.com). > > I am somewhat confused by this. > Do you mean that the delegating transaction (the one signed using the > script of A with `SIGHASH_NONE`) has as input (consumes) multiple delegate > outputs D1, D2... with individual scripts S1, S2... ? > > Correct -- you can do this if you want multiple independent delegates to be able to revoke, or if you want S1 and S2 to mix height + time based relative locks -- bonus points if D1.txid == D2.txid, then you can be sure they're counting from the same origin point. > > Sequenced Contingent Delegation: By constructing a specific TXID that > may delegate the coins, you can make a coin's delegation contingent on some > other contract reaching a specific state. For example, suppose I had a > contract that had 100 different possible end states, all with fixed > outpoints at the end. I could delegate coins in different arrangements to > be claimable only if the contract reaches that state. Note that such a > model requires some level of coordination between the main and observing > contract as each Coin delegate can only be claimed one time. > > Does this require that each contract end-state have a known TXID at setup > time? > Without anyprevout or similar, I believe so. > > > Redelegating: This is where A delegates to S, S delegates to S'. This > type of mechanism most likely requires the coin to be moved on-chain to the > script (A OR S or S'), but the on-chain movement may be delayed (via > presigned transactions) until S' actually wants to do something with the > coin. > > The script `A || S || S'` suggests that delegation effectively still > allows the original owner to still control the coin, right? > Which I suppose is implied by "Revocation" above. > Yes, redelegating (or I guess rather recursive delegation?) would mean A, S, and S' are all in play. if you want to revoke just A, then S must move to a utxo with S and S'. > > Regards, > ZmnSCPxj > > --000000000000e9b82705bda14e09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
inline r= esponses

On Mon, Mar 15, 2021 at 11:10 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
Good morning Jeremy,

This is a very cool idea!

> Multiple Delegates: By signing a txn with several delegate outputs, it= is possible to enforce multiple disparate conditions. Normally this is sup= erfluous -- why not just concatenate S1 and S2? The answer is that you may = have S1 require a relative height lock and S2 require a relative time lock = (this was one of the mechanisms investigated for powswap.com).

I am somewhat confused by this.
Do you mean that the delegating transaction (the one signed using the scrip= t of A with `SIGHASH_NONE`) has as input (consumes) multiple delegate outpu= ts D1, D2... with individual scripts S1, S2... ?


Co= rrect -- you can do this if you want multiple independent delegates to be a= ble to revoke, or if you want S1 and S2 to mix height + time based relative= locks -- bonus points if D1.txid =3D=3D D2.txid, then you can be sure they= 're counting from the same origin point.

=C2=A0=
> Sequenced Contingent Delegation: By constructing a specific TXID that = may delegate the coins, you can make a coin's delegation contingent on = some other contract reaching a specific state. For example, suppose I had a= contract that had 100 different possible end states, all with fixed outpoi= nts at the end. I could delegate coins in different arrangements to be clai= mable only if the contract reaches that state. Note that such a model requi= res some level of coordination between the main and observing contract as e= ach Coin delegate can only be claimed one time.

Does this require that each contract end-state have a known TXID at setup t= ime?

Without anyprevout or similar, I believe so.

=C2=A0

> Redelegating: This is where A delegates to S, S delegates to S'. T= his type of mechanism most likely requires the coin to be moved on-chain to= the script (A OR S or S'), but the on-chain movement may be delayed (v= ia presigned transactions) until S' actually wants to do something with= the coin.

The script `A || S || S'` suggests that delegation effectively still al= lows the original owner to still control the coin, right?
Which I suppose is implied by "Revocation" above.

Yes, redelegating (or I= guess rather recursive delegation?) would mean A, S, and S' are all in= play. if you want to revoke just A, then S must move to a utxo with S and = S'.

Regards,
ZmnSCPxj

--000000000000e9b82705bda14e09--