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

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev