As a start, I've tried to describe the status quo on the limitations page:
https://bitcoinj.github.io/limitations#consensus
Honestly I think protection from replays would need to be built into the
consensus rules. At network level, e.g. dropping nodes based on version
string, I agree with Jameson in that it will be very unreliable.
One option that hasn't been mentioned is using a low fee. As capacity
will shrink drastically on the minority chain, low fee transactions will
likely stay unconfirmed for a long time. However, the winning chain also
will loose some capacity (unless the nature of the fork is increasing
block size of course), so it will be difficult to hit the spot. For this
reason, I don't think this option is reliable either. But at least it
doesn't require any changes to bitcoinj.
IMHO: I don't think the ETH/ETC split can repeat on the Bitcoin
blockchain. The long difficulty intervals, combined with already full
blocks will cause the Bitcoin minority chain die off *much* quicker.
> <
https://groups.google.com/d/optout>.
> <
https://groups.google.com/d/optout>.