path: root/5a/03164f9e9b668ba749501f56efe9e7ceefa631

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 <jtimon@monetize.io>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CAAS2fgTovm7OtFFqdRYWDw5KxV+r5WD598JPnG5ydMYAs_gQWg@mail.gmail.com>
References: <20140322084702.GA13436@savin> <20140322150836.GG3180@nl.grid.coop>
	<20140322190825.GB6047@savin> <532DE7E6.4050304@monetize.io>
	<20140325122851.GA9818@savin> <5331EF3D.4000504@monetize.io>
	<CAAS2fgTovm7OtFFqdRYWDw5KxV+r5WD598JPnG5ydMYAs_gQWg@mail.gmail.com>
Date: Thu, 27 Mar 2014 17:14:04 +0100
Message-ID: <CAC1+kJMkiVLEnHKibWbaCdtEwCE30M4SPM96H6Nq7kZey-_4eg@mail.gmail.com>
From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@monetize.io>
To: Peter Todd <pete@petertodd.org>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <gmaxwell@gmail.com> wrote:
> On Tue, Mar 25, 2014 at 2:03 PM, Mark Friedenbach <mark@monetize.io> 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?