>
> Anyway the stuff Mike is saying about being able to detect upgrades is
> incorrect - detecting an upgrade is *easier* with a soft-fork, just look
> at the block header nVersion numbers and warn the user if they increase
> beyond what you know is valid. Bitcoin Core implements this IIRC, and
> bitcoinj should.
>
Nobody said hard forks shouldn't have an associated block version number
increase - that's a straw man. They should! The difference is only whether
older clients are presented with data they would refuse to accept thus
ensuring they don't accept the new version blocks.
Meanwhile, what I said *is* correct. New version numbers result in only a
log print. Being hard forked off results in both log prints *and* the
-alertnotify being run: it's noisier, and if the user followed the
instructions printed to the console when there is no config file present,
he/she should also get an email or some other kind of more meaningful alert.
Finally, please stop trying to imply that all this is settled and I'm
somehow an idiot for bringing it up. You've done that on the pull request
and now here, it gives me a headache. Instead of making hand-waving
references to "stuff on IRC ages ago", explain why it's better to keep
these nodes in some fantasy world where they think they're fully validating
but are actually not.
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
