<oembed><type>rich</type><version>1.0</version><author_name>npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2</author_name><author_url>https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2013-10-29&#xA;📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----&#xA;Hash: SHA256&#xA;&#xA;&#xA;&#xA;Peter Todd &lt;pete at petertodd.org&gt; wrote:&#xA;&gt;On Tue, Oct 29, 2013 at 10:52:31AM +0100, Mike Hearn wrote:&#xA;&gt;&gt; For block 0x11 again shall there be a separate code for &#34;block is&#xA;&gt;from the&#xA;&gt;&gt; future&#34;? We don&#39;t want to lose the nVersion field to people just&#xA;&gt;using it&#xA;&gt;&gt; for nonsense, so does it make sense to reject blocks that claim to be&#xA;&gt;v2 or&#xA;&gt;&gt; v3?&#xA;&gt;&#xA;&gt;That would prevent us from using nVersion as a soft-forking mechanism.&#xA;&#xA;Actually, that statement didn&#39;t go far enough: rejecting blocks with nVersions that you don&#39;t expect is a hard fork.&#xA;-----BEGIN PGP SIGNATURE-----&#xA;Version: APG v1.0.9&#xA;&#xA;iQFQBAEBCAA6BQJSb544MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8&#xA;cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhfuGCADHB+5WZ3oSRCCYgId+&#xA;5c4rxZHjjmXXIVOlXySjoRQ20JUnGbkUqN057VlutYbWaGV7OqR0oQyzh0LGpMdL&#xA;BU9hg8XoHbyIvA0WhCfEJvFzkwseN8Ac77UxtV3leBpBkSzjqlMS9QBGU6L5rw2U&#xA;uo8Sd7bQaqkadOPode3MMWDtmmqAZaj2dN02w/8C1rRna3SrbYRVYbaVAuN9yREO&#xA;99DOGEM2V7ni+eo4sQoxP2jf8vmNzy1EuQH8v1OloPgcpxl/GkLVXzQh4ZfO1ApE&#xA;UVKBo93oT34Tce9LwZy+k8XpeCvBRJ/+QwsbAAgdVYKr8KmRcAW4oR2KN7Y0jjq4&#xA;44xU&#xA;=OaON&#xA;-----END PGP SIGNATURE-----</html></oembed>