Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.106 as permitted sender)
	client-ip=62.13.148.106; envelope-from=pete@petertodd.org;
	helo=outmail148106.authsmtp.co.uk; 
Date: Sun, 14 Dec 2014 23:17:14 -0500
From: Peter Todd <pete@petertodd.org>
To: Alex Mizrahi <alex.mizrahi@gmail.com>
Message-ID: <20141215041714.GA23859@savin.petertodd.org>
References: <20141212090551.GA8259@muck> <548ADED1.6060300@gmail.com>
	<CAE28kUR-PLzMGC23ETesc2Bz1_F1JfgcqyMW4qFvV5Vjk+ubbg@mail.gmail.com>
	<CAOG=w-v3qjG3zd_WhfFU-OGnsHZEuYvY82eL4GqcdgY6np5bvA@mail.gmail.com>
	<CAE28kUSZcGrFL3OMf=uOJ2=NQ89M54FOhR_iOXkEubrb6qqVAg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo"
Content-Disposition: inline
In-Reply-To: <CAE28kUSZcGrFL3OMf=uOJ2=NQ89M54FOhR_iOXkEubrb6qqVAg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
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
Precedence: list


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

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?
> >
>=20
> 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/msg03=
890.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

--=20
'peter'[:-1]@petertodd.org
00000000000000000681f4e5c84bc0bf7e6c5db8673eef225da652fbb785a0de

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

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

iQGrBAEBCACVBQJUjmDDXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwNjgxZjRlNWM4NGJjMGJmN2U2YzVkYjg2NzNlZWYyMjVk
YTY1MmZiYjc4NWEwZGUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuOIAf9GqXAeWQaVe3KMDJUMFIvRaQg
MoDiBJjyameAT9LCm1x21KQrTmD+bOpO7inBpEN8cuUNL0t7Q1mlAIcKbEipe70Q
0EKjxIZnVyvfClLOVlQC/APn2iJbvvqJyfYxff72t1jYWWWREWWbcdq1fcQGrr0K
DlL1FlEudVKlqGTESiZQ8G8DIkTDs8hTbq0QBL0xuJl8QKT3TDXro27G1UDvrl19
hWY/mGnkv9RbVcN0xYlK/ZbAYWeewuW/HQYucVA0xiDO2j4loEuah4gLHl6BQFlD
02hdewGftjsJhOi9eHYHOqUnTeWZdo8EyyVglil9LwdXan4ekdDlZVhHo0c/1Q==
=ZXeF
-----END PGP SIGNATURE-----

--envbJBWh7q8WU6mo--