public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@jtimon.cc>
To: s7r@sky-ip.org
Cc: Cameron Garnham via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin XT 0.11A
Date: Thu, 20 Aug 2015 00:28:07 +0200	[thread overview]
Message-ID: <CABm2gDo-jgE7ow5eNTp70YwQKNL3OfDMT=uU9H6G09MS_J2k-Q@mail.gmail.com> (raw)
In-Reply-To: <55D4A3BD.2060706@sky-ip.org>

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.


  reply	other threads:[~2015-08-19 22:28 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-15 22:39 [bitcoin-dev] Bitcoin XT 0.11A muyuubyou
2015-08-16 18:37 ` Andrew LeCody
2015-08-16 23:02 ` Cameron Garnham
2015-08-16 23:22   ` Andrew LeCody
2015-08-17  0:03     ` Cameron Garnham
2015-08-17  6:42       ` Peter Todd
2015-08-17 12:29         ` Andrew LeCody
2015-08-17 12:33           ` Eric Lombrozo
2015-08-19 10:09             ` Jorge Timón
2015-08-19 15:41               ` s7r
2015-08-19 22:28                 ` Jorge Timón [this message]
2015-08-19 22:45                   ` Adam Back
2015-08-19 23:23                     ` Peter Todd
2015-08-20 10:25                   ` s7r
2015-08-20 11:32                     ` Milly Bitcoin
2015-08-20 11:46                       ` Hector Chu
2015-08-20 12:29                         ` Milly Bitcoin
2015-08-20 14:25                           ` Tamas Blummer
2015-08-17 21:42     ` Matt Corallo
  -- strict thread matches above, loose matches on Subject: below --
2015-08-16  2:08 muyuubyou
2015-08-15 17:02 Mike Hearn
2015-08-15 17:57 ` s7r
2015-08-15 18:38 ` s7r
2015-08-15 19:21   ` Mike Hearn
2015-08-15 20:36     ` Milly Bitcoin
2015-08-15 20:47       ` Bryan Bishop
2015-08-15 21:10         ` Milly Bitcoin
2015-08-15 20:55       ` Micha Bailey
2015-08-15 21:32 ` Eric Lombrozo
2015-08-15 22:01   ` Ken Friece
2015-08-15 22:16     ` Eric Lombrozo
2015-08-15 22:27       ` Angel Leon
2015-08-15 22:28       ` Ken Friece
2015-08-15 22:55         ` Mark Friedenbach
2015-08-15 23:04           ` Ken Friece
2015-08-15 23:07             ` Eric Lombrozo
2015-08-15 23:30               ` Michael Naber
2015-08-15 23:40               ` Mark Friedenbach
2015-08-15 23:57                 ` Ken Friece
2015-08-16  0:06                 ` Milly Bitcoin
2015-08-16 13:49   ` Mike Hearn
2015-08-16 15:44     ` Anthony Towns
2015-08-16 16:07     ` Tamas Blummer
2015-08-16 16:12       ` Levin Keller
2015-08-16 17:01       ` Adam Back
2015-08-16 18:15         ` Tamas Blummer
2015-08-16 20:27 ` Eric Voskuil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABm2gDo-jgE7ow5eNTp70YwQKNL3OfDMT=uU9H6G09MS_J2k-Q@mail.gmail.com' \
    --to=jtimon@jtimon.cc \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=s7r@sky-ip.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox