<oembed><type>rich</type><version>1.0</version><author_name>npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u</author_name><author_url>https://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-06-15&#xA;📝 Original message:On Mon, Jun 15, 2015 at 5:08 PM, Aaron Voisine &lt;voisine at gmail.com&gt; wrote:&#xA;&#xA;&gt; Wasn&#39;t the XT hard fork proposed as a last resort, should the bitcoin-core&#xA;&gt; maintainers simply refuse to lift the 1Mb limit? No one wants to go that&#xA;&gt; route. An alternate hard-fork proposal like BIP100 that gets consensus, or&#xA;&gt; a modified version of gavin&#39;s that ups the limit to 8Mb instead of 20Mb, or&#xA;&gt; hell even some major changes to the non-consunsus code to make it&#xA;&gt; adequately handle the situation when blocks fill up, and allow wallet&#xA;&gt; software to continue working with a send-and-forget use pattern, any of&#xA;&gt; these would be enough to avoid the need for an XT only hard-fork.&#xA;&gt;&#xA;&gt; So far BIP100 is the only one that seems to actually be getting any sort&#xA;&gt; of momentum toward consensus, and it was proposed... 2 days ago? When the&#xA;&gt; XT fork was proposed as a last resort, it was when the opponents were (to&#xA;&gt; my understanding) suggesting we just let blocks fill up, and hopefully&#xA;&gt; things would just work out on their own.&#xA;&gt;&#xA;&#xA;We are not reaching consensus about any proposal, Garzik&#39;s or otherwise.&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/8ccbaeef/attachment.html&gt;</html></oembed>