From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0860026C for ; 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 ; 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 ) id 1ZSZmx-0003rg-E2; Fri, 21 Aug 2015 02:02:31 +0200 From: xor To: bitcoin-dev@lists.linuxfoundation.org, Mike Hearn , Gavin Andresen 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--