From: Gareth Williams <gacrux@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication
Date: Wed, 17 Dec 2014 22:55:28 +1100 [thread overview]
Message-ID: <CALohRkgbHvLCwAY0+2zpd-LwRxnntzcpPuUjU4zDEz=oODaK1w@mail.gmail.com> (raw)
In-Reply-To: <20141215045236.GB23859@savin.petertodd.org>
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
next prev parent reply other threads:[~2014-12-17 11:55 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-12 9:05 Peter Todd
2014-12-12 12:25 ` Gareth Williams
2014-12-12 17:04 ` Alex Mizrahi
[not found] ` <CAOG=w-v3qjG3zd_WhfFU-OGnsHZEuYvY82eL4GqcdgY6np5bvA@mail.gmail.com>
2014-12-12 17:50 ` Alex Mizrahi
2014-12-13 13:32 ` Gareth Williams
2014-12-15 4:52 ` Peter Todd
2014-12-17 11:55 ` Gareth Williams [this message]
2014-12-21 6:12 ` Peter Todd
2014-12-15 4:17 ` Peter Todd
2014-12-12 13:41 ` odinn
2014-12-12 14:17 ` Justus Ranvier
2014-12-15 4:59 ` Peter Todd
2014-12-17 1:16 ` odinn
2014-12-20 14:48 ` [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles Peter Todd
[not found] ` <CAOG=w-vrHPY1aCNndmoW9QyCh9XnWyv8uZn2PyjZ6rNg2MoSSw@mail.gmail.com>
2014-12-21 5:52 ` Peter Todd
[not found] ` <CAOG=w-tZke--6OsqNjJhE9SOdCwdZYZM8iz1VBTFziegt9UZWw@mail.gmail.com>
2014-12-21 7:01 ` Peter Todd
[not found] ` <CAOG=w-s1_VXJAKxBpMOK=B50qnHjxSe4J=vwwSfFPRz0_Cb9rA@mail.gmail.com>
2014-12-21 15:32 ` Peter Todd
2014-12-21 11:25 ` Jorge Timón
2014-12-21 16:07 ` Peter Todd
2014-12-21 19:39 ` Jorge Timón
2014-12-21 10:01 ` Adam Back
2014-12-21 15:29 ` Peter Todd
2014-12-21 13:49 ` paul snow
2014-12-21 15:22 ` Peter Todd
2014-12-21 15:41 ` paul snow
2014-12-22 0:11 ` Peter Todd
2015-01-06 11:03 ` joliver
2014-12-22 20:05 ` Adam Back
2014-12-16 20:28 [Bitcoin-development] Setting the record straight on Proof-of-Publication paul snow
2014-12-17 22:20 paul snow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALohRkgbHvLCwAY0+2zpd-LwRxnntzcpPuUjU4zDEz=oODaK1w@mail.gmail.com' \
--to=gacrux@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox