A seemingly microscopic change to Bitcoin signatures could unlock a simpler Lightning Network, more powerful second layers, and a new generation of contracts. The fight over BIP-118 and BIP-448 is really a fight over how much of Bitcoin’s past a transaction should be forced to remember.
Bitcoin has a memory problem.
Not the kind you might expect.
The blockchain remembers too much by design. Every confirmed transaction is recorded in a history that anyone can independently verify. That persistence is one of Bitcoin’s greatest strengths.
But deep inside the cryptography of an individual Bitcoin transaction, there is another kind of memory.
When you sign a transaction today, your signature usually remembers exactly which coin you are spending.
It remembers its past.
That sounds obviously desirable.
If I authorize the movement of this bitcoin, why would I ever want the same signature to authorize the movement of a different bitcoin?
For ordinary payments, you probably wouldn’t.
But for Lightning channels and other sophisticated protocols built on top of Bitcoin, this very property can become a burden.
Sometimes you want to prepare a transaction in advance without knowing exactly which previous transaction it will ultimately spend.
Sometimes you want the same cryptographic authorization to remain useful even when the history immediately beneath it changes.
Sometimes the past is not what matters.
The future is.
This is the strange idea behind one of the most consequential—and least understood—Bitcoin upgrade debates happening right now.
The names involved are painfully unmarketable:
**BIP-118.****SIGHASH_ANYPREVOUT.****BIP-448.****OP_TEMPLATEHASH.****OP_CHECKSIGFROMSTACK.**OP_INTERNALKEY.
You could hardly invent a better collection of words for ensuring that 99.9% of Bitcoin holders stop reading.
That would be a mistake.
Because beneath those names lies a simple question that could shape the next generation of Bitcoin:
Should a Bitcoin signature always be chained to the exact transaction that came before it?
For almost all Bitcoin users today, the answer is yes. Some developers increasingly believe the answer should occasionally be no.
And what happens next could determine whether Lightning remains dependent on its current penalty architecture—or evolves into something much cleaner.
Most people imagine a digital signature as a cryptographic version of signing a check.
You own a private key. You create a transaction. You sign it. The network verifies that you authorized the payment. Simple.
But the thing being signed is crucial.
Bitcoin signatures do not normally say merely:
“I authorize Alice to receive 0.1 BTC.”
The signature commits to a carefully constructed digest of transaction information.
Depending on the signature-hash mode, that can bind the authorization to transaction outputs, inputs, scripts, amounts and—critically—the previous output being spent.
That previous output is identified by an outpoint: essentially the transaction ID of the previous transaction plus the index of the particular output inside it.
This gives a transaction a very strong sense of ancestry.
A signature is not just saying:
Spend a coin under these conditions.
It is saying:
Spend this particular coin, created at this precise location in Bitcoin history.
For normal Bitcoin payments, that is exactly what you want. You do not want a signature intended for one UTXO being copied onto another.
But second-layer protocols operate in a stranger world. They frequently create transactions that may never be broadcast. Those transactions represent possible future states.
And the exact transaction that eventually appears on-chain may depend on what happened earlier.
This is where Bitcoin’s insistence on remembering the exact previous output can become expensive.
BIP-118 exists to loosen that requirement in carefully opt-in circumstances. Its core idea is that a signature can deliberately avoid committing to the exact UTXO being spent, making it possible to rebind that signed transaction to another compatible previous output.
That sounds terrifying.
It is also potentially extremely useful.
Imagine you write a letter saying:
If Door A opens, execute Plan X.
But there are ten possible versions of Door A.
Under Bitcoin’s ordinary signature model, you might need to prepare ten different signed versions of Plan X—one for each possible door.
Change the door, and the signature no longer matches.
ANYPREVOUT asks:
What if Plan X could say:
If
any compatible Door Aopens, execute Plan X.
The plan stays the same. The history immediately behind it may change. The authorization survives.
That is the essence of rebindable signatures.
**BIP-118 creates new Tapscript public-key behavior and new signature-hash modes called **SIGHASH_ANYPREVOUT
** and **SIGHASH_ANYPREVOUTANYSCRIPT
. Instead of always committing to the exact previous outpoint, these signatures intentionally omit some of that ancestry.
This is not enabled for everyone by default.
It is opt-in.
A wallet does not suddenly begin creating reusable signatures for ordinary bitcoin payments.
A protocol deliberately constructs outputs capable of using the new signature behavior.
That distinction matters because weakening what a signature commits to introduces very real dangers.
BIP-118 explicitly warns about signature replay and transaction malleability. When the same signature is valid across multiple compatible UTXOs, implementers must ensure that replay cannot cause unwanted loss.
Bitcoin is not casually forgetting history.
Developers are asking whether some advanced contracts should be allowed to forget a very specific part of it.
The most famous motivation is Lightning.
Today’s Lightning Network is built around a concept that sounds surprisingly brutal:
If you publish an old channel state, you may lose everything.
Lightning channel participants continually update their shared state as payments move back and forth. Older states must become unsafe to broadcast. The current Lightning architecture achieves this using revocation secrets and penalty transactions.
If Alice publishes an obsolete state that gives her more bitcoin than she is currently entitled to, Bob can use previously revealed information to punish her and potentially claim the channel funds.
It works.
But the architecture is complicated.
Participants need to carefully preserve state.
Backups are dangerous.
Restoring an old Lightning state can create catastrophic problems.
Watchtowers exist partly because users must detect outdated channel states being broadcast.
There has long been another idea.
Instead of punishing the publication of an old state, why not simply allow the newer state to override it?
This concept was originally known as eltoo and is now generally discussed as LN-Symmetry.
The philosophical difference is beautiful.
Current Lightning says:
Publish the past and you may be punished.
LN-Symmetry says:
Publish the past and the future replaces it.
That sounds much closer to how we normally expect versioned systems to behave.
Version 7 beats version 6.
No nuclear penalty required.
BIP-118 was designed in large part to make this kind of dynamic replacement possible. Its rebindable signatures allow later transactions to attach themselves to prior compatible states without requiring a separate signature for every possible ancestry.
This is why a tiny change in what a signature remembers can completely alter Lightning architecture.
Forget one part of the past.
Simplify the future.
Why rational CEOs are mathematically forced to destroy their own consumer base—and the only policy that can stop the collapse.
This year, the discussion became more interesting.
BIP-448, assigned in March 2026, proposes a package of three Tapscript operations:
BIP-446:OP_TEMPLATEHASH
BIP-348:OP_CHECKSIGFROMSTACK
BIP-349:OP_INTERNALKEY
The proposal is currently a draft soft fork, not an activated Bitcoin feature, and its activation mechanism remains to be determined.
Its goal overlaps significantly with BIP-118. But the philosophy is different.
