Should Bitcoin SV Remove SIGHASH_FORKID? Exploring the Deba…
Should Bitcoin SV Remove SIGHASH_FORKID? Exploring the Debate
There’s ongoing discussion about removing SIGHASH_FORKID (0x40), a flag added to transaction signatures to differentiate BSV from Bitcoin (BTC) and prevent replay attacks. Some in the BSV community want to eliminate it to align with Satoshi Nakamoto’s original Bitcoin protocol, but the change hasn’t happened due to significant risks. Here’s a breakdown of the debate, based on recent conversations on X.
Why Remove SIGHASH_FORKID?
SIGHASH_FORKID was introduced in Bitcoin Cash (BCH) and inherited by BSV to ensure transactions aren’t accidentally replayed on BTC or BCH after their forks. Advocates for removing it argue it’s a deviation from Bitcoin’s original design, which didn’t require fork-specific identifiers. Restoring the pre-fork signature algorithm (pre-BIP 143, no FORKID) would align BSV with Satoshi’s vision of a pure, unmodified protocol.
Proposed Alternatives:
-Move Your BSV Funds: One suggestion is for BSV holders to spend a small amount (e.g., a satoshi) to update their unspent transaction outputs (UTXOs). This changes the transaction ID (TXID) in BSV, preventing BTC SegWit transactions from being replayed. It’s simple but requires users to act proactively.
-Redistribute Vulnerable UTXOs: Another idea is to identify UTXOs in BSV that could become “anyone-can-spend” if SIGHASH_FORKID is removed (e.g., those tied to SegWit transactions in BTC). “Honest miners” could redistribute these BSV to their original addresses before the change. This is controversial, as it involves centralized intervention, which many see as against Bitcoin’s principles.
-Keep SIGHASH_FORKID: Some argue to maintain the status quo, as removing FORKID risks exposing BSV to replay attacks, where BTC transactions (especially SegWit ones) could be replicated on BSV, potentially allowing anyone to spend certain UTXOs due to BSV’s rejection of SegWit and P2SH.
Why It Hasn’t Been Done
The primary reason for not removing SIGHASH_FORKID is the risk highlighted by Bitcoin Core developer Greg Maxwell. Without FORKID, SegWit transactions from BTC could be replayed on BSV, turning some UTXOs into “anyone-can-spend” because BSV doesn’t recognize SegWit scripts. This could lead to funds being stolen, especially for users who sent BTC to SegWit addresses after the BSV fork (2018). Due to these concerns, BSV abandoned plans to remove FORKID in the proposed “Chronicle upgrade.” Critics of the change also note that users who lose private keys could be stuck with unspendable BSV if the signature algorithm reverts, complicating the issue further.
What Do You Think?
The debate balances BSV’s goal of restoring Bitcoin’s original protocol with the practical need to protect users from replay risks. Should BSV remove SIGHASH_FORKID and accept the risks? Should users be responsible for moving their funds? Or is miner intervention a viable fix? Share your thoughts below!
Replies
The Chronicle release is due to remove SIGHASH_FORKID, and that is going to be released when Teranode goes public I think
They changed their minds. Now they want to add a new sighash (Relax) instead of removing sighash_forkid.
Probably because of Greg Maxwell's comments about how this will cause many BSV UTXOs to become "anyonecanspend." Although they aren't actually anyonecanspend technically, it's known that p2sh in Bitcoin are unlocked with the original hash message that appears in the lock. But in BTC, you don't just need the message, but also a signature on the SegWit network which BSV doesn't adhere to. Ultimately, you can locate UTXOs in BTC that have made the hash messages public, and with that, you can unlock them in BSV if they are in the same txid.
I think there's a fear in BSV that something like this would legitimize exchanges to sell all their BSV, and that the networks would be flooded with "I've been robbed in BSV" messages.
imo i dont see a compelling reason to remove it, it doesnt change the protocol meaningfully, and protects from this specific attack
On the other hand, some believe Satoshi doesn't have the keys to the initial coins, but there is speculation that he could have one or more TXs signed with the old algo.
It is also said that those who changed BTC and should be explaining themselves are the BTC devs.
Somehow, some believe that stealing from segwiters who don't know anything about it, and who haven't moved their BSV in all this time, isn't such a bad idea.
In Twitter discussions, the fork is brought up by segwiters as clear evidence that BSV is the fork (and not Segwit). I understand why some people want it removed... in fact, I think CSW himself didn't want it when we were still BCH.
the forkID* is brought up...