Re: [bitcoin-dev] Delegated signatures in Bitcoin within existing rules, no fork required

[Jeremy <jlrubin@mit.edu>]

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