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 [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
