Subject: Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee

From: Troy Benjegerdes <[email-masked]>
Date: Sun, 23 Mar 2014 18:17:37 -0500

> > Right, but there's also a lot of the community who thinks
> > proof-of-publication applications are bad and should be discouraged. I
> > argued before that the way OP_RETURN was being deployed didn't actually
> > give any reason to use it vs. other data encoding methods.
> >
> > Unfortunately underlying all this is a real ignorance about how Bitcoin
> > actually works and what proof-of-publication actually is:
> 
> I understand that proof of publication is not the same thing as
> regular timestamping, but requiring permanent storage in the
> blockchain is not the only way you can implement proof of publication.
> Mark Friedenbach proposes this:
> 
> Store hashes, or a hash root, and soft-fork that blocks are only
> accepted if (a) the data tree is provided, or (b) sufficient work is
> built on it and/or sufficient time has passed
> 
> This way full nodes can ignore the published data until is sufficiently buried.
> 
> > I think we're just going to have to agree to disagree on our
> > interpretations of the economics with regard to attacking merge-mined
> > chains. Myself, I'm very, very wary of systems that have poor security
> > against economically irrational attackers regardless of how good the
> > security is, in theory, against economically rational ones.
> 
> The attacker was of course economically irrational in my previous
> example for which you didn't have any complain. So I think we can
> agree that a merged mined separated chain is more secure than a
> non-merged mined separated chain and that attacking a merged mined
> chain is not free.
> By not being clear on this you're indirectly promoting non-merged
> mined altchains as a better option than merged mined altchains, which
> is what I don't think is responsible on your part.
> 

I can't speak for Peter, but *I* am currently of the opinion that non-merged
mined altchains using memory-hard proof-of-work are a far better option than
sha-256 merged-mined altchains. This is not a popular position on this list,
and I would like to respectfully disagree, but still collaborate on all the
other things where bitcoin-core *is* the best-in-class code available.

A truly 'distributed' system must support multiple alchains, and multiple 
proof-of-work hash algorithms, and probably support proof-of-stake as well.

If sha-256 is the only game in town the only advantage over the federal
reserve is I can at least audit the code that controls the money supply,
but it's not in any way distributed if the hash power is concentrated
among 5-10 major pools and 5-10 sha-256 asic vendors.

I find it very irresponsible for Bitcoiners to on one hand extol the virtues
of distributed systems and then in the same message claim any discussion
about alternate chains as 'off-topic'.

If bitcoin-core is for *distributed systems*, then all the different altcoins
with different hash algorithms should be viable topics for discussion.

----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  [email-masked]
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash