rich1.0npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydhttps://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydnjumphttps://nostr.ae📅 Original date posted:2013-10-29 📝 Original message: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. On Tue, Oct 29, 2013 at 12:38 PM, Peter Todd <pete at petertodd.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > > Peter Todd <pete at petertodd.org> wrote: > >On Tue, Oct 29, 2013 at 10:52:31AM +0100, Mike Hearn wrote: > >> For block 0x11 again shall there be a separate code for "block is > >from the > >> future"? We don't want to lose the nVersion field to people just > >using it > >> for nonsense, so does it make sense to reject blocks that claim to be > >v2 or > >> v3? > > > >That would prevent us from using nVersion as a soft-forking mechanism. > > Actually, that statement didn't go far enough: rejecting blocks with > nVersions that you don't expect is a hard fork. > -----BEGIN PGP SIGNATURE----- > Version: APG v1.0.9 > > iQFQBAEBCAA6BQJSb544MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 > cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhfuGCADHB+5WZ3oSRCCYgId+ > 5c4rxZHjjmXXIVOlXySjoRQ20JUnGbkUqN057VlutYbWaGV7OqR0oQyzh0LGpMdL > BU9hg8XoHbyIvA0WhCfEJvFzkwseN8Ac77UxtV3leBpBkSzjqlMS9QBGU6L5rw2U > uo8Sd7bQaqkadOPode3MMWDtmmqAZaj2dN02w/8C1rRna3SrbYRVYbaVAuN9yREO > 99DOGEM2V7ni+eo4sQoxP2jf8vmNzy1EuQH8v1OloPgcpxl/GkLVXzQh4ZfO1ApE > UVKBo93oT34Tce9LwZy+k8XpeCvBRJ/+QwsbAAgdVYKr8KmRcAW4oR2KN7Y0jjq4 > 44xU > =OaON > -----END PGP SIGNATURE----- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131029/25e2fca3/attachment.html>