From: Jeremy <jlrubin@mit•edu>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Delegated signatures in Bitcoin within existing rules, no fork required
Date: Tue, 16 Mar 2021 23:30:23 -0700 [thread overview]
Message-ID: <CAD5xwhj73Uq6j_Wu2e6-4VA_-=50mwK4G-Mf24mC87CFvF-LnA@mail.gmail.com> (raw)
In-Reply-To: <_SJunY4b2FhUkCj49-C_D7Uj1VYlS8qqZuO2-NIAEAIkCIfWEWVVgx-pNN0ZXlujGKUiU_hfcV-aq9yK6LHjHoK_5E0pYncVWtW99regZnE=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 4523 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 6665 bytes --]
next prev parent reply other threads:[~2021-03-17 6:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-10 23:55 Jeremy
2021-03-16 6:09 ` ZmnSCPxj
2021-03-16 6:16 ` Jeremy
2021-03-16 8:36 ` ZmnSCPxj
2021-03-17 6:30 ` Jeremy [this message]
2021-03-24 13:33 ` Guido Dassori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAD5xwhj73Uq6j_Wu2e6-4VA_-=50mwK4G-Mf24mC87CFvF-LnA@mail.gmail.com' \
--to=jlrubin@mit$(echo .)edu \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox