Quote from: DaveF on Today at 05:43:35 PM

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, 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.

Quote

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.

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.

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.