From: Eric Lombrozo <elombrozo@gmail•com>
To: NxtChg <nxtchg@hush•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Annoucing Not-BitcoinXT
Date: Mon, 17 Aug 2015 09:37:01 -0700 [thread overview]
Message-ID: <CE3B7411-2863-4D6B-85B0-4F28D4D7F391@gmail.com> (raw)
In-Reply-To: <20150817133438.DDD4243128@smtp.hushmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3546 bytes --]
> On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Great, so how about you go tell theymos to stop censoring XT posts and banning the other side on /r/Bitcoin?
>
> Let users decide what Bitcoin is or isn't.
FWIW,
I don’t think what theymos did is very constructive.I understand his position…but it only hurts the cause, unfortunately - the PR battle is not the same thing as a discussion on technical merits. He hurts the PR battle and plays into Mike’s hand by doing that. The actual underlying issue actually has little to do with block size - it has to do with Mike and Gavin feeling that the core devs are being obstructionist.
Regardless of the technical merits of XT, the fact that we’ve never done a hard fork before, not even for things some other devs have wanted…and not due to any malice on anyone’s part but because simply that’s just the nature of decentralized consensus with well-defined settlement guarantees…this is the problem - Mike and Gavin think they’re somehow special and their fork should be pushed while the rest of us resist pushing our own controversial pet ideas because we want civility and understand that at this stage in Bitcoin’s development trying to fork the blockchain over highly divisive issues is counterproductive and destructive.
But the fact of the matter is that in the PR battle, arguments against the fork actually play into Mike’s hand, and that’s the problem.
The whole block size thing is too nuanced and too easily spun simplistically. It’s too easy to spin resistance to bigger blocks (even though the resistance is actually much more towards untested hardforking mechanisms and serious security concerns) as “obstructionism” and it’s too easy to spin bigger blocks as “scalability” because most of the people can’t tell the fucking difference.
The fact is most of the people don’t really understand the fundamental issue and are taking sides based on charismatic leadership and authority which is actually entirely counter to the spirit of decentralized consensus. It’s beyond ironic.
If you guys want to win the PR battle, the key is to make it clear that you are not obstructionist and are giving everyone equal treatment…Bitcoin was designed such that changing the rules is *hard* and this is a feature. Bitcoin simply does not have a reliable and tested hard forking mechanism…and a hard fork for such a politically divisive issue will almost certainly lead to a lack of cooperation and refusal to work together out of spite. All of us would like to be able to process more transactions on the network. It’s not a matter of whether we think higher capacity is a bad thing - it’s more that some of us are concerned that Bitcoin is not sufficiently mature to be able to handle such a schism with so much hostility.
Let’s face it, folks - from a PR standpoint, the block size issue is irrelevant. Nobody really understands it except for a handful of people - I’ve tried to explain it, I’ve even written articles about it - but most people just don’t get it. Most people don’t really get scalability either - they seem to think that scalability is just doing the same thing you’ve always done manyfold.
Block size is an especially dangerous issue politically because it’s one of those that requires deep understanding yet superficially sounds really simple. It’s perfect Dunning-Kruger bait.
So let’s be a little smarter about this.
[-- Attachment #1.2: Type: text/html, Size: 5866 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
next prev parent reply other threads:[~2015-08-17 16:37 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-16 22:34 jyellen
2015-08-17 3:10 ` jl2012
2015-08-17 7:04 ` Peter Todd
2015-08-17 10:09 ` NxtChg
2015-08-17 12:40 ` Vali Zero
2015-08-17 13:34 ` NxtChg
2015-08-17 14:03 ` Eric Lombrozo
2015-08-17 14:09 ` Levin Keller
2015-08-17 14:30 ` Eric Lombrozo
2015-08-17 14:36 ` Adam Back
2015-08-17 14:58 ` GC
2015-08-17 15:03 ` Levin Keller
2015-08-17 15:07 ` Eric Lombrozo
2015-08-19 3:49 ` odinn
2015-08-17 15:10 ` NxtChg
2015-08-17 16:37 ` Eric Lombrozo [this message]
2015-08-17 16:55 ` Eric Lombrozo
2015-08-18 4:37 ` Dave Scotese
2015-08-18 5:13 ` GC
2015-08-18 5:33 ` Dave Scotese
2015-08-18 9:46 ` NxtChg
2015-08-19 9:47 ` Jorge Timón
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=CE3B7411-2863-4D6B-85B0-4F28D4D7F391@gmail.com \
--to=elombrozo@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=nxtchg@hush$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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