Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.54 as permitted sender)
	client-ip=209.85.220.54; envelope-from=gacrux@gmail.com;
	helo=mail-pa0-f54.google.com; 
Message-ID: <548ADED1.6060300@gmail.com>
Date: Fri, 12 Dec 2014 23:25:53 +1100
From: Gareth Williams <gacrux@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <20141212090551.GA8259@muck>
In-Reply-To: <20141212090551.GA8259@muck>
OpenPGP: id=378E4544
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="0FjtPjXblO8RTPjs0CNDqmg1NP03Badpt"
Subject: Re: [Bitcoin-development] Setting the record straight on
	Proof-of-Publication
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--0FjtPjXblO8RTPjs0CNDqmg1NP03Badpt
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 12/12/14 20:05, Peter Todd wrote:
> Secondly using a limited-supply token in a proof-of-publicaton system i=
s
> what lets you have secure client side validation rather than the
> alternative of 2-way-pegging that requires users to trust miners not to=

> steal the pegged funds.=20

"Secure" and "client side validation" don't really belong in the same
sentence, do they?

If I am to accept a transaction with any assurance of security at all,
the important question to ask is not: "does my client consider this
valid?" but: "does the rest of the world consider this valid?"

Validated data in the blockchain is far more useful for this purpose
than unvalidated data with a mere proof of publication in the
blockchain, precisely because it records what /everybody else/ considers
valid history (and very likely will continue to consider valid history
in future.)

Pegged sidechains have their challenges, but at least they provide
distributed consensus on transaction history.

Proof-of-publication systems like Counterparty and Mastercoin require me
to trust, with zero evidence, that everybody else's client has the exact
same interpretation of transaction history as mine, and will continue to
have for the indefinite future. How is that not a horribly broken
security model? I'd use a sidechain - with reasonable parameters that
disincentivise peg theft as much as practical - over that any day.


--0FjtPjXblO8RTPjs0CNDqmg1NP03Badpt
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUit7RAAoJEEY5w2E3jkVEXeYIAMCDFUBN5fE/lrHv7k3WOA2C
ommijKVgOrV5LJGUp+d18SM/olbWUdLrULVA+XjPealTs9FKMDoX1suJ6cgcj/6L
+1SbdC5kh4U4MLXluPDyx6hDngsg2KeeahCapO5pK//p3M6ySbh7svXF/fMcf6/i
ku57j6rjQj/MOiKfE51Gqpigv5R+XZdnKzIrXSbOHdEnF92cBT8qTCDh3hWprMUw
A8LacYgg1Gcfu7bCS8PsoOm10IdG4qFK1guXP4oovdayef02lSRCDVjr0MA+1QfD
qL4iRN1xCEsuSI0Ed2AYaPkoF7khFhCAAVL/ksCwO2HUhxcLYHxlKmoWDwbUinc=
=S3TB
-----END PGP SIGNATURE-----

--0FjtPjXblO8RTPjs0CNDqmg1NP03Badpt--