{"type":"rich","version":"1.0","author_name":"npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8","author_url":"https://nostr.ae/npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-07-30\n📝 Original message:1) Unlike previous blocksize hardfork proposals, this uses median time\ninstead of block.nTime for activation. I like that more but my\npreference is still using height for everything. But that discussion\nis not specific to this proposal, so it's better if we discuss that\nfor all of them here:\nhttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html\n\n2) I think uncontroversial hardforks should also take miner\nconfirmation into account, just like uncontroversial softforks do. We\ncannot make sure other users have upgraded before activating the\nchain, but we can know whether miners have upgraded or not. Having\nthat tool available, why not use it. Of course other hardforks may not\ncare about miners' upgrade state. For example \"anti-miner hardforks,\nsee https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#asic-reset-hardfork\nBut again, this is common to all uncontroversial hardforks, so it\nwould probably better to discussed it in\nhttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html\n(gmaxwell assigned to bip99 to my bip draft).\n\n3) As commented to you privately, I don't like to make any assumptions\nabout technological advancements (much less on economical growth). I\ndon't expect many people to agree with me here (I guess I've seen too\nmany \"peak oil\" [or more generally, peak energy production] plus I've\nread Nietzsche's \"On the utility and liability of history for life\"\n[1]; so considering morals, technology or economics as \"monotonic\nfunctions\" in history is simply a ridiculous notion to me), but it's\nundeniable that internet connections have improved overall around the\nworld in the last 6 years. I think we should wait for the\ntechnological improvements to happen and then adapt the blocksize\naccordingly. I know, that's not a \"definitive solution\", we will need\nto change it from time to time and this is somewhat ugly.\nBut even if I'm the only one that considers a \"technological\nde-growth\" possible, I don't think is wise to rely on pseudo-laws like\nMoore's or Nielsen’s so-called \"laws\".\nStealing a quote from another thread:\n\n\"Prediction is difficult, especially about the future.\" - Niels Bohr\n\nSo I would prefer a more limited solution like bip102 (even though I\nwould prefer to have some simulations leading to  a concrete value\n(even if it's bigger) rather than using 2MB's arbitrary number.\n\nThose are my 3 cents.\n\n[1] https://philohist.files.wordpress.com/2008/01/nietzsche-uses-history.pdf\n\nOn Thu, Jul 30, 2015 at 4:25 PM, Pieter Wuille via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Hello all,\n\u003e\n\u003e here is a proposal for long-term scalability I've been working on:\n\u003e https://gist.github.com/sipa/c65665fc360ca7a176a6\n\u003e\n\u003e Some things are not included yet, such as a testnet whose size runs ahead of\n\u003e the main chain, and the inclusion of Gavin's more accurate sigop checking\n\u003e after the hard fork.\n\u003e\n\u003e Comments?\n\u003e\n\u003e --\n\u003e Pieter\n\u003e\n\u003e\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"}