{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2013-10-29\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\n\n\nPeter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003eOn Tue, Oct 29, 2013 at 10:52:31AM +0100, Mike Hearn wrote:\n\u003e\u003e For block 0x11 again shall there be a separate code for \"block is\n\u003efrom the\n\u003e\u003e future\"? We don't want to lose the nVersion field to people just\n\u003eusing it\n\u003e\u003e for nonsense, so does it make sense to reject blocks that claim to be\n\u003ev2 or\n\u003e\u003e v3?\n\u003e\n\u003eThat would prevent us from using nVersion as a soft-forking mechanism.\n\nActually, that statement didn't go far enough: rejecting blocks with nVersions that you don't expect is a hard fork.\n-----BEGIN PGP SIGNATURE-----\nVersion: APG v1.0.9\n\niQFQBAEBCAA6BQJSb544MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8\ncGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhfuGCADHB+5WZ3oSRCCYgId+\n5c4rxZHjjmXXIVOlXySjoRQ20JUnGbkUqN057VlutYbWaGV7OqR0oQyzh0LGpMdL\nBU9hg8XoHbyIvA0WhCfEJvFzkwseN8Ac77UxtV3leBpBkSzjqlMS9QBGU6L5rw2U\nuo8Sd7bQaqkadOPode3MMWDtmmqAZaj2dN02w/8C1rRna3SrbYRVYbaVAuN9yREO\n99DOGEM2V7ni+eo4sQoxP2jf8vmNzy1EuQH8v1OloPgcpxl/GkLVXzQh4ZfO1ApE\nUVKBo93oT34Tce9LwZy+k8XpeCvBRJ/+QwsbAAgdVYKr8KmRcAW4oR2KN7Y0jjq4\n44xU\n=OaON\n-----END PGP SIGNATURE-----"}