Miner's Choice: The Bitcoin SV Vision
There's no denying Bitcoin Cash has a vibrant and diverse developer ecosystem.
One of the newest (and most promising) Bitcoin Cash node implementations to appear is Bitcoin SV, a project born from the desire to empower miners by giving them the tools and data necessary to make informed decisions about critical protocol changes.
By finally giving them a choice and a voice (as originally intended), miners will be better able to drive the process of restoring Bitcoin to its optimal state of unbounded blocks and original op-codes.
In November, mining nodes running Bitcoin SV will activate a short list of upgrades on the BCH network, most importantly an increase of the default max block size from 32MB to 128MB. This is a stepping stone, part of a bigger roadmap towards 2GB by May 2020 – one which this article will focus on.
The Bitcoin SV Vision
nChain's presentation really resonated with me, and I felt it was something that should be heard by everyone in the wider community. So naturally I was frustrated by the thought that the content buried amongst 8 hours of audio would be missed by most people.
I decided that I would transcribe Jimmy & Craig's speech, in the hope that it provides some additional exposure to the Bitcoin SV vision.
SV Presentation, Aug 30 2018
Jimmy: Hi everyone I'm Jimmy Nguyen, CEO of nChain. I'll be leading our presentation today with Dr. Wright. First of all I want to begin by thanking everyone for being here. We're here because we all care about and love Bitcoin. And while we may have some philosophical differences that I think are important to talk about today, I think it's important to remind everyone that everybody in this room is here because they care about creating a Bitcoin protocol that we believe will fulfil Satoshi's Vision, because that's what Bitcoin Cash was birthed to do. It was to restore what Bitcoin was from BTC, and that's going to frame a lot of our conversation today.
I want to use our time this morning to talk about some overarching issues which explain - I think - our position on what should happen with the Bitcoin protocol. What I want to talk to you about today is our belief that the Bitcoin protocol - what we all need for everyone's benefit - is something that's stable, is scalable and is secure. I want to describe what we mean by that. What we mean by that is what we're proposing with our newly announced Bitcoin SV, designed to restore the original Satoshi Vision.
I know a lot of people have been asking to see code, we've just released overnight an alpha preview of the code on a GitHub repository. You can check it out, it's not designed to be tested yet, that's going to start in about a week or so and Steve can tell you more about that, but we're moving our process along. In addition, also announced overnight is the launch of a pool directed by Craig here - SVpool - for miners who want to join in running a node implementation that fulfils the vision we're going to talk about. That's open for pre-registration, a lot of people have already pre-registered, and this is part of our path to providing a choice for miners because we think that's really important that miners have a voice and a choice in what is happening with the Bitcoin roadmap.
We believe it's time for Bitcoin as an entire world and ecosystem to grow up and professionalize, and that's what we're advocating. And what do we mean by that? What we mean by that is a protocol that is stable. If you go back to some of the early Satoshi writings, the nature of Bitcoin is such that once version 0.1 was released the core design was set in stone for its lifetime. Now do we mean that not a single change can ever happen again? No that's ridiculous. But we do believe that just like the Internet lives on a protocol that has changed very little since its beginning and allow businesses to build applications and websites on it reliably, that the Bitcoin Cash blockchain needs to get to that point as well. A reliable, stable protocol that doesn't involve disagreements between developer groups every 3 or 6 months about what features should go in or not, because that's not helpful for anyone. And that's why we're advocating taking the steps that are necessary - which have started - to restore what was the original Bitcoin protocol, and lock it down except for any critical changes that people can propose from time to time. But we have to create something stable for the major enterprises of the world to build on top of.
Craig: Proposing doesn't mean you just put it out there. It means you come out with use-cases, with data, with testing. And not a little bit – a lot. You have to convince the majority of miners, and that's not going to happen the way it was, ever again.
Jimmy: So the best way for you to all think about it is: We want businesses of the world to build on top of this blockchain. Do you want them to build on sand, or do you want them to build on rock? The reason that's important to keep in mind is, a lot of us in this room are not running major enterprises, but when we talk to the major enterprises of the world when they're considering building on Bitcoin Cash, the first questions they ask us are about "Is it going to be scaleable enough to support this big project we have?” “At what point in the future can we actually implement?” "Should we invest millions of dollars from our business to start building this particular project if we don't know the chain is going to scale or we don't know what the protocol is going to be looking like in a year or two years from now?”
Those are the really pragmatic conversations that major enterprises have to have before they decide to build on something. That's why we're advocating creating a protocol that solid rock, that gives reliability to the major enterprises of the world, because that's what's going to lead to growth and scale of the network. So the benefits we're advocating are that there shouldn't be unnecessary experiments and changes on the Bitcoin Cash protocol. If we lock down the protocol and allow it to scale, what happens?
A lot of the disagreements that have emerged over the last few months are unfortunate, but they're the natural result of having a decentralized development community. There's nothing inherently wrong with that, but it inhibits the growth of the network. We think it's better once you have a locked protocol to let the business developers of the world create their applications and their projects on it, and we don't have to be engaging in unnecessary debates every 6 months among developer groups about particular features. It actually creates a better stable ecosystem for everyone and it provides more certainty, which at the end of the day leads to growth of a network. This means more money for miners and more revenue for all of the businesses that operate on it. Stability is good for any business ecosystem.
We also need something that's scalable, and I know there are certain disagreements in the Bitcoin Cash developer community about how you achieve scale and it's okay to have different opinions, but I think we have to remember that even in its earliest days from the early Satoshi writings, it was predicted that Bitcoin can already scale - this is way back then - larger than the Visa network could, with existing hardware - back then - for a fraction of the costs. That was always the vision.
Craig: It was never meant to be a home user network. I don't care whether people like that or not. I don't give a shit whether they like that or not. It was designed for datacenters. It's designed to be money. You'd never get 5 billion people using anything that's going to run as home hobby nodes. And if you want home hobby nodes, go make yourself a shitcoin, because Bitcoin's growing up.
Jimmy: That of course was also part of early Satoshi posts, which is that the design supported letting users be users, and the more burden it is to run a node then the fewer nodes there will be, and that will result in big server farms. Some people resist that, we don't think there's anything inherently wrong with that. And this is what's going to allow Bitcoin to grow up and professionalize. So what does this mean in economic terms? We did some modelling over the last week at nChain using some of our business analysts, to evaluate why it's so important to scale fast and now in terms of block size. The reason is there's a direct economic need for miners. In two years the block reward will be split in half again to 6.25 BCH. So anyone who's mining now will in two years receive half of what they're receiving today. In order to maintain even current profitability, what that means is in two years they have to make up that 6.25 coins worth of value in something else, which has to come in transaction fees and which has to come in higher transaction volume.
Craig: It doesn't happen because you have less coins. Some of these idiot ideas like BTC love to say "There's less coins so the price will double". Bullshit. There are not less coins, there are less coins being mined. What we'll find is this idea of a Ponzi dump. The speculation is going to end. In two years time we're going to get to a point where it halves and the price does not increase.
Jimmy: What we have to do is prepare the network now for the massive scaling that's needed to ensure miners have the same economic incentive to continue mining, to continue to secure and grow the network. So what does that mean in the future? That means miners are going to depend more on transaction fees and volumes. Their revenue streams will diversify, it won't just be the pure payment transactions (which will be the cheapest, as they require the least data), but things such as token usage, smart contract usage, applications that embed data and files and op-return, as well as a whole host of other things we're seeing from companies approaching us.
Individual transaction fees we still want to be kept low, because of course we want people to be using the network, particularly for its pure original purpose of electronic cash. But that means you have to have higher transaction volume and that means the block size has to be significantly increased now.
So let me walk you through some modelling we did – and this is rough, I don't ask you to accept it as an exact science. You might play with the variables we inserted in your own way, but the lesson at the end of the day is going to be clear. We did a modelling of what transaction fees would need to be, to make up for the 6.25 BCH value that will be lost in two years in block reward. We did it at three different BCH price points in two years. Assuming the coin is worth a $1,000 USD, which means you have to make up $6,250 worth of block reward, at $5,000 USD meaning you have to make up $31,250, and at $10,000 USD meaning you have to make up about $62,500.
We did it based on various transaction types, assuming that you would have a mix of transactions in a block, because one block is not just going to only have purely payment transactions. The transaction types we evaluated just as a start were payments, which are very simple at 225 bytes, maybe smart contract transactions at 1,000 bytes, and tokens at 1,500 bytes. There will be more, but this is just a start for evaluation.
We also did it at three possible transaction fee levels. The amounts here are expressed in USD as opposed to satoshi, but per byte, with the idea that fees might be really low, medium or high, depending on how the network evolves. When you model that out, what would be the transaction fees that happen? Of course they're going to depend on the size of a transaction.
At a low fee which we model that at $0.00009 of a U.S. dollar (so fractions of a cent per byte), a payment transaction (and this is still high – we think payment transactions should be less, but just for the purposes of this valuation) at a low fee possibly 2 cents, smart contracts transactions could be 9 cents, token transactions might be 13 cents.
We did it for medium and high fees, and we recognize that each block is going to carry a different proportion of any of these transactions in any given block – you couldn't exactly predict it, but we're looking at averages. So this actually assumes higher fees than we think would be ideal, but that means that even if we have higher individual transaction fees, that's going to require large blocks. So then we evaluated 'Well what would be the total number of transactions you needed in order to fill a block, to get enough transaction fees to make up this lost block reward?'
If the block capacity was filled entirely with just payment transactions (the smallest ones), then you’d need a lot of them. You'd need like 1.6 million individual transactions to generate the fee amount for the medium coin price target of $5,000 USD. If you did a mix where we just assumed 40% payments, 30% smart contract transactions and 30% token transactions, you would need a smaller number because some of these have a larger data size. So about 800,000 total transactions in a block. So what does this ultimately mean for block size? And this is what's so critical to our belief of why we have to start scaling larger now.
In the low transaction fee scenario, we priced out 'What is the minimum block capacity needed to have those transactions that would generate the value of 6.25 BCH?’ At a minimum you would need (assuming low fee transactions) at $1,000 dollars per Bitcoin Cash - 67.1 megabytes, at $5,000 dollars - 335 megabytes and at $10,000 dollars - 670.6 megabytes. But that's assuming the entire block is full, and we never want to get to a network where the blocks are 100% full.
This is just the minimum space that's needed to fit those transactions to generate that block reward. Ideally Craig's belief is that you should have a network where the blocks cap is (at least) 50x the daily average to ensure the throughput you need to grow. So we then calculated 'What would the maximum block size be at its highest, assuming a 2% block utilization?’ And then also if you wanted to get a different approach, 10% which we never really wanted to get to, but if you want to be a little more conservative you could do that. At the low transaction fee scenario it’s telling you that you need max block sizes in two years of 3.3 gigabyte, 16 gigabyte or even 32 gigabyte. The scenarios change if the transaction fees go higher – you don't need as big blocks because the transaction fees are higher.
Craig: Of course the other problem though, if transaction fees are higher then we won't get the volume, because we compete with other industries and other things like that. So unless we keep this low – which means big blocks, we lose.
Jimmy: But even under the higher transaction fee scenarios, you're still talking about needing fairly large block sizes. Here, 1.3 gigabytes, 6.5 gigabytes or 13 gigabytes, and even at the smallest you're talking 894 megabytes or 4 or 8 gigabytes. That's in two years.
If we have to get to that point or anywhere near that point - you can play with my variables, you can fiddle around with the numbers in ways you think are more acceptable to your way of thinking, but the same conclusion is going to be reached. You need to start getting bigger blocks to support the transaction volume and capacity needed to ensure that miners continue to make the same revenue necessary to make up for the block reward halving. That is happening in two years.
If we have to get anywhere near 4, 16 gigabytes in two years, we can't wait a year from now. We have to start that process now. That's critical because otherwise in two years mining is going to become less profitable and that threatens the whole viability and security of the network if the miners cannot make up the actual revenue they need to make up in transaction volume and fees.
Craig: More than that, people are already starting to look to the future and what they can do. They have options right now. They can either move into Bitcoin Cash, but that means they need to know in two years time that it will be there for them to actually put their transactions on, and this is the thing: It takes two to three years for real organisations to actually build applications. Everyone thinks this is a shit show where you write a quick app in three weeks. You don't. Real organizations spend years. When I worked at the Australian Stock Exchange, the NIPA network took five years of development. They planned five years on that network. That's a real exchange. SBI know these sort of things, two year planning. You don't put millions into these things thinking 'Oh it's okay, the protocol should be okay in two years'. You want to know it's going to be the same, no changes now and 6, 8, 10 years down the track or you don't do it.
Jimmy: So our calls for increased scaling now are not just arbitrary. It's not because Craig and I, or the nChain team sat around and said 'Oh we just need 128 megabytes’, or ‘We need whatever number you want to throw out'. It's based out of our instinct that there is a financial imperative for the mining network and their revenue to start scaling and scaling now. The other reason it's driven by is the conversations we have with major businesses who come to us saying 'Hey can you help us figure out how to implement "blank" on the Bitcoin Cash blockchain’. A property title registry, a new way of doing smart contracts, a decentralised Stock Exchange. All these kinds of things companies talk to us about, but they're reluctant to even begin development because the network capacity is not there and they don't know that it's going to be there, and it takes (as Craig said) some of these businesses at least a year sometimes two years to build a sophisticated project, which they'll do on the Internet because it's stable, but they are reluctant to even start doing on Bitcoin Cash and unless we as a community can convince them that this protocol is both stable and scalable at mass scale, it's not going to happen.
We just talked last week with a company that's got a venture to do property title registry on the blockchain. They would prefer to do it on the Bitcoin Cash blockchain but because they want to record not just the ownership of title but to include 3D graphic image files of the property of a building, a piece of land, that requires huge amounts of data (and they would pay a massive premium and transaction fee for the ability to do that) but they can't even start thinking about it on Bitcoin Cash with its current network, and you may think that's not important but that is where the future of transaction volume, transaction fees and miner premium fees is going to lay.
Craig: That group alone would be willing to pay enough so that there would be an annuity cost on the cost of their data. By an annuity cost, I mean life. The upfront payment of hard drives for the entire existence of the human race. They would pay that upfront at a premium for a distributed network that would support 1,000 different miners, more than we have now. I mean as in mining pools, the lot. That's what people will pay to put on this thing.
Jimmy: And so we are encouraging moving to that because that will ensure the viability of the network and its growth. And we have to stop thinking about Bitcoin Cash purely as its original (and we still think lead) purpose, electronic cash. That alone is not going to sustain the growth of the network given the mining block reward halving that's going to come, and it won't get big businesses to come make this what we think it should be – The global public ledger of the future. Just like we all live and operate on a single public Internet, we really believe, and are trying to move the crypto and blockchain world to operating on a single public ledger which is the Bitcoin Cash blockchain.
Craig: In discussions with people like the World Gold Council, just their settlement data - not trades – will exceed gigabyte blocks. Just daily settlement.
Jimmy: So then it gets to the question of 'Alright, there's philosophical differences right now between the developer groups, what do we do with the block size?’ When we announced the desire to launch our Bitcoin SV project, we believed that the default block size should be set to 128 megabytes and now maybe you can understand why that's just not some arbitrary number. That's a path to getting to what we think it needs to be in two years.
However, we're also perfectly open to the idea of just not really having a cap at all and letting it be miner configurable, because at the end of the day we believe miners should be directing much of the road show of what happens with Bitcoin development, as opposed to just the developer groups, and that's okay – they are the primary key users that sustain the network and it would allow them to configure based upon what market demands are, what market usage is, what their own individual desires are in terms of what types of transactions and capacity to mine.
So those are two different approaches with which we're perfectly happy and I think that a lot of people would be perfectly happy with a miner configurable approach. Bitcoin ABC has max block size configurable now in debug settings, but it's not apparent to a lot of miners. One of the things we want to do in Bitcoin SV is actually move this and make it much more prominent.
It's actually similar to Bitcoin Unlimited's emergent consensus approach. So a miner configurable approach I think is actually very consistent with approaches that different developer groups have taken. So in SV, as Steve can explain more later, he'll make it more prominent in terms of where you can see the setting.
Finally, let me talk about security. We all agree that it's important for the Bitcoin Cash network to be as secure as possible – I don't think anyone disagrees with that. We also agree that you don't just start scaling to bigger and bigger blocks just arbitrarily, that you want security confirmed in that. And so as Steve and Andy can talk about with you more later, we are starting our own gigablock testnets, starting two of them - actually three - two ourselves and one with the outside party, to continue the testing that others have started such as Bitcoin Unlimited. We'll be releasing data of that as it comes along.
Steve’s going to be working on code improvements and there's other things we can do with hardware acceleration that will help support security of it. We've just finished discussions with an outside security firm that will be engaged to audit the Bitcoin SV code, and we'll continue using them as well as a public bug bounty program to begin the steps to doing what major software development firms do. What a Microsoft would do, what a Google would do with software. They take steps to professionalize the process. There's nothing wrong with that. Not only is there nothing wrong with it, it's where the community needs to move.
Here are things that Steve is planning with our team for a safe upgrade: We'll be using the gigablock testnets we're running for stress testing, we'll provide data to the mining community so they can make their own decisions about what would be safe block sizes. We don't want to be the ones telling them every six months 'Here's what the block size should be'. We can certainly provide data. make recommendations, but leave it up to the miners to decide what they want to do, making informed choices on risk and reward, because we want to empower them to make their own choices.
Craig: This should not be a developer choice. This should be a competitive choice. Miners should compete to be the best. The thing is, we don't want to support every laggard miner at home. We want the best miners running this network for profit. And if that means 20% of the bottom ones drop off, that means the top ones make more profit. If there's more profit, then it attracts better people into the industry. That's how capitalism works. That's how free markets work, without any technocrat telling the free market what to do.
Jimmy: We were going to spend some time talking about some of the issues with changing the protocol but I'll save that for question and answers later when we get into some of the technical feature discussions. So let me close by just summarizing what we think are the advantages of the approach we're advocating. We don't think it's entirely irreconcilable with other team's approaches.
I want to be clear, we do not want a split of Bitcoin Cash.
We do not want a split of the work that people in this room have done for so long, because a lot of people worked very hard in this room to create what is Bitcoin Cash, and I think we're all very thankful and grateful. We do think that what the discussions that have happened over the last few months have revealed is, there's just a different philosophy about where we should be going and who should be directing the roadmap. We think we should be going quickly to a scalable - very scalable - but stable and locked protocol, so that the developer groups aren't having these unnecessary disagreements in the future. We believe that choices should be driven by miners and we should give them the choices to do that.
Craig: Bitcoin is not about having everyone run their node. That is not what decentralization was ever about. It is stable money. Right back from the beginning, there is one thing Bitcoin was designed to deliver, first and foremost is stable money. It has a distributed system, because any system that has a single player can be shut down, changed or altered – it is not stable. It is only through competition from the best miners competing that we end up with stable money.
Jimmy: So let me conclude by summarizing what we think are advantages of the approach we're advocating – we want scaling quickly and safely, but I explain why: This is not because Craig woke up and said 'Oh we want bigger blocks'. There is an imperative economically built into the system to do this and do it now. We want to lock the original Bitcoin protocol so that businesses can reliably build on it. Professionalize the whole process with quality assurance and security audits. Promote zero-conf security.
We want to create a pathway to rapid adoption globally, and not just for payments but by the big enterprises which will lead to the miner revenue which is critical. Unless they are being profitable and making money, miners will not continue doing this after two years, and the approach we're advocating will also lead to premium services for them, such as data, such as this property registry type venture for which they'll get paid more money given the data capacity needed.
Finally we want to empower miners with choice and a voice in this process, and let them drive it and let developers groups accomplish what they set out to do – restore Bitcoin. But then, allow Bitcoin the room to grow and breathe in a way it never has really been allowed to do, and then see what happens. If there are changes that people want to propose years down the road, fine consider them then, but do not make this an experiment every six months.
Craig: There was a comment 10 years ago. 'In 20 years, we either have massive transaction volume or none'. We are half way. If we do not scale in the next couple of years, it's over. That simple. All your investment, piss it away in the wind. We either scale or you may as well go home now.
Jimmy: So I will leave you with this thought again. We need to create for the enterprises of the world the solid rock foundation that is massively scalable and then they will come build. Otherwise they will not come build on sand. So please keep that in mind as we engage in the discussions over the next hours and days. We want to thank everyone for their passion and support of Bitcoin. We all have that as a common goal and I think that's critical for us to all remember.
Update: Jimmy kindly provided some slide data from the presentation, which I've added to the post. The numbers are really telling.. We must scale now and we must scale fast.
8 of 8 reviewers say it's worth paying for
0 of 8 reviewers say it's not worth paying for