Bitcoin does not scale to the required size. The Bitcoin reliable broadcast channel is a massively replicated public ledger of every transaction that ever there was, each of which has to be evaluated for correctness by every full peer. With recursive snarks, we can now instead have a massively replicated public sql index of private ledgers. Such a blockchain with as many transactions as bitcoin, will, after running for as long as Bitcoin, only occupy a few dozen megabytes of disk storage, rather than near a terabyte, and each peer and client wallet only has to evaluate the root recursive snark to prove the validity of every transaction that ever there was, including all those lost in the mists of time.
though his peer can probably guess quite accurately that they are. The client creates a proof that this an output from a transaction with valid inputs, and his peer creates a proof that the peer verified the client's proof and that output being committed was not already committed to another different transaction, and registers the commitment on the blockchain. The output is now valid for that transaction, and not for any other, without the reliable broadcast channel containing any information about the transaction of which it is an output, nor the transaction of which it will become an input.
You have to register the unspent transaction outputs on the public
index, the reliable broadcast channel, within some reasonable
time, say perhaps below block height $\lfloor(h/32⌋+2\rfloor)*32$,
where h is the block height on which the first commit of an
output to the transaction was registered. If not all the inputs to
the transaction were registered, then obviously no one can
produce a proof of validity for any of the outputs. After that
block height you cannot register any further outputs, but if you
prove that after that block height no output of the transaction was
registered, you can create a new unspent transaction output for
each transaction input to the failed transaction which effectively
rolls back the failed transaction. This time limit enables us to
recover from failed transactions, and, perhaps, more importantly,
enables us to clean up the mutable sql index that the immense
chain of immutable sql indexes represents, and that the public
broadcast channel contains. We eventually drop outputs that have
been committed to a particular transaction, and can then
eventually drop the commits of that output without risking
orphaning valid outputs that have not yet been registered in the
public broadcast channel.
## summarizing away useless old data
So that the public broadcast channel can eventually dump old
blocks, and thus old spend events, every time we produce a new
base level block containing new events (an sql index of new
transaction outputs, and an sql index table with the same primary
of spend commitments of past unspent transaction outputs to
transactions) we also produce a consolidation block, a summary
block that condenses two past blocks into one summary block,
thus enabling the two past blocks that it summarizes to be dropped.
Immediately before forming a block of height $2n+1$, which is
a block height whose binary representation ends in a one, we use
the information in base level blocks $2n-3, 2n-2, 2n-1$,
and $2n$ to produces a level one summary block that allows base
level blocks $2n-3$ and $2n-2$, the two oldest remaining base
level blocks to be dropped. When we form the block of height
$2n+1$, it will have an edge to the block of height 2n, forming a
chain, and an edge to the summary block summarizing blocks
$2n-3$ and $2n-2$, forming a tree.
At every block height of $4n+2$. which is a block height whose
binary representation ends in a one followed by a zero, we use the
information in the level one summary blocks for heights
$4n-5$, $4n-3$, $4n-1$, and $4n+1$, to produce a level two
summary block that allows the level one summary blocks for
$4n-5$ and $4n-3$, the two oldest remaining lever one
summary blocks, to be dropped. The base level blocks are level zero.
At every block height of $8n+4$. which is a block height whose
binary representation ends in a one followed by two zeroes, we
use the information in the level two summary blocks for heights
$8n-10$, $8n-6$, $8n-2$, and $8n+2$, to produce a level
three summary block that allows the level two summary blocks
for $8n-10$ and $8n-6$, the two oldest remaining level two
summary blocks, to be dropped.
And similarly, for every block height of $2^{m+1}*n + 2^m$,
every block height whose binary representation ends in a one
followed by $m$ zeroes, we use the information in four level $m$
summary blocks, the blocks $2^{m+1}*n + 2^{m-1}- 4*2^{m}$, $2^{m+1}*n + 2^{m-1}- 3*2^{m}$, $2^{m+1}*n + 2^{m-1}- 2*2^{m}$, and $2^{m+1}*n + 2^{m-1}- 1*2^{m}$ to produce an $m+1$ summary block that allows the two oldest remaining level $m$ summary blocks, the blocks $2^{m+1}*n + 2^{m-1}- 4*2^{m}$ and $2^{m+1}*n + 2^{m-1}- 3*2^{m}$ to be dropped.
We summarise the data in the earliest two blocks by discarding
every transaction output that was, at the time those blocks were
created, an unspent transaction output, but is now marked as used
in any of the four blocks by committing it to a particular
transaction. We discard commits which refer to outputs that have
now been discarded by previous summary blocks and have timed
out, which is to say, commits in a level m summary block being
summarised into a level m+1 summary block that reference
outputs in the immediately previous level m+1 summary block.
However if, a commit references an output that is now in a
summary block of level greater than m+1, that commit has to be
kept around to prevent double spending of the previous output,
which has not yet been summarised away.
We produce the summary block of past blocks just before we
produce the base level block, and the base level block has an
edge pointing to the previous base level block, a chain edge,
and an edge pointing to the just created summary block a tree
Each transaction output contains a hash of the verification rule,
one of the requirements whereby one will prove that the output
was validly committed as an input to a transaction when the time
comes to commit it to a transaction. One always has to prove that
the transaction will not create money out of thin air, but one also
has to prove the transaction was done by valid authority, and the
output defines what is its valid authority. The normal and usual
verification rule is to prove that the party committing the output
knows a certain secret. But the verification rule could be anything,
thus enabling contracts on the blockchain,
and could instead be that a valid current state of the sidechain, which is a valid descendant of the state previously used in the previous similar transaction that created this output,
committed this output as an input to the new transaction -- in which case the output
represents the money on a sidechain, and the transaction moves money between the sidechain and mainchain.
This hash allows anyone to innovate some sidechain idea, or
some contract idea, without needing everyone else on the
blockchain to buy in first. The rest of the blockchain does not
have to know how to verify valid authority, does not need to
know the preimage of the hash of the method of verification, just
verify that the party committing did the correct verification,
whatever it was. Rather than showing the reliable broadcast
channel a snark for the verification of authority,
which other people might not be able to check, the party committing a
transaction shows it a recursive snark that shows that he verified
the verification of authority using the verification method
specified by the output. And what that method was, outsiders do
not need to know, reducing the burden of getting everyone
playing by the same complex rules. If a contract or a sidechain
looks indistinguishable from any other transaction, it not only
creates privacy and reduces the amount of data that other people
on the blockchain have to handle and know how to handle, it also
radically simplifies blockchain governance, bringing us closer to
the ideal of transactions over distance being governed by
