Six years ago the Bitcoin ecosystem didn’t have the resources to support multiple development teams – it certainly does now. Assuming you have the resources, that is a good strategy– you increase your chances of success, because you only fail to solve the problem if all of the solutions fail.Īpply that reasoning to development teams and, assuming you have the resources, it is better to have multiple teams because there will be less disruption if one of them fails. Part of eliminating single points of failure is trying different solutions to a problem at the same time. Also known as “decentralize all the things”/“diversity is good”/“competition is good”. What to do about the short-term scaling issues brings me to my third priority: eliminating single points of failure. I’d prefer a nice, simple, clean solution, but I’m old enough to know that most of the world’s great technologies are built on top of horrifying piles of legacy cruft, and they work just fine pretty much all of the time.Īnd Bitcoin will survive without a short-term solution, but adoption and growth might be set back a year or two. In the long run I think everything will work out fine, no matter what happens with the block limit.Ĭlever engineers will find ways to work around around the limit, whether that is ‘extension blocks’ or the lightning network or a sidechain that everybody moves their coins to doesn’t really matter. I’m still worried about reliability of the network in the short term, which is why I’ve been so vocal on the block size limit issue, and which is part of the reason I’m supporting alternatives to Bitcoin Core. I’m still active asking dumb questions to people smarter than me to try to avoid mistakes as the protocol evolves. And seeing multi-signature “p2sh” adopted is very personally satisfying. So if those are my top priorities, what should I be working on?īitcoin-the-protocol is doing really well security-wise the responsibly-report-a-vulnerability-in-bitcoin mailing list has been quiet for many months. Those are still my top priorities, but I try to take a higher-level view, looking at the entire Bitcoin ecosystem instead of just the Core software implementation. When I was lead maintainer of Core I had the following top-three priorities:Ģ) Keep the network reliably processing transactions. Madness! Chaos! ANARCHY! … I hear some people say, but there is a method to my madness. I’d still like to focus on protocol-level, cross-implementation issues but lately I’ve been distracted and have generated a lot of controversy (and hurt feelings) by helping out with some other implementations (first XT, lately Bitcoin Classic, maybe Bitcoin Unlimited soon. Almost two years ago, when I stepped down as lead maintainer for Bitcoin Core, I wrote: I’m pleased to be able to focus more on protocol-level, cross-implementation issues and less on issues specific to the Bitcoin Core software.
0 Comments
Leave a Reply. |