<oembed><type>rich</type><version>1.0</version><author_name>npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd</author_name><author_url>https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2013-10-30&#xA;📝 Original message:&gt; But if you are getting soft-forked recent versions of the reference&#xA;&gt; implementation WILL alert you; see this code in main.cpp:&#xA;&gt;&#xA;&#xA;Perhaps I&#39;m confused about how we&#39;re using the term soft fork. My&#xA;understanding is that this is where a new upgrade is designed to look valid&#xA;to old nodes, and if you don&#39;t upgrade you rely on the miner majority to&#xA;get you &#34;back on track&#34;. For instance, P2SH was done this way - old nodes&#xA;that didn&#39;t upgrade during that transition believed all spends of P2SH&#xA;outputs were valid, even those spending someone elses coins.&#xA;&#xA;In this case, the code you cite won&#39;t do anything because your client will&#xA;never reject a block during a soft-forking upgrade, even if it does&#xA;something that&#39;s supposed to be invalid or nonsensical.&#xA;&#xA;If a new block version changes the serialization format or script language&#xA;or SIGHASH rules such that old clients reject the block, then they will end&#xA;up on a hard fork and the alerting code will trigger, which is correct and&#xA;as it should be.&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131030/e37ddff8/attachment.html&gt;</html></oembed>