Why shouldn’t we reduce Bitcoin confirmation times?


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.

1 thought on “Why shouldn’t we reduce Bitcoin confirmation times?

  1. How can you buy lunch with bit coin on your lunch break and still have time to eat your lunch if the confirmation time is longer than your lunch break?

Leave a Reply

Your email address will not be published. Required fields are marked *