MIME-Version: 1.0
In-Reply-To: <CABm2gDo-jgE7ow5eNTp70YwQKNL3OfDMT=uU9H6G09MS_J2k-Q@mail.gmail.com>
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>
Date: Wed, 19 Aug 2015 15:45:48 -0700
Message-ID: <CALqxMTGUtRm4nW1TTVwr0i+NYD93f-i9d9=nkJnPQdPEw8Zy0g@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Cameron Garnham via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin XT 0.11A
Precedence: list

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
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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-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