Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

[Gareth Williams <gacrux@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3998 bytes --]

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 the
> 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.)







[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]