> > 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' ho...@hozed.org
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
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
