Did you test older versions till you found one that worked or do you just know that they will not?
I tested the oldest that would run at all for me. But I know that prior to 0.8 that you will have to do something about the BDB locks situation,
I also know that the BDB locks fix shared around back in 2013 will only take you up to 2016 or 2017 or something and then it still runs out of BDB locks.
Part of the reason that the community fixed the BDB issue rather than figuring out a rule that would mandate blocks that were always be valid to all nodes and softforking it in was that BDB was complicated enough that it seemed infeasible to come up with such a rule.
For my purposes I wanted to validate how far back you could go with an utterly stock node, unattended, unconfigured, no debate over what constitutes a hardfork or not. I was checking this because faketoshi sued myself and a dozen other current and former Bitcoin developers demanding that we write backdoored node software which will hand him control over the huge stash of coins he claims to own (but claims to have "lost" to "hackers"), or otherwise pay him billions of dollars in damages. We pointed out that even the people who are still developers lack the ability to help him pull off his heist because users simply wouldn't run the backdoored version in any quantity. Faketoshi countered that users have no choice but to run the latest version. Part of our reply was 'Users can and do run old versions or completely independent versions, in fact the most recent isn't even the most popular and in fact versions from about ten years ago just work.' So I wanted to make absolutely sure that 0.8.x did work and that the nodes on the p2p network claiming to be 0.8.x were actually working and not fake or something.
For a long time while I was working on Bitcoin I kept a fleet of older versions running specifically to monitor compatibility, but I haven't worked on Bitcoin in quite some time, and efforts like keeping old nodes running kinda fell by the wayside as the environment become more hostile which switched Bitcoin from being something I loved working on to something I worked on to avoid letting my friends down.
You are WAY more informed on this then me, but if 0.8 can sync, if I can can get it running from what I can see 0.6.3 should also, but it may not work properly on a modern OS. Eliminating the security implications running it on 32 bit Windows XP should work.
Just wondering, not that important.
Some recent versions like maybe 0.18+ also get angry at some older versions in the 0.7.x region at least and tend to disconnect them because there were some limits added to some messages like getheaders and 0.7.x will respond with too many. This isn't a consensus change but would get in the way of doing a test. Interestingly, running a sufficiently OLDER version would still work (at least for that reason) because they don't produce the messages that anger the recent code.
I think basically 0.8 is as far back as you can go before there starts being a lot of difficulty and asterisks. It's also hard to impossible to find binaries older than that (as they got taken off hosting sites due to security issues with them) unless you already have them, so you basically need an old operating system to build them from source.
My belief is that if you work around/fix the BDB locks issue then its likely code all the way back to where Satoshi added NOPs in script will validate the blocks, but anything prior to Satoshi's changes in 0.3.7 in 2010 are likely latently hardfork incompatible due to the
verifyscript split. By latent incompatible I mean that they'll likely accept the current chain, but someone could craft a special transaction today that would be accepted but they'd reject-- so a hardfork but not triggered yet.
(and I say 'likely' because I haven't seen it actually tested. Sometimes something you think would be a consensus break is actually prevented by different code, so there is no replacement for actually testing)
It's pretty clear that Satoshi didn't *initially* have a comprehensive understanding of the criteria needed for consensus stability as people do today. You can see him figuring it out through changes like eliminating OP_VER are introducing OP_NOPx, so he made a number of changes early on without much care if they created latent hardforks. At the time he was doing this stuff, no one else really understood it at all, so there isn't any discussion about the details (at least not in public). Because the hardforks were latent though you could continue to run the old code, making it appear completely compatible even when it wasn't, so it's only been through careful historical analysis that people have gone and figured out exactly what changed where in what ways.
The definition of "hardfork" has also shifted a bit over time: Three major kinds of "hardfork" come to mind, from weakest to strongest:
(1) A latent hardforking consensus change: This is a rule where a node will accept transactions that the 'prior' code wouldn't accept.
(2) A triggered hardforking consensus change: This is a latent change where a triggering transactions actually exists in the most work change.
(3) A hardforked chain: This is a triggered hardforking change that was triggered at a time when enough usage of the 'prior' version existed that a separate chain formed and consensus was actually split in practice.
I think the original usage of "hardfork" tended to be mostly refer to the last type or rarely the others, but in modern usage the meaning has shifted more to the first type-- largely because a focus on not accidentally creating latent hardforks is how you avoid a hardforked chain.
It's only the last type that has an active impact on users, and this is part of why you'll find quite confident messages from people (myself included) that say that Bitcoin has never had a hardfork except maybe if you want to count that BDB issue. Yet today you can also find threads like this one where I'm pointing out latent (and maybe triggered) hardforks created by Satoshi (accidentally in some cases, maybe in all cases).
You could also come up with some levels between 2 and 3 that would be interesting and relevant: Even if a forked chain didn't form were any users forced off software they preferred to use. If some hereto unknown latent hardfork from 0.3.x days got triggered today it would likely be completely unnoticed and not disrupt anyone. But if a hereto unknown latent hardfork from 0.11.x were triggered today it wouldn't form a split but it would almost certainly disrupt some users, cause some problems, and maybe leave some people unable to use their favorite choice in software.
Then there are other things like-- is removing a checkpoint that fixes the hash of block 1 a hardfork? -- in one sense it's a latent hardforking change but one that could ONLY ever be triggered if the entire chain was erased with a gigantic reorg, rendering the entire system unusable and pointless. Personally I think it's worthless to consider such things as hardforks. I think it's best to only consider things that could have at some point could have credibly created a hardforked chain in an otherwise working system to be hardforks. If the definition is expanded too broadly it loses its power to aid understanding. Like, e.g. Bitcoin should be extremely careful about introducing hardforking changes: But should it be extremely careful about removing ancient checkpoints? No. Only careful to the extent that they might be providing protection against something, not for consensus stability reasons.
If your interest is mostly in 0.3.10 - 0.8 if you want to deal with the BDB and P2P issues then I'm quite confident you'd find the consensus rules are completely compatible. And if you found that they were incompatible it would be a new and interesting discovery that might inform software development practices-- because if it's not compatible (for reasons other than BDB) it would be due to a yet unknown accidental triggered hardfork. I'd make a sizable bet no such thing exists though. If your interest goes much older, I'm less confident but also because of self-inconsistencies like BDB and OP_VER I think it's just less interesting: old enough versions were too broken to be treated as a viable consensus system.
