From: Peter Todd <pete@petertodd•org>
To: Pulat Yunusov <pulat@yunusov•org>
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
Date: Mon, 11 Dec 2017 18:16:19 -0500 [thread overview]
Message-ID: <20171211231619.GA22761@savin.petertodd.org> (raw)
In-Reply-To: <CAC08FKvbbOsYWLieS+kgsdZByFiFXuQbBs1trvHuDAdG35HXkA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
prev parent reply other threads:[~2017-12-11 23:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-05 10:15 Peter Todd
2017-12-11 22:23 ` Pulat Yunusov
2017-12-11 23:16 ` Peter Todd [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171211231619.GA22761@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pulat@yunusov$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox