From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <xor@freenetproject.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0860026C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2015 00:04:02 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de
[80.67.31.37])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C8E45131
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2015 00:04:00 +0000 (UTC)
Received: from [77.177.152.235] (helo=anonymous)
by smtprelay03.ispgateway.de with esmtpsa
(TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84)
(envelope-from <xor@freenetproject.org>)
id 1ZSZmx-0003rg-E2; Fri, 21 Aug 2015 02:02:31 +0200
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"
X-Df-Sender: eG9yQGZyZWVtYWlsLmJvZ2VydC5kZQ==
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_05,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] Analyzing mathematical / scientific sanity of XT's
foundation (BIP101)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Aug 2015 00:04:02 -0000
--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--