rich1.0npub14h948ndawt32ps3y225sslch8344tmw8k5z0lxuxr6wq9tu6sl2qj9yjx0https://nostr.ae/npub14h948ndawt32ps3y225sslch8344tmw8k5z0lxuxr6wq9tu6sl2qj9yjx0njumphttps://nostr.ae📅 Original date posted:2017-03-29 📝 Original message:On Mar 29, 2017 9:50 AM, "Martin Lízner via bitcoin-dev" < bitcoin-dev at lists.linuxfoundation.org> wrote: Im tending to believe, that HF is necessary evil now. I will firmly disagree. We know how to do a soft-fork blocksize increase. If it is decided that a block size increase is justified, we can do it with extension blocks in a way that achieves full backwards compatibility for all nodes. Barring a significant security motivation, there is no need to hardfork. I am also solidly unconvinced that increasing the blocksize today is a good move, even as little as SegWit does. It's too expensive for a home user to run a full node, and user-run full nodes are what provide the strongest defence against political manuveuring. When considering what block size is acceptable, the impact of running bitcoin in the background on affordable, non-dedicated home-hardware should be a top consideration. Disk space I believe is the most significant problem today, with RAM being the second most significant problem, and finally bandwidth consumption as the third most important consideration. I believe that v0.14 is already too expensive on all three fronts, and that block size increases shouldn't be considered at all until the requirements are reduced (or until consumer hardware is better, but I believe we are talking 3-7 years of waiting if we pick that option). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/873b902d/attachment.html>