From: Peter Todd <pete@petertodd•org>
To: Alex Mizrahi <alex.mizrahi@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>,
Mark Friedenbach <mark@friedenbach•org>
Subject: Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication
Date: Sun, 14 Dec 2014 23:17:14 -0500 [thread overview]
Message-ID: <20141215041714.GA23859@savin.petertodd.org> (raw)
In-Reply-To: <CAE28kUSZcGrFL3OMf=uOJ2=NQ89M54FOhR_iOXkEubrb6qqVAg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3130 bytes --]
On Fri, Dec 12, 2014 at 07:50:48PM +0200, Alex Mizrahi wrote:
> > I think what Gareth was getting at was that with client-side validation
> > there can be no concept of a soft-fork. And how certain are you that the
> > consensus rules will never change?
> >
>
> Yes, it is true that you can't do a soft-fork, but you can do a hard-fork.
> Using scheduled updates: client simply stops working at a certain block,
> and user is required to download an update.
You're quite mistaken actually. One of the first things to come out of
my research as Mastercoin's Chief Scientist - indeed after a week on the
job - was how to safely upgrade embedded consensus systems in a
decentralized fashion:
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03890.html
To recap, where valuable scarce tokens are concerned we want to ensure
that an attacker can't use a fork caused by an upgrade to double-spend
tokens. We solve this problem by ensuring that when a token visible to
version V_i is spent in a V_{i+1} client, the token appears spent to
version V_i clients as well. This is easy to accomplish by a "split
transaction" scheme that separates all operations into separate
"increment" and "decrement" operations.
The simplest example of this principle in action is colored coins, which
are certainly an example of an embedded consensus system. Colored coin
implementations naturally ensure that all versions of the system see a
token getting spent the same way - the corresponding txout is spent! So
long as changes to the coloring rules are handled such that only one set
of rules - one version - can apply to a given txout spend we get
anti-doublespend protection.
The second aspect of the problem is the social/political implications of
upgrades - because embedded consensus systems don't outsource trust they
very clearly require the co-operation of the economic majority in an
upgrade. For instance if the community has two competing proposals for
how to upgrade version V1 of Counterparty, V2a and V2b, choosing to move
your tokens to either version becomes a vote with serious economic
consequences. In fact, it's quite possible that a community would choose
to simply fork into two different systems each offering a different set
of features. Equally in the event of such a fork someone can create a
third version, V3, that recombines the two incompatible forks. Again,
anyone who agrees with version V3 can choose to move their tokens to it,
healing the fork.
Arguably this process of handling forks by direct economic voting is
significantly *more* decentralized than Bitcoin's soft-fork mechanism as
adoption of a new version is something all participants in the system
play a part in equally. (as measured by economic stake) Of course, it
will lead to sometimes ugly political battles, but that's simply part of
the cost of having democratic systems.
> It looks like people make a cargo cult out of Bitcoin's emergent
> properties.
+1
--
'peter'[:-1]@petertodd.org
00000000000000000681f4e5c84bc0bf7e6c5db8673eef225da652fbb785a0de
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2014-12-15 4:17 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-12 9:05 Peter Todd
2014-12-12 12:25 ` Gareth Williams
2014-12-12 17:04 ` Alex Mizrahi
[not found] ` <CAOG=w-v3qjG3zd_WhfFU-OGnsHZEuYvY82eL4GqcdgY6np5bvA@mail.gmail.com>
2014-12-12 17:50 ` Alex Mizrahi
2014-12-13 13:32 ` Gareth Williams
2014-12-15 4:52 ` Peter Todd
2014-12-17 11:55 ` Gareth Williams
2014-12-21 6:12 ` Peter Todd
2014-12-15 4:17 ` Peter Todd [this message]
2014-12-12 13:41 ` odinn
2014-12-12 14:17 ` Justus Ranvier
2014-12-15 4:59 ` Peter Todd
2014-12-17 1:16 ` odinn
2014-12-20 14:48 ` [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles Peter Todd
[not found] ` <CAOG=w-vrHPY1aCNndmoW9QyCh9XnWyv8uZn2PyjZ6rNg2MoSSw@mail.gmail.com>
2014-12-21 5:52 ` Peter Todd
[not found] ` <CAOG=w-tZke--6OsqNjJhE9SOdCwdZYZM8iz1VBTFziegt9UZWw@mail.gmail.com>
2014-12-21 7:01 ` Peter Todd
[not found] ` <CAOG=w-s1_VXJAKxBpMOK=B50qnHjxSe4J=vwwSfFPRz0_Cb9rA@mail.gmail.com>
2014-12-21 15:32 ` Peter Todd
2014-12-21 11:25 ` Jorge Timón
2014-12-21 16:07 ` Peter Todd
2014-12-21 19:39 ` Jorge Timón
2014-12-21 10:01 ` Adam Back
2014-12-21 15:29 ` Peter Todd
2014-12-21 13:49 ` paul snow
2014-12-21 15:22 ` Peter Todd
2014-12-21 15:41 ` paul snow
2014-12-22 0:11 ` Peter Todd
2015-01-06 11:03 ` joliver
2014-12-22 20:05 ` Adam Back
2014-12-16 20:28 [Bitcoin-development] Setting the record straight on Proof-of-Publication paul snow
2014-12-17 22:20 paul snow
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=20141215041714.GA23859@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=alex.mizrahi@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mark@friedenbach$(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