Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.180 as permitted sender)
	client-ip=209.85.192.180; envelope-from=gacrux@gmail.com;
	helo=mail-pd0-f180.google.com; 
Message-ID: <548C3FE6.9090508@gmail.com>
Date: Sun, 14 Dec 2014 00:32:22 +1100
From: Gareth Williams <gacrux@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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>
In-Reply-To: <CAE28kUSZcGrFL3OMf=uOJ2=NQ89M54FOhR_iOXkEubrb6qqVAg@mail.gmail.com>
OpenPGP: id=378E4544
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="URKjGmjk80pF96KUQUBUQGAQ6dx8KE3F3"
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)
--URKjGmjk80pF96KUQUBUQGAQ6dx8KE3F3
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 13/12/14 04:04, Alex Mizrahi wrote:
> Well, client-side validation is mathematically secure, while SPV is
> economically secure.
> I.e. it is secure if you make several assumptions about economics of th=
e
> whole thing.

Comparisons with the SPV security of sidechains are fallacious. The
alternative to a proof-of-publication system reliant on client-side
validation is a blockchain. The question of whether the token used on
said blockchain should be two-way-pegged to BTC is completely orthogonal.=


(ie. yes, sidechains are "economically secure", in that you're reduced
to balancing economic incentives to avoid peg theft. But sidechains also
give us something unique in return - the ability to innovate without
needing to start new artificial scarcity races. Nothing else can do that.=
)

<snip>

> You know, The Great Fork of 2013 was resolved through human
> intervention, Bitcoin nodes were not smart enough to detect that
> something is going awry on their own.

I hate to think what the outcome would've been on a proof-of-publication
system. You don't even have a fork. You just have a whole bunch of nodes
who sort-of-mostly agree on a shared history, except where they don't.
Maybe they just disagree on the validity of a single transaction.
They'll slowly diverge over time (as bad transactions are used as input
to other transactions.) You have no reliable way to detect this lapse in
consensus, nor any mechanism to incentivse convergence. Indeed, you have
no consensus mechanism in the first place.

Bitcoin is where it is today because of Satoshi's elegant solution to
exactly such problems. Which some people now appear to be in a hurry to
discard :)

Alex Mizrahi wrote:
> Using scheduled updates: client simply stops working at a certain block=
,
> and user is required to download an update.

<snip>

> An alternative to this is to make updates mandatory. You will no longer=

> need to maintain compatibility with version 0.1 (which is impossible)
> and you can also evolve consensus rules over time.

Peter Todd might disagree with the wisdom of that :) He wrote an
excellent email to this list not long ago warning of the dangers of
centralisation. IIRC one point he made was that scheduled, regular
hardforks were a real threat - if a single entity (eg. the Bitcoin
Foundation) were to become politically established as the coordinator of
such forks, they would have de-facto control over the protocol.

Even in that dark scenario, I would feel a measure of confidence that
past transactions I had received could not be tampered with. The fact
that those transactions happened, and that there was (and is) consensus
they were valid, is publicly documented in the blockchain. I trust any
reasonable person would not accept a client that ignored validated data
in the blockchain as "Bitcoin" any more.

Your proof-of-publication system with mandatory updates is another
matter entirely. No public record of transactions I have received with
that system exists, anywhere. If tomorrow's mandatory update has the
effect of zeroing my account balance (by happening to now interpret one
or more transactions I received, or their inputs, as invalid) then I
have no recourse. I won't find sympathy with the majority of users, who
are unaffected and just accept the update.

In short, what you describe doesn't sound very decentralised :) Do you
want transactions you receive validated by distributed consensus and
burried under PoW, or validated by some guy's mandatory-updating python
script?

(Also worth noting: all such systems are effectively "mandatory
updating" due to the risk of subtle consensus bugs of the type I
described above. Your only assurance that your view of the world is the
same as everyone elses' is that you're running the exact same software.
I played with Counterparty a while ago and quickly learned - the hard
way - to do a 'git pull' before any important operation.)


--URKjGmjk80pF96KUQUBUQGAQ6dx8KE3F3
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

iQEcBAEBAgAGBQJUjD/mAAoJEEY5w2E3jkVEZXoIAIsSWprMJ5cKt093sSVlxB/+
0SpfEgsx6wGnr7O5c3MY2SG+/KKB3IF8L8v2Truc0e8P2aa8tepB0Yk1f2vbwcY5
mJRfYgDA5fOH4PYX7Khq36PdaAuFjDvtJNTwhxVN5Q5bz3WLlDzd3IEZqSp/7NiP
hhhUa4BuI4Vdz3EpEPbhgCQVd1qXsfxGe6nNwMrZZi/eMQE10StibHKfQOPpxmrf
1T0fc1QfRVMPpU04xTB8f4n9tlxKqSinEvQ/9hRdGDEWyuw0BuHiv9YDeZaogcqO
rGgBIvts8tX06EsXBx2IVkX9FMbGux9t/ncanbVljk4Qdl9aU7E3RMq3qKU9Gwc=
=IKbX
-----END PGP SIGNATURE-----

--URKjGmjk80pF96KUQUBUQGAQ6dx8KE3F3--