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