<div dir="ltr">Yes, exactly. That's the point. As you well know I think the whole soft-fork mechanism is wrong and should not be used. If the rules change, your node is *supposed* to end up on a chain fork and trigger an alert to you, that's pretty much the whole purpose of Bitcoin's design. Undermining that security model is problematic.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 29, 2013 at 12:38 PM, Peter Todd <span dir="ltr"><<a href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<div class="im"><br>
<br>
<br>
Peter Todd <<a href="mailto:pete@petertodd.org">pete@petertodd.org</a>> wrote:<br>
>On Tue, Oct 29, 2013 at 10:52:31AM +0100, Mike Hearn wrote:<br>
>> For block 0x11 again shall there be a separate code for "block is<br>
>from the<br>
>> future"? We don't want to lose the nVersion field to people just<br>
>using it<br>
>> for nonsense, so does it make sense to reject blocks that claim to be<br>
>v2 or<br>
>> v3?<br>
><br>
>That would prevent us from using nVersion as a soft-forking mechanism.<br>
<br>
</div>Actually, that statement didn't go far enough: rejecting blocks with nVersions that you don't expect is a hard fork.<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: APG v1.0.9<br>
<br>
iQFQBAEBCAA6BQJSb544MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8<br>
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhfuGCADHB+5WZ3oSRCCYgId+<br>
5c4rxZHjjmXXIVOlXySjoRQ20JUnGbkUqN057VlutYbWaGV7OqR0oQyzh0LGpMdL<br>
BU9hg8XoHbyIvA0WhCfEJvFzkwseN8Ac77UxtV3leBpBkSzjqlMS9QBGU6L5rw2U<br>
uo8Sd7bQaqkadOPode3MMWDtmmqAZaj2dN02w/8C1rRna3SrbYRVYbaVAuN9yREO<br>
99DOGEM2V7ni+eo4sQoxP2jf8vmNzy1EuQH8v1OloPgcpxl/GkLVXzQh4ZfO1ApE<br>
UVKBo93oT34Tce9LwZy+k8XpeCvBRJ/+QwsbAAgdVYKr8KmRcAW4oR2KN7Y0jjq4<br>
44xU<br>
=OaON<br>
-----END PGP SIGNATURE-----<br>
<br>
</blockquote></div><br></div>