Why shouldn't we reduce Bitcoin confirmation times?
Bitcoin's confirmation times are a consistent source of confusion and criticism from newbies in the Bitcoin space, and it's very common for some people to see the ...
What's up, party people? Chris DeRose here, community director of the Counterparty Foundation, and in today's video I wanted to address the question, "Why can't we reduce confirmation times?" or perhaps better said, "Why shouldn't we reduce confirmation times?" So there's a lot of reasons why confirmation times are what they are, and to a certain degree I think it was a little bit specious that Satoshi felt that six times an hour or ten minutes was probably a good guess as to what the right value should be. There's a lot of people who speculate on what the ideal value should be, but what there aren't a lot of are people that are very educated in the subject matter who feel that lower confirmation times are great or even good. There's a lot of different reasons why the confirmation times are where they're at and not least of it is that confirmation needs to be envisioned not as a yes or a no. It's not to say that something is or isn't confirmed. You see a lot of altcoins that sometimes pitch this view. As soon as I hear that, I'm turned off, because what confirmation is is it's a degree or a spectrum of assurance that a transaction has been confirmed or that a transaction has been settled.
Now this spectrum starts at zero and ends at 99.999999 forever percent, never 100. At the time that the first block has occurred, there is a significant degree of assurance. By the time the second confirmation has occurred, there is a significantly higher degree of assurance. It goes from there probably even at an exponential rate. To say that when we take the confirmation blocks down to say a minute or something or two seconds, it's not to say that you get the same amount of assurance.
It is a fraction of that ten minutes no matter what you do. If you made block times one minute, then it is one-tenth as secure as ten minutes, and ten minutes are of course one-sixth as secure as one hour. So you've got to consider what is an ideal confirmation time. There's a lot of factors that go into it and truthfully I'm not an expert on that subject, but you have to consider that confirmations themselves are needed to maintain the network state, to solidify that state, but also to prevent forking. So if you made the confirmations too shallow or too short, what will end up happening is your forks will grow longer and you'll have basically the same amount of problems as you would have with longer confirmations. Not only that, but you'll have more forking, which increases uncertainty and there's significantly more problems that could occur by transactions being included in one fork and not in the other.
So when the network finally merged again say in an hour or ten minutes or whatever it is, you could end up having missed transactions or certainly any number of issues related to the certainty of your transactions that were in the mempool of some other fork. So with confirmation times, at the very least it should be understood that it's not necessarily a bug that we have a ten-minute confirmation time. It's probably a very good feature. If we were to come up with maybe an ideal scenario, it could be said that at the same time we calculate difficulty maybe that would be a time to calculate blocks. But then what you lose in that environment is the reliability of using blocks as a time unit. We know that blocks are every ten minutes roughly.
There is a high standard deviation on that, but roughly every ten minutes. We can use it as a measure of time and distance. I can make a bet, for example, in Counterparty that expires in a hundred blocks, and I know that that's a hundred times ten minutes of time that'll occur roughly. If we made it a dynamic sizing, we wouldn't have that ability. So you're back at, "What is the ideal size?" "It may not be ten minutes, but it isn't too far from ten minutes." And what's also certain is you don't necessarily gain very much by changing it.
You'd hard fork the network, you'd cause all kinds of problems for the minors and you'd have to sell all these changes, and what'd you get? Probably nothing. This gets into the issue, "Why does confirmation even matter?" because in many cases if you haven't noticed with Bitcoin, you can do a transaction, you can issue a spent. And if you are looking at a webpage or something, that spend will transpire pretty much immediately. You'll just sit there for ten minutes and wait for a confirmation. As soon as that transaction hits the mempool, that's enough assurance for the merchant to continue. There's a couple reasons for that.
Not only that it's likely to happen and it's likely to be confirmed, but also because the transaction is ensured typically by way of an insurance provider. In BitPay's case, it's BIP-70… Well, actually Coinbase's case, it's BIP-70 that they'll use to ensure that transaction gets validated, and they will pick up the slack, so to speak. They will ensure that that keeps going through if it is not picked up in a block. With the confirmation times, 40% of Bitcoin is a settlement mechanism and there's a degree of settlement certainty that the block times represent. I think that that's most of the issue around block times, but I don't know. Maybe you feel differently.
If you do, why don't you leave a comment below? Tell me how you feel. Maybe you have some more questions about Bitcoin. If you do, explore my channel and see if I've answered that question already. If I haven't, go ahead and tweet me, @derosetech. If you like this video, subscribe. Later, party people.