<oembed><type>rich</type><version>1.0</version><author_name>npub1ttkq82l7hflyj6r3vxuw9c9pu7ce0fmaky98x3awz3cqpk7t5l0sz0gtzm</author_name><author_url>https://nostr.ae/npub1ttkq82l7hflyj6r3vxuw9c9pu7ce0fmaky98x3awz3cqpk7t5l0sz0gtzm</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2017-03-28&#xA;📝 Original message:Thank you for the proposal Wang Chung!&#xA;&#xA;It is clear that, spam aside, blocks are getting full and we need increase&#xA;them soon. What I don&#39;t like about your proposal is it forces all node&#xA;operators to implicitly accept larger blocks in 2020, even maybe against&#xA;their will. 32 MB blocks might result in a loss of decentralization, and it&#xA;might be too difficult to coordinate for small blocks before it&#39;s too late.&#xA;&#xA;&#xA;So I think Core can&#39;t decide on hard forks like this. It must be left up to&#xA;the users. I think only choice is for Core to add a run-time option to&#xA;allow node operators to increase block size limit, so that this very&#xA;controversial decision is not coming from Core. It must come from the&#xA;community.&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170328/df218008/attachment-0001.html&gt;</html></oembed>