Good morning Jeremy, > Just a minor curiosity I figured was worth mentioning on the composition of > delegations and anyprevout... > > DA: Let full delegation be a script S such that I can sign script R and then > R may sign for a transaction T. > DB: Let partial delegation be a script S such that I can sign a tuple (script > R, transaction T) and R may sign T. > > A simple version of this could be done for scriptless multisigs where S signs > T and then onion encrypts to the signers of R and distributes the shares.
Just to be clear, do you mean, "for the case where R is a scriptless multisig"? And, "onion encrypts the signature"? Since part of the signature `(R, s)` would be a scalar modulo k, `s`, another way would be to SSS that scalar and distribute the shares to the R multisig signers, that may require less computation and would allow R to be k-of-n. > However, under such a model, if T is signed by S with AnyPrevOut, then T is > now arbitrarily rebindable. > > Therefore let us define more strictly: > > DC: Let half-delegation be a script S such that I can sign a tuple (script R, > transaction T) and R may sign T and revealing T/R does grant authorization to > any other party. Do you mean "does *not* grant"? If S is a delegator that intends to delegate to R, and creates a simple Taproot with keypath S, and signs a spend from that using `SIGHASH_ANYPREVOUT` and distributes shares of the signature to R, then once the signature is revealed onchain, anyone (not just R) may rebind the transaction to any other Taproot with keypath S, which I think is what you wish to prevent with the stricter definition "does *not* grant authorization to any other party"? > > The signer of R could choose to sign with APO, in which case they make the > txn rebindable. They could also reveal the private keys for R similarly. > For "correct" use, R should sign with SIGHASH_ALL, binding the transaction to > a single instance. Well, for the limited case where R is a k-of-n multisig (including n-of-n) it seems the "sign and SSS" would work similarly, for "correct" use R should sign with `SIGHASH_ALL` anyway, so in the "sign and SSS" method S should always sign with `SIGHASH_ALL`. This does not work if the script S itself is hosted in some construction that requires `SIGHASH_ANYPREVOUT` at the base layer, which I believe is what you are concerned about? In that case all signers should really give fresh pubkeys, i.e. no address reuse. > Observation: a tuple script R + transaction T can, in many cases, be > represented by script R || <H(transaction T)> CTV. > Corollary: half-delegation can be derived from full delegation and a covenant. > > Therefore delegation + CTV + APO may be sufficient for making chaperone > signatures work, if they are desired by a user. Hmm what? Is there some other use for chaperone signatures other than to artificially encumber `SIGHASH_ANYPREVOUT` or have definitions drifted over time? > Remarks: > > APO's design discussion should not revisit Chaperone signatures (hopefully > already a dead horse?) but instead consider how APO might compose with > Delegation proposals and CTV. no chaperones == good Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
