path: root/47/0ff2cd87cded8dfed9c20568edf01f0ac70b74

Return-Path: <jlrubin@mit.edu>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A1667C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>; Tue, 16 Mar 2021 02:16:35 -0400
Received: by mail-io1-f46.google.com with SMTP id u20so35931830iot.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAD5xwhhC1Y13p7KazfUOXFZ5vi5MA9EQ-scyafv4aNkjskoXBg@mail.gmail.com>
 <plFEi9xoSnZ0TDJ7wH2dJx1F727FCSBrPsa2-26AXtveHKolt9bzTE1tiGIoPSjhgBfToVID2YHEaMGwwVU5dZ3Sozmz9UO-6HvbEDmm67I=@protonmail.com>
In-Reply-To: <plFEi9xoSnZ0TDJ7wH2dJx1F727FCSBrPsa2-26AXtveHKolt9bzTE1tiGIoPSjhgBfToVID2YHEaMGwwVU5dZ3Sozmz9UO-6HvbEDmm67I=@protonmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Mon, 15 Mar 2021 23:16:23 -0700
X-Gmail-Original-Message-ID: <CAD5xwhhMjsYMRebN4Td614qOyAey24h7vQAjZjP_ETzvXJQBLw@mail.gmail.com>
Message-ID: <CAD5xwhhMjsYMRebN4Td614qOyAey24h7vQAjZjP_ETzvXJQBLw@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000e9b82705bda14e09"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: Tue, 16 Mar 2021 06:16:38 -0000

--000000000000e9b82705bda14e09
Content-Type: text/plain; charset="UTF-8"

inline responses
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


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
> 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

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">inline r=
esponses<br clear=3D"all"></div><div><div dir=3D"ltr" class=3D"gmail_signat=
ure" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"h=
ttps://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=
=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div></di=
v><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">On Mon, Mar 15, 2021 at 11:10 PM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSC=
Pxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">Good morning Jeremy,<br>
<br>
This is a very cool idea!<br>
<br>
&gt; 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 <a href=3D"http://powswap.=
com" rel=3D"noreferrer" target=3D"_blank">powswap.com</a>).<br>
<br>
I am somewhat confused by this.<br>
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... ?<br>
<br></blockquote><div><br></div><div><div style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">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=
&#39;re counting from the same origin point.<br></div><br></div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; Sequenced Contingent Delegation: By constructing a specific TXID that =
may delegate the coins, you can make a coin&#39;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.<br>
<br>
Does this require that each contract end-state have a known TXID at setup t=
ime?<br></blockquote><div><br></div><div><div style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default=
">Without anyprevout or similar, I believe so.</div><br></div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
&gt; Redelegating: This is where A delegates to S, S delegates to S&#39;. T=
his type of mechanism most likely requires the coin to be moved on-chain to=
 the script (A OR S or S&#39;), but the on-chain movement may be delayed (v=
ia presigned transactions) until S&#39; actually wants to do something with=
 the coin.<br>
<br>
The script `A || S || S&#39;` suggests that delegation effectively still al=
lows the original owner to still control the coin, right?<br>
Which I suppose is implied by &quot;Revocation&quot; above.<br></blockquote=
><div><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)" class=3D"gmail_default">Yes, redelegating (or I=
 guess rather recursive delegation?) would mean A, S, and S&#39; are all in=
 play. if you want to revoke just A, then S must move to a utxo with S and =
S&#39;.</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size=
:small;color:rgb(0,0,0)" class=3D"gmail_default"></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
</blockquote></div></div>

--000000000000e9b82705bda14e09--