Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.176 as permitted sender)
	client-ip=209.85.213.176; envelope-from=gacrux@gmail.com;
	helo=mail-ig0-f176.google.com; 
MIME-Version: 1.0
In-Reply-To: <20141215045236.GB23859@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>
	<548C3FE6.9090508@gmail.com>
	<20141215045236.GB23859@savin.petertodd.org>
Date: Wed, 17 Dec 2014 22:55:28 +1100
Message-ID: <CALohRkgbHvLCwAY0+2zpd-LwRxnntzcpPuUjU4zDEz=oODaK1w@mail.gmail.com>
From: Gareth Williams <gacrux@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Bitcoin-development] Setting the record straight on
	Proof-of-Publication
Precedence: list

On Mon, Dec 15, 2014 at 3:52 PM, Peter Todd <pete@petertodd.org> wrote:
>> 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.)
>
> I covered this in my original post: 1-way-pegs allow the creation of new
> valuable tokens without those tokens being useful for speculation.

I stand corrected. A permanent 1-way-peg is sufficient to preserve
scarcity; "nothing else can do that" WRT 2-way-pegs was overreaching.

I still don't see what "2-way-peg vs. 1-way-peg" has to do with
"embedded consensus vs. blockchain consensus" though, and feel it
disingenious to conflate them.

Blockchain consensus (eg. sidechains) can utilise either mechanism,
1-way-peg or 2-way-peg. Arguments in favour of 1-way-peg are
interesting, but they're ultimatley just arguments in favour of one
type of sidechain over another.

Arguments in favour of embedded consensus - and I feel I'm being
generous with the term "consensus" here - should surely stand on their
own merit against blockchain consensus, if they're to be convincing.

> Of course even without 1-way-pegs there's a much more important issue
> with your objection: worrying about creating new artificial scarcity
> races while innovating is fundementally a *moralistic* and *regulatory*
> concern that has no little if any bearing on whether or not the systems
> created are useful and secure. It's also an objection that raises
> serious questions about conflicts of interest between giving accurate
> and honest technical advice and promoting ways of using Bitcoin that
> will drive the price up.

IMO the question of whether scarcity can be preserved while enabling
innovation bears heavily on the liklihood of longterm viability of
said innovations - and perhaps of Bitcoin itself.

FWIW I'll happily declare that I hold a modest amount of BTC and have
an interest in the price appreciating. I'm sure you'll admit you're
hardly an impartial party in this discussion yourself Peter :) But it
really shouldn't matter. I'm not here today to make it, but I think
the argument for preservation of scarcity stands quite well on its own
merits - as rightly it should, regardless of anybody's interests.

> A number of mechanisms for detecting divergence are possible in embedded
> consensus systems, some of them even natural outcomes. For instance
> transactions can contain a hash of the previous consensus state, thereby
> creating an indicator of consensus measured in terms of economic stake.
> Extending that idea many anti-censorship proposals are to use such state
> hashes as encryption keys - if you are out of consensus you won't even
> see the transaction. (and you can't be double-spent either if
> implemented correctly; see my other reply to this thread today)

<snip>

> Indeed I did, which is why I worked out a better way to do upgrades
> almost a year ago:
>
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06578.html

<snip>

> The quality of Counterparty's software engineering has no bearing on
> whether or not the underlying idea is a good one; you wouldn't say ring
> signatures are an inherently bad idea just because the CryptoNote
> implementation of them is atrocious.

Very interesting. I admit I hadn't come across these ideas before; I
really must search the archive before posting :) They certainly offer
a measure of robustness over the naive approach. I'm not sure they
address my primary concerns however, WRT how consensus is demonstrated
and incentivised.

I know what my own node considers valid transaction history; how can I
be confident that everyone else takes the same view? For contrast,
with blockchain consensus, I can be confident that there is consensus
on the longest chain observed. If I receive a new transaction, simply
waiting for it to be buried under N blocks of PoW provides a high
level of confidence that everyone else considers it valid.

The obvious "embedded consensus" answer of "wait until N other
transactions have occurred that include a hash of system state that
includes your transaction" doesn't provide me with any confidence; it
could be simulated with a Sybil attack.

<snip>

> I prefer to make robust arguments; if I can start with accepting that
> 95% of what my opponents say is true, yet still end up being correct,
> all the better!

Indeed :) To avoid wasting time it's only ever worth arguing against
the strongest opposing position you're aware of (whether your opponent
is aware of it or not.)

https://en.wikipedia.org/wiki/Principle_of_charity