<oembed><type>rich</type><version>1.0</version><author_name>npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0</author_name><author_url>https://nostr.ae/npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2017-04-09&#xA;📝 Original message:Curious: I&#39;m not sure why a serious discussion of POW change is not on the&#xA;table as a part of a longer-term roadmap.&#xA;&#xA;Done right, a ramp down of reliance on SHA-256 and a ramp-up on some of the&#xA;proven, np-complete graph-theoretic or polygon manipulation POW would keep&#xA;Bitcoin in commodity hardware and out of the hands of centralized&#xA;manufacturing for many years.&#xA;&#xA;Clearly a level-playing field is critical to keeping centralization from&#xA;being a &#34;defining feature&#34; of Bitcoin over the long term.   I&#39;ve heard the&#xA;term &#34;level playing field&#34; bandied about quite a bit.   And it seems to me&#xA;that the risk of state actor control and botnet attacks is less than&#xA;state-actor manipulation of specialized manufacturing of &#34;SHA-256 forever&#34;&#xA;hardware.   Indeed, the reliance on a fairly simple hash seems less and&#xA;less likely a &#34;feature&#34; and more of a baggage.&#xA;&#xA;Perhaps regular, high-consensus POW changes might even be *necessary* as a&#xA;part of good maintenance of cryptocurrency in general.   Killing the&#xA;existing POW, and using an as-yet undefined, but deployment-bit ready POW&#xA;field to flip-flop between the current and the &#34;next one&#34; every 8 years or&#xA;or so, with a ramp down beginning in the 7th year....  A stub function that&#xA;is guaranteed to fail unless a new consensus POW is selected within 7&#xA;years.&#xA;&#xA;Something like that?&#xA;&#xA;Haven&#39;t thought about it *that* much, but I think the network would respond&#xA;well to a well known cutover date.   This would enable rapid-response to&#xA;quantum tech, or some other needed POW switch as well... because the&#xA;mechanisms would be in-place and ready to switch as needed.&#xA;&#xA;Lots of people seem to panic over POW changes as &#34;irresponsible&#34;, but it&#39;s&#xA;only irresponsible if done irresponsibly.&#xA;&#xA;&#xA;On Fri, Apr 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev &lt;&#xA;bitcoin-dev at lists.linuxfoundation.org&gt; wrote:&#xA;&#xA;&gt; Jimmy Song,&#xA;&gt;&#xA;&gt; 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;&gt; If anything, we would be making policy changes to prevent the use of&#xA;&gt; patented PoW algorithms instead of making changes to enable them.&#xA;&gt;&#xA;&gt; Thanks,&#xA;&gt; Praxeology Guy&#xA;&gt;&#xA;&gt; _______________________________________________&#xA;&gt; bitcoin-dev mailing list&#xA;&gt; bitcoin-dev at lists.linuxfoundation.org&#xA;&gt; https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev&#xA;&gt;&#xA;&gt;&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170409/d885a90e/attachment.html&gt;</html></oembed>