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.
https://github.com/bitcoin-dot-org/bitcoin.org/commits/maste...
As long as the core coders can associate and work well with good communicators, it's all good as far as I'm concerned.
The comment I replied to does not challenge the assumptions, but the conclusions. Whether the assumptions are true or not, I do not know.
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.
> 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
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.
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.
Only compression or merging can increase the transaction count per block without becoming incompatible with old full 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.
Can you clarify what you mean by the majority hash rate needs to enforce the new rules?
If someone blindly accepts non-standard zero confs they've got bigger problems.
The author of the article is the CEO of Coinbase. They want Bitcoin retail-sized transactions to clear fast, so their exposure to Bitcoin price variations is low. Coinbase guarantees the price of Bitcoin for several minutes when merchants use their service. The longer they have to hold those Bitcoins, the more risk they take.
Please transfer your money back under your control. That's the whole point of bitcoin. You won't be able to do this when problems happen.
I mean, if it's only a few hundred dollars in BTC, it doesn't matter much. But it's a terrible feeling to lose way more than that.
Here's a recap of Coinbase's problems over the years, in case it matters: https://news.ycombinator.com/item?id=8947926
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...
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.
Luke-JR seems to have --- special --- views of the world. Not sure if I would trust him with anything at all.
HN discussion: https://news.ycombinator.com/item?id=10905118
I'm skeptical that the FOSS philosophy is the correct philosophy for anything which becomes harder to replace as it becomes more established.
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.
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.
The dynamics don't work the same way as a traditonal FOSS fork. Perhaps getting mindshare first is the way.
(It's worth noting that Bitcoin Core supporters have been DDOSing people running the various attempts at a "LibreOffice" that've been tried).
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.
Classic hasn't activated yet. If Classic were already accepting 2MB blocks, the chain would have already forked.
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.
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.
Just pointing out that that would still be an order of magnitude better than my current non-bitcoin options for forex/remittance ($100s, days).
>2. They prefer ‘perfect’ solutions to ‘good enough’. And if no perfect solution exists they seem ok with inaction, even if that puts bitcoin at risk.
I mean the kind of 'good enough' thinking got us into the router mess we are currently in.
The key thing to realise is this. Whilst the remaining Bitcoin Core developers (really: Blockstream) like to present their alternative plans like Lightning as tradeoff-free "solutions", the reality is that their proposed alternatives to the Bitcoin block chain are not launched or even close to launching, are developing extremely slowly, are missing huge chunks from their basic design and even if we assume they find answers to those problems and do actually launch something - the design itself is in no way "perfection" and has very serious unanswered critiques. It is very likely, in my view and the views of others, that their new system would actually be worse than Bitcoin, not better.
Thus driving Bitcoin into a brick wall at high speed because they prefer to believe in vapourware is not perfectionism, it's just idiocy. You don't need to be a businessman to understand that.
In short, they're in the grip of the nirvana fallacy:
> The number of lines of code that need to be written for this across the entire industry will be several orders of magnitude more than a scaling solution of changing 1MB blocks to 2MB blocks. This was explained to core developers at the conference and it didn’t seem to change their opinion of what the best short term solution was to scaling.
Aka, the author knows the day to day challenges of writing core better than the core developers. I believe reading the piece only validated my original heuristic.
You mean the problem caused by everyone using the system? Certainly, if you don't have a system, you won't have problems with the system.
1. Some of them show very poor communication skills or a lack of maturity — this has hurt bitcoin’s ability to bring new protocol developers into the space.
2. They prefer ‘perfect’ solutions to ‘good enough’. And if no perfect solution exists they seem ok with inaction, even if that puts bitcoin at risk.
I get this bad feeling that someone (author of the article) is planning a takeover and for all the wrong reasons. I've seen this "yeah they are smart guys, but they are introverts and our business needs to be extravert and agile and adaptive and fast moving and all other buzz words", then you introduce some of thous extrovert super agile people who just want to "bang out a solution, since any change is better than no change". Next thing you notice is that the old core team members are leaving after their protests about future of the product fell on deaf ears and these new guys are just pushing their own agenda/vision. Fast forward few years and just 1-2 or most likely none of the original team members are there anymore and cracks start to appear and these cracks are because the "better than nothing" solutions back in the day are found after all flawed, but now you have a lot of work build on top of rotten foundation and since your team now consists only of short sighted: "just fix it" people they are going to try to fix the problem at the top instead of at it's core "because we can't hold bringing in new features".