At a excessive stage, a person would lock funds right into a CAT covenant that commits to a selected r-value.
This implies the spending transaction for this utxo should use that individual r-value when sending funds. If the person sends funds and tries to RBF, they’ll inevitably find yourself utilizing a brand new s-value, leading to nonce-reuse and permitting for his or her funds to be slashed by anybody watching the mempool.
Particularly, this entails the next scripts (as outlined by bt canary of their unique spec https://gitlab.com/-/snippets/3735654)
Locking Script:
// Confirm r and compose signature
OP_OVER
OP_HASH160
<$(<r> OP_HASH160)>
OP_EQUALVERIFY
OP_CAT
OP_SWAP
// Stack: <signature>, <pubKey>
// Customary P2PKH script
OP_DUP
OP_HASH160
<$(<pubKey> OP_HASH160)>
OP_EQUALVERIFY
OP_CHECKSIG
Unlocking script
<pubKey>
<r>
<$(<s><0x41> OP_CAT)>
As we will see, the locking script commits to the r-value, which the unlocking script should present together with the s-value for use.
CAT is critical to concatenate the r and s values collectively on the stack, to be verified by CHECKSIG on the finish of the script.
Non-public key restoration is specified on the unique spec as effectively: https://gitlab.com/-/snippets/3735654
(Or a extra complete rationalization of how slashing is achieved for these which are new to schnorr signatures may be seen right here: https://internet.archive.org/internet/20231003173156/https://suredbits.com/introduction-to-schnorr-signatures/ )