SATS20Docs · 07 / 8
Security model
Why the signatures prove the sender and the program.
What the signatures prove
Every input of an action is signed by a key through a leaf that contains the program's cmr, and the signature commits to every output. Bitcoin consensus alone therefore proves who sent the action, which program it targets, and that it was not altered. The indexer adds no trust for authorship.
How each rule closes a forgery path
| Rule | What it prevents |
|---|---|
| Exact 68-byte leaf | No extra opcodes and no OP_IF branch that could skip the signature check. |
| 32-byte key | Other key sizes make OP_CHECKSIG succeed without verifying (BIP342). |
| 64-byte or SIGHASH_ALL signature | Other sighash types would not commit to the outputs. |
| Single-leaf control block whose internal key equals the signer | Input 0 is that key's canonical account, so a sender cannot spend someone else's account. |
| Every input is a program-account spend | No plain inputs can be mixed in, so every input is signed by a known key for this program. |
cmr in the leaf | A signature for one program cannot be replayed against another. |
| Program code is added by the indexer, after the action JSON | Nothing in an action can replace the program code or deployer. |
| Output 1 must be the sender's account | The sender's funds can't be redirected. |