path: root/60/d9f388669cb31b9cfe1a3548b814583c43a1e1

Return-Path: <s7r@sky-ip.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 03348273
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 20 Aug 2015 10:25:43 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outbound.mailhostbox.com (outbound.mailhostbox.com
	[162.222.225.27])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id EC4DB102
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 20 Aug 2015 10:25:36 +0000 (UTC)
Received: from [0.0.0.0] (chomsky.torservers.net [77.247.181.162])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: s7r@sky-ip.org)
	by outbound.mailhostbox.com (Postfix) with ESMTPSA id 1F9563604D7;
	Thu, 20 Aug 2015 10:25:30 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky-ip.org;
	s=20110108; t=1440066333;
	bh=VNnh+YSPitiHAfcSjVuUZK703SySdqjrbsdgt8WBgvY=;
	h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To;
	b=KMqVj1bQLk/8IvSeD/j/vPWrZlJXzSuKianiDS8Pm3hC6I0dNs9n3/5kpIE6Jm6K3
	LU5m0V7dUTTSO7v4PeAu341lOtCBchEtbY1tgG/yxVuZNwPSkKlD6bwoYMGqXjnle+
	yGspYhVns3xpWMBxwUMO/q69SNy9YCP0pO/Gn4C4=
Reply-To: s7r@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>
	<CABm2gDo-jgE7ow5eNTp70YwQKNL3OfDMT=uU9H6G09MS_J2k-Q@mail.gmail.com>
To: =?UTF-8?Q?Jorge_Tim=c3=b3n?= <jtimon@jtimon.cc>
From: s7r <s7r@sky-ip.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <55D5AB11.3090307@sky-ip.org>
Date: Thu, 20 Aug 2015 13:25:21 +0300
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
	Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CABm2gDo-jgE7ow5eNTp70YwQKNL3OfDMT=uU9H6G09MS_J2k-Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-CTCH-RefID: str=0001.0A020203.55D5AB1E.00AF, ss=1, re=0.000, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: s7r@sky-ip.org
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.1 cv=DJxymH5b c=1 sm=1 tr=0
	a=8Ww6+Lg8qb0XbX4HKykbog==:117 a=8Ww6+Lg8qb0XbX4HKykbog==:17
	a=6PzwTDcoQqoA:10 a=IkcTkHD0fZMA:10 a=Ia0SYzNCXpyur49DyNEA:9
	a=94EYIuUR2MZTaitz:21 a=e_-yY94WJEOyDp9q:21 a=QEXdDO2ut3YA:10
	a=QpHJ3eixMjkA:10
X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,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: Thu, 20 Aug 2015 10:25:43 -0000


On 8/20/2015 1:28 AM, Jorge Timón wrote:
[snip]
>> 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.
> 

This is exactly the point. If shouldn't matter if somebody who forks
also tries lobbying to Bitcoin companies and miners and also trying to
convince users to adopt the fork. Bitcoin should be immune to such
attacks, otherwise it is really flawed.

Think of a very unlikely but not theoretically impossible example:
The Prime Minister of X with a government controlled authority forks
Bitcoin and changes a very important consensus rule. To ensure adoption
at hashing power level, he issues an order and raises electricity cost
for the entire population with 10 cents or so, and compensates the
miners adopting his fork with free electricity to mine Bitcoin. What
better stimulator could a miner get if not this one?

This is a social problem, not a technical one. There is no code in
Bitcoin or rule in the protocol itself to defend against such a thing.

What can and will make this attack impossible?
The users (economic power) which always ultimately should win any
dispute will refuse using the coins mined by the miners adopting the
controversial fork, which means the coins they mine will be worthless.
Even if they are created with low costs / free electricity, the mined
coins will still be worthless so it won't worth it for the miners to
take this step. Better pay for electricity and win something less vs.
not paying for electricity but winning nothing.

The same with -XT, nobody should be able to affect the entire bitcoin
ecosystem regardless how many miners or bitcoin companies you can lobby.
If this is possible, then Bitcoin is not as secure as we thought.

>> 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.
> 

I agree, wrongly expressed here - sorry about it. It's true that a
software fork is nothing alike a Schism hardfork. I am still optimistic
that we aren't at a Schism hardfork yet and hope we won't get there and
-XT will rejoin in following the consensus rule and stop this division.

>> 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?
> 

This is something which seams very unfair to me as well. This was my
first question after the -XT release which Mike replied to here:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010241.html

To be frank the arguments didn't convince me at all. I am against this
model where users will is ignored. By forcing you to stop using
something it's not what exactly I would call a way to express your will,
it is more like a force out.

>> 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.
> 

Correct - but the point still stands. If 75% of the hashing power wants
to do something which you don't agree to, as an user you don't have any
real options to prevent them. Only game them as in don't use bitcoin to
decrease its value so they are mining worthless or less valuable coins -
but by this you are hitting Bitcoin as a whole and not just the miners.