My view on the current situation of Bitcoin and the Blockchain
joi.ito.com
joi.ito.com
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-...
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.
https://www.reddit.com/r/btc/comments/41exno/bram_cohen_hate...
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, 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.
> 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).
This is not the case. See: https://bitcoin.org/en/bitcoin-core/capacity-increases-faq
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.
> This is not the case. See: https://bitcoin.org/en/bitcoin-core/capacity-increases-faq
No, parent's statement is correct. Luke Jr, for instance, thinks that 1MB is already too big: https://www.reddit.com/r/btc/comments/404b01/ulukejr_1_mb_is...
You're pointing at a document jointly written by a number of Core Developers, but some 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.
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.
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.
AFAIK there's only been one hard fork, https://github.com/bitcoin/bips/blob/master/bip-0050.mediawi...
That was accidental, and was reverted as soon as people realized. Someone pushed through a $10,000 double-spend in the meantime.
Other than that, I don't think any hardforks have taken place.
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
The second is a soft fork, not a hard fork.
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.
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.
A 10MB limit won't make running a node impractical.
Also there are nodes and full nodes. People who download the full blockchain aren't 'leech' nodes.
1mb up (while literally 10s of millions of people around the world have a better connection) still contributes to the network.
Ya they are. If you're not a full nose you're not contributing to the network you're just adding load to the full nodes.
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.
And that's Bitcoin today.
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.
Aaah, that explains it.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
Cross border - unless you need local currency
Payment channels.
No need to worry about replacing any numbers, your software does it for you.
Hardware wallets, etc... Use your brain, common sense prevents the majority of losses.
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.
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.
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.
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.
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.
Human beings are the problem.
That's based on this gwern estimate of the number of deaths caused by the folding@home project: http://www.gwern.net/Charity%20is%20not%20about%20helping
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.
Surely you don't really buy into such an enormous logical fallacy?
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