Invalidation of existing nonstandard-redemption UTXOs and transactions: Perspective from context of the proposed 2025 VM-Limit CHIP
Summary of problem
Bitcoin (Cash) generally respects that existing and currently-possible UTXOs will continue to be redeemable, as spending of UTXOs is a core premise of financial sovereignty. Does this rule have its limits? Where is the line drawn in the face of consensus changes? While there were numerous previous cases as we will see below, they were less obvious; CHIP-2021-05-vm-limits brings this question into sharp focus.
The context
Most of the existing limits modified or replaced by the VM-Limits CHIP are consensus, but one subset stands out: Signature operations as defined in the 2020-05-15 Sigchecks upgrade. Limits to signature operations are significantly more relaxed for nonstandard transactions, which are subject to crude sigchecks limits per transaction and block, versus standard relayed transactions which are subject to a per input density limit.
The VM-limits proposal would continue to permit all currently allowed standard transactions - with some extreme theoretical edge cases relegated to nonstandardness. Discussion of this relegation to nonstandardness is not the focus of this writeup, but we do talk about it a bit at the end anyway.
Due to its focus on allowing currently-standard transactions, some nonstandard transactions currently accepted in blocks (but not relaying) may no longer be accepted post upgrade.
It is unknown how widespread such cases are, they tend to be difficult to track down due to their nature of remaining hidden behind P2SH until redeemed. Furthermore, they are unlikely to be part of any popular usecases, as popular usecases typically require transactions to be relayable with reasonable reliability, which rules out nonstandard transactions.
Can we reasonably call it “confiscating money”? General lines of reasonableness
A particularly provoking version of objection to applying the VM-Limits upgrade as it stands goes as follows:
-
There exists a class of nonstandard transactions that would become invalid post-upgrade.
-
Due to the nature of P2SH, it’s impossible to know for sure if any UTXOs that exist today are only redeemable with this class of transactions. New ones may even be created today, or existing ones revealed in public channels.
-
An upgrade that makes these UTXOs irredeemable are basically “confiscation”, violating a fundamental principle of Bitcoin in general and Bitcoin Cash in particular, which partially based its split on the notion that high fees causing UTXOs to be practically irredeemable are unjustifiable.
This line of logic would be sound if Bitcoin (Cash) has never done transaction softforks in its 15-year history; in other words, never invalidating any previously valid transactions. Note that by the strictest definition this doesn’t just apply to potential onchain UTXOs becoming irredeemable, but also applies to transactions that could be remade and re-signed to claim UTXOs. This is because users could potentially be holding onto pre-signed but unbroadcast transactions as a way to conceal their ownership of coins; if they do not have access to re-signing facilities, invalidating the transaction they hold make the coins irredeemable in practice as well.
To expand further, such withheld transactions could themselves output to UTXOs that become irredeemable post-upgrade. Fun!
However, as we can easily show, the line of logic does not hold, and have been violated several times throughout Bitcoin (Cash) history. If there ever existed such a strict principle, it hasn’t been upheld with any rigor whatsoever.
Consensus transaction softforks: Some notable instances
We would exclude any emergency bugfix instances, and strictly only include “upgrades” where the desire is to improve bitcoin’s functionality.
2010: UTXO, withheld transactions “Just in case” panic disabling of math opcodes. While it could be argued that this is part of an urgent bugfix, there was no real justification to not constrain the disabling to a smaller set.
2012: UTXO, withheld transactions BIP16 P2SH. New rules for a particular shape of outputs, which must be redeemed through evaluated redeemScript in standard transactions. It is possible, though with no known usecases at the time or today, that some UTXOs or UTXOs-of-withheld-transactions may become irredeemable (albeit previously nonstandard) because their corresponding script cannot evaluate to True.
2015: Withheld transactions BIP66 DER signatures. While it does not make any UTXOs strictly irredeemable, it’s possible some withheld transactions may need to be re-signed, possibly constituting a “confiscation” by some standards.
2015,2016: UTXO, withheld transactions BIP65/68/112 CLTV and CSV. Some OP_NOPs were consumed as new opcodes. Previously valid but nonstandard transaction made invalid, while standard transactions had its scope expanded.
—This is post BCH split—
2017: Withheld transactions UAHF SIGHASH_FORKID. BTC transactions not valid on BCH, any potentially withheld standard transactions cannot claim funds on the new chain.
2017: UTXO, withheld transactions BIP62 LOW_S and NULLFAIL. Previously valid but nonstandard transactions made invalid.
2018: UTXO, withheld transactions BIP62 PUSHONLY and CLEANSTACK. Previously valid but nonstandard transactions made invalid.
2019: UTXO, withheld transactions BIP62 MINIMALDATA. Previously valid but nonstandard transactions made invalid.
2023: UTXO, withheld transactions CHIP-2021-01 Restrict Transaction Version. Previously valid but nonstandard transactions made invalid.
2023: UTXO, withheld transactions CHIP-2022-05 Pay-to-Script-Hash-32 (P2SH32). New rules for a particular shape of outputs, which must be redeemed through evaluated redeemScript in standard transactions. Pre-upgrade they could be theoretically spendable via nonstandard transactions without evaluating redeemscript.
2023: UTXO, withheld transactions CHIP-2022-02 CashTokens. New rules for a particular shape of outputs (PATFOs), which if existed before the upgrade becomes strictly unspendable post-upgrade. Pre-upgrade PATFOs could theoretically be spendable via nonstandard transactions.
A simple test: Prior Standardness
“Keep user funds redeemable both in theory and in practice! Your keys, your coins!” is an obviously noble and some would say even sacred principle of Bitcoin (Cash). So how does one reconcile this principle with the numerous violations above?
With some exceptions - one in 2010, one involving explicitly reserved opcodes and one at BCH split - all of the above historical cases invalidated only nonstandard transactions. An argument could be made that we have a longrunning historical precendence of upgrades consuming some parts of the nonstandard space to facilitate new functions. If there was any desire to preserve sanctity of nonstandard transactions or UTXOs, that ship has long sailed.
There’s an underlying logic to this: Nonstandard transactions are generally difficult to use as they’re not relayed, so they’re not expected to be part of any popular or even reasonably common niche usecases. Redeemability expectations are therefore also correspondingly lower.
It would therefore seem reasonable to state that transactions and UTXOs nonstandard prior to a given upgrade are generally fair game for constraining in the upgrade.
The case of segwit recovery
This longrunning history has one notable case where problem arose from invalidating nonstandard transactions: Segwit recovery invalidation from the BIP62 CLEANSTACK upgrade in 2018. Segwit recovery is a special case where some nonstandard transactions, existing as an artifact from the BCH split, did find a miner-enabled major usecase. Not accounting for this usecase seemed like a major oversight of the CLEANSTACK upgrade in hindsight.
No comparable nonstandard transaction usecases of any nature exist today on BCH other than segwit recovery itself, though - so it’s unlikely that VM-Limits would create complications of a similar sort.
Making previously standard transactions nonstandard
If we go by this longstanding historical precedent though, one particular complication may occur: Moving previously standard transaction into nonstandard would lower its expectation for protection, making it more likely to be invalidated in future upgrades. This has not been a notable problem thus far, but CHIP-2021-05-vm-limits may be the first upgrade to bring this into serious consideration since SIGHASH_FORKID.
The range of standard transactions affected have no known usecases and so this is unlikely to pose a problem, but it did require some clarification as intentionally relegating standard transactions to nonstandardness has no non-crisis precedent. CHIP-2021-05-vm-limits did so by establishing a genuine new precedent:
“By extension, it should be noted that any abusive behavior made nonstandard by this proposal is a candidate for full invalidation in future upgrades.”
This resolves the problem in effectively stating that “for standard transactions with no known usecases, relegating them to nonstandard is a valid path to future deprecation”. In my opinion this is a sensible and satisfying resolution.
