path: root/7e/4bf4717a79bbc3939b3862d4e72a641673f8aa

Return-Path: <jlrubin@mit.edu>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E07AFC000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 17 Mar 2021 06:30:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id C0E384ED1A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 17 Mar 2021 06:30:39 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 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_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id kuaK4mYYEo0E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 17 Mar 2021 06:30:38 +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 smtp4.osuosl.org (Postfix) with ESMTPS id ABDA24EC69
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 17 Mar 2021 06:30:37 +0000 (UTC)
Received: from mail-io1-f47.google.com (mail-io1-f47.google.com
 [209.85.166.47]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12H6UZaP003133
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 17 Mar 2021 02:30:36 -0400
Received: by mail-io1-f47.google.com with SMTP id y20so21499174iot.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 16 Mar 2021 23:30:35 -0700 (PDT)
X-Gm-Message-State: AOAM532/VrvozDB32ejeNUhwOJMpPIprn/x/Q2gD1sc7m3mtOtz1jM8I
 JU6Enn40jF5uX3tH/7tGeir7DvplrtpaE50rWtk=
X-Google-Smtp-Source: ABdhPJxRrYDHDlidxU/xZ7V0ja7U/oMVzdHMcWGIRc3Fb3WX/14A1f5KRUSRIeGV07V2PzuEfqNHhDA+sEJ5CLgtEUY=
X-Received: by 2002:a02:cc1a:: with SMTP id n26mr1710496jap.21.1615962635224; 
 Tue, 16 Mar 2021 23:30:35 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhhC1Y13p7KazfUOXFZ5vi5MA9EQ-scyafv4aNkjskoXBg@mail.gmail.com>
 <plFEi9xoSnZ0TDJ7wH2dJx1F727FCSBrPsa2-26AXtveHKolt9bzTE1tiGIoPSjhgBfToVID2YHEaMGwwVU5dZ3Sozmz9UO-6HvbEDmm67I=@protonmail.com>
 <CAD5xwhhMjsYMRebN4Td614qOyAey24h7vQAjZjP_ETzvXJQBLw@mail.gmail.com>
 <_SJunY4b2FhUkCj49-C_D7Uj1VYlS8qqZuO2-NIAEAIkCIfWEWVVgx-pNN0ZXlujGKUiU_hfcV-aq9yK6LHjHoK_5E0pYncVWtW99regZnE=@protonmail.com>
In-Reply-To: <_SJunY4b2FhUkCj49-C_D7Uj1VYlS8qqZuO2-NIAEAIkCIfWEWVVgx-pNN0ZXlujGKUiU_hfcV-aq9yK6LHjHoK_5E0pYncVWtW99regZnE=@protonmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Tue, 16 Mar 2021 23:30:23 -0700
X-Gmail-Original-Message-ID: <CAD5xwhj73Uq6j_Wu2e6-4VA_-=50mwK4G-Mf24mC87CFvF-LnA@mail.gmail.com>
Message-ID: <CAD5xwhj73Uq6j_Wu2e6-4VA_-=50mwK4G-Mf24mC87CFvF-LnA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000d7cbff05bdb59ea3"
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: Wed, 17 Mar 2021 06:30:40 -0000

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

ZmnSCPxj,

The chief reason to use SIGHASH_NONE (or SIGHASH_SINGLE for partial funds
delegations) is to make it so that the delegator can dynamically choose
things like a change output. Otherwise you need to know exactly what you
want beforehand.

I'd note that you can also achieve a decent amount of scripting capability
for fully pre-signed transactions using layered encryption. E.g., given
script Checksig(Alice) and Checksig(Bob), you can delegate to
2 of CheckMulti(Carol, Dave, Eve) by (for example) encrypting either a
presigned txn or the actual sk's themselves with enc(Carol, enc(Dave, m)),
enc(Carol, enc(Eve, m)), enc(Dave, enc(Eve, m)). This allows you to
post-hoc delegate a presigned (or the keys -- which may or may not be safe
if they are from a HD wallet mind you). You can also do a variant of
timelock encryption by encrypting m using a verifiable delay function (this
actually permits a new kind of relative lock, depending on where you layer
the VDF enc, which would be N seconds from when the two parties agree to
decrypt). The general protocol can also be optimized by giving Carol
enc(Dave, m) and enc(Eve) but then you have to have a confidential channel
to each delegate. You can also do a ZKCP type thing if you prove that a txn
matching a specific format is encrypted with the preimage to a hash.
There's a lot you can do as improvement on simple "hand the key" -- this
sounds kinda similar to scriptless scripts?

W.r.t. privacy, it certainly is a hit. But I think in situations where
privacy is a goal, then the delegation can contact the original signer and
ask to cooperate. However in some circumstances that won't be viable given
access to keys or whatnot. I would suggest in these cases that you can do a
hybrid: delegate to a script and provide a default sighash_all txn, and a
modifiable sighash_none/single. Then the delegates can decide what is best
to use and optimistically get the originals to sign off.

Interestingly, there is a subset of cases where it is desirable to have
privacy *from the original script holder*. Conceivably the tx does need to
be public at some point, but for interest, once delegated to from S to S',
S' could show a signature covering a txn hash from S', and request that S
sign it. S' can reveal partial information -- e.g., which inputs are being
spent, but not which outputs are being created. Maybe not super useful, but
it is interesting to note of course.

Best,

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


On Tue, Mar 16, 2021 at 1:36 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Jeremy,
>
> Thank you.
>
> Assuming only keys, an easier way of delegating would be simply to give a
> copy of the privkey outright to the delegatee.
>
> However, an advantage of this technique you described is that the
> delegator can impose additional restrictions that are programmable via any
> SCRIPT, an ability that merely handing over the privkey cannot do.
> Thus the technique has an ability that mere handover cannot achieve.
>
> If the delegatee is a known single entity, and S is simply the delegatee
> key plus some additional restrictions, it may be possible to sign with
> `SIGHASH_ALL` a transaction that spends A and D, and outputs to a singlesig
> of the delegatee key.
> This would avoid the use of `SIGHASH_NONE`, for a mild improvement in
> privacy.
> The output would still allow the delegatee to dispose of the funds by its
> unilateral decision subject to the fulfillment of the script S (at the cost
> of yet another transaction).
> On the other hand, if S is unusual enough, the enhanced privacy may be
> moot (the S already marks the transaction as unusual), so this variation
> has little value.
>
> In terms of offchain technology, if the delegator remains online, the
> delegatee may present a witness satisfying S to the delegator, and ask the
> delegator to provide an alternate transaction that spends A directly
> without spending D and outputs to whatever the delegatee wants.
> The delegator cannot refuse since the delegatee can always use the
> `SIGHASH_NONE` signature and spend to whatever it decides provided it can
> present a witness satisfying S.
> This is basically a typical "close transaction" for layer 2 technology.
> On the other hand, one generalized use-case for delegation would be if the
> delegator suspects it may not be online or able to sign with the delegator
> key, so this variation has reduced value as well.
>
> Regards,
> ZmnSCPxj
>

--000000000000d7cbff05bdb59ea3
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">ZmnSCPxj=
,</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#=
000000">The chief reason to use SIGHASH_NONE (or SIGHASH_SINGLE for partial=
 funds delegations) is to make it so that the delegator can dynamically cho=
ose things like a change output. Otherwise you need to know exactly what yo=
u want beforehand.<br></div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:#000000">I&#39;d note that you can also achieve a decen=
t amount of scripting capability for fully pre-signed transactions using la=
yered encryption. E.g., given script Checksig(Alice) and Checksig(Bob), you=
 can delegate to <br></div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:#000000">2 of CheckMulti=
(Carol, Dave, Eve) by (for example) encrypting either a presigned txn or th=
e actual sk&#39;s themselves with enc(Carol, enc(Dave, m)), enc(Carol, enc(=
Eve, m)), enc(Dave, enc(Eve, m)). This allows you to post-hoc delegate a pr=
esigned (or the keys -- which may or may not be safe if they are from a HD =
wallet mind you). You can also do a variant of timelock encryption by encry=
pting m using a verifiable delay function (this actually permits a new kind=
 of relative lock, depending on where you layer the VDF enc, which would be=
 N seconds from when the two parties agree to decrypt). The general protoco=
l can also be optimized by giving Carol enc(Dave, m) and enc(Eve) but then =
you have to have a confidential channel to each delegate. You can also do a=
 ZKCP type thing if you prove that a txn matching a specific format is encr=
ypted with the preimage to a hash. There&#39;s a lot you can do as improvem=
ent on simple &quot;hand the key&quot; -- this sounds kinda similar to scri=
ptless scripts?<br></div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000">W.r.t. privacy, it certainly is a hit. But I thin=
k in situations where privacy is a goal, then the delegation can contact th=
e original signer and ask to cooperate. However in some circumstances that =
won&#39;t be viable given access to keys or whatnot. I would suggest in the=
se cases that you can do a hybrid: delegate to a script and provide a defau=
lt sighash_all txn, and a modifiable sighash_none/single. Then the delegate=
s can decide what is best to use and optimistically get the originals to si=
gn off.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:#000000">Interestingly, there is a subset of cases where it is desirab=
le to have privacy *from the original script holder*. Conceivably the tx do=
es need to be public at some point, but for interest, once delegated to fro=
m S to S&#39;, S&#39; could show a signature covering a txn hash from S&#39=
;, and request that S sign it. S&#39; can reveal partial information -- e.g=
., which inputs are being spent, but not which outputs are being created. M=
aybe not super useful, but it is interesting to note of course.<br></div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">B=
est,</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:#000000">Jeremy<br clear=3D"all"></div><div><div dir=3D"ltr" class=3D"gma=
il_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"_blank"></a></div></d=
iv></div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Tue, Mar 16, 2021 at 1:36 AM ZmnSCPxj &lt;<a href=3D"mailto=
:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">Good morning Jeremy,<br>
<br>
Thank you.<br>
<br>
Assuming only keys, an easier way of delegating would be simply to give a c=
opy of the privkey outright to the delegatee.<br>
<br>
However, an advantage of this technique you described is that the delegator=
 can impose additional restrictions that are programmable via any SCRIPT, a=
n ability that merely handing over the privkey cannot do.<br>
Thus the technique has an ability that mere handover cannot achieve.<br>
<br>
If the delegatee is a known single entity, and S is simply the delegatee ke=
y plus some additional restrictions, it may be possible to sign with `SIGHA=
SH_ALL` a transaction that spends A and D, and outputs to a singlesig of th=
e delegatee key.<br>
This would avoid the use of `SIGHASH_NONE`, for a mild improvement in priva=
cy.<br>
The output would still allow the delegatee to dispose of the funds by its u=
nilateral decision subject to the fulfillment of the script S (at the cost =
of yet another transaction).<br>
On the other hand, if S is unusual enough, the enhanced privacy may be moot=
 (the S already marks the transaction as unusual), so this variation has li=
ttle value.<br>
<br>
In terms of offchain technology, if the delegator remains online, the deleg=
atee may present a witness satisfying S to the delegator, and ask the deleg=
ator to provide an alternate transaction that spends A directly without spe=
nding D and outputs to whatever the delegatee wants.<br>
The delegator cannot refuse since the delegatee can always use the `SIGHASH=
_NONE` signature and spend to whatever it decides provided it can present a=
 witness satisfying S.<br>
This is basically a typical &quot;close transaction&quot; for layer 2 techn=
ology.<br>
On the other hand, one generalized use-case for delegation would be if the =
delegator suspects it may not be online or able to sign with the delegator =
key, so this variation has reduced value as well.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div></div>

--000000000000d7cbff05bdb59ea3--