<oembed><type>rich</type><version>1.0</version><author_name>npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8</author_name><author_url>https://nostr.ae/npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2017-04-08&#xA;📝 Original message:On 8 Apr 2017 5:06 am, &#34;Jimmy Song via bitcoin-dev&#34; &lt;&#xA;bitcoin-dev at lists.linuxfoundation.org&gt; wrote:&#xA;&#xA;Praxeology Guy,&#xA;&#xA;Why would the actual end users of Bitcoin (the long term and short term&#xA;&gt; owners of bitcoins) who run fully verifying nodes want to change Bitcoin&#xA;&gt; policy in order to make their money more vulnerable to 51% attack?&#xA;&gt;&#xA;&#xA;Certainly, if only one company made use of the extra nonce space, they&#xA;would have an advantage. But think of it this way, if some newer ASIC&#xA;optimization comes up, would you rather have a non-ASICBoosted hash rate to&#xA;defend with or an ASICBoosted hash rate? Certainly, the latter, being&#xA;higher will secure the Bitcoin network better against newer optimizations.&#xA;&#xA;&#xA;Why?&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170408/9bce75cb/attachment.html&gt;</html></oembed>