<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I think it&#39;s probably safer to have a fork-to-minumum (e.g. minimal 
coinbase+header) after a certain date than to fork up at a certain date.
 At least in that case, the default isn&#39;t breaking consensus, but you 
still get the same pressure to fork to a permanent solution.<br><br>I don&#39;t endorse the above proposal, but remarked for the sake of guiding the argument you are making.<br></div></div><div class="gmail_extra"><br clear="all"><div><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">--<br><a href="https://twitter.com/JeremyRubin" target="_blank">@JeremyRubin</a><a href="https://twitter.com/JeremyRubin" target="_blank"></a></div></div></div>
</div>
<br><div class="gmail_quote">On Tue, Mar 28, 2017 at 1:31 PM, Wang Chun via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The basic idea is, let&#39;s stop the debate for whether we should upgrade<br>
to 2MB, 8MB or 32MiB. 32MiB is well above any proposals&#39; upper limit,<br>
so any final decision would be a soft fork to this already deployed<br>
release. If by 2020, we still agree 1MB is enough, it can be changed<br>
back to 1MB limit and it would also a soft fork on top of that.<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Mar 29, 2017 at 1:23 AM, Alphonse Pace &lt;<a href="mailto:alp.bitcoin@gmail.com">alp.bitcoin@gmail.com</a>&gt; wrote:<br>
&gt; What meeting are you referring to?  Who were the participants?<br>
&gt;<br>
&gt; Removing the limit but relying on the p2p protocol is not really a true<br>
&gt; 32MiB limit, but a limit of whatever transport methods provide.  This can<br>
&gt; lead to differing consensus if alternative layers for relaying are used.<br>
&gt; What you seem to be asking for is an unbound block size (or at least<br>
&gt; determined by whatever miners produce).  This has the possibility (and even<br>
&gt; likelihood) of removing many participants from the network, including many<br>
&gt; small miners.<br>
&gt;<br>
&gt; 32MB in less than 3 years also appears to be far beyond limits of safety<br>
&gt; which are known to exist far sooner, and we cannot expect hardware and<br>
&gt; networking layers to improve by those amounts in that time.<br>
&gt;<br>
&gt; It also seems like it would be much better to wait until SegWit activates in<br>
&gt; order to truly measure the effects on the network from this increased<br>
&gt; capacity before committing to any additional increases.<br>
&gt;<br>
&gt; -Alphonse<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev<br>
&gt; &lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I&#39;ve proposed this hard fork approach last year in Hong Kong Consensus<br>
&gt;&gt; but immediately rejected by coredevs at that meeting, after more than<br>
&gt;&gt; one year it seems that lots of people haven&#39;t heard of it. So I would<br>
&gt;&gt; post this here again for comment.<br>
&gt;&gt;<br>
&gt;&gt; The basic idea is, as many of us agree, hard fork is risky and should<br>
&gt;&gt; be well prepared. We need a long time to deploy it.<br>
&gt;&gt;<br>
&gt;&gt; Despite spam tx on the network, the block capacity is approaching its<br>
&gt;&gt; limit, and we must think ahead. Shall we code a patch right now, to<br>
&gt;&gt; remove the block size limit of 1MB, but not activate it until far in<br>
&gt;&gt; the future. I would propose to remove the 1MB limit at the next block<br>
&gt;&gt; halving in spring 2020, only limit the block size to 32MiB which is<br>
&gt;&gt; the maximum size the current p2p protocol allows. This patch must be<br>
&gt;&gt; in the immediate next release of Bitcoin Core.<br>
&gt;&gt;<br>
&gt;&gt; With this patch in core&#39;s next release, Bitcoin works just as before,<br>
&gt;&gt; no fork will ever occur, until spring 2020. But everyone knows there<br>
&gt;&gt; will be a fork scheduled. Third party services, libraries, wallets and<br>
&gt;&gt; exchanges will have enough time to prepare for it over the next three<br>
&gt;&gt; years.<br>
&gt;&gt;<br>
&gt;&gt; We don&#39;t yet have an agreement on how to increase the block size<br>
&gt;&gt; limit. There have been many proposals over the past years, like<br>
&gt;&gt; BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so<br>
&gt;&gt; on. These hard fork proposals, with this patch already in Core&#39;s<br>
&gt;&gt; release, they all become soft fork. We&#39;ll have enough time to discuss<br>
&gt;&gt; all these proposals and decide which one to go. Take an example, if we<br>
&gt;&gt; choose to fork to only 2MB, since 32MiB already scheduled, reduce it<br>
&gt;&gt; from 32MiB to 2MB will be a soft fork.<br>
&gt;&gt;<br>
&gt;&gt; Anyway, we must code something right now, before it becomes too late.<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt; <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;<br>
&gt;<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>