Hi zmnscpxj,
>
>> 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"?
No. Let's suppose that R = 2 of 3 {a,b,c}.
S signs T. S distributes enc(a, enc(b, T)), enc(a, enc(c, T)), and enc(b,
enc(c, T)) and then R can 'sign' by decrypt and broadcast (of course you
have
an FLP issue here, but let's ignore that for now).
This is a "scriptless multisig with onion encryption" in this context.
Note: you don't have to encrypt T, just the witness to T technically.
>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.
Yep that works too! There are a lot of different things S can do here, was
just giving the simplest "it works" version v.s. focusing on efficiency.
>> 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"?
Yes absolutely, that was a typo.
>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"?
Correct.
>>
>> 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`.
Correct.
>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.
I don't think so? Not sure what you mean here.
>> 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?
I don't know; but they are interesting. Of course you can just always write
a script like `<1||pk> checksig <chap_pk> checksig`, but where this is
unique is that you can accomplish post-hoc chaperoning which lets you
dynamically pick/rotate keys, for example.
>> 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
:)
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
