Hello, For sake of peace, I wanted to give a chance to XT's block size growth efforts by actually *reading* BIP101 [1] which seems to be their specification. Thus, please read this mail as something which aims to establish peaceful cooperation between the non-XT and XT community; not as something which wants to brush off BIP101 :) Please also be aware that I am an outside non-Bitcoin developer, and thus judge the document merely from the stuff which it actually contains, not from discussions during its development. I hope this actually allows increased objectivity: A scientific document such as BIP101 should be fully self-contained. BIP101 proposes this: > The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 > 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000 > seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC > (timestamp 2083190400). The maximum size of blocks in between doublings > will increase linearly based on the block's timestamp. The maximum size of > blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes. I.e. a fixed function instead of adaptive, demand-based growth. Let us for a moment give the benefit of doubt and blindly assume that a fixed function is better than the adaptive growth which I advocated [2]. If we ignore the reasons [3] behind the choice of the initial value of 8MB for simplicity, what this function aims to model is this: > The doubling interval was chosen based on long-term growth trends for CPU > power, storage, and Internet bandwidth. The 20-year limit was chosen > because exponential growth cannot continue forever. If long-term trends do > not continue, maximum block sizes can be reduced by miner consensus (a > soft-fork). So you're trying to match a natural process of resource growth with a bounded exponential growth function. I would blind-guess the natural growth to be something like [4] or [5]. Your function is not symmetrical, so it is for sure not aims to be [4], rather maybe close to [5] ? Let us blindly assume it is a honorable and adequate way of limiting resource usage to try to limit usage of a resource (= block size) to a function which matches measured natural supply of the resource (= available CPU / storage / network as the proposed function aims to model). We can probably all say that this is a standard scientific behavior, and used in many systems. Now what is also the mathematical / scientific standard is this: If you aim to match a natural dataset with a model function of it, you provide: 1) a plot of the measurements of the natural data you're trying to match. I.e. you plot your source data behind "based on long-term growth trends for CPU power, storage, and Internet bandwidth". I am unable to locate such a plot in the BIP101 document; and also not a link to the raw source data. Can you please provide at least the raw data, if not a plot? 2) a plot of your model function. Also cannot find this in BIP101. Can you please provide it? 3) a joined plot of 1 and 2. This is what will prove whether your model is adequate: If the source data and your model function match, it is. This is the central thing I am missing in BIP101. I would be happy if you could provide the plots, or at least the raw data. I would love to offer help with GnuPlot, but this will take some weeks [6]. Let me stress further possible mathematical problems which show why the plots are important for deciding whether BIP101 is a good idea: Once we have a plot of the functions, the central question will be this: Has the natural source data sufficiently revealed its saturation curve so we can guess its defining constants? This is important because: While the logistic function [4] seems to be symmetrical, and thus the constants are revealed without nature reaching saturation yet, it is quite possible that the natural growth of CPU / disk / network is rather a generalised logistic function [5] which is not symmetrical. Then we would have to wait until saturation starts so we can guess the constants needed to model it. Thus, if natural growth has not reached the beginning of saturation yet, and the saturation curve cannot be guessed, it is questionable of whether BIP101 is adequate: It is then possible that natural saturation is slower than BIP101-saturation (= more resources will be available than consumed), and in the future we will reach a situation where blocks are smaller than the natural capacity again. Then the whole discussion to increase block size will happen again - but possibly with a much larger economy behind Bitcoin, and thus much less possibility of reaching consensus. Thus, in conclusion, please: - provide plots, or at least data. - once you have the plots, be open to scientifically admit that BIP101 might be insufficient if the plots show the open questions I have just elaborated. I am also open to admitting that your data is sufficient from what I can say :) DISCLAIMER: I am in no way good at math. Hence please only use my elaborations to disprove stuff, not to prove it. Greetings, xor, a developer for the anonymous P2P network https://freenetproject.org/ (while it existed for 16 years, we only have 3 months of funding left, so please excuse me abusing this publicity to say that we accept Bitcoin donations :) [1] https://github.com/bitcoin/bips/blob/a409100854f52454b0ba30f98f8f5e585695ec0e/bip-0101.mediawiki [2] http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010262.html [3] > The initial size of 8,000,000 bytes was chosen after testing the current > reference implementation code with larger block sizes and receiving > feedback from miners on bandwidth-constrained networks (in particular, > Chinese miners behind the Great Firewall of China). Notice: Similar to what is said in the main part of the mail about data and plots, it would be nice to provide source data and plots for this as well. [4] https://en.wikipedia.org/wiki/Logistic_function [5] https://en.wikipedia.org/wiki/Generalised_logistic_function [6] I'm busy with finishing my bachelor's thesis for the next two weeks, which is rather very important to me :) Afterwards, I am willing to help with GnuPlot. But I think it is crucial to resolve the fears of the community much sooner, so you should maybe consider plotting this yourself.