From: xor <xor@freenetproject•org>
To: bitcoin-dev@lists•linuxfoundation.org,
Mike Hearn <hearn@vinumeris•com>,
Gavin Andresen <gavinandresen@gmail•com>
Subject: [bitcoin-dev] Analyzing mathematical / scientific sanity of XT's foundation (BIP101)
Date: Fri, 21 Aug 2015 02:03:19 +0200 [thread overview]
Message-ID: <2872462.P4u4bhk3zl@1337h4x0r> (raw)
[-- 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 --]
reply other threads:[~2015-08-21 0:04 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2872462.P4u4bhk3zl@1337h4x0r \
--to=xor@freenetproject$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gavinandresen@gmail$(echo .)com \
--cc=hearn@vinumeris$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox