I believe the author has been very careful in saying "if no perfect solution exists they seem ok with inaction", highlighting a different problem from "let's bang out code that sorta works and move on.
Also, poor communication skills and "immaturity" have also been a "traditional" problems in FLOSS too.
Being unwelcoming to new devs is especially a big problem for a project that _is already_ losing the old trusted devs.
Why do you think a bitcoin core developer wrote the FAQ? In a large project like this it is not at all unusual to have documentation written by people outside the core development team. In fact you can go look at the history of this page, David Harding wrote most of it and I do not see any commits from him in core.
Part of having effective communication is having people on your wider team that are experts in that area, even if they aren't one of the people writing all the software.
Unwelcoming to new devs is not true. Who wrote code & wasn't let in? Also, go to the bitcoin irc and try asking technical questions and observe how everyone is so willing to help new devs looking to get in.
I feel like people are generally comfortable making the assertion that the community is unwelcoming; but those making the assertion generally don't seem to be able to back it up.
A welcoming community doesn't need to coddle everyone who might send a patch, because that's a lot of people. If they want to succeed, they should document enough to get started, and review unfinished patches.
Until you get half way down the article and discover that the Core developers aren't simply proposing inaction:
> It is worth noting that bitcoin core’s response to scaling has been to propose a solution called segregated witness. While it is a well done piece of technology, I believe it would be quite risky
SegWit can only reduce bandwidth for clients that don't need to perform full validation. Blocksize is otherwise unchanged. Miners' and payment processors' bandwidth requirements are unchanged. Lightweight wallets does benefit, as does the nodes/servers they get their data from.
SegWit is also intended up to open up some new middle ground security options-- e.g. making it realistically possible for nodes that verify a random fraction of the data; with a security model in between light an full.
It also addresses some of problems with validation costs that are quadratic in transaction size.
It's also, by far, not the only tool in the Increased-capacity-without-harming-decentralization tool belt, for example I recently described a new approach for signature aggregation which, if applied to the current transaction load would decrease transaction sizes around 30% while making verification somewhat faster.
All fully validating nodes must still download all the signature data. The total can not exceed 1MB per block without forking. SegWit does not reduce transaction sizes.
SegWit is not a compression technique, it is a bandwidth redundancy reduction technique. It simply makes it so that some nodes doesn't need to fetch all of the transaction data.
Take a look at the discount for segregated witness transactions. You'll see that in a world with segwit there are more transactions per block than without.
Can't be done without forking if the total data per block required to validate all the transactions exceeds 1 MB. Old full nodes will reject the blocks.
Only compression or merging can increase the transaction count per block without becoming incompatible with old full nodes.
Luke jr showed how you can implement segwit as a soft fork. The txs look like "anyone can spend" txs and the signatures are excised to the witness data structure (decreasing the tx size). To validate the segwit txs you need to upgrade, but it's not correct to say that a hardfork is needed to increase the number of txs per block.
Only works with a majority hashrate enforcing the new rules, and miners still need full bandwidth and storage like before. Then you really just create a secondary blocksize limit for the associated signature data. And old full nodes are silently converted into non-full nodes, SPV nodes.
But sure, it is a backwards compatible way to reduce overhead for old nodes. But if they want to remain full nodes then they must upgrade and take on larger storage and bandwidth requirements anyway.
AFAIK the intent of segwit is not to reduce overhead but to fix tx malleability. As an consequence of the politicized block size debate a discount was added to increase the number of txs per block--and this was seen as a compromise for the big blocker camp. It turns out you can roll it out with a softfork as well (and provide script versioning), making it a safer alternative to upping the limit with a contentious hardfork.
Can you clarify what you mean by the majority hash rate needs to enforce the new rules?
If they're anyone-can-spend scripts superficially, then old nodes will accept any attempt to spend, not just those of the actual intended recipient. Because they doesn't recognize the softfork rules that restrict who are supposed to be able to spend. To determine that you need the additional signature SegWit data, and only SegWit parsing nodes will understand the difference.
They're non standard and therefore don't get relayed by old nodes. They won't make it into the longer chain because we're assuming the fork is activated. So what does an attack look like, exactly?
If someone blindly accepts non-standard zero confs they've got bigger problems.
I just realized I might be wrong. Anyone-can-spend transactions will be non standard, but transactions spending those outputs might be standard (don't know offhand). In that case, the risk is someone accepting standard transactions with zero confs, which is slightly worse but still doesn't seem too bad considering that all such forks are well publicized and there's no guarantee for zero conf security.
Also, poor communication skills and "immaturity" have also been a "traditional" problems in FLOSS too. Being unwelcoming to new devs is especially a big problem for a project that _is already_ losing the old trusted devs.