Date: Mon, 11 Dec 2017 18:16:19 -0500
From: Peter Todd <pete@petertodd.org>
To: Pulat Yunusov <pulat@yunusov.org>
Message-ID: <20171211231619.GA22761@savin.petertodd.org>
References: <20171205101551.GA10265@fedora-23-dvm>
	<CAC08FKvbbOsYWLieS+kgsdZByFiFXuQbBs1trvHuDAdG35HXkA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU"
Content-Disposition: inline
In-Reply-To: <CAC08FKvbbOsYWLieS+kgsdZByFiFXuQbBs1trvHuDAdG35HXkA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Scalable Semi-Trustless Asset Transfer via
 Single-Use-Seals and Proof-of-Publication
Precedence: list


--EeQfGwPcQSOJBaQU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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-publica=
tion
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 e=
ach
range to a separate server (be it an actual server, or a fault-tolerate clu=
ster
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 trus=
ting
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 diffic=
ult
problem.

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

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

--EeQfGwPcQSOJBaQU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJaLxG/AAoJECSBQD2l8JH7dG8IAIluw6HgzM595sOCX2JFt7Za
W9Lfa1bzEjdwfNyrlz3j6f75gUudNAUJlkP1eVSJXSNcJQUtgsNwBKSvRWGHl4LX
irmHxkurpcK9EPZOc8ptWAiTT4hCU7IULaAda2I7HqGsv5bOo/opcpezBqCrhcok
eGBhEd+DfG7CRaBGO0/w5gGqTOK8dti0SFY7NeVcjdo+ihDaO7MB5QHf2DMUIgrv
95U88Szxg90ziaVJuf2A+Ik+ZgWxZN26EB3vD717vtylAfLRm9YritImTpbpX+ky
Z+Q76uuYxKOlWSHTQJg0oLKVsWGjRTkrjqK2Krzn+hB8C0DiBx21/XgYBk7B3uc=
=QF6b
-----END PGP SIGNATURE-----

--EeQfGwPcQSOJBaQU--