From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 03348273 for ; 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 ; 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: <55D1167B.1060107@gmail.com> <55D124D7.4050209@gmail.com> <61AD0CE6-014E-44E2-B9C7-00B35D2E09CC@petertodd.org> <55D4A3BD.2060706@sky-ip.org> To: =?UTF-8?Q?Jorge_Tim=c3=b3n?= From: s7r 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: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.