[bitcoin-discuss] Scaling Sidechain ("Bitcoin Extended" (?)) -- Avoiding Future Inefficiencies

Paul Sztorc truthcoin at gmail.com
Tue Jun 13 21:43:03 UTC 2017


Summary
--------

This post is about two ways that "Core"* might help "EX" (and other
sidechains) to be healthier and more successful in the future: a code
refactor, and the addition of UTXO commitments.

* See my note two sections down about the imperfect naming.

I would like to know if anyone has any objections, before proceeding
further with either.

I am posting in [discuss], instead of [dev], because this is pre-action
and more informal (and, vaguely, more "off topic").

Purpose
---------

I've previously discussed [1,2] my plans to increase Bitcoin capacity by
allowing users to offload some of their transaction volume to sidechains.

I would now like to get more specific, and discuss the properties of
such a chain in particular. This "scaling sidechain" would aim to
resemble the mainchain (ie, "our present-day Bitcoin Core") as much as
possible, yet with the sole change being a categorically larger blocksize.


Name (?)
----------

I am calling it "Bitcoin Extended" (Bitcoin "EX"), given that it
resembles [1] extension blocks in structure, and [2] predecessors "..XT
/ ..Classic / ..Unlimited", in intention (despite the fact that the
implementation strategy is quite different -- Extended is not a hard
fork). I will call the mainchain "Bitcoin Core", even though that is
somewhat imprecise (...I just don't know what else to call it).

I am highly open to better naming conventions. How would you describe a
developer who is interested in working on Bitcoin Core, but not
interested in working on Bitcoin sidechains (given that they will be
different software projects)? What word would describe people who are
-by default- friendly, permissive, or hostile to such chains?


1. Code Refactor for Node Costs / Validation Costs
----------------------------------------------------

Jeremy Rand gave an excellent QCON talk [3] about Namecoin, in which he
specifically emphasized (slide 23) the importance of following an
upstream project closely. His conclusion is likely quite obvious for
this list, but worth belaboring: "If you're not prepared to quickly
merge upstream commits, your blockchain is going to have bad things
happen." Luke Dashjr is cited as advising "if Bitcoin makes a change,
follow their lead even if it looks non-urgent, and follow their lead
quickly".

Hence, it would be convenient for EX if everything related to "node
cost" (or "validation cost") were pushed into its own specific place,
ideally one file. This would include blocksize/weight and SIGOPs limits.
It may also include transaction standard-ness or default estimations, or
anything else you can think of.

If this were done, it would allow much easier comparisons between the
two software repositories. As a result, the EX could more easily mirror
the features of Core as they are released. For example, Schnorr SA can
be developed for both chains at once, with no marginal inconvenience.

Maintaining EX would thereafter be "free", or nearly so.

This should probably not be done for every sidechain that might ever get
added, but I think for the very first try, it would be nice.


2. UTXO Commitments (Allowing Sidechains to Discard Old History)
------------------------------------------------------------------

Sidechains may be able to use UTXO commitments to safely discard
significantly old history (say, older than 6 months). The marginal risk
of relying on UTXO commitments is much lower on the sidechain than on
the mainchain, for two reasons.

The first reason could be called "accounting". Typically, UTXO
commitments threaten to surrender a few important things, namely the
protection against counterfeiting (defined as: producing coins in
violation of the issuance schedule). However, in drivechain, there is a
hierarchical asymmetry where the mainchain tracks transfers into and out
of each sidechain (indeed, to the mainchain they are regular BTC
transactions). As long as the mainchain follows the issuance schedule
--and I see no reason to expect otherwise-- the sidechain must follow it
as well.

The second reason is that the disadvantages of reliance-on-utxo are
subsumed by the risks of using sidechains in the first place. If we
build a grid of four cases: main/side and reliance/no-reliance, then it
seems that three of these variants (the 'UTXO-reliant-mainchain'
variant, as well as both sidechain variants) will experience some kind
of bad outcome if 'miners are ~honest for ~6 months'=FALSE. The relative
risk seems to be: M < M+utxo < S = S+utxo , where M/ denotes
main/sidechain and utxo denotes reliance on such commitments. So there
is no additional risk -- if one has come as far as sidechains, one may
as well go further to UTXO commitments.

So, in practice, "sidechain utxo reliance" would seem to have few costs.
And the benefits might be tremendous...it allows the Bitcoin ecosystem
to copy an Altcoin's feature, potentially without copying its
accumulated bloat.

Let me explain, by contrasting two worlds:

1. A world where Bitcoin exists, and a set of Altcoins exist that
perform a bunch of non-Bitcoin features.
2. A world where Bitcoin exists, and every 6 months someone creates a
whole new wave of Altcoins, which each provide the exact same service as
their counterparts in the previous 6-month-Altcoin-wave. Every 6 months
there is a new investor cycle of Alt-holders. Users never hold the
Altcoins, they just buy into them, use them for services, and then sell
them.

Bitcoin would appear to have a greater disadvantage in the second
case...after all, Bitcoin's blockchain grows and grows, but the Altcoins
can do a clever rinse-and-repeat maneuver and start afresh (Cheaters!!).

However, with UTXO commitments, sidechains might get the best of both
worlds -- longevity without burden.

I know a bunch of people were working on UTXO commitments at one point
(Bram Cohen ? .. and then Peter Todd I believe claimed it could be done
out-of-band). For the purpose I outline here, I believe it would be
better to force miners to enforce the commitment...but I simply do not
know. I am not up to date on this area..it is too hard to keep track of
where everything is!


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

If there are objections to doing either, please let them be heard. And
please share your relevant information, as it is too hard for me to keep
track of what everyone has been doing.

Thank you,
Paul


[1]
http://www.drivechain.info/literature/index.html#milan-presentation---sidechain-scaling
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014364.html
[3]
https://qconlondon.com/london-2017/system/files/presentation-slides/qcon_slides_-_jeremy_rand.pdf


More information about the bitcoin-discuss mailing list