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 EEC0D93D for ; Wed, 19 Aug 2015 22:45:50 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3B4152EE for ; Wed, 19 Aug 2015 22:45:50 +0000 (UTC) Received: from mail-io0-f177.google.com ([209.85.223.177]) by mrelay.perfora.net (mreueus001) with ESMTPSA (Nemesis) id 0MG8Zd-1ZVoU61w5X-00FApI for ; Thu, 20 Aug 2015 00:45:49 +0200 Received: by iods203 with SMTP id s203so26676377iod.0 for ; Wed, 19 Aug 2015 15:45:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.155.12 with SMTP id d12mr17565734ioe.131.1440024348806; Wed, 19 Aug 2015 15:45:48 -0700 (PDT) Received: by 10.50.43.168 with HTTP; Wed, 19 Aug 2015 15:45:48 -0700 (PDT) In-Reply-To: References: <55D1167B.1060107@gmail.com> <55D124D7.4050209@gmail.com> <61AD0CE6-014E-44E2-B9C7-00B35D2E09CC@petertodd.org> <55D4A3BD.2060706@sky-ip.org> Date: Wed, 19 Aug 2015 15:45:48 -0700 Message-ID: From: Adam Back To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:4RqF1pOLiQHhrJxVph0BHUklHVd/QsuiOmBo+xGyjXvsKRFF46V uhD7uiPqT3PKUf1bM6WWPkK9uDXnuF1TGudeb/jnAXs/bmy/fgO6iMUY5Pb+By35IDSOcRb zxC4APvKRlFK8BUYPtTcrW1f45ukLhNUqv9Fod+QwJRmbwU0Olk7C8f3N77XTEHqM/DAsFz 7Vu5ZqZbII/QxBZo84iyA== X-UI-Out-Filterresults: notjunk:1;V01:K0:fE7MhbBRSMw=:4ZFhVZx3ZF12e40zcW/Yiz zB+zcyyjD6VjVDHkdsNbN5ZTp1imfomYCx82lt08lnCSbNjvFscZJcfAuYo3wA3qbVspbzHcz 9ux24OBUN/dht7SA2S1QajALsmigxtGzGkX4XaMdlfTawe5v+a2WHf3s/un3jzybgTk+xZMtz cmu/LkErikOVelGcnrCQH8u1CJx4VJ+PMo1KCB9tL1AF+4H9PCjm25OjJQ0Zpn/joLZYNWGN2 /SOUX06ndAZyJT4qkDbk9g5PA5L+VJUvz/NjBpOaDOX/iFe/iDOwK8BChEDz+WRySGXYS6h7b NMfgY0S7iSo0ALC4UwbcNAsUzr9W6qBWj552gghOou5UvmFu/qgW2hNfuTwc7A3iVQZyemvnm aZxLBOpnCqOmabJu8mu/g2lSKovcOdWQklnUjfDtL1iNaQhs+Oe9EfIPEIXDKZnXa5JGy6K26 lOyWh2c8c91OkwlLliuWk+29vbT2j2FZaZn+p5bbsEoHsHsZuJSaPQpvQc2wuDLNOiSVWcsx1 1ldImW8mHbsUDfSIZzp+cTeOIYpMmx5SJOMCqhsY1P1y0lf14Q0JPLnWxL1gx5YLekucdDDWM RWmfj4BUbeocl+pOaaM4stw35v9gcXS3rJ7NEuZqSzutQsN183e/p6jGvHo8p03l0YYaAyuRA chJihgzG0ZjUNqHbaGkNfeLhhtJFh60GBJGoAcp/XD8tj4F7SYQCwYYfPuZixG5+6UQ/lNBvm bR6B9figuppUmaSi 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 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: Wed, 19 Aug 2015 22:45:51 -0000 Wouldnt the experience for SPV nodes be chaotic? If the full nodes are 50:50 XT and bitcoin core, then SPV clients would connect at random and because XT and core will diverge immediately after activation. Adam On 19 August 2015 at 15:28, Jorge Tim=C3=B3n wrote: > On Wed, Aug 19, 2015 at 5:41 PM, s7r 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-e331b8631759a4ed6a4cf= b4d10f473caR137 > 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 create= d. > >> 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 bett= er. >> >> - 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. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev