{"type":"rich","version":"1.0","author_name":"npub14h948ndawt32ps3y225sslch8344tmw8k5z0lxuxr6wq9tu6sl2qj9yjx0","author_url":"https://nostr.ae/npub14h948ndawt32ps3y225sslch8344tmw8k5z0lxuxr6wq9tu6sl2qj9yjx0","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-03-29\n📝 Original message:On Mar 29, 2017 9:50 AM, \"Martin Lízner via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\nIm tending to believe, that HF is necessary evil now.\n\n\nI will firmly disagree. We know how to do a soft-fork blocksize increase.\nIf it is decided that a block size increase is justified, we can do it with\nextension blocks in a way that achieves full backwards compatibility for\nall nodes.\n\nBarring a significant security motivation, there is no need to hardfork.\n\nI am also solidly unconvinced that increasing the blocksize today is a good\nmove, even as little as SegWit does. It's too expensive for a home user to\nrun a full node, and user-run full nodes are what provide the strongest\ndefence against political manuveuring.\n\nWhen considering what block size is acceptable, the impact of running\nbitcoin in the background on affordable, non-dedicated home-hardware should\nbe a top consideration.\n\nDisk space I believe is the most significant problem today, with RAM being\nthe second most significant problem, and finally bandwidth consumption as\nthe third most important consideration. I believe that v0.14 is already too\nexpensive on all three fronts, and that block size increases shouldn't be\nconsidered at all until the requirements are reduced (or until consumer\nhardware is better, but I believe we are talking 3-7 years of waiting if we\npick that option).\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/873b902d/attachment.html\u003e"}