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