From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WTCwW-0007FI-R2 for bitcoin-development@lists.sourceforge.net; Thu, 27 Mar 2014 16:14:12 +0000 Received: from mail-la0-f50.google.com ([209.85.215.50]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WTCwV-0001qG-3r for bitcoin-development@lists.sourceforge.net; Thu, 27 Mar 2014 16:14:12 +0000 Received: by mail-la0-f50.google.com with SMTP id y1so2747847lam.23 for ; Thu, 27 Mar 2014 09:14:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8OxOK0pftGyCmmZ7lsnCsTaCH43G3SJKnqXsFjtgZRc=; b=IxCKmGEvroa1I0eHhjHSSL/70POAmjd7kf7IpIx/fL9QnPm0hne4SjX617+K7F3Dx1 2isBGUuWkyISggpth+O/AAnVQU1jVNpKCR5fLV/50/WLEb2HN2DKG9HQDMUTNb44xrDq zDZpYAkM3fh6IhST9OYbHSwhqqcKUbPeLmxB6/EgEUmZ8P/AqjB13IWnDI651bdPOPgv /Ek/Rkd/8rqTboNYhXjUUTrRlS9uNJGTVN0f0KPa+bcCnQUWwvRwsDzPgEl4HT2sLLZ6 6mj5MFRs2lFHPkSogwdb6aMXkJUcwnaReWXIjj6dikXXxQp4YmSPJhiOspi9Ur3FmZAa 6bYA== X-Gm-Message-State: ALoCoQkEPIRr/nrRsUzr6iM7VJXOhNKE1KyR0By7Gc/MOdwoerubrFXWWBJWpqVbyJF5evnx2jVJ MIME-Version: 1.0 X-Received: by 10.152.5.73 with SMTP id q9mr22059laq.69.1395936844345; Thu, 27 Mar 2014 09:14:04 -0700 (PDT) Received: by 10.112.60.196 with HTTP; Thu, 27 Mar 2014 09:14:04 -0700 (PDT) X-Originating-IP: [85.59.165.247] In-Reply-To: References: <20140322084702.GA13436@savin> <20140322150836.GG3180@nl.grid.coop> <20140322190825.GB6047@savin> <532DE7E6.4050304@monetize.io> <20140325122851.GA9818@savin> <5331EF3D.4000504@monetize.io> Date: Thu, 27 Mar 2014 17:14:04 +0100 Message-ID: From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= To: Peter Todd Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1WTCwV-0001qG-3r Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Tree-chains preliminary summary 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: Thu, 27 Mar 2014 16:14:13 -0000 I'll make sure I understand your proposal better before commenting much on it, but at a first glance, I don't see how it is incompatible with 2 way peg and merged mining itself. Why wouldn't you want merged mining for the root of your tree? A miner could only chose a leaf block at a time, but it could merged mine with other leafs in other independent trees. Anyway, I'll better comment on the 2 way peg and merged mining issues raised so far. On 3/25/14, Gregory Maxwell wrote: > On Tue, Mar 25, 2014 at 2:03 PM, Mark Friedenbach wrote: >> More importantly, to your last point there is absolutely no way this >> scheme can lead to inflation. The worst that could happen is theft of >> coins willingly put into the pegging pool. But in no way is it possible >> to inflate the coin supply. > > I don't think it would be entirely unfair to describe one of the > possible ways a secondary coin becoming unbacked can play out as > inflation-- after all, people have described altcoins as inflation. In > the worst case its no _worse_ inflation, I think, than an altcoin is-- > however. I think that's an obscure corner case that is not likely going to ever be implemented. If you produce real inflation there will likely be a "bank run". If you're going to implement something equivalent to demurrage you should call it demurrage instead of inflation. And that's only for the pegged coin in the side chain: BITCOINS IN THE MAIN CHAIN WILL NEVER BE INFLATED USING 2P2. So I think it's less confusing if we just say that 2-way peg can't produce inflation in general, and leave "unless you explicitly introduce an inflation mechanism" as a probably unnecessary clarification. > I see your point, but gmaxwell accurately guesses below that when I'm > talking about inflation, I'm including the inflation of the alt too. You don't need inflation on the side chain. You don't need to create another currency to create another chain with different and maybe experimental features, that's the whole point. With merged mining, you're adding up the different created seigniorage subsidies to the same fire to share the heat. With 2-way peg, you don't even need to create a new p2p currency with a seigniorage to burn on hashes or be accused of "pre-mining" as the more ecological alternative in existence. Your chain can secure itself on fees, just like bitcoin in the future. Merged mining will help, but it's not the panacea and you will need to reward miners because that's what your security ultimately depends on. This is mostly about not burning the world, it may not be as interesting to you as improving bitcoin's scalability but you're not doing anyone a favor by presenting both concepts as being incompatible, not even yourself. > With tree-chains that's particularly obvious as the scheme doesn't try > to privilege one chain over another beyond parent-child relationships. If I understand it correctly, all the utxo nodes in the tree implement the same rules so doesn't seem suitable to solve the same problems. I understand that merged mining IS NOT a solution to scalability on its own, having 10 independent 1MB blocks is no worse than 1 10MB block in terms of performance vs centralization. But maybe it's possible to have a 10 GB sharded side-chain (your proposal) that it's merged mined with the main chain and where the currency of the side-chain comes from. So merged mining could help solve the scalability problem indirectly. And 2-way peg could be a useful previous step for your proposal to be deployed "on production", with real bitcoins without forcing all bitcoin users to take the associated risks, only the people who opt in. > Incidentally, I understand that the pegged chains are meant to be > merge-mined. 2 way peg doesn't require merged mining but it is assumed that merged mining will be used since it provides more security than independent mining. I thought you agreed with this and your claim was just that merged mining is less secure than "embedded consensus", something I have never denied, my complain against "embedded consensus" is that it doesn't seem to scale (with Bitcoin as it is today) and can't offer many features that a hardfork merged mined chain could offer (like those explained on our freimarkets proposal). But since you're implying again that "merged mining is superior to independent mining" is generally false, I invite you again to dismantle my example http://sourceforge.net/p/bitcoin/mailman/message/31806950/ or to prove your hypothesis that "is free to attack merged mining chains" by attacking namecoin for free. Either one will serve, my you're not responding to any of the suggestions. Instead, you're saying that "people defending merged mining assume that attackers are economically rational". I think you're referring to me and it's false. Of course the attacker doesn't need to be economically rational. For some unknown reason he's attacking a chain, without questioning the rationality of the attack, I just sum costs, including opportunity costs, because costs are all what proof of work security is about. Please, do one of the two before continuing your merged mining defamation campaign. > merge-mined. To me this seems problematic and cheap to attack. Consider > a merge-mined zerocoin sidechain: Can you profit from depositing some > coins, taking them out again, then reorging the zerocoin chain to undo > that withdrawl on the zerocoin side, and performing it all over again? That's what the quieting periods are for. After the widrawal, the coins are blocked until they reach maturity or someone else provides a reorg proof invalidating the withdrawal. > It'd be easy to drain the pegging pool that way, and with merge-mining > there's no inherent cost to you to do so. Not unique to zerocoin either > of course, just in that case who actually double-spent is unknowable. We could talk about this in the 2-way peg thread, but anyway... Let's say 80% of bitcoin miners also mine Zerocoin. Let's say zerocoin's reward ZR is 1% of Bitcoin's Reward BR Let's say "megahash" hashes 40% of Bitcoin's mining and is our attacker. Previously megahash rented its hardware for 0.41 BR for each GHash/s, because that was the market price at the time. Now it will mine bitcoin and attack zerocoin, so it will recover 0.4 BR, leaving the costs of the attack at 0.01 BR per GHash/s (assuming it doesn't rent additional hardware, which could also do). Since it controls 40% of Bitcoins hashing, it controls approximately 50% of zerocoin hashing. So megahash tries to withdraw AR coins (attack reward) and then double spend. >From block N in zerocoin (ZN), it starts building an alternative chain that doesn't reveal with the double spend. After X blocks, he publishes a withdraw on zerocoin. To collect coins from the pegged pool on bitcoin's chain, he provides a proof that a chain including the withdraw with length at least X + ZM (maturity in zerocoin) To access those funds, he will have to wait BM (Bitcoin maturity) blocks in main chain during which anyone can recover the funds to the pegged pool in exchange of a fee that megahash has to provide itself, by providing a chain with the same root, more work and in which the committed utxo doesn't include the withdrawal transaction. So with merged mining, megahash has been spending 0.01 BR per GHash/s from block ZN to block ZN + X + ZM and the attack will still likely fail unless it is willing to also censor all reorg proofs in the main chain, otherwise it will has to start again when such a proof appears. Without merged mining and maintaining the rewards, the numbers would be practically the same, with the difference that the attacker could sacrifice its bitcoin income (there's no reason to do it with merged mining) to attack the independent chain more brutally (40% of bitcoin would be 4000% of the independent chain instead of 50% like in the example). Anyway the particular situation in which a single entity controls 40% of the hashing power should be rare. That's potentially dangerous for bitcoin and although changing the hashing algorithm would be painful and risky, I would be terribly scared of that happening if I was that entity. Letting my percentage of hash rate dilute as others grow would definitely be part of my plan. Although this is again completely orthogonal to the merged mining or not discussion, hashing algorithms are often mixed in the discussions against merged mining. If you had to introduce that hashing algorithm hardfork change you will probably chose something with similar properties than those of SHA256, like being easy to implement specialized hardware for it. You could even chose a memory-hard algorithm if you want to promote ASIC production centralization, but you can't chose an "anti-ASIC" algorithm because those don't exist. It is well known that any information machine that can be built with software can also be built with specialized hardware and viceversa. Sadly that kind of fallacy is often used to justify the ecological crime that starting a new chain with no plans of doing merged mining represents. But as said this is orthogonal to sharded chains, 2 way peg and merged mining, which are also only indirectly related with each other. > Well I'll certainly raid 2-way pegging for ideas. :) I think the big > difference between the two is how I'd like to see tree-chains reduce > dependence on miner validation - ideally miners wouldn't validate at all > if the efficiency can be regained with ZK-SNARKS or something. Dropping > validation from mining could also avoid the problem of how in Bitcoin > there is no explicit mechanism that actually forces miners to validate > the chain. Not unlike gmaxwell's "firedrill" ideas, you would be able to > "firedrill" clients at any point by just mining some invalid garage. Yes, snarks could do wonders. For 2-way peg too, SPV proofs could become full proofs and headers compression could probably improve a lot as well. But let's find out everything that can be done without snarks first. > (not to say miners would certainly not do validation - you still want to > be able to pay them transaction fees, but in that case they're doing the > validation only for themselves) Mhmm, if miners don't validate, they risk to mine on top of invalid blocks. Are you saying they don't care about that?