From: xor <xor@freenetproject.org>
To: bitcoin-dev@lists.linuxfoundation.org, Mike Hearn <hearn@vinumeris.com>,
	Gavin Andresen <gavinandresen@gmail.com>
Reply-To: xor@freenetproject.org
Date: Fri, 21 Aug 2015 02:03:19 +0200
Message-ID: <2872462.P4u4bhk3zl@1337h4x0r>
Organization: Freenet Project
User-Agent: KMail/4.13.3 (Linux/3.13.0-62-generic; KDE/4.13.3; x86_64; ; )
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart24850324.8NVn8fVPPh";
	micalg="pgp-sha256"; protocol="application/pgp-signature"
Subject: [bitcoin-dev] Analyzing mathematical / scientific sanity of XT's
	foundation (BIP101)
Precedence: list


--nextPart24850324.8NVn8fVPPh
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Hello,

For sake of peace, I wanted to give a chance to XT's block size growth =
efforts=20
by actually *reading* BIP101 [1] which seems to be their specification.=

Thus, please read this mail as something which aims to establish peacef=
ul=20
cooperation between the non-XT and XT community; not as something which=
 wants=20
to brush off BIP101 :)

Please also be aware that I am an outside non-Bitcoin developer, and th=
us=20
judge the document merely from the stuff which it actually contains, no=
t from=20
discussions during its development.
I hope this actually allows increased objectivity: A scientific documen=
t=20
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-1=
1
> 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,00=
0
> seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 U=
TC
> (timestamp 2083190400). The maximum size of blocks in between doublin=
gs
> will increase linearly based on the block's timestamp. The maximum si=
ze 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=20
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=20
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 tren=
ds 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 b=
ounded=20
exponential growth function. I would blind-guess the natural growth to =
be=20
something like [4] or [5]. Your function is not symmetrical, so it is f=
or sure=20
not aims to be [4], rather maybe close to [5] ?

Let us blindly assume it is a honorable and adequate way of limiting re=
source=20
usage to try to limit usage of a resource (=3D block size) to a functio=
n which=20
matches measured natural supply of the resource (=3D available CPU / st=
orage /=20
network as the proposed function aims to model).
We can probably all say that this is a standard scientific behavior, an=
d used=20
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=20=

provide:

1) a plot of the measurements of the natural data you're trying to matc=
h.=20
I.e. you plot your source data behind "based on long-term growth trends=
 for=20
CPU power, storage, and Internet bandwidth". I am unable to locate such=
 a plot=20
in the BIP101 document; and also not a link to the raw source data. Can=
 you=20
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=20
please provide it?

3) a joined plot of 1 and 2. This is what will prove whether your model=
 is=20
adequate: If the source data and your model function match, it is. This=
 is the=20
central thing I am missing in BIP101.

I would be happy if you could provide the plots, or at least the raw da=
ta. I=20
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=20
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=20
can guess its defining constants?
This is important because: While the logistic function [4] seems to be=20=

symmetrical, and thus the constants are revealed without nature reachin=
g=20
saturation yet, it is quite possible that the natural growth of CPU / d=
isk /=20
network is rather a generalised logistic function [5] which is not=20
symmetrical. Then we would have to wait until saturation starts so we c=
an=20
guess the constants needed to model it.

Thus, if natural growth has not reached the beginning of saturation yet=
, and=20
the saturation curve cannot be guessed, it is questionable of whether B=
IP101=20
is adequate: It is then possible that natural saturation is slower than=
=20
BIP101-saturation (=3D more resources will be available than consumed),=
 and in=20
the future we will reach a situation where blocks are smaller than the =
natural=20
capacity again.
Then the whole discussion to increase block size will happen again - bu=
t=20
possibly with a much larger economy behind Bitcoin, and thus much less=20=

possibility of reaching consensus.

Thus, in conclusion, please:
=2D provide plots, or at least data.
=2D once you have the plots, be open to scientifically admit that BIP101 =
might=20
be insufficient if the plots show the open questions I have just elabor=
ated. I=20
am also open to admitting that your data is sufficient from what I can =
say=20
:)

DISCLAIMER: I am in no way good at math. Hence please only use my elabo=
rations=20
to disprove stuff, not to prove it.


Greetings,
=09xor, a developer for the anonymous P2P network https://freenetprojec=
t.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 accep=
t
        Bitcoin donations :)


[1]=20
https://github.com/bitcoin/bips/blob/a409100854f52454b0ba30f98f8f5e5856=
95ec0e/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 curr=
ent
> 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=20
plots, it would be nice to provide source data and plots for this as we=
ll.

[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=20
is rather very important to me :) Afterwards, I am willing to help with=
=20
GnuPlot. But I think it is crucial to resolve the fears of the communit=
y much=20
sooner, so you should maybe consider plotting this yourself.

--nextPart24850324.8NVn8fVPPh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAABCAAGBQJV1mrLAAoJEMtmZ+8tjWt53NwP/3DIbmG6UQj5MpQ2hhe07N+k
R2SFNaOW4iOHy1QgDTGVnFaVZ4b1U/+OYevGlXF8px7jxhMW+sNpKuKh3lztjHZq
h0cJxB/x5nbVPXhcrrFUGCu1ONpMUIwylsqaG1AGsR5eSRGOaeleGwqG8sf0tEi3
f6416xz+RI/LFUO5oikoGiq5dkSUmyhj9lZYprHpYBmDaCpcP38PtvUhEZmkAAR6
OVIQJKqQtA/L8rWWz4YNW5TM2vRF7Vs2fIOJGV4ES6Zcq8SNj9YUq1T4yZua5GhZ
ssFC19uNoRWAEOQEOCToOfq3EgxKXpKKef+cC7w2i25RFe3E4oNtTMHKBaorLBbq
3Fym6+gn9fp6v7iyRnrJUsajKafl+243lgVdyL9ztMrTeG3asheqVwJ79l0swQDG
bE7qVefdeJmd4wtnZLfKIjOme5ch9n88UMmJam1hQcC2SBDrJq9NrR6/Ax5lofgo
8CC9+z6w0eFhkmcgMqv6eMbYfi+umJLeb668Thu7Gyaalx/zs6uTYx/a3UgDmYeh
7RI3d71HLNdvaIPhsPlExyuASAugjEK8SqgShIn7i42ON4KDJPOiBHCbMtkBUy2A
h/9DBkXXv+A+vxU8QCdjKe4nGq8UxOeXrE4KWqGjBnjuFQRdFeMabBKmE2QtXS//
iAaMWzIB6CymAAzb08Ms
=QfYP
-----END PGP SIGNATURE-----

--nextPart24850324.8NVn8fVPPh--