Re: [bitcoin-dev] Annoucing Not-BitcoinXT

[Eric Lombrozo <elombrozo@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3984 bytes --]

I should add that in the interest of peace and goodwill, I extend an offer to both Mike and Gavin to make their grievances heard…but only on the condition that we make a good effort to avoid misrepresentation and misreading of the other side’s intentions.

> On Aug 17, 2015, at 9:37 AM, Eric Lombrozo <elombrozo@gmail.com> wrote:
> 
> 
>> On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org <mailto: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: 6633 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]