From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F0934CAA for ; Mon, 11 Dec 2017 23:16:25 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149080.authsmtp.com (outmail149080.authsmtp.com [62.13.149.80]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3732D17E for ; Mon, 11 Dec 2017 23:16:24 +0000 (UTC) Received: from mail-c245.authsmtp.com (mail-c245.authsmtp.com [62.13.128.245]) by punt24.authsmtp.com. (8.15.2/8.15.2) with ESMTP id vBBNGNV1002773; Mon, 11 Dec 2017 23:16:23 GMT (envelope-from pete@petertodd.org) Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id vBBNGLD5091070 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Dec 2017 23:16:22 GMT (envelope-from pete@petertodd.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 94D2F40188; Mon, 11 Dec 2017 23:16:20 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id F41F820304; Mon, 11 Dec 2017 18:16:19 -0500 (EST) Date: Mon, 11 Dec 2017 18:16:19 -0500 From: Peter Todd To: Pulat Yunusov Message-ID: <20171211231619.GA22761@savin.petertodd.org> References: <20171205101551.GA10265@fedora-23-dvm> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: 4d634ac1-dec9-11e7-9f3b-9cb654bb2504 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwMUHFAXAgsB AmEbWVdeUVt7W2E7 bghPaBtcak9QXgdq T0pMXVMcUncaf2t9 chseWxhycAUIf3t5 bQhmCnZYWBUpdFsp Fx1dCGwHMGB9YTYc Al1RJFFSdQcYLB1A alQxNiYHcQ5VPz4z GA41ejw8IwAXEy9c RggHKV9aeksOH3sA XQ0ZATEiBlZNbj4o IgBuFkQVGl0fP196 L1ooOxojMhkdDgAb IlpARRRULl0aDyMt AUtiR0kZHnhaT2Jk HxcsIxRBHj1VXEIA X-Authentic-SMTP: 61633532353630.1039:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 52.5.185.120/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Scalable Semi-Trustless Asset Transfer via Single-Use-Seals and Proof-of-Publication X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 23:16:26 -0000 --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--