ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-05-08 📝 Original message:Good morning Luke, > Is ...
📅 Original date posted:2019-05-08
📝 Original message:Good morning Luke,
> Is there any way to use the Taproot construct here while retaining external
> script limitations that the involved party(ies) cannot agree to override?
> For example, it is conceivable that one might wish to have an unconditional
> CLTV enforced in all circumstances.
Perhaps this can be enforced offchain, by participants refusing to sign a transaction unless it has an `nLockTime` of the agreed-upon "unconditional CLTV".
Then the CLTV need only be on branches which have a strict subset of the participants as signers.
>
> It may be useful to have a way to add a salt to tap branches.
Would not adding `OP_PUSH(<salt>) OP_DROP` to the leaves work?
If you enforce always salting with a 32-byte salt, that "only" saves 3 bytes of witness data (for the `OP_PUSHDATA1+size` and `OP_DROP` opcodes).
Or do you refer to always salting every node?
(I am uncertain, but would not adding a salt to every leaf be sufficient?)
(in any case, if you use different pubkeys for each contract, rather than reusing keys, is that not enough randomization to prevent creating rainbow tables of scripts?)
>
> Some way to sign an additional script (not committed to by the witness
> program) seems like it could be a trivial addition.
It seems to me the annex can be used for this, by having it contain both the script and the signature somehow concatenated.
Regards,
ZmnSCPxj
📝 Original message:Good morning Luke,
> Is there any way to use the Taproot construct here while retaining external
> script limitations that the involved party(ies) cannot agree to override?
> For example, it is conceivable that one might wish to have an unconditional
> CLTV enforced in all circumstances.
Perhaps this can be enforced offchain, by participants refusing to sign a transaction unless it has an `nLockTime` of the agreed-upon "unconditional CLTV".
Then the CLTV need only be on branches which have a strict subset of the participants as signers.
>
> It may be useful to have a way to add a salt to tap branches.
Would not adding `OP_PUSH(<salt>) OP_DROP` to the leaves work?
If you enforce always salting with a 32-byte salt, that "only" saves 3 bytes of witness data (for the `OP_PUSHDATA1+size` and `OP_DROP` opcodes).
Or do you refer to always salting every node?
(I am uncertain, but would not adding a salt to every leaf be sufficient?)
(in any case, if you use different pubkeys for each contract, rather than reusing keys, is that not enough randomization to prevent creating rainbow tables of scripts?)
>
> Some way to sign an additional script (not committed to by the witness
> program) seems like it could be a trivial addition.
It seems to me the annex can be used for this, by having it contain both the script and the signature somehow concatenated.
Regards,
ZmnSCPxj