[Cryptography] Standards Trolls: Re: Bitcoin is a disaster.

[jrzx]

> > On Sunday, January 10, 2021 6:45 PM, John Levine johnl at iecc.com wrote:
> > > Reality check: ...
> > >
> > > Bitcoin as we all know is limited to 10tps. Credit
> > > card networks  handle about 11000tps all day every
> > > day. It's three orders of magnitude higher.
> > >
> > > > will need a crypto coin that enables seven
> > > > billion people to buy a lollipop.
> > >
> > > No kidding. I'm not holding my breath, although in Africa
> > > M-Pesa comes surprisingly close.
> >
> > I have, on paper, a design that can support visa volume
> > transactions on a moderately well connected computer. It is
> > yet another variant of one of many blockdag designs that
> > can also support visa volume transactions on a moderately
> > well connected computer. I think my design will be
> > somewhat more efficient, but at present there is no valid
> > comparison data. We are not short of designs on paper.

On Sunday, January 10, 2021 7:37 PM, John Levine <johnl at iecc.com> wrote:
> I expect we'd all like to see it.

There are thirty or more proposed blockdag systems, and it is not worth
other people spending time examining my proposed variant in detail until
I write considerably more code.

But I will outline the blockdag concept, and my variant on it.

Why is bitcoin slow?

The bandwidth limit on adding transactions is not a problem.

Suppose a typical transaction consists to two input coins, a change output
coin, and the actual payment.  (I use the term coin to refer to transaction
inputs and outputs, although they don't come in any fixed denominations
except as part of anti tracking measures)

Each output coin consists of payment amout, suppose around sixty four bits,
and a public key, two hundred and fifty six bits.  It also has a script
reference on any special conditions as to what constitutes a valid spend,
which might have a lot of long arguments, but it generally will not, so the
script reference will normally be one byte.

The input coins can be a hash reference to a coin in the consensus
blockchain, two fifty six bits, or they can be a reference by total order
within the blockchain, sixty four bits.

We use can use a Schnorr group signature, which is five hundred and
twelve bits no matter how many coins are being signed, no matter how
many people are signing, and no matter if it is an n of m signature.

So a typical transaction should be around 1680 bits, maybe less.

At scale you inevitably have a large number of clients and a small number
of full peers.  Say a few hundred peers, a few billion clients, most of  them
lightning gateways.  So we can assume every peer has a good connection.

A typical, moderately good, home connection is thirty Mbps download but
its upload connection is only ten Mbs or so.

So if our peers are typical decent home connections, and they will be a lot
better than that, bandwidth limits them to adding transactions at 10Mbps,
six thousand transactions per second, visa magnitude.

Which if everyone in the world is buying their lollipops on the blockchain
will still need most people using the lightning networ layer, rather than
the blockchain layer, but everyone can still fairly routinely access the
blockchain layer itself.

So if bandwidth is not a problem, why is bitcoin so slow?

The bottleneck in bitcoin is that to avoid too many forks, which waste time
with fork resolution, you need a fair bit of consensus on the previous block
before you form the next block.

On a blockdag, you don't. Every peer is continually forming his own fork,
and these forks reach consensus about their left great grand child, or left
great great ... great grandchild.  The blocks that eventually become the
consensus as leftmost blocks form a blockchain.  So we can roll right ahead,
and groups of blocks that deviate from the consensus, which is all of them
but one, eventually get included, but later in the total order than they
initially thought they were.

In a blockdag, each block has several children, instead of just one.  Total
order starting from any one block is depth first search.  The left blocks
come before the right blocks, and the child blocks come before the parent
block.  Each block may be referenced by several different parent blocks, but
only the first reference in the total order matters.

Each leftmost block defines the total order of all previous blocks, the
total order being the dag in depth first order.

Each peer disagrees with all the other peers about the total order of recent
blocks and recent transactions, each is its own fork, but they all agree
about the total order of older blocks and older transactions.

[There are umpteen proposals for blockdags](https://www.researchgate.net/publication/346973648_SoK_Diving_into_DAG-based_Blockchain_Systems) most of them garbage, but the
general principle is sound.

For a bunch of algorithms that plausibly claim to approach the upload
limit, see

[Team Rocket, Maofan Yin, Kevin Sekniqi, Robbert van Renesse, and Emin Gün Sirer. Scalable and probabilistic leaderless bft consensus through metastability.](https://files.avalabs.org/papers/consensus.pdf)

[Vivek Bagaria, Sreeram Kannan, David Tse, Giulia Fanti, and Pramod Viswanath. Prism: Deconstructing the blockchain to approach physical limits. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security,pages 585–602, 2019.](https://arxiv.org/pdf/1810.08092.pdf)

[George Danezis and David Hrycyszyn. Blockmania: from block dags to consensus, 2018. Lei Yang, Vivek Bagaria, Gerui Wang, Mohammad Alizadeh, David Tse, Giulia Fanti, and Pramod Viswanath. Prism: Scaling bitcoin by 10,000 x. arXiv preprint arXiv:1909.11261, 2019.](https://arxiv.org/pdf/1809.01620.pdf)

[Tai-Yuan Chen, Wei-Ning Huang, Po-Chun Kuo, Hao Chung, and Tzu-Wei Chao. Dexon: A highly scalable, decentralized dag-based consensus algorithm. arXiv preprint arXiv:1811.07525, 2018.](https://eprint.iacr.org/2018/1112.pdf)

[Xavier Boyen, Christopher Carr, and Thomas Haines. Blockchain-free cryptocurrencies: A framework for truly decentralised fast transactions. Cryptology ePrint Archive, 2016.](https://eprint.iacr.org/2016/871.pdf)

The specific details of many of these proposed systems are rather silly and
often vague, typical academic exercises unconcerned with real world
issues, but the general idea that the academics intend to illustrate is sound
and should work, certainly can be made to work.  They need to be
understood as academic illustrations of the idea of the general algorithm
for fast and massive blockdag consensus, and not necessarily intended as
ready to roll implementations of that idea.

Here is an even more vague outline of my variant of this idea, which I
would name "Yet another blockdag consensus algorithm", except it would
be excessively vain to give it a name until there is rough running code.

I propose proof of stake.  The stake of a peer is not the stake it owns, but
the stake that it has injected into the blockchain on behalf of its clients and
that its clients have not spent yet.  Each peer pays on behalf of its clients
for the amount of space it takes up on the blockchain, though it does not pay
in each block.  It makes an advance payment that will cover many transactions
in many blocks. (The money disappears, built in deflation, instead of built in
inflation).  Each block is a record of what a peer has injected (actually two
peers in a gossip interaction, transactions are not injected until one peer
gossips them to another peer, but that is an implementation detail deep in the
weeds that can be ignored.)

The special sauce that makes each proposed blockdag different from each of the
others is how each peer decides what consensus is forming about the leftmost
edge of the dag, the graph analysis that each peer performs.  And this, my
special sauce, I will explain when I have something running.

Each peer adopts as its leftmost child for its latest block, a previous block
that looks like a good candidate for consensus, which looks like a good
candidate for consensus because the left child has a left child that looks like
consensus actually is forming around that grandchild , in part because the the
left child has a ... left child has a ... left child that looks like it might
have consensus, until eventually, as new blocks pile on top of old blocks, we
actually do get consensus about the left most child sufficiently deep in the
dag from the latest blocks.

The blockdag can run fast because all the forks that are continually forming
eventually get stuffed into the consensus total order somewhere.  So we don't
have to impose a speed limit to prevent excessive forking.