From: s7r <s7r@sky-ip.org>
To: "Jorge Timón" <jtimon@jtimon.cc>
Cc: Cameron Garnham via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin XT 0.11A
Date: Thu, 20 Aug 2015 13:25:21 +0300 [thread overview]
Message-ID: <55D5AB11.3090307@sky-ip.org> (raw)
In-Reply-To: <CABm2gDo-jgE7ow5eNTp70YwQKNL3OfDMT=uU9H6G09MS_J2k-Q@mail.gmail.com>
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.
next prev parent reply other threads:[~2015-08-20 10:25 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
2015-08-19 22:45 ` Adam Back
2015-08-19 23:23 ` Peter Todd
2015-08-20 10:25 ` s7r [this message]
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=55D5AB11.3090307@sky-ip.org \
--to=s7r@sky-ip.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=jtimon@jtimon.cc \
/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