[bitcoin-dev] Analyzing mathematical / scientific sanity of XT's foundation (BIP101)

[bitcoin-dev] Analyzing mathematical / scientific sanity of XT's foundation (BIP101)

[xor]

[-- Attachment #1: Type: text/plain, Size: 6548 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]