<div>I think at least the three following things have to be done before the block size can be increased by any significant amount:<br></div><div>1. A network protocol defined UTXO snapshot format be defined, UTXO snapshots being created automatically in a deterministic periodic and low-cost fashion.&nbsp; Ability to synchronize starting from such a UTXO snapshot as requested by a user.<br></div><div>2. SPV support from a pruned node that has the latest UTXO snapshot.&nbsp; Probably requires committing the UTXO snapshot hash to the block.<br></div><div>3. Given the above fixes the problem of needing full block chain history storage, and people are comfortable with such a security model, a good portion of the network can switch to this security model, and still satisfy our desire for the system to be sufficiently distributed.&nbsp; This requires lots of testing.<br></div><div>4. More current studies on the effect of increasing the block size on synchronizing node drop out due to other reasons such as network bandwidth, memory, and CPU usage.<br></div><div><br></div><div>Without doing the above, scheduling to increasing the block size would be wreckless.<br></div><div><br></div><div>Cheers,<br></div><div>Praxeology Guy<br></div><div><br></div><div><br></div><blockquote type="cite" class="protonmail_quote"><div>-------- Original Message --------<br></div><div>Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting<br></div><div>Local Time: March 29, 2017 2:10 PM<br></div><div>UTC Time: March 29, 2017 7:10 PM<br></div><div>From: <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br></div><div>To: Martin Lízner &lt;<a href="mailto:martin.lizner@gmail.com">martin.lizner@gmail.com</a>&gt;, Bitcoin Protocol Discussion &lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt;<br></div><div><br></div><div dir="ltr">In order for any blocksize increase to be agreed upon, more consensus is needed.&nbsp; The proportion of users believing no blocksize increases are needed is larger than the hardfork target core wants(95% consensus).&nbsp; The proportion of users believing in microtransactions for all is also larger than 5%, and both of those groups may be larger than 10% respectively.&nbsp; I don't think either the Big-blocks faction nor the low-node-costs faction have even a simple majority of support.&nbsp; Getting consensus is going to be a big mess, but it is critical that it is done.<br></div><div class="gmail_extra"><div><br></div><div class="gmail_quote"><div>On Wed, Mar 29, 2017 at 12:49 AM, Martin Lízner via bitcoin-dev <span dir="ltr">&lt;<a rel="noreferrer nofollow noopener" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>If there should be a hard-fork, Core team should author the code. Other dev teams have marginal support among all BTC users.<br></div><div><br></div><div>Im tending to believe, that HF is necessary evil now. But lets do it in conservative approach:<br></div><div>- Fix historical BTC issues, improve code<br></div><div>- Plan HF activation date well ahead - 12 months+<br></div><div>- Allow increasing block size on year-year basis as Luke suggested<br></div><div>- Compromise with miners on initial block size bump (e.g. 2MB)<br></div><div>- SegWit<br></div><div><br></div><div>Martin Lizner<br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><div><br></div><div class="gmail_quote"><div>On Tue, Mar 28, 2017 at 6:59 PM, Wang Chun via bitcoin-dev <span dir="ltr">&lt;<a rel="noreferrer nofollow noopener" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;</span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I've proposed this hard fork approach last year in Hong Kong Consensus<br></div><div> but immediately rejected by coredevs at that meeting, after more than<br></div><div> one year it seems that lots of people haven't heard of it. So I would<br></div><div> post this here again for comment.<br></div><div> <br></div><div> The basic idea is, as many of us agree, hard fork is risky and should<br></div><div> be well prepared. We need a long time to deploy it.<br></div><div> <br></div><div> Despite spam tx on the network, the block capacity is approaching its<br></div><div> limit, and we must think ahead. Shall we code a patch right now, to<br></div><div> remove the block size limit of 1MB, but not activate it until far in<br></div><div> the future. I would propose to remove the 1MB limit at the next block<br></div><div> halving in spring 2020, only limit the block size to 32MiB which is<br></div><div> the maximum size the current p2p protocol allows. This patch must be<br></div><div> in the immediate next release of Bitcoin Core.<br></div><div> <br></div><div> With this patch in core's next release, Bitcoin works just as before,<br></div><div> no fork will ever occur, until spring 2020. But everyone knows there<br></div><div> will be a fork scheduled. Third party services, libraries, wallets and<br></div><div> exchanges will have enough time to prepare for it over the next three<br></div><div> years.<br></div><div> <br></div><div> We don't yet have an agreement on how to increase the block size<br></div><div> limit. There have been many proposals over the past years, like<br></div><div> BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so<br></div><div> on. These hard fork proposals, with this patch already in Core's<br></div><div> release, they all become soft fork. We'll have enough time to discuss<br></div><div> all these proposals and decide which one to go. Take an example, if we<br></div><div> choose to fork to only 2MB, since 32MiB already scheduled, reduce it<br></div><div> from 32MiB to 2MB will be a soft fork.<br></div><div> <br></div><div> Anyway, we must code something right now, before it becomes too late.<br></div><div> ______________________________<wbr>_________________<br></div><div> bitcoin-dev mailing list<br></div><div> <a rel="noreferrer nofollow noopener" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br></div><div> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer nofollow noopener">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br></div></blockquote></div><div><br></div></div></div></div><div><br></div><div>______________________________<wbr>_________________<br></div><div> bitcoin-dev mailing list<br></div><div> <a rel="noreferrer nofollow noopener" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br></div><div> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer nofollow noopener">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br></div><div> <br></div></blockquote></div></div></blockquote><div><br></div>