Author: Jeremy Rubin
In this blog series, I will document some interesting uses of CSFS that I have noticed.
The goal is to record things that others may not yet know.
Did I invent them? Maybe, maybe not. Pointing out the work of those who came before is welcome!
Non-replaceable and non-reusable addresses
Create a Taproot output and use the "NUMS dot" as the internal public key (using the NUMS key path and setting only one script leaf (tapleaf), meaning you always know all the cost options), and use a script leaf (tapleaf) that either satisfies <PK> CHECKSIG (check signature) script or provides evidence that this public key has generated more than one signature for any two different pieces of data; then, choose one of the two:
- Using CTV, it can be sent to OP_RETUREN;
- Without using CTV, it becomes something anyone can spend.
This means that once you observe the signature of a transaction originating from this address, you know that the sender will not send another signature unless they are willing to have their funds burned.
More fun:
This kind of "ambiguous insurance" can also be used in different outputs and different addresses to protect addresses with new collateral, and can even be retroactive .
Function lookup table pre-compilation
Suppose we want to add an opcode to Bitcoin that can evaluate f(x) .
设x = musig(巨大的联盟，带有一次性的启动仪式)设CSFS(key, sig, data) = ...Please recall the key chaining technique ( Chinese translation )... Use key chaining to create a script with the following logic:
CSFS(X, sig_x, sig_arg)CSFS(Tweaked(X, arg), sig_arg, arg)CSFS(Tweaked(X, arg), sig_f, f(arg)))sig_f != sig_arg Now, (within the signer committee) run f(arg) on all values of arg .
This gives you a lookup table that can be used in any size tree structure in any script, with a constant overhead: 3 signatures and 2 public keys, or 256 bytes, which is cheaper in many cases than using a pre-generated tree structure with taproot.
This technique can also be modified to work with multiple parameters, as long as the result can be pre-calculated. This excludes functions with "large output space" such as OP_CAT , but the lookup table can be rule-based, such as a Merkle tree.
As for its application, the above techniques are equivalent in terms of trust when (for example) a Merkle tree must be signed with a key anyway. For instance, a tree storing user balances can be constructed such that any user can "look up" their balance from the set of signatures.
For typical use of the "standard library", large consortia can be used for one-time trusted setup.
SIGHASH Tag Detection
Currently, Bitcoin scripts cannot restrict which sighash tag a public key uses. CSFS, however, can provide a limited version in the Taproot output. Here's how:
Using CSFS, you can obtain a summary of a transaction from a signature and store it on a stack.
Without OP_CAT, its usage is limited...
However, we have the following formula:
What is the output length of SigMsg() ? The total length of SigMsg() can be calculated using this formula: 174 - is_anyonecanpay * 49 - is_none * 32 + has_annex * 32
(Translator's note: Here, is_anyonecanpay , is_none , has_annex are all boolean values, indicating whether these sighash tags were used in the signature.)
That is, a maximum of 206 bytes (when has_annex is set).
Note: This number should eventually include 1 byte of sighash epoch and 64 bytes of taggedhash value.
This means that, using CSFS, you can constrain a signature to use a specific sighash label by using OP_SIZE.
- is_anyonecanpay=0, is_none=0, has_annex=0, size is 174+65
- is_anyonecanpay=0, is_none=0, has_annex=1, size is 206+65
- is_anyonecanpay=0, is_none=1, has_annex=0, size is 142+65
- is_anyonecanpay=0, is_none=1, has_annex=1, size is 174+65
- is_anyonecanpay=1, is_none=0, has_annex=0, size is 125+65
- is_anyonecanpay=1, is_none=0, has_annex=1, size is 157+65
- is_anyonecanpay=1, is_none=1, has_annex=0, size is 93+65
- is_anyonecanpay=1, is_none=1, has_annex=1, size is 125+65
In other words, you can use CSFS to distinguish between the tag combinations of anyonecanpay and none and annex , except for cases where both is_none and has_annex are set or not set (because the size is the same, so they cannot be distinguished).
Well, to put it another way, you might only be able to think about the following combinations:
- is_anyonecanpay=0, is_none=1, has_annex=0, size is 142+65
- is_anyonecanpay=1, is_none=1, has_annex=0, size is 93+65
As for the following combinations, they are less interesting, but still worth considering, because Annex is not a standard trading platform:
- is_anyonecanpay=0, is_none=0, has_annex=1, size is 206+65
- is_anyonecanpay=1, is_none=0, has_annex=1, size is 157+65
Note: Given these combinations, you can still set other tags!
