`OP_TXVERSION` is a footgun if transactions are allowed to lie about their version
Hi all,
I'm sorry I forgot to describe an interaction in the initial proposal that I now think we should make explicit in the spec: until non-standard transactions can't lie about their version, most contracts attempting to use the new OP_TXVERSION
can be abused by a rogue miner.
To summarize: transactions have been discouraged but not completely disallowed from lying about their version for almost 10 years now (commit dae3e10a5abe93833c57183b7c00f1db9200f46e
). This means typical users can't create transactions with misleading version numbers, but miners can manually include such transactions without their block being rejected by the network.
When Gavin Andresen originally made the change, it was still unclear how upgrades to Bitcoin (Cash) would be deployed, and it was seen as more conservative to make misleading versions non-standard rather than banning them completely (just in case the "hard forks are always bad" perspective won out). Unfortunately, it was abused a few times in the following years – at present there have been 6 transactions which lied about their version (claimed versions: 0
, 3
, 4
, 2164260863
, 2187681472
, and 2591798512
), the most recent was mined in 2016.
I'd previously assumed the issue was not in scope for this CHIP – if a future upgrade created a new transaction version, it could disallow misleading versions at that time (and new version formats already have to contend with block-height activation anyways).
However, I missed a slight ambiguity in the current specification – if we wait to enforce honest transaction versions, it's possible to create contracts which intentionally require a misleading transaction "version" or otherwise repurpose the version field. E.g. a petty/malicious strategy is to lock some funds in an output-age constrained (OP_CHECKSEQUENCEVERIFY
) contract which requires a misleading version to spend, then publicly accuse "the developers" of trying to freeze your money in a future upgrade. In general, the community has always preferred to avoid situations like this: we never want to even give the impression of breaking existing functionality. I was careful to clarify the same type of situation in the math64 CHIP, but I forgot to include any mention of the same possibility around transaction versions.
At a minimum, I think we should amend the specification to mention this issue explicitly. But before we waste time on that, I'm wondering if we can simply amend the spec to elevate the honest version policy from "standard" to "consensus".
@tomzander's CHIP 2021-01 Restrict Transaction Version has been around for over a year now. As far as I can tell, it has unanimous support. (I'm afraid I just forgot about it in November or I would have pushed to make it "official" then.)
With the CHIP process/schedule, Nov 15 was the deadline for reaching agreement on upgrade contents, but this is also a slight ambiguity in one of the accepted specifications (CHIP-2021-02: Native Introspection Opcodes
). And we have a month before Feb 15 – the target deadline for stable software releases supporting the upgrade. And of course, we still have >4 months before deployment. (Remember, this is already a well-established, 10 year old standard policy.)
So what does everyone prefer?
- Text-only clarification of issue and recommend avoiding
OP_TXVERSION
until a future upgrade, or - move honest version policy from "standard" to "consensus".
In the interest of cleanliness, I prefer (2), but if anyone is vehemently opposed to enforcing transaction versions in May, we can certainly kick it to next upgrade. I've just never heard any opposition, and it would be a shame to miss the opportunity because no one remembered to bring it up in November.