Also ran into an interesting P2P incompatibility with 0.5 sending a headers message that was too big.
0.7.x will do so too, you can see me mention it in my post above.
Without BDB locks configuring, 0.3.20 gets to block 124,275, 0.4 and 0.4 to 258,354, and 0.6 and 0.7 to 364,670. With a high enough BDB locks settings, I was able to get 0.5 to tip after 2 weeks of syncing. I didn't try anything older all the way because I didn't have the patience to wait that long.
Good to see confirmation! and indeed, it's a brutal wait.
[quote author=pooya87 link=topic=1946144.msg60838073#msg60838073 date=1661660042
Considering that the only versions that I know of in Taproot is the defined Tapleaf versions (currently only 0xc0 is defined) and the fact that OP_VER seems to be pushing the protocol version to the stack (doesn't look like the value depends on
the stack itself.), and the fact that Taproot interprets 0x62 as OP_SUCCESS, could you explain what you mean here?
[/quote]As NotATether says, OP_SUCCESS makes a forced success.
So the idea of OP_VER at least so far as anyone is able to infer was to be able to write scripts with rules enforced by new versions of the script evaluator but which would be accepted by old versions. But this is vulnerable if you imagine that the script author could be malicious and intentionally trying to crack the consensus.
OP_SUCCESS accomplishes the same end, but it guarantees that a malicious script author can't use it to write a consensus cracking script that passes on 'new' nodes but not old ones.
This means that bitcoin could today just easily add operations in any of the values used by OP_SUCCESS now, with whatever semantics are sensible (e.g. doesn't have to be a _VERIFY style opcode that produces no output and can only fail the transaction) and without a whole bunch of cautious analysis about how they'll be evaluated by older code.
That's all.