path: root/89/17a88360ebb1b1b614e086e36e7d21c5210fcc

Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D66B1938
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 19 Aug 2015 22:28:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f54.google.com (mail-la0-f54.google.com
	[209.85.215.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ABB2D21A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 19 Aug 2015 22:28:09 +0000 (UTC)
Received: by lagz9 with SMTP id z9so11836870lag.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 19 Aug 2015 15:28:08 -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=Bs2kh53lwbAhsO753ke/PuqSOWYqwfr2hRbuckYTnqg=;
	b=Sp0NpML8v+HS5npvQv0A9xoqnesAvhRe1P6JisLxmRe6wm8SZkdFeMMcYlCVe9vY8B
	26rFR1TD15+Mg4UVpYwjVkuHgTnMQ6YyvkOx5klGLQ0etDWlXaHDDbKwKmbXaGGdpEOd
	Vv86H3uvqQ+wn4PZSQDNnd75fMtsdOx3YcWqpGJEAJncJ6nqwBRGxcCeF404eopJ6wnl
	4mN+XJJIimbMo+n1SMwyHd74FAWHU4W/2doB4fkix77WzgWXlyDjdl4a6ZZmT/qSFh7/
	+Cwww34XWirKYu0VzgrMAE607Pl27dyGnT6FBV9OfXjSxxLwoa9FW4H8whButjl05NGU
	o++g==
X-Gm-Message-State: ALoCoQnDsQNOFdOdm0/beyb0kZVXLMeKuQCQTOqdIizIdCd4hzhUd7SEFXgBZmZeRERivK56xdhy
MIME-Version: 1.0
X-Received: by 10.152.42.170 with SMTP id p10mr10823644lal.39.1440023287928;
	Wed, 19 Aug 2015 15:28:07 -0700 (PDT)
Received: by 10.25.15.22 with HTTP; Wed, 19 Aug 2015 15:28:07 -0700 (PDT)
In-Reply-To: <55D4A3BD.2060706@sky-ip.org>
References: <CADWuND3EfO6YO3g4H09_mWhrHC4PX4SZpTTuETiX2PyCxSRCsQ@mail.gmail.com>
	<55D1167B.1060107@gmail.com>
	<CAEX2NSfaPv0g07hfT31voGWX05Z6uaBsZOjhMkOwBr4mdHbPQw@mail.gmail.com>
	<55D124D7.4050209@gmail.com>
	<61AD0CE6-014E-44E2-B9C7-00B35D2E09CC@petertodd.org>
	<CAEX2NSeAgrN877zAVDrk_J+7EVDPagt8u4+HB7hDMVMPwS6Zng@mail.gmail.com>
	<F99FFEE6-6D10-480D-B96D-960B84092C88@gmail.com>
	<CABm2gDoEVmqiOpPcf1wUsNt4pmU=oVawq2-0YwrEjm1W1YBmeg@mail.gmail.com>
	<55D4A3BD.2060706@sky-ip.org>
Date: Thu, 20 Aug 2015 00:28:07 +0200
Message-ID: <CABm2gDo-jgE7ow5eNTp70YwQKNL3OfDMT=uU9H6G09MS_J2k-Q@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: s7r@sky-ip.org
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,
	URIBL_BLACK autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Cameron Garnham via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin XT 0.11A
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Aug 2015 22:28:13 -0000

On Wed, Aug 19, 2015 at 5:41 PM, s7r <s7r@sky-ip.org> wrote:
> Hello Jorge, Eric,
>
> With all this noise on the -dev mail list I had to implement application
> level filters so I can treat with priority posts from certain people,
> you are on that list. While I agree with your arguments, I think it is
> _very_ important to highlight some things. I am neither for the
> blocksize increase neither against it, because plain and simple I don't
> have enough arguments to take some definitive decision on this topic.

I think everyone is in that position (we just don't have enough data
about the proposed sizes) or it's just too optimistic.

> What I am angry about is spreading FUD that a fork could kill Bitcoin
> and what we are experiencing now is somehow terrible.
>
> 1. Bitcoin XT is not necessarily an attack over Bitcoin and will not
> split it into 2 different coins. It is the result of an open source free
> system which lacks centralization. It is just at early stage, it could
> have thousands for forks (or fork attempts) during its life.

Bitcoin XT is just a software fork and nobody seem to have a problem
with that (as repeated in other threads), people are worried about the
way bip101 is going to be attempted to be deployed using Bitcoin XT.
We already have more than 5000 software forks and that's totally fine.

A Schism fork may not kill Bitcoin but it will certainly create 2
different coins.
The claim that "there will be a winner and everybody will just move
there" is incredibly naive and uninformative.
Many people will sell their xtbtc and reject the hardfork
independently of its support by miners.
Nobody knows what the result will be, but both currencies' prices
dropping near zero is certainly a possibility that Gavin and Mike are
not aware about or are not informing their followers about.
Here's something a little bit longer about this topic:
https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR137
Note the last part:

"
+This is very disruptive and hopefully will never be needed. But if
+it's needed the best deployment path is just to activate the rule
+changes after certain block height in the future. On the other hand,
+it is healthy decentralization-wise that many independent software
+projects are ready to deploy a schism hardfork.
"

> 2. We have no proof that Mike Hearn and Gavin Andresen are trying to do
> something bad to Bitcoin. So far everything they have done is (or should
> be) allowed. They have forked an open source software and implemented a
> voting system for a consensus rule change - doesn't sound like they are
> committing a crime here (either legally or morally). If they are
> qualified enough to maintain the software, or if the decision is
> technically correct or not is another story, and it should only matter
> to whoever uses / wants to use -XT.

Again, no problem with the code fork, but the Schism hardfork is very
risky regardless of their intentions.

> 3. If Bitcoin's value can be decreased (or Bitcoin as a project killed)
> just by 2 people forking the software and submitting a consensus rule to
> a vote, it means Bitcoin is dead already and it should be worthless! We
> can't go around and panic every time somebody forks Bitcoin and tries to
> change something - this should be allowed by the nature of its license.
> If tomorrow 5 more people fork 5 different software implementing the
> bitcoin protocol and submit 5 different new consensus rules to a vote,
> then what? We should all sell so the price will drop to 1 cent, because
> it is somehow not good enough, not stable enough?

If they don't extensively lobby Bitcoin companies, they don't start a
massive PR campaign labbeling other developers as "obstructionists"
and don't misinform a big part of the Bitcoin users (often using
logical fallacies, intentionally or not), probably those 5 new
currencies will be ignored and nothing bad will happen.
Unfortunately in this case a great division between users is being created.

> I can fork tomorrow Bitcoin Core to a Bitcoin-XYZ software which at some
> block in the future spends all the longest dusted coins to me, out of
> which I give away 50% to the miners (so the hashing power will have
> incentive to use my fork).
>
> Can they do it? YES
> Will they do it? NO
> Should the world care about this? NO
>
> It's as simple as that. We cannot continue to panic that "Bitcoin as a
> project" is at threat because somebody forked it.

Can you please stop conflating "Bitcoin Core as a project" and
"Bitcoin consensus rules".
They are different things and nobody is or can be "in charge" of the
later, face it.

Can you please also stop conflating software fork and
"Schism/controversial/contentious hardfork"? Nobody has anything
against the former and as you point out it is allowed by its free
software license.

> 4. By having a software fork and consensus rule submitted to vote we
> actually prove how open Bitcoin is, and how there is lack of control
> over it from all parties (developers, miners, engineers on the mail
> list). This is reason to increase Bitcoin's value! It is a feature, not
> a flaw!

Why should miners have a voting power that the rest of the users lack?

> It's very important for everyone in the ecosystem to understand:
>
> - yes, Bitcoin is open source, even you can fork it tomorrow if you want
> and you think enough users might follow you.
>
> - no, it's not a requirement for 100% of the nodes in the network to be
> running Core, or -XT or other implementation. The more we have, the better.
>
> - yes, there is absolutely no authority in Bitcoin - this is what lead
> to this dispute in the first place. This is the truly decentralized
> nature of the software, not important if we have 10.000 full nodes or
> 1000 full nodes.

All this sounds reasonable.

> - no, Bitcoin won't split / die or whatever because of this fork.
> Regardless what it happens, if XT will reach the threshold or not,
> Bitcoin will go on just because it has some unique advantages and has no
> competitor from some points of view.

But you cannot know this will happen this way!
If the threshold is reached (let's forget about noXT for now), the
remaining miners cannot be forced to adopt bip101.
And users can never be forced to adopt hardforks.
It is possible that 75% of the hashrate moves to the bip101 chain
while 99% of the users remain in the old Bitcoin chain. Or 50/50,
40/60...nobody knows.

> - Bitcoin by its design has many many advantages, but also the
> limitation that it relies on majority being honest / doing the right
> thing! This is just the way it is, and the benefits it is offering
> heavily win over this fundamental limitation.

No, it doesn't rely on that. It just relies on the majority of the
miners not attacking the network for too long (ie the number of
confirmations people are waiting).
If I'm running a full node, I'm not isolated from the network and the
majority of the hashrate is not reorging the chain I am safe no matter
how dishonest the "majority" (whatever that means in this context) is.