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