Paperclip Write the plan
Choose the destination, amount and timing conditions. Bitcoin calculates a short digital fingerprint of those transaction details.
TEMPLATEHASH makes the fingerprint. It does not enforce the plan on its own.BITCOIN / REBINDABLE TRANSACTIONS / RDTS
More room for payments.
Less need to coordinate.
Small changes to Bitcoin Script could make shared funds and payment channels easier to build. This experiment keeps transaction authorization focused on how coins can move.
OFF-CHAIN PAYMENTS
₿
Bitcoin settlementEnforceable spending conditions
Many payments. A verifiable path back on-chain.
Experimental, not a mainnet upgrade. This is an independent, unnumbered draft—not an assigned or endorsed BIP. Signet uses test coins. The diagrams explain possibilities, not production guarantees.
START HERE / NO SCRIPT KNOWLEDGE NEEDED
A spending plan Bitcoin can check.
Normally, your signature authorizes a transaction. This experiment lets you authorize a constrained future spend before the exact coin that funds it is known. Think of a signed payment plan—not a blank cheque.
Approve the plan
Your signature can authorize that fingerprint. Change a covered detail, such as the amount paid, and the old signature no longer works.
Our CSFS checks only the current transaction template. Other messages are rejected.Use it later
A carefully designed protocol can reuse that authorization with different funding coins, without asking you to sign again.
Funding, fees, expiry and recovery still need their own safeguards.Why would I care?
A wallet could prepare a permitted Ark refresh while you are online, then let a service carry it out while you are away. The service should only be able to follow the authorized plan.
See what we tested →Translate the jargon
- Covenant
- A rule that restricts how a coin can be spent in a later transaction.
- Template hash
- A 32-byte fingerprint of selected transaction details. It is a commitment, not encrypted transaction data.
- Rebinding
- Using the same authorization with a different funding outpoint, while the covered details remain the same.
- Outpoint
- The reference to a particular output of a previous transaction—the coin being spent.
- VTXO / Ark refresh
- An Ark virtual output represents a claim backed by on-chain funds. Refreshing replaces it with a new claim before its expiry.
- RDTS
- Reduced Data Temporary Softfork: the existing data-efficient Script environment this experiment builds on.
01 / THREE BUILDING BLOCKS
Describe the spend. Authorize it. Reuse the key.
A covenant constrains a future spend. These operations provide building blocks; the surrounding protocol still has to protect the user.
TEMPLATEHASH
“This transaction shape.”
Produces a 32-byte commitment to outputs, sequences, locktime, version and the current input index. It leaves out input outpoints, amounts and spent-output scripts.
Defines permitted spendingCHECKSIGFROMSTACK
“I authorize this template.”
In this draft, the message must equal that exact template hash. A different message fails—even if someone supplies a valid signature for it.
Narrowed from BIP348INTERNALKEY
“Use the key already here.”
Reads the Taproot internal public key from the validated control block. Scripts can avoid repeating it. It never reveals a private key.
Avoids duplicate key data02 / WHY REBINDING MATTERS
Authorize the destination before the funding is final.
A template can stay the same when its funding outpoint changes. Try changing the transaction below.
Try it: changing the payment breaks the authorization. Changing only the funding reference keeps the same fingerprint.
FUNDING INPUTOutpoint AWhere the coins come from
COMMITTED OUTPUT100,000 sats to AliceWhere the coins may go
TEMPLATE HASHCommitment AExactly 32 bytes
The authorized template matches. The transaction still needs all other required checks.
Conceptual illustration, not a transaction builder. Template matching alone does not prove funding sufficiency, ownership, fees or replay safety. Rebinding requires careful protocol design.
03 / WHAT CHANGES FROM BIP448?
The same toolbox, with a narrower signature message.
BIP448 proposes three modular operations. This draft adapts them to RDTS and restricts CSFS to transaction templates.
In plain English
Upstream BIP348/BIP448 lets the caller choose the message being signed; it does not require a transaction template. Our version accepts only the fingerprint of this transaction’s template. A short message is not enough—it must be the right one.
UPSTREAM BIP348 / BIP448
General signature verification
Arbitrary message→Signature check
General-purpose authorization, including delegation and oracle attestations. Message size remains subject to the applicable Script limits.
SPAM-LIMITING PROPOSAL
The current input’s template
32-byte TEMPLATEHASH→Signature check
Exactly 32 bytes, at consensus. An unrelated 32-byte hash also fails. The 64-byte Schnorr signature is separate from this message limit.
Technical comparison: exact rules
| Property | Upstream BIP448 | Spam-limiting proposal |
|---|---|---|
| CSFS message | Arbitrary message; not limited to transaction templates | Current input’s template hash only |
| Message-size control | Applicable Script limits | Exactly 32 bytes; no size-policy opt-out |
| Cryptography | BIP446 tagged SHA256 + BIP340 | Same template hash and signature algorithm |
| Script environment | Ordinary Tapscript rules | RDTS: 256-byte elements, seven branch hashes, no annex or IF/NOTIF |
| Upgrade context | Proposed soft fork under ordinary Tapscript | Adding opcodes relaxes existing RDTS rules; template-only CSFS then tightens the earlier experiment |
| Deployment | Draft; activation unspecified | Experimental signet; template-only block rule from height 3250. Production activation unspecified. |
The cap is per CSFS message, not per transaction. Our tested two-input Ark refund uses two separate 32-byte messages.
04 / BITCOIN AS MONEY
Less coordination could mean more usable payments.
The benefit comes from better payment protocols—not from adding general-purpose on-chain applications.
ARKExperimental path tested
Prepare a refresh.
Let it happen while you’re offline.
Today, signing and coordination requirements can make refreshing virtual outputs an interactive task. Rebindable authorizations can permit specific future replacement transactions before their funding outpoints exist.
1PreauthorizeWallet online
→2RefreshWallet offline
→3Timed exitIndependent recovery
1 / The wallet prepares and signs the permitted future refresh while the user is online.
Earlier private tests: two offline refreshes of one experimental balance, watchman recovery, crash/reorg handling, and a unilateral exit with the services stopped.
Not a complete production Ark implementation. Safe offline duration is bounded; expiry, fee funding, recovery data and monitoring still matter.
LIGHTNINGFuture protocol work
Make channel updates
easier to reason about.
Rebindable signatures are a building block for LN-Symmetry, where newer channel states can replace older ones during a dispute period. This could simplify channel recovery and help make multi-party channels practical.
EARLIER STATEState 01
NEWER AUTHORIZATIONState 02
Potential monetary benefit: simpler shared payment infrastructure, with fewer coordination burdens and a path to enforce balances on-chain.
These opcodes do not upgrade existing channels automatically. Compatibility with RDTS, fees, dispute timing and the full channel protocol still need implementation and testing.
Coordinate lessAuthorize constrained future spends
Settle efficientlyPotentially reduce pre-signing overhead
Keep an exitDesign recovery into the protocol
LIVE SIGNET / OCTOBER 8, 2026
Tested with real transactions. Test coins only.
Confirmed recovery paths under the active template-only CSFS rule.
ARK · RECOVERY CONFIRMED
Refresh offline. Recover independently.
One offline refresh, watchman recovery and a confirmed 98,000-sat exit with both services stopped. A delayed second refresh was not funded near expiry.
THREE-PARTY EXPERIMENT · PASSED
Replace an old state. Settle the latest.
Three participants, two signed updates and a confirmed exit after the 12-block contest period. Early settlement was rejected.
Small experimental protocols, not production Ark or a BOLT Lightning implementation. These results support further evaluation; they do not prove activation readiness or eliminate every data-storage path.
05 / LIMITS ARE PART OF THE DESIGN
Focused capability. Explicit tradeoffs.
Not a blanket anti-spam guarantee
Our CSFS accepts only the current transaction template hash; unrelated messages are rejected. Other scripts, keys and outputs can still carry data. A meaningful payment cannot be identified just by looking at its hash.
Less general-purpose flexibility
Oracle and delegation constructions that need other CSFS messages will not work unchanged. Existing outputs relying on CSFS signatures over other messages may become unspendable after activation.
Recovery still needs engineering
No opcode guarantees confirmation, sufficient liquidity or indefinite offline safety. Applications must handle fees, deadlines, pinning, backup delivery and replay domains.
Sources & technical detail
Draft specification ↗BIP448: rebindable transactions ↗BIP348: CSFS ↗BIP446: TEMPLATEHASH ↗Implementation & test evidence ↗
Builds on work by Gregory Sanders, Antoine Poinsot, Steven Roose, Brandon Black and Jeremy Rubin. This adaptation is independent; no author or Bitcoin Knots endorsement is implied.