<div dir="ltr">If there should be a hard-fork, Core team should author the code. Other dev teams have marginal support among all BTC users.<div><br></div><div>Im tending to believe, that HF is necessary evil now. But lets do it in conservative approach:</div><div>- Fix historical BTC issues, improve code</div><div>- Plan HF activation date well ahead - 12 months+</div><div>- Allow increasing block size on year-year basis as Luke suggested</div><div>- Compromise with miners on initial block size bump (e.g. 2MB)</div><div>- SegWit</div><div><br></div><div>Martin Lizner</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 28, 2017 at 6:59 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">I&#39;ve proposed this hard fork approach last year in Hong Kong Consensus<br>
but immediately rejected by coredevs at that meeting, after more than<br>
one year it seems that lots of people haven&#39;t heard of it. So I would<br>
post this here again for comment.<br>
<br>
The basic idea is, as many of us agree, hard fork is risky and should<br>
be well prepared. We need a long time to deploy it.<br>
<br>
Despite spam tx on the network, the block capacity is approaching its<br>
limit, and we must think ahead. Shall we code a patch right now, to<br>
remove the block size limit of 1MB, but not activate it until far in<br>
the future. I would propose to remove the 1MB limit at the next block<br>
halving in spring 2020, only limit the block size to 32MiB which is<br>
the maximum size the current p2p protocol allows. This patch must be<br>
in the immediate next release of Bitcoin Core.<br>
<br>
With this patch in core&#39;s next release, Bitcoin works just as before,<br>
no fork will ever occur, until spring 2020. But everyone knows there<br>
will be a fork scheduled. Third party services, libraries, wallets and<br>
exchanges will have enough time to prepare for it over the next three<br>
years.<br>
<br>
We don&#39;t yet have an agreement on how to increase the block size<br>
limit. There have been many proposals over the past years, like<br>
BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so<br>
on. These hard fork proposals, with this patch already in Core&#39;s<br>
release, they all become soft fork. We&#39;ll have enough time to discuss<br>
all these proposals and decide which one to go. Take an example, if we<br>
choose to fork to only 2MB, since 32MiB already scheduled, reduce it<br>
from 32MiB to 2MB will be a soft fork.<br>
<br>
Anyway, we must code something right now, before it becomes too late.<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>
</blockquote></div><br></div>