path: root/58/15c3e23ff545c1dcbf9c2c434c06ab2b55c413

Return-Path: <jlrubin@mit.edu>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 62523C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 Mar 2021 23:55:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 41E5B605F7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 Mar 2021 23:55:59 +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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id VvwX15Uy_mar
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 Mar 2021 23:55:57 +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 smtp3.osuosl.org (Postfix) with ESMTPS id 9AE47605F5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 Mar 2021 23:55:57 +0000 (UTC)
Received: from mail-io1-f48.google.com (mail-io1-f48.google.com
 [209.85.166.48]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12ANttqb028863
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 10 Mar 2021 18:55:56 -0500
Received: by mail-io1-f48.google.com with SMTP id o9so19963615iow.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 Mar 2021 15:55:55 -0800 (PST)
X-Gm-Message-State: AOAM531zEyJHLOG5m1XFlzeRiBAwPbX+js/QTt02b0oh8AKnOb5CjFQC
 YeahNOA6+GNnhEGxhiqDgJCMzQhyny3mN9hYUSQ=
X-Google-Smtp-Source: ABdhPJyOfMU04Y+CZhCODS8O1t+mgw485iYXTceDKxC9bQH92x0DOrvrEPTCvUP7vTY1wSh3fYp1NEm8AsH3nbrep9c=
X-Received: by 2002:a05:6602:1592:: with SMTP id
 e18mr4038780iow.49.1615420554772; 
 Wed, 10 Mar 2021 15:55:54 -0800 (PST)
MIME-Version: 1.0
From: Jeremy <jlrubin@mit.edu>
Date: Wed, 10 Mar 2021 15:55:43 -0800
X-Gmail-Original-Message-ID: <CAD5xwhhC1Y13p7KazfUOXFZ5vi5MA9EQ-scyafv4aNkjskoXBg@mail.gmail.com>
Message-ID: <CAD5xwhhC1Y13p7KazfUOXFZ5vi5MA9EQ-scyafv4aNkjskoXBg@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000054881805bd3768d5"
Subject: [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: Wed, 10 Mar 2021 23:55:59 -0000

--00000000000054881805bd3768d5
Content-Type: text/plain; charset="UTF-8"

I'm aware that some folks (I think nullc, sipa, myself... maybe more?) are
aware of how to do script delegation in Bitcoin today (without any
modifications to Bitcoin), but realized in a conversation with Andrew P
that the technique is not widely known. So I figured it made sense to do a
brief explainer of how this works for the archives / so the technique is
documented. If someone has other citations for this, please respond below.

If you like cartoons follow along here:

https://docs.google.com/presentation/d/1ikcthy3p-Ah59pJyss0TLEj-Q2FF6tv7BXhkORzErAE/edit#slide=id.p

Technically what we are doing is delegating a UTXO to a specific UTXO, and
not to a script.


Suppose you have a coin on UTXO A. You would like to delegate it to script
S. You can either scan the chain for any UTXOs bound to S or use some
arbitrary coin B to create a transaction X with an output D that has script
S (doesn't have to have any value, but let's say it has a nominal amount to
avoid dust issues). Because tx X is not malleable, we don't need to
actually broadcast it and spend B till we want to use the delegation, and
it can be created (for the TXID) without B's owner being online. However
you get the UTXO, and if it exists or not yet, let's call it D.

*Note: if you're using a delegation script multiple times, you can optimize
the creation step a bit*

Now, using A, you sign a transaction with 2 inputs (one of them being D)
and SIGHASH_NONE. This signs all of the inputs (but not their sequences!)
but none of the outputs. Let's call this transaction stub G.

Now, using S, you sign D's input on G with SIGHASH_ALL and the outputs you
want to create (whatever they may be). Let's call the finished transaction
F.

Effectively, the holder of A has delegated the control of their coin to a
specific instance of the script S. Once delegated, S may authorize almost
any transaction they want (complicated if they want to sign a multiple
input transaction; but there are good substitutes).

Advanced Topics:

*Revocation*: There are multiple ways to revoke, either moving A, moving D,
refusing to sign and create D (when D is derived from B), etc. Because
these are UTXO-bound they are revocable. (the cartoon may help here)
*Cross input delegation*: A set of N coins may create a sighash_none
transaction with 1 additional input for the delegating script
*Partial Spending Authorizations*: Replacing sighash_none with
sighash_single allows an input to specify a single change address (plug --
OP_CTV covenants can be thought of as a way to get around sighash_single to
allow sighash_single to cover signing a set of outputs)
*Delegation after time*: Because the lock_time field is covered,
delegations can be set up to only be valid at some point in the future.
Only a single sequence lock per delegated coin may be used directly.
*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).
*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.
*CTV Specific P2SH Non Coin Delegation: *OP_CTV allows for a similar form
of delegation where by a Segwit P2SH address, as a part of the CTV
committed data, can be used without binding it to any specific UTXO. With
the addition of OP_CAT, it would be possible to both programmatically
change the outputs (rather than just approving the fixed txn) and to
dynamically select the script.
*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.

There are obviously many other things you can do with delegation in
general, the above are specific to how coin delegation is done. I'm
probably missing some of the fun stuff -- please riff on this!

Best,

Jeremy

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

--00000000000054881805bd3768d5
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:#000000"><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)">I&#39;m
 aware that some folks (I think nullc, sipa, myself... maybe more?) are=20
aware of how to do script delegation in Bitcoin today (without any=20
modifications to Bitcoin), but realized in a conversation with Andrew P=20
that the technique is not widely known. So I figured it made sense to do
 a brief explainer of how this works for the archives / so the technique
 is documented. If someone has other citations for this, please respond=20
below.<br></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)">If you like cartoons follow along here:<br></div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)"><a href=3D"https://docs.google.com/presentation/d/1ikcthy3p-Ah59pJyss0T=
LEj-Q2FF6tv7BXhkORzErAE/edit#slide=3Did.p" target=3D"_blank">https://docs.g=
oogle.com/presentation/d/1ikcthy3p-Ah59pJyss0TLEj-Q2FF6tv7BXhkORzErAE/edit#=
slide=3Did.p</a></div><div><br></div><div><div style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_defaul=
t">Technically what we are doing is delegating a UTXO to a specific UTXO, a=
nd not to a script.<br></div><br></div><div><br></div><div><div style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" clas=
s=3D"gmail_default">Suppose
 you have a coin on UTXO A. You would like to delegate it to script S.=20
You can either scan the chain for any UTXOs bound to S or use some=20
arbitrary coin B to create a transaction X with an output D that has=20
script S (doesn&#39;t have to have any value, but let&#39;s say it has a no=
minal
 amount to avoid dust issues). Because tx X is not malleable, we don&#39;t=
=20
need to actually broadcast it and spend B till we want to use the=20
delegation, and it can be created (for the TXID) without B&#39;s owner bein=
g
 online. However you get the UTXO, and if it exists or not yet, let&#39;s=
=20
call it D.<br></div><div style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)" class=3D"gmail_default"><i>Note: if you&#39;re using a delegation script=
 multiple times, you can optimize the creation step a bit</i></div><div sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)" class=3D"gmail_default"><i><br></i></div><div style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_def=
ault">Now,
 using A, you sign a transaction with 2 inputs (one of them being D) and
 SIGHASH_NONE. This signs all of the inputs (but not their sequences!)=20
but none of the outputs. Let&#39;s call this transaction stub G.<br></div><=
div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_def=
ault">Now,
 using S, you sign D&#39;s input on G with SIGHASH_ALL and the outputs you=
=20
want to create (whatever they may be). Let&#39;s call the finished=20
transaction F.</div><div style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)" class=3D"gmail_default">Effectively,
 the holder of A has delegated the control of their coin to a specific=20
instance of the script S. Once delegated, S may authorize almost any=20
transaction they want (complicated if they want to sign a multiple input
 transaction; but there are good substitutes).</div><div style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gm=
ail_default"><br></div><div style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Advanced Topics:=
</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gm=
ail_default"><b>Revocation</b>:
 There are multiple ways to revoke, either moving A, moving D, refusing=20
to sign and create D (when D is derived from B), etc. Because these are=20
UTXO-bound they are revocable. (the cartoon may help here)</div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default"><b>Cross input delegation</b>: A set of N coins m=
ay create a sighash_none transaction with 1 additional input for the delega=
ting script</div><div style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b>Partial Spending Au=
thorizations</b>:
 Replacing sighash_none with sighash_single allows an input to specify a
 single change address (plug -- OP_CTV covenants can be thought of as a=20
way to get around sighash_single to allow sighash_single to cover=20
signing a set of outputs)</div><div style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b>Deleg=
ation after time</b>:
 Because the lock_time field is covered, delegations can be set up to=20
only be valid at some point in the future. Only a single sequence lock=20
per delegated coin may be used directly.<br></div><div style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmai=
l_default"><b>Multiple Delegates: </b>By
 signing a txn with several delegate outputs, it is possible to enforce=20
multiple disparate conditions. Normally this is superfluous -- why not=20
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=20
of the mechanisms investigated for <a href=3D"http://powswap.com" target=3D=
"_blank">powswap.com</a>).</div><div style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b>Sequ=
enced Contingent Delegation</b>:
 By constructing a specific TXID that may delegate the coins, you can=20
make a coin&#39;s delegation contingent on some other contract reaching a=
=20
specific state. For example, suppose I had a contract that had 100=20
different possible end states, all with fixed outpoints at the end. I=20
could delegate coins in different arrangements to be claimable only if=20
the contract reaches that state. Note that such a model requires some=20
level of coordination between the main and observing contract as each=20
Coin delegate can only be claimed one time.</div><div style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail=
_default"><b>CTV Specific P2SH Non Coin Delegation: </b>OP_CTV
 allows for a similar form of delegation where by a Segwit P2SH address,
 as a part of the CTV committed data, can be used without binding it to=20
any specific UTXO. With the addition of OP_CAT, it would be possible to=20
both programmatically change the outputs (rather than just approving the
 fixed txn) and to dynamically select the script.</div><div style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D=
"gmail_default"><b>Redelegating: </b>This
 is where A delegates to S, S delegates to S&#39;. This type of mechanism=
=20
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 (via presigned=20
transactions) until S&#39; actually wants to do something with the coin.<br=
></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"g=
mail_default">There
 are obviously many other things you can do with delegation in general,=20
the above are specific to how coin delegation is done. I&#39;m probably=20
missing some of the fun stuff -- please riff on this!<br></div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Bes=
t,</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"=
gmail_default">Jeremy</div></div></div><br clear=3D"all"><div><div dir=3D"l=
tr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=
=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank=
">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_bl=
ank"></a></div></div></div></div>

--00000000000054881805bd3768d5--