From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WRreF-0001CS-Lu for bitcoin-development@lists.sourceforge.net; Sun, 23 Mar 2014 23:17:47 +0000 X-ACL-Warn: Received: from nl.grid.coop ([50.7.166.116]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WRreD-0002cL-5H for bitcoin-development@lists.sourceforge.net; Sun, 23 Mar 2014 23:17:47 +0000 Received: from localhost (localhost [127.0.0.1]) (uid 1000) by nl.grid.coop with local; Sun, 23 Mar 2014 18:17:37 -0500 id 000000000006A343.00000000532F6B91.0000132B Date: Sun, 23 Mar 2014 18:17:37 -0500 From: Troy Benjegerdes To: Jorge =?iso-8859-1?Q?Tim=F3n?= Message-ID: <20140323231737.GM3180@nl.grid.coop> References: <20140322084702.GA13436@savin> <20140322193435.GC6047@savin> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1WRreD-0002cL-5H Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 23:17:47 -0000 > > 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' hozer@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