<unnamed>

Public Key

npub1ttkq82l7hflyj6r3vxuw9c9pu7ce0fmaky98x3awz3cqpk7t5l0sz0gtzm

Profile Code

nprofile1qqs94mqr40lt5ljfdpckrw8zuzs70vvh5a7mzznng7hpguqqm0960hcpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0qyxhwumn8ghj7mn0wvhxcmmvhg9st2

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:58:13 UTC

- reply

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