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