<oembed><type>rich</type><version>1.0</version><author_name>npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd</author_name><author_url>https://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-06-26&#xA;📝 Original message:On Fri, Jun 26, 2015 at 7:47 PM, Patrick Strateman &lt;&#xA;patrick.strateman at gmail.com&gt; wrote:&#xA;&#xA;&gt;  For a proposed hard fork to reach a level of consensus necessary to be&#xA;&gt; safe requires that there be a clear and self evident course of action.&#xA;&gt;&#xA;&#xA;Safety increases with more lead-in time.  If the reference client was&#xA;updated so that the hard fork happened in two years, it would be pretty&#xA;safe.  Miners would have time to update.&#xA;&#xA;If miners (or the community) objected, it is sort of like a game of chicken.&#xA;&#xA;This is one of the problems with not making decisions in advance, the&#xA;resulting hard fork is inherently safer.&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/dd5e7ab9/attachment.html&gt;</html></oembed>