{"type":"rich","version":"1.0","author_name":"npub1xddusuj8cyeqaqalq0zklafvdgr26pt32t0tvquw5mmwwwm3dehsqlkyw0","author_url":"https://nostr.ae/npub1xddusuj8cyeqaqalq0zklafvdgr26pt32t0tvquw5mmwwwm3dehsqlkyw0","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-03-28\n📝 Original message:His demand (not suggestion) allows it without any safeguards.\n\n\u003eThis patch must be in the immediate next release of Bitcoin Core.\n\nThat is not a suggestion.\n\nWang - still waiting on the details of this meeting.  In the spirit of\nopenness, I think you ought to share with the community what kind of secret\nmeetings are happening.\n\n\nOn Tue, Mar 28, 2017 at 3:43 PM, Tom Zander via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Tuesday, 28 March 2017 21:56:49 CEST Paul Iverson via bitcoin-dev wrote:\n\u003e \u003e It is clear that, spam aside, blocks are getting full and we need\n\u003e increase\n\u003e \u003e them soon. What I don't like about your proposal is it forces all node\n\u003e \u003e operators to implicitly accept larger blocks in 2020, even maybe against\n\u003e \u003e their will. 32 MB blocks might result in a loss of decentralization, and\n\u003e \u003e it might be too difficult to coordinate for small blocks before it's too\n\u003e \u003e late.\n\u003e\n\u003e The suggestion was not to produce 32MB blocks, so your fear here is\n\u003e unfounded.\n\u003e\n\u003e --\n\u003e Tom Zander\n\u003e Blog: https://zander.github.io\n\u003e Vlog: https://vimeo.com/channels/tomscryptochannel\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170328/a84076b1/attachment.html\u003e"}