Back
Scaling, Security, Stability & Secure Instant Transactions
In January 2019, Bitstocks CTO, David Arakelian invited Steve Shadders, the Technical Director of nChain (the development company that brought us the Bitcoin SV project), to the Bitstocks studio. In their hour-long conversation, they ran through what’s been happening at the Bitcoin SV project and what lies ahead in the year to come. If you’re a dedicated YouTuber, and have the time, make sure you watch the recording. If you’d prefer a more concise version of the core discussion, here’s a selection of excerpts from their conversation.
David: Could you let us know a little bit about yourself, how you ended up in Bitcoin, how you joined nChain, and what are you currently doing?
Steve: Well, I started in the Bitcoin world in 2011, and I was a total noob at that point. I actually looked up my very first post on the BitcoinTalk forum a couple of months ago I. I was asking why we have a ten-minute block time and why can't we shorten it to one minute. So everybody learns from their mistakes eventually…
I got involved because at the time mining pools had just started to become a phenomenon, and there was very little software around that could handle a volume of traffic that mining pools have to have to deal with. It was just after GPU mining had become a thing. At that time, everyone was using a piece of software called push-pull D which is written by Jeff Garzik. And, no offence at all meant to Jeff (he knocked it up quickly because there was a need for it), but it didn't anticipate certain problems that the Bitcoin client had at the time. For example, it could only feed a certain amount of work out. So I built a version of a mining pool engine that could feed off multiple Bitcoin daemons. The project just kind of snowballed and got bigger and bigger, and at one point I think it was running close to 50% of the network.
I left the Bitcoin world for a few years and got dragged back into it by a colleague of mine who thought it would be a good idea for me to run a mining pool. After two years of mining pool engine development, I'd never actually run a miner or a pool myself. That was when I met Craig, early in 2017, and started getting involved with nChain doing mining pool related stuff. And again that just snowballed until here I found myself living in London and heading up the engineering department of nChain.
David: So you have a pretty good understanding of the Bitcoin protocol and the software implementations. I’d like to know why you started working on Bitcoin SV? And also, tell us about the Bitcoin SV project’s roadmap for the next year and what you want to achieve with Bitcoin SV.
Steve: The Bitcoin SV project has been described as having four tech pillars, the four S’s which are scaling, stability, security, and secure instant transactions (or zero confirmation transactions).
Steve: Stability refers to keeping the protocol stable, and it is that aspect that brings a huge boost to the project’s development. By keeping the protocol stable, we're not wasting any time or energy having discussions and arguing about protocol changes, like we were for the vast majority of last year. Instead, we can really focus on scaling the security side of the project. I like to talk fairly extensively about making sure we've got really solid QA (Quality Assurance) processes in place to deal with mistakes. While mistakes will always slip in, a robust QA process lets us catch them before they cause problems.
Steve: The scaling aspect is one of the reasons why the Bitcoin SV project came into existence. We were somewhat frustrated with the pace of development work in Bitcoin Cash. With Bitcoin SV there's a lot of things we can implement internally, although we do so extremely carefully - we don't want to make consensus-breaking changes.
There are also other of our approaches which have delivered success. At present, many are only being used on the testnets in the Gigablock Testnet which is taking a lot of the work away from bitcoind. Bitcoind is a nightmare of a violation of the principle of separation of concerns. It does a whole lot of things, and it doesn't need to do all of those things.
The important part of Bitcoin is making sure that the consensus rules are respected and not broken accidentally. There's a whole bunch of other stuff such as the peer-to-peer networking code, that is not truly part of the consensus protocol and doesn't necessarily need to sit inside a single process. One of the things that we've been working on as a proof-of-concept for the Teranode Project is to build an external agent that pairs with the Bitcoin node and handles all of the peer-to-peer work on its behalf.
Bitcoind handles single connections quite well, but it handles lots and lots of connections quite badly. So, if this external agent can sit there and handle the multi-threaded parts of peer-to-peer networking and then just feed transactions in and out of the Bitcoin node on a single connection, the collective machine delivers an awful lot more performance.
We’re also doing internal work on bitcoind as well, but that's a slower path to success which is why we're doing all these things in parallel. It's also an interesting proof-of-concept for the notion of the teranode, which is the idea of breaking up bitcoind into multiple microservices. We need to start doing that at an early point because when you start separating the components of Bitcoin SV, that's where you begin to understand and see the dependencies and interaction between different components and how they can be broken.
David: I tend to agree. I think if someone was to have a look into the evolution of bitcoind, it’s a little bit confusing to understand what it provides out of the box. It can be a wallet, it can be a miner, and it can provide blockchain data for other people to synchronise with - it does a lot of things. And yet, in some of those aspects, it doesn't perform quite so well.
If we were to decouple all these components into single agents or entities or software as you suggest, and each of them performs their task really well, we'll have quite drastic improvements when it comes to using the Bitcoin protocol overall. Two examples that come to my mind is GUI and API’s. I don’t think the GUI (Graphic User Interface) is supposed to be an out-of-the-box aspect. There are SPV wallets and other proper mechanisms to safeguard your wallets outside of the Bitcoin network, offline. You can use them to interact with the Bitcoin network with passphrases and everything, so I think that code on its own should be completely wiped out and never brought back.
The second thing: In my opinion, bitcoind is completely lacking proper API's to interact with the network. The database and the blockchain is growing exponentially and going forward its growth will continue to escalate, and we’ll need stable API’s to handle the load. We need easy access to the data. Right now, for example, for developers to interact with the network and to find out how much funds you have in a given address or transactions, it's a constant hop between different API's. This is frustrating because, first of all, you lose that scalability, and secondly, the process is continually changing. In the upcoming versions of Bitcoin Core they are removing some API’s that they are rebranding. It lacks the stability that API developers and developers, in general, require to build software on top of it.
David: In terms of security, you mentioned that you were quite rigorous about it. Tell me, what measures have you put in place to provide a high level of scrutiny?
Steve: Well, there are a few different things. Internally in the Bitcoin SV team, we've got a formalised Change Management Process which means there’s a specific set of steps that any piece of code has to go through before it gets rolled out.
The Bitcoin SV project consists of two independent branches: a development branch and a QA branch (the QA team is almost as big as the development team). Any change has to get signed off by both teams which means that code basically goes through an iterative cycle as developer work on it, they get a code review from their peers at the dev team and some external people as well, and then it feeds into this QA process which is about five different test environments. Code has to pass through these five different sets of tests where every new set is a regression test. This has happened for every piece of code and functionality that’s been added in the past: it gets tested and retested and then it feeds into our public testnets.
Something that’s on my to-do list for this year is to get the business community engaged in those testnets to make sure that every exchange and every wallet with a test instance of their software are running it on those testnets. This will make it easier to put code out for public review.
This brings me to the second key pillar of our security strategy which is our bug bounty program, one of the biggest in the world. Our bug bounty programme rivals those of the Google’s and Microsoft's of the world. The programme encourages external security researchers to use the code and see if they can break it and we offer a hefty reward if they succeed.
The third pillar is the security audit process that we've just been through. What we did was we engaged with a professional security audit firm to do a complete audit which took about six weeks. It's probably not exhaustive as there's more that they could do, and so we're planning on engaging them for further work.
Still, the audit helped in a couple of ways. First, it identified a few issues that we needed to resolve both in code and in terms of process, and it also provided us with additional testing tools, etc. They helped us with instrumenting a fuzzing tool which basically takes a piece of code and throws random data at it to check that it's giving the expected output. In one sense, security is never absolute. It's a process of continuous improvement.
Recently we did have a bug get through our process. Though it wasn’t a serious bug, it fired up our spirit of continuous improvement, and we’ll be looking at how that got through. What would have had to have been different in the code review process to have ensured that it got caught in the code review stage or one of the subsequent testing stages? I'll be looking into that to ensure we improve our process, so the same type of bug is more than likely to get caught next time instead of slipping through the net.
Steve: In the upcoming year we’ll be working on the secure instant transactions side to make sure Bitcoin SV supports some of the things that we want to do. A merchant API will be one of the critical things. The form, whether it’ll be a REST-API, JSON-RPC or a binary protocol, has not been settled.
But, some form of API is crucial because it will enable merchants to get all of the assurance that they need about a zero confirmation transaction. They can find out in advance what transaction fee is required by 99.9% of the miners, which gives you a relatively high level of assurance before you even broadcast the transaction. The zero-conf problem largely goes away if you can broadcast a transaction to miners and be sure to get a response from them a second later to say that they've accepted the transaction.
How do you create a holistic approach to providing banking like services on Bitcoin that is delivered so seamlessly and integrated, that you don’t even know it’s there?
At Bitstocks, we’re building a platform that harmonises the two Ring Systems of Sovereignty. We are calling this model Gravity.
Watch CEO, Michael Hudson's presentation from the CoinGeek conference where he revealed the Bitstocks Bitcoin SV Banking Ecosystem and Platform, Gravity, and introduced the Bitstocks perspective, formulated around what it really means to be Human in the modern world. You can also head straight over to our website to sign up for Gravity.
*Capital at risk.
© 2022 Bitstocks. All rights reserved.
