Brian Armstrong, the CEO of Coinbase, wrote a blog post [0] today that gives a very different take on things. He criticized Bitcoin Core's development team for their poor communication with the community, for their inhospitality to new contributors, and for their repeated rejection of practical and simple solutions to Bitcoin's immediate scaling problem. He advocated adopting Bitcoin Classic's short-term fix for full transaction blocks and wrote that it is vital in the long term to foster an environment in which multiple development teams can compete to introduce new features and improvements to the protocol.
There are many people in the Bitcoin ecosystem who, like Brian, feel strongly that if Bitcoin is to survive and thrive, then not only must the blocksize-limit be increased, but the exclusive power to decide the future of Bitcoin must be taken out of the hands of the Bitcoin Core team.
Got a citation for that? I submitted my first PR (albeit a tiny change) to Bitcoin Core last week, and it was merged in a few days. No questions asked, no pushback.
I guess it all depends on what the change is in the end... if you're forking the blockchain, I'd damn well hope some pushback.
Which makes it strange how in 2015 he suddenly took an interest in Bitcoin and (1) supports everything Blockstream is doing (2) writes blog posts attacking long-time Bitcoin contributors like Mike Hearn and Gavin Andresen.
Perhaps Bram Cohen is "consulting" for Blockstream? They admit they spent over $10m+ in their first 12 months of operations in 2015 which is a high burn rate considering how few full-time employees ("founders") they had during that time.
Bram Cohen doesn't hate Bitcoin. He's fascinated by it and someone skeptical of its future; when you attack people for having moderate views that acknowledge real risks and limitations you increase the perception of Bitcoin as a ponzi scheme.
Bram, like almost all other technical experts holds a collection of views that you disagree with. He's never been paid by Blockstream.
Your claim with respect to blockstream's finances are incorrect, and you know they are incorrect since you were previously corrected on them; I can only assume that you're continuing to repeat them in an effort to intentionally defame Blockstream. You should stop.
I feel like that's giving the Bitcoin Core developers a bit too much credit.
> When asked "can you scale this?" They said, "we'll do the best we can." That wasn't good enough for many, especially those who don't understand the architecture or the nature of what is going on inside of Bitcoin.
The larger issue is that some of the core developers don't want to scale Bitcoin at all. They would rather have a more decentralized, less widely used Bitcoin. There is no right answer here of course, but many companies and VCs bet their future on a widely used, less decentralized version of Bitcoin (i.e. one where it's hard to run a Bitcoin server on a home internet connection, much like SMTP today).
> Many people call them "Bitcoin Core" as if they are some sort of company you can fire or a random set of developers with skills that you can just train others to acquire.
They called themselves Bitcoin Core, and even went so far as to create a separate website and have started branding the reference client as Bitcoin Core.
> It feels like while the Bitcoin Core development community is robust, the ecosystem of stakeholders and the understanding of how decisions are made and information is shared is still fragile and vulnerable.
The real issue is that Bitcoin has no "official" governance, so it's resulting in design-by-committee and stalemate on key decisions. The project needs a BDFL, but since it has none it will fail to keep pace with innovation in the space. Unlike most internet protocols, the consensus layer prevents anyone from effectively forking the project, without creating a whole separate blockchain (unless they can convince 100% of the community to follow them).
Luckily, we are starting to see more innovation and competition in the blockchain space, with Ethereum being by far the most interesting newcomer IMO (and run by a competent team with a clear governance structure).
> The larger issue is that some of the core developers don't want to scale Bitcoin at all. They would rather have a more decentralized, less widely used Bitcoin.
What some of the core developers don't want to do is scale by increasing the block size and thusly increase the costs of being part of the decentralized network.
As an analogy, consider the EMFILE error in Unix. The kernel has a pre-set constant of how many file descriptors a user can open simultaneously.
Your computer might have it set to 256 and you might never have a problem because you use it for single-user workloads. When I deploy services to the cloud, however, it's annoying that sometimes the constant is too low: the system can handle a lot more TCP connections sometimes and the constant is inappropriate.
Now let's say you have a peer-to-peer network whose participants' computing capabilities (= EMFILE limit) are unknown. Let's say this network becomes super popular, and a lot of the nodes are close to hitting their file descriptor limit.
If you raise the constant from 256 to Infinity for everyone in the network, some nodes might be able to handle the load (for example powerful cloud computers), but some desktop computers will just struggle. No matter how high you set the constant, you're not introducing more capacity. You're throwing nodes out.
Luckily, there seem to be ways to scale the network without relaying (and persisting) every single transaction to every node.
> > The larger issue is that some of the core developers don't want to scale Bitcoin at all. They would rather have a more decentralized, less widely used Bitcoin.
Hi, Which developers don't want Bitcoin to scale at all.
I think that it's critical that when the founder and lead developer of Bitcoin "Classic" makes allegations like this that they back them up concretely.
Increasing the block size is not the only way to make the system scale.
Imagine that you have 300GB available to store logs for requests to your webserver.
Let's say you're at 250GB and you can make calculations that, based on your website's growth and traffic projections, you'll hit your 300GB limit by the end of the year.
One way to scale is to buy new hard drives. Another way to scale is to keep only the most recent 300GB.
Another way to scale is to ask yourself: do you want every single entry in the log, with user agent, IP, headers and TLS handshake parameters? Perhaps you care only about malicious actors. Perhaps you care about some critical business events.
In that case, an alternative would be to aggregate and collapse log entries.
In the context of a system that is designed for decentralization, those scaling strategies seem to be a better fit.
> the consensus layer prevents anyone from effectively forking the project
This isn't true, as soon as 51% of clients are trying to push "new" blocks not recognized by the old client old clients cannot recognize them and the chain forks. This has happened several times in the past, but we have never seen anything like Classic where it was a version increment out of the Core tree that is set to break old clients.
There was technically a second hard fork a couple of months after the accidental one in order to carry out the change that caused the first one in a more controlled and planned manner. Sticking with the existing code was not an option for technical reasons: "This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page)."
Also, there was technically also one way back in 2010 to fix an integer overflow bug that allowed large amounts of BTC to be created from thin air: https://bitcointalk.org/index.php?topic=823.0
Right. And that would be a disaster. Imagine if io.js forked node.js, but the fork was effectively unusable until 75% of projects started using it. And as soon as that threshold was reached, everyone still using and developing node.js was stuck with unmaintainable software and forced to migrate against their wish.
Personal opinions aside, what Bitcoin Classic is trying to do is follow the traditional open source project fork playbook, but it will not succeed with a consensus protocol - at best they are keeping attention focused on the issue. Blockchain development works best when there is competition _between_ blockchains, not within them.
Except that is the problem in Bitcoin. None of the money, none of the participation, none of the market are in alternate blockchains. They are in the bitcoin blockchain. That is fine, like the article says, when you have BDFL steering the project and keeping the original vision absolute, but that is not the case with bitcoin. Development is hijacked by those in a small insular group who refuse to adopt extremely popular reforms despite the userbase dramatically demanding the change.
This has happened before. It happened with ffmpeg when it was forked into libav. Up until the fork happened the leadership of ffmpeg did not yield - only after the competition was real did they change their behavior and then they made the smart decision of obsoleting libav by merging back in all changes made.
I'm not sure how you think Bitcoin Classic is failing. They already have a majority of hashing power pledged, and last I saw they had around a quarter of nodes running Classic or XT a week or so ago. If Classic wins, it simply demonstrates that the current project leaders of bitcoin core are not acting in the interests of a supermajority of the community as a whole according to their desires, and free software never works like that. If everyone wants change, someone will provide that change - it has happened so many times in the past they are near innumerable to list. I do not see how, if 75% of bitcoin users want 2MB blocks, it will not happen.
The impressive thing about Bitcoin is that it works well despite many attempts to break it. That's so rare in computing. The basic concept was well worked out.
Some of the people in the financial community just want a shared ledger between the big players that doesn't require a separate organization to run it. That's simpler than creating a shared trusted organization, like the Depository Trust Company. Those systems are consensus ledgers where known parties each have a vote. There's no proof of work, and it's not a currency system. That's unrelated to Bitcoin, but it's taken seriously because Bitcoin hasn't been broken.
The "current situation of Bitcoin" mostly seems to involve a dispute over block size. At the moment, some denial of service attack is creating large numbers of tiny transactions and causing a transaction backlog. Transactions which specify a higher fee get through OK, apparently.
The "core developers" think they have a voice in how Bitcoin works, but in fact, the three top mining pools in China have well over 50% of the mining power and decide what happens.
Too many Bitcoin exchanges are still run by crooks. Anyone knowing the whereabouts of "Big Vern", Cryptsy's CEO, should contact the Silver Law Firm, which is suing him.
Reading this, it seems that the author does not understand Bitcoin, blockchains, BFT consensus, or indeed computer programming. He acts as if the people working on Bitcoin are some kind of mages with arcane knowledge that nobody else has. They are simply well-versed in a very quirky distributed database.
> some kind of mages with arcane knowledge that nobody else has. They are simply well-versed in a very quirky distributed database.
Being well-versed in very quirky distributed databases absolutely makes you a mage with arcane knowledge.
Edit to expand: being an expert in bitcoin requires understanding distributed databases, distributed consensus, cryptography, bytecode interpreters, and having some knowledge of economics probably wouldn't hurt.
Being an expert in any one of these things is more than enough to get you a great career. Being an expert in all of them operating cooperatively is... pretty arcane knowledge.
To be fair, most bitcoin developers are likely to be experts in one or two of those things and just reasonably conversant in the others. Satoshi's paper was pretty clear on the consensus and the crypto, but sort of hand-waved the network, for example. It is my understanding that there have been significant improvements to the security of bitcoin's P2P network since then...
I'm personally bearish on Bitcoin. (It's neat tech but as a product I think it's doomed to always be on the margins.) Despite that, I'd agree with Ito here that there are a relatively small number of people who really have the background and the experience to work on the core code.
Distributed systems are hard. Cryptography is hard. Financial systems are hard. Transactional databases are hard. Securing systems that handle real money is hard. Open source development itself isn't easy.
The number of engineers who think they can handle all that is way, way larger than the number who actually can. As an example, just consider how many systems get breached because people build their own crypto. And look at how we're still finding critical bugs in core security libraries.
The thing I have issue with is not his assumption that only a few people can work on Bitcoin, but that only the Bitcoin core team understands BFT consensus and POW.
Could you point out where he said that? I mainly noticed him saying that few people had the necessary experience to work on the code, not that nobody else could possibly understand some core concepts.
"They often view the people working on Bitcoin as a bunch of crazy Libertarians who came up with a cool idea but believe that a bunch of hired guns could put the same thing together given enough money."
This is my favorite point.
There's a lot of people out there who think "sure, yeah, hacker types can prototype creative stuff but anything they do can be done better by Serious People with Serious Degrees."
The history of the original PC revolution is the history of that being proven wrong. In the 70s and 80s all the Serious People with Serious Degress from the Right Schools worked for IBM, HP, and other mainframe vendors and made 2-3 times as much as the hackers who drove them into the ground with radically cheaper and eventually better products.
Due to its low capital costs, IT/CS is an inherently radically meritocratic industry. Someone with no college degree can show up an expert by actually delivering something superior... if they can, that is, and there are enough who can that it happens fairly often.
If anything the pattern that I see in this industry is that the indie hackers are ahead of the curve. They're the ones who prototype the hard stuff and solve the hard problems. The Serious People take up the rear, coming in later and building out and scaling what's already been done. They're the regular army, not the special forces. Serious People run the Internet now but they didn't build it... if it had been left up to them it would be a byzantine OSI network run by telcos and we'd still be using text terminals (with limited graphics maybe) for $1/minute.
I read:
"It feels like while the Bitcoin Core development community is robust, the ecosystem of stakeholders and the understanding of how decisions are made and information is shared is still fragile and vulnerable. I fear that the communication and now emotional rift between various key groups and individuals is wide right now, but I believe it's imperative that we try to bring the community together and focus on executing on a shared technical plan that represents our best shot at broad consensus from both a technical and a practical perspective."
It reads like a response on the Bitcoin situation describted in the Jan 14 Medium article by Mike Hearn on the "Resolution of the Bitcoin experiment". Problems resulting in the rift between Bitcoin Core and Bitcoin XT, Bitcoin Classic and Bitcoin Unlimited.
https://medium.com/@octskyward/the-resolution-of-the-bitcoin...
He seems to suggest Ethereum and Bitcoin alternatives cannot yet replace Bitcoin Core as it is robust and battle tested as he writes:
"If you're serious about security and stability -- and you should be -- Bitcoin is almost the only choice with the largest bounty, and largest community, with the most practical modern experience deploying to a broad and active network in the real world."
But is Bitcoin the only choice and are the bitcoin stability problems outlined by Mike Hearn and others an "idee fixe" or just a dispute over blocksize?
Is it correct to call it a $6.5 billion bounty? Once Bitcoin is hacked, the value of all the coins go to 0, no? Who would accept them knowing they could lose them so easily.
On the flip side, if the perpetrator could cover their tracks, the potential would be much greater than 6.5 billion. The feasibility of this depends on how many wallets are audited by external systems (humans and machines), and the ability to identify ones that are not. Once the word gets out, I agree with you it becomes a bank run and the value goes to zero.
> if the perpetrator could cover their tracks, the potential would be much greater than 6.5 billion
I think it's interesting to consider that this already could have happened or could currently be happening. A sophisticated attacker may be quietly reaping rewards in such a way that it's going unnoticed.
Granted it's unlikely given Bitcoin's core design is to prevent exactly that kind of untrackable-bad-actor-behavior, but it's absolutely possible with known weaknesses like a 51% attack.
I would hope some of the parties heavily invested in Bitcoin have verification tools that monitor the mempool vs. what ends in the Blockchain as I think even the most subtle attacks could be discovered that way... however even that may require an impossible perfect knowledge of the global mempool at any point-in-time.
A smart actor who broke Bitcoin would do things at the edges to manipulate the market and the value of BTC to extract as much as they could before people realized something was seriously wrong.
Most retail accept them through companies like coinbase or bitpay but they immediately convert them to USD so their exposure to a bitcoin hack is minimal.
The reason they do this has more to do with the fluctuating price though as they can't risk the value dropping after they sell something.
Right, also it's a bounty that can only be claimed through effecting a double-spend attack. I'm pretty sure that you would not be able to extract anywhere close to the full market cap in this manner.
In theory there could be a short window between when Bitcoin gets hacked and when people realize it; during that window the hackers could cash out some amount, although not billions.
Using context from the article I think the commenter and article author are both referring to attacks (like a 51% attack or an unthought of new attack) where coins can effectively be stolen.
Good point, attacks on mining were probably what was being referred to here. Specifically because one of the counterarguments to the blocksize increase was that it promoted centralized mining, increasing the odds of a 51% attack.
I'll leave my other comment in this tree as food for thought, because Bitcoin has definitely driven research in cryptography. But it's the least likely attack vector.
SHA256 is used for mining but that would only expose new coins that are being generated. If there was a vulnerability there the community would switch to a new mining algorithm to secure new blocks.
Addresses are protected by hashing a public key to the bitcoin address (https://en.bitcoin.it/wiki/Technical_background_of_version_1...). If you've always sent coins to new addresses like the hierarchical deterministic wallets do then your public key is only exposed after you spend the coins, so you are not susceptible to a cracking attempt on the public key.
> If there was a vulnerability there the community would switch to a new mining algorithm to secure new blocks.
This would be extremely interesting to watch as a new algorithm would render all (or at least most) existing miners useless as they use SHA256-specific-ASICs. The economic and control fundamentals of Bitcoin completely change if you change the hash algorithm.
Not to mention it takes non-zero time to choose a new hash, make the code changes, and deploy it worldwide. Even if somehow you do that in hours or days, what happens in the mean time? Bitcoin would be entirely unsafe to use and anyone using it as their primary financial store better hope they have some food stockpiled (and bills paid)!
Luckily I've not heard anyone question the math behind Bitcoin's proof-of-work algorithm, so I think this possibility is exceedingly unlikely as the math is well understood.
Breaking Bitcoin's hash algorithm would require a feasible pre-image attack on SHA-256. Such a thing would have far greater consequences than forcing Bitcoin to change its proof-of-work algorithm. Tons of protocols and applications would be rendered insecure. We'd all be scrambling to fix TLS, SSH, IPSec, GPG, and dozens of other key pieces of software. I'm not sure how Debian-based systems would upgrade, since deb packages are verified by SHA-256. In short, it would be utter chaos.
Every system you mentioned other than Bitcoin already supports alternatives to SHA-256. There'd be a scramble for sure, but no different than the current steady stream of OpenSSL vulns. Probably less of a scramble than many OpenSSL vulns as SHA-256 could often be disabled via simple config file changes.
Bitcoin on the other hand would have to fundamentally change due to miners with ASICs. The code change might be minimal, but the economic, political, and psychological impact would be huge. For miners to lose their entire infrastructure investment in ASICs may cause an unrecoverable drop in hash rate as it takes 2 weeks for difficulty to recalculate.
This is why SHA-3 exists. If it starts looking feasible that SHA-256 is going to be broken, we already have alternatives. We've already seen TLS et al switch from hashes like MD5 and SHA-1 a few years ago. Pretty much all the other systems have systems in place to migrate in case one part of the validation system is cracked. Bitcoin doesn't, and given the fractured state of the community, having a migration system would be difficult at the very least.
I'm mixing merchant's and end user's perspectives here - no chargebacks, low tx fees, no need to share sensitive data with anyone, easy p2p transactions, no cross border tx fees, few other things.
No chargebacks - this is a huge negative for users
Low tx fees - most users currently don't see tx fees with most payment systems. Bitcoin puts them on the user.
Sensitive data - if you consider a credit card number sensitive you are doing it wrong. They are designed to be easy to replace if compromised and even then new technology is making single use numbers common.
Easy - which is why sorryforyourloss is a thing. Bitcoin is confusing for most people and difficult to secure for everyone.
Multisignature transactions with mutually trusted arbitrators.
Why then mine in the first place, you just reintroduced trusted parties?
Hardware wallets, etc... Use your brain, common sense prevents the majority of losses.
If you are careful enough, everything is fine almost by definition. But a good, i.e. user friendly, system is one that lets you make mistakes without hurting you too badly. Therefore asking what to do in order to be fine is kind of the wrong question, one should better ask with what kind of stupidity you can still get away.
Because they only need to be trusted until the transaction is complete. Banks must be trusted in perpetuity. The trust model is much stronger when any breach of trust can lead to instant reaction, moving all funds away in seconds and blacklisting them.
That's why friendlier hardware and software wallets are being developed, and protocols to automate most of the tedious work.
Look at for example the payments protocol with the ability to verify the identity of the seller (via TLS certificates), transmit your delivery address and get a digitally signed receipt in one click. With support for extensions it can even do things like silently negotiate for who to use as a trusted arbitrator and the time period for settlement (after X time without it being contested, the seller can withdraw the money without need for interaction).
Bitcoin can emulate everything banks do, and still have far stronger security guarantees.
Banks simply can not do the same without adopting public cryptographic logs like that of Bitcoin.
Low tx fees compared to CC and even ACH transactions is a win-win as long as the merchants are passing the savings on to the consumers (which some do).
Same with chargebacks. Realistically they've become more of a fraud tool then a protection mechanism.
Sensitive data - PAN and CVV data is sensitive to the point where merchants are forced to spend millions to be compliant with the PCI DSS standard so yes this is a huge deal.
That same tokenization technology you're referring to is there to reduce the PCI footprint. This tech isn't cheap but is worth it for the merchants and again is a non-issue for BTC.
With chargebacks, you're missing the bigger picture. If someone mugs you and steals your credit card, you call the bank and your stolen card's cancelled, plus the mugger now has a paper trail. Bitcoin, someone mugs you and steals your hardware wallet, well, sucks to be you.
Regarding PCI, a lot of the things that are mentioned are things that you should be doing anyways. Walling off your billing network, getting a third party to audit your systems, testing your systems. I've been with a company going through a PCI compliance audit, and I think the only thing that really needed changing was making a few configuration changes to the web server to disable a few legacy defaults. Perhaps I'm just too old for the break early, break often scheme that most teams want to run under, but having certain areas of code need a bit more diligence before being pushed out is not a terrible thing.
Chargebacks - well sure they can be used as intended (although in your particular scenario the mugger would have to be able to get into the wallet), the reality however is that chargebacks are a source of fraud which is costly for the merchants to deal with and as a result the cost is passed on to the consumer. With bitcoin, just like with cash, the merchant knows that they are safe from the chargeback scenario and is in position to offer discounts to consumers paying with bitcoin. My local gas station is charging less if you pay with cash vs a credit card for example.
PCI data is "toxic". I spent about 10 years working for a company whose primary business was working with the merchants to help them reduce their PCI footprint - they were paying us millions of dollars to do that. Guess who was paying for it at the end of the day?
I'm not saying accepting bitcoin as a method of payment means throwing caution to the wind. I'm also not saying PCI is unreasonable - but again things like PCI are there because the way Credit Card processing works makes Credit Card data extremely sensitive and prone to abuse.
The reason I sold all my bitcoin is that the blocksize impasse started smelling like corruption to me. The interests of Chinese miners seems to have undue influence. If Bitcoin Core doesn't have the interest of the whole community then there's no trust. And without trust the whole scheme falls apart.
As someone who is a curious outsider to the whole bitcoin thing, the more I read all the bickering, the more I think "I'm going to stay away until they've got things figured out". After all, I'd be getting in to use the technology, rather than attempt speculate on its value.
It's ironic that a currency designed to solve the problems of currencies controlled by human beings is now suffering the very same problems that caused all the fiat currencies before it to fail.
All fiat currencies before have failed? I am pretty sure ere are lots of fiat currencies that are doing just fine (like the dollar, which has never failed)
If you assume that bitcoin uses 10x more computing power than folding, and it uses most of it in China which has far worse pollution, than the estimate comes to 340 deaths per year. That's just direct deaths, who knows how much damage is caused by indirect damage and the long term impact of those wasted resources.
How is it a logical fallacy? Do you see any errors with my math? Are you saying that it doesn't kill people?
It is true that air conditioning kills people and contributes greatly to pollution. That's why there have been a lot of attempts to reduce its use. But bitcoin is way worse. Fortunately far fewer people use it than air conditioning. According to this article, a single bitcoin transaction uses as much energy as a 1.5 households use in a day: https://motherboard.vice.com/read/bitcoin-is-unsustainable
There are many people in the Bitcoin ecosystem who, like Brian, feel strongly that if Bitcoin is to survive and thrive, then not only must the blocksize-limit be increased, but the exclusive power to decide the future of Bitcoin must be taken out of the hands of the Bitcoin Core team.
0. https://medium.com/@barmstrong/what-happened-at-the-satoshi-...