{"type":"rich","version":"1.0","author_name":"npub1ttkq82l7hflyj6r3vxuw9c9pu7ce0fmaky98x3awz3cqpk7t5l0sz0gtzm","author_url":"https://nostr.ae/npub1ttkq82l7hflyj6r3vxuw9c9pu7ce0fmaky98x3awz3cqpk7t5l0sz0gtzm","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-03-28\n📝 Original message:Thank you for the proposal Wang Chung!\n\nIt is clear that, spam aside, blocks are getting full and we need increase\nthem soon. What I don't like about your proposal is it forces all node\noperators to implicitly accept larger blocks in 2020, even maybe against\ntheir will. 32 MB blocks might result in a loss of decentralization, and it\nmight be too difficult to coordinate for small blocks before it's too late.\n\n\nSo I think Core can't decide on hard forks like this. It must be left up to\nthe users. I think only choice is for Core to add a run-time option to\nallow node operators to increase block size limit, so that this very\ncontroversial decision is not coming from Core. It must come from the\ncommunity.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170328/df218008/attachment-0001.html\u003e"}