I think nodes do this by default
Nope, if the transaction includes any INPUTs from a block post-fork, that transaction would be invalid on the Bitcoin blockchain side and those nodes would not relay the transaction.
That makes sense. In fact, I just read that in the transaction validation logic last night. Duh!
But they do relay new block announcements. Even if they are off the current chain. Right?
However, long term support would require BUY-IN from the existing BitCoin developers because at some point they will lock-in a block CHECKPOINT outside your fork.
If the fork is trying to use the same port (8333) and it gained a following (i.e., a lot of nodes using it) then likely the Bitcoin-Qt/bitcoind client would treat these as harmful and possibly require an update to address this thread (e.g., have the client disconnect early after some threshold of invalid transactions is received).
So option (2) requires BitCoin developer buy-in even for a plausible test.
I'm not an advocate of that path. I just mentioned it because I presume that is what wingding was initially thinking.
1. Download source
2. Change the mining parameters
3. Checkpoint a particular forking block
4. Compile, run and "Away we go!"
Could do option (1) by:
1a Download source
1b Download block chain
2a Change the mining parameters
2b Change the port
2c Tweak the genesis to change its hash
2d Re-hash all the other blocks at trivial difficulty
3. Checkpoint a particular forking block
4. Compile, run and "Away we go!"
At least that would get to a stable TestNet configuration to mess with.
Now I'm not Pollyanna. I don't expect this concept to be popular despite the free coins.
Without significant mixed-mining support people are going to treat this chain like Indiana John's whip!
I just want to compile the client and dink with it for practice. I've got my own Alt-Coin ideas. I just need a simple shared goal as motivation to get started.