Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id E07AFC000A for ; 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 ; 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 ; 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 ; 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 ; Wed, 17 Mar 2021 02:30:36 -0400 Received: by mail-io1-f47.google.com with SMTP id y20so21499174iot.4 for ; 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: <_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 Date: Tue, 16 Mar 2021 23:30:23 -0700 X-Gmail-Original-Message-ID: Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="000000000000d7cbff05bdb59ea3" 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: 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 On Tue, Mar 16, 2021 at 1:36 AM ZmnSCPxj 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
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 cho= ose things like a change output. Otherwise you need to know exactly what yo= u want beforehand.

I'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
2 of CheckMulti= (Carol, Dave, Eve) by (for example) encrypting either a presigned txn or th= e 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 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's a lot you can do as improvem= ent on simple "hand the key" -- this sounds kinda similar to scri= ptless scripts?

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

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', 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. M= aybe not super useful, but it is interesting to note of course.

B= est,

Jeremy

On Tue, Mar 16, 2021 at 1:36 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
<= 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,

Thank you.

Assuming only keys, an easier way of delegating would be simply to give a c= opy 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, a= n 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 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.
This would avoid the use of `SIGHASH_NONE`, for a mild improvement in priva= cy.
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).
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.

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.
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 techn= ology.
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--