As someone who hasn't been following bitcoin development very closely, can you please give me some examples or sources as to why they deserve to be unseated?

Do you trust these people?

Austin Hill, CEO of Blockstream, admits to committing fraud to scam people:

http://betakit.com/montreal-angel-austin-hill-failed-spectac...

Greg Maxwell, CTO of Blockstream, vandalizes pages on Wikipedia for fun:

https://en.wikipedia.org/w/index.php?title=Wikipedia:Adminis...

Patrick Strateman, co-founder of Blockstream, has been accused of fraud/theft:

https://bitcointalk.org/index.php?topic=159071.0

Luke-Jr, consultant to Blockstream claims the sun orbits the earth, slavery is okay, sodomy should be punished by death and that gay marriage is a logical impossibility.

http://forums3.armagetronad.net/viewtopic.php?p=203850#p2038...

https://np.reddit.com/r/bitcoin_uncensored/comments/492ztl/l...

https://www.reddit.com/r/Christianity/comments/48avz0/inform...

Unfortunately this comment and this account (created only to criticise the bitcoin core team) is a good representation of the calibre of most of the criticism and attacks they have been copping over the last year or so.

Let's be more clear: it's horribly misleading.

E.g. the Austin Hill example is from when the man was 16, and comes from a talk he gave about how he learned an important moral lesson from that moral failure that changed the course of the rest of his life.

I don't really see anything horribly misleading here. The linked article mentions this as well.

Luke-JR seems to have --- special --- views of the world. Not sure if I would trust him with anything at all.

It's been posted elsewhere in this thread, but: https://medium.com/@octskyward/the-resolution-of-the-bitcoin...

HN discussion: https://news.ycombinator.com/item?id=10905118

this is open source software - you act as if the seat can't be earned with enough commits.

That's the thing; the core maintainers won't allow anyone new in. At least nobody who disagrees with their pretty much objectively harmful inaction on raising the transaction limit, a stance they've adopted out of extreme stubbornness combined with glaring financial conflicts of interest.

I think the parent meant "unseated" as in LibreOffice unseating OpenOffice: the proper way to attempt a coup of a FOSS project is to fork it and outcompete it.

But Bitcoin isn't just a FOSS project -- it aspires to be a currency, even a financial system of sorts. Currencies have a network effect; the more widespread their adoption, the greater their gravity, making a popular currency difficult to supplant.

I'm skeptical that the FOSS philosophy is the correct philosophy for anything which becomes harder to replace as it becomes more established.

It seems to me that the problem with Bitcoin is that its "consensus rules" (the flowchart to follow to decide a block of transactions as either being valid or invalid) aren't instantiated anywhere, but rather are just buried within the particular implementation details of BitcoinCore.

In an ideal world, you'd split these up:

1. there'd be a currency steering committee (with some structure whose ideal form is above my pay-grade) that produces a machine-readable validity ruleset (sort of like a DTD or XML Schema);

2. and then there'd be a proliferation of competing clients that all know how to parse those rulesets, and use them to validate blocks; but which otherwise go about their business of being Bitcoin clients in entirely separate ways.

With such a split, issues with the management of "BitcoinCore the FOSS reference client implementation" wouldn't overlap with issues with "Bitcoin, the ruleset that, in being instantiated in a majority of nodes, gives them a consensus chain." Instead, the first would just be a regular code project, no longer at-all critical; and the second would be something more like the project of defining a new version of e.g. the ePub standard, or of drafting an RFC.

There are several problems with this. Firstly, a machine-readable validity ruleset would basically just have to be a library implementing the rules, simply because of their complexity - for example, one of the previous validity changes requires scripts of a particular format to be treated as hashes of the actual script, which is provided by the transaction redeeming it. Secondly, bugs in implementations can effectively cause the to enforce unexpected additional rules, such as the BDB lock limit which caused an unplanned hard fork a few years back. Thirdly, everyone involved still needs to be a skilled developer with knowledge of distributed systems - especially the currency steering committee, since changes to the validity ruleset can break the whole thing in subtle and unexpected ways - and the committee still needs in-depth knowledge of the actual implementations to know if they can cope with their planned rule changes.

The challenge is that the rules are only legitimized by the clients choosing to follow them. You can't launch new rules until at least 50% of clients by weight are following those rules. There is no way for the ruleset to somehow disable or ignore a misbehaving client, you need consensus.

Right, this would just make the difference explicit: given a good spec for defining the rulesets, a client would be able to just give a drop-down for which ruleset to follow (or allow you to point the client at your own by URL, etc.)

They have been split up. Bitcoin Core now builds a separate library, libbitcoinconsensus.

but that has already happened, TFA is advocating moving to LibreOffice (BitcoinClassic).

BitcoinClassic has to do what LibreOffice has done first. Write more code, have more active developers, fix more bugs - be the better community for new developers etc. So far none of this happened.

That has been tried before with XT and it failed.

Bitcoin Classic is the attempt to change the reference implementation from the Core code to their code, by only changing as little as possible (that is, raising the 1 MB blocksize to 2 MB).

The current problem is not being more open to other developers but to get a different reference implementation installed on full nodes and miners.

Yeah, but that's a chicken and egg problem because unless/until BitcoinClassic outcompetes the other one, none of your code will ever get executed, so any developer wanting to scratch an itch must contribute to the existing bitcoin rather than BitcoinClassic.

The dynamics don't work the same way as a traditonal FOSS fork. Perhaps getting mindshare first is the way.

I know; and obviously Bitcoin Core aren't going to fire themselves. I'm just addressing the why they should be unseated, not the how.

(It's worth noting that Bitcoin Core supporters have been DDOSing people running the various attempts at a "LibreOffice" that've been tried).

DDOSing nodes does nothing to support Bitcoin Core.

Bitcoin nodes get DDOSed from time to time-- e.g. people incorrectly believe they're the node for some service they think they can extort. Sometimes users on bufferbloat afflicted connections mistake other users fetching the chain from them as a DOS attack.

That said, since these claims that people are DDOSing "Bitcoin classic" were first made, I've had someone running a classic node-- in the hope of identifying the attacker-- which has received no attacks. I don't believe the claimed attacks are widespread if they're even happening at all.

That's not the sort of DDoS going on here. Classic nodes are getting DOS'd in a way that Core is also vulnerable to.

Classic hasn't activated yet. If Classic were already accepting 2MB blocks, the chain would have already forked.

This just makes me go: "well, duh". If I would come in on your current project and make changes you didn't agree with, would you "let me in"?

If things are really so bad and Bitcoin is FOSS, why don't you (or whoever cares about rising the limit most) just fork the project and create Bitcoin 2.0. If this is truly best thing for the currency then everyone is bound to jump the ship and use your new currency.

The forks XT and Classic are both trying to do that. XT was actively fought with things like DDoS attacks and lies and other foul play. Classic goes for a more moderate (IMHO too cowardly) increase, and is at least not being fought in the same way.

Authority in Bitcoin comes from hashing power not by credentials or anything else. Go and convince the Chinese mining pools to adopt someone's fork. These are the guys spending >$50k a month on electricity and millions of dollars in mining gear. You can also go start collecting Dogecoin or Ethereum or start your own crypto currency. Nobel Prize winner F.A Hayek in his book "The Denationalization of Money" suggested that in the future there should be multiple competing currencies anyway, not one uber currency to rule them all.

That's exactly what we're doing. Here's a chart for Bitcoin Classic blocks mined: https://coin.dance/blocks/classic

What an uninformed amateur sees from this page is ... utter chaos in Total Miner Support by Proposal. BIP 100 leads but the BIP repo linked doesn't contain such a BIP, the link is broken. 8MB doesn't even have a link. The four of them together managed to convince 27% to change to something and 3.8% for classic is the last.

Please provide an example of person with loads of recent commits (past year or so) who wasn't allowed in.

But if you really think that changes need to be made that the quintumvirate don't want to make... your commits aren't going to be approved.

I mean they don't add new people to the core, decision-making team (relevant to this controversy: those who decide the block size i.e. transaction limit).

Now, many open source projects don't add new people to the core, decision-making team, but few open source projects are run by people who are acting in direct opposition to the [financial] interests of their userbase.

Sure, but they aren't being paid by their users so why should they follow their interests? Ideally the users should be paying for development they control but that of course would never happen because of the Tragedy of the Commons and such.

They should follow the user's interest because if they don't users will just leave Bitcoin for another cryptocurrency. Who wants to use a crypto that has 0.50$ fees, and takes hours to confirm a transaction?

> Who wants to use a crypto that has 0.50$ fees, and takes hours to confirm a transaction?

Just pointing out that that would still be an order of magnitude better than my current non-bitcoin options for forex/remittance ($100s, days).

What the heck are you talking about? The bitcoin core repo accepts contributions from any and all. There are new developers showing up all the time.