So an update on 1-way pegging (aka bitcoin staging, explained in quoted text
at bottom): it turns out secure 2-way pegging is also possible (with some
bitcoin change to help support it). The interesting thing is this allows
interoperability in terms of being able to move bitcoin into and out of a
side chain. The side chains may have some different parameters, or
experimental things people might want to come up with (subject to some
minimum compatibility at the level of being able to produce an SPV proof of
a given form).
At the time of the 1-way peg discussion I considered 2-way peg as desirable
and it seemed plausible with bitcoin changes, but the motivation for 1-way
peg was to make it less risky to make changes on bitcoin, so that seemed
like a catch-22 loop. Also in the 2-way peg thought experiment I had not
realized how simple it was to still impose a security firewall in the 2-way
peg also.
So Greg Maxwell proposed in Dec last year a practically compact way to do
2-way pegging using SPV proofs. And also provided a simple argument of how
this can provide a security firewall. (Security firewall means the impact
of security bugs on the side-chain is limited to the people with coins in
it; bitcoin holders who did not use it are unaffected). [1]
How it works:
1. to maintain the 21m coins promise, you start a side-chain with no
in-chain mining subsidy, all bitcoin creation happens on bitcoin chain (as
with 1-way peg). Reach a reasonable hash rate. (Other semantics than 1:1
peg should be possible, but this is the base case).
2. you move coins to the side-chain by spending them to a fancy script,
which suspends them, and allows them to be reanimated by the production of
an SPV proof of burn on the side-chain.
3. the side-chain has no mining reward, but it allows you to mint coins at
no mining cost by providing an SPV proof that the coin has been suspended as
in 2 on bitcoin. The SPV proof must be buried significantly before being
used to reduce risk of reorganization. The side-chain is an SPV client to
the bitcoin network, and so maintains a view of the bitcoin hash chain (but
not the block data).
4. the bitcoin chain is firewalled from security bugs on the side chain,
because bitcoin imposes the rule that no more coins can be reanimated than
are currently suspend (with respect to a given chain).
5. to simplify what they hypothetical bitcoin change would need to consider
and understand, after a coin is reanimated there is a maturity period
imposed (say same as fresh mined coins). During the maturity period the
reanimation script allows a fraud proof to spend the coins back. A fraud
bounty fee (equal to the reanimate fee) can be offered by the mover to
incentivize side-chain full nodes to watch reanimations and search for fraud
proofs.
6. a fraud proof is an SPV proof with a longer chain showing that the proof
of burn was orphaned.
There are a few options to compress the SPV proof, via Fiat-Shamir transform
to provide a compact proof of amount work contained in a merkle tree of
proofs of work (as proposed by Fabien Coelho link on
http://hashcash.org/papers/) with params like 90% of work is proven. But
better is something Greg proposed based on skip-lists organized in a tree,
where 'lucky' proofs of work are used to skip back further. (Recalling that
if you search for a 64-bit leading-0 proof-of-work, half the time you get a
65-bit, quarter 66-bit etc.) With this mechanism you can accurately
prove the amount of proof of work in a compressed tree (rather than ~90%).
Apart from pegging from bitcoin to a side-chain, if a private chain is made
with same rules to the side-chain it becomes possible with some
modifications to the above algorithm to peg the side-chain to a private
chain. Private chain meaning a chain with the same format but signature of
single server in place of hashing, and timestamping of the block signatures
in the mined side chain. And then reactive security on top of that by full
nodes/auditors trying to find fraud proofs (rewrites of history relative to
side-chain mined time-stamp or approved double-spends). The reaction is to
publish a fraud proof and move coins back to the side chain, and then
regroup on a new server. (Open transactions has this audit + reactive model
but as far as I know does it via escrow, eg the voting pools for k of n
escrow of the assets on the private server.) I also proposed the same
reactive audit model but for auditable namespaces [4].
Private chains add some possiblity for higher scaling, while retaining
bitcoin security properties. (You need to add the ability for a user to
unilaterally move his coins to the side-chain they came from in event the
chain server refuses to process transactions involving them. This appears
to be possible if you have compatible formats on the private chain and
side-chain).
This pegging discussion involved a number of #bitcoin-wizards, Greg Maxwell,
Matt Corallo, Pieter Wuille, Jorge Timon, Mark
