[bitcoin-discuss] Scaling Sidechain -- spec / blocksize limit (how high can it go?)

Paul Sztorc truthcoin at gmail.com
Tue Jun 13 23:54:51 UTC 2017


Hello bitcoin-discuss,

Exactly one email ago [1] I tried to firm up some of the details of a
"scaling sidechain" (which I have been calling "Bitcoin Extended" until
someone comes up with a better way of describing it). Specifically, what
its focus and design principles might be, and how we might help it
succeed in the future.

In this post I will continue to get even more specific, by describing
the only alteration such a sidechain might make. Which is, of course,
the infamous blocksize limit.

In some sense, this is "off topic" for [bitcoin-dev] because it is about
a software project other than the one that all of those other
[bitcoin-dev] emails are about. Sidechains are a 'grey area' in terms of
if they are-or-aren't "Bitcoin", which is why it is here in
[bitcoin-discuss].


Most of the Details Are the Same
------------------------------------

For many reasons, everything else would be the same. Even ratios of
sigops to blocksize, or blocksize to blockweight, would likely be fixed
at their present values. For simplicity, the blocksize would probably be
set *equal* to the block weight -- the "discount" for using witness
scripts [2] would likely remain.

So, to specify the blocksize is --really-- to spec out the entire chain.


Motivation
-----------

In some sense, there is no need for us to determine an optimal
maxBlockSize, because miners can adjust it upward (by adding new
sidechains) or downward (by removing sidechains or imposing soft
limits), and they will likely slide it around to maximize their total
collective revenue.

So, it will eventually converge to something acceptable (...probably).
However, this convergence process will likely take up time, during which
there may be frustration (if oversmall), hold-up problems (if
overlarge), costly transition periods, and suboptimal performance in
general.

So we might as well use our accumulated expertise to guess at which
parameters will be viable.


Approach
---------

If our goal is for the chains to specialize in size (one large, one
small), we will want the large chain to be as large as possible.

How large can we realistically go?


The "Other" Bitcoin Security Model
------------------------------------

The traditional Bitcoin security model is well-known: that every user
run a full node, and the nodes all communicate with each other as equal
peers. This model is endorsed by the present software (which might even
take Luke-Jr's advice and _reduce_ its capacity).

The second is less conservative, and from it there may be no turning
back. For these and other reasons, the second model has been shunned. It
is a model where users mostly rely on the incentive system of Bitcoin to
enforce 'honest' behavior on miners. Users can then semi-trust miners,
in most if not all cases.

Satoshi was inconsistent, by endorsing both points of view. Since the
first already has strong representation, I will shore up the second here
momentarily with this sentence from the whitepaper: "Businesses that
receive frequent payments will probably still want to run their own
nodes for more independent security and quicker verification". This
sentence immediately restricts the reader's attention to "businesses"
(not users), and qualifies further that these be 'frequent transactor
businesses'. Finally, it uses the word "still" -- which implies that
while these entities would run a node, all other entities would no
longer be doing so.

An endless debate about "but alerts are impossible" and "why did Satoshi
himself impose the blocksize limit in 2010" might follow, in order to
shore up the first model at this point.

Fortunately, we no longer need to undergo a Talmudic deconstruction of
Satoshi's words to sort the correct thesis from the incorrect. With
sidechains, we can simply try both!

So, in conclusion, this security model will aim for Satoshi's more
liberal flavor, and be different in the following ways:

* It will emphasize "leeching" off the P2P network, and will
de-emphasize "seeding" (ie, maintaining it).
* Users will not run a full node, unless they catch wind of some kind of
malfeasance. In such a case, they are more like "emergency auditors"
than "equal peers".
* We can assume that our auditor will not use TOR. The TOR crowd will
stick with Bitcoin Core / Luke-Jr, and a smaller blocksize.
* For tractability, we can assume they live in a First World city, and
are reasonably well-off enough to afford modern computing equipment and
an average internet connection.

Each of these differences de-emphasizes decentralization, on purpose.
Users are explicitly opting-in to less decentralization. (And I am even
open to calling this thing, something _other_ than "Bitcoin").


Assumptions & Calculations
---------------------------

1. Bandwidth is the limiting factor, if only because everything else
(CPU, storage) can be cheaply increased, whereas bandwidth requires
large scale infrastructure investment which is often beyond the user's
control.
2. Our user is a resident of a first world city (see above), and has
access to 50 Mbps download speeds [3]. 50 Mbps = 6.25 MBps.
3. The user can "audit" the blockchain for 8 hours a night (by telling
his computer to do this, while he is asleep).
4. He has 7 days to complete the audit.
5. The audit requires 6 months worth of block history (at 10 minutes/block).

By multiplication, we have 6.25 MB * (60*60*8*7) = 1,260,000 MB of
downloading capacity per each "audit week". And each audit requires that
(52/2)*7*24*6 = 26,208 blocks be downloaded.

We reach a result of (1,260,000 / 26,208) ~= 48 MB per block.

I would then cut this immediately in half, to 24 MB, to provide a margin
of safety. Since 4 MB would already be allocated to Bitcoin Core
post-SegWit (and be necessary for the sidechain audit), this would leave
20 MB for the Scaling Sidechain. I would impose this figure as a hard limit.

For sanity, I would also impose a default soft limit of 8 MB per block
(just under half of the 20 MB).

Each limit would grow at 20% per year (until the year 2064), a rate
intentionally just above the 17.7% chosen by Pieter Wuille [4]. This is
because we have diminished our focus on "average" bandwidth growth, and
are more interested in bandwidth growth among people who are willing to
pay for bandwidth. Intentionally, over time a smaller and smaller
portion of the world would be able to run full nodes. (Or, more
precisely, it would take them longer and longer to perform a 6-month audit).


Conclusion
-----------

Hard Limit: 20 MB per block, growing 20% per year
Soft Limit:  8 MB per block, growing 20% per year


How does that sound? Crazy? Funny? Garbage? Something else?
Paul


[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2017-June/000147.html
[2] https://segwit.org/what-is-behind-the-segwit-discount-8515a8d3bca9
[3]
http://money.cnn.com/2016/08/04/technology/internet-speed-broadband/index.html
[4] https://gist.github.com/sipa/c65665fc360ca7a176a6


More information about the bitcoin-discuss mailing list