On Mon, Dec 11, 2017 at 10:23:21PM +0000, Pulat Yunusov wrote:
> Thank you for your post, Peter. Why is it necessary to centralize the p-o-p
> sidechain and have a maintainer? It seems the Bitcoin network will secure
> the most critical element, which is the witness authenticity. Wouldn't a
> second decentralized network be able to perform the functions of the
> maintainer so the entire system is trustless?

It's centralized in that writeup basically because centralizing it is
*significantly* easier; it's not obvious how to maintain a proof-of-publication
ledger in a decentralized, scalable, way.

In the centralized version it's obvious how to scale process by which the
ledger is built via sharding: split the key range up as needed and assign each
range to a separate server (be it an actual server, or a fault-tolerate cluster
acting as a single server) that reports back to a master co-ordinator who
builds the tree from the per-range sub-tips reported back by the shards. If
required due to extreme scale, do this on multiple levels. Similarly, once the
tree is built, storage and distribution can obviously be done via sharding.

In short, no matter how much the transaction rate on a PoP ledger grows, it's
possible to meet demand by simply buying more hardware, and distributing the
key space over a larger number of smaller shards.

But that simple architecture only works with trust: the coordinator is trusting
the shards to build valid trees and distribute the results. Without trust, how
do you ensure that actually happens? How do you pick who is assigned to what
shard? How do you incentivise correct behavior?

That's not to say this is impossible - in fact my prior work on Treechains(1)
is an attempt to do just this - but it's an orders of magnitude more difficult
problem.

1) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-March/004797.html,
   "[Bitcoin-development] Tree-chains preliminary summary", Mar 25th 2014,
   Peter Todd

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org