What is "transaction confirmation time"?

When I say confirmation time is “subjective”, I mean that there is no mandatory rule that determines when a transaction is considered “confirmed”. The best any technology can provide is guarantees of how impracticable/expensive it is to rollback a transaction. Different recipients will be satisfied with different types of security. For example, many merchants won’t consider your bitcoin transaction received until it “goes down” to a depth of six blocks, while some will accept four blocks, and some will wait as long as ten. The point is that they decide for themselves. “Confirmation time” is determined by the degree of caution of the seller.

So what types of safeguards are there? There is a whole zoo of approaches and ideas for security assurance, but I would say that most of them, if not all of them, can be categorized into three types, which I will describe and discuss below in descending order of strength.

Deterministic finality

The strongest form of confirmations is usually called “deterministic finality”. Essentially, this means that nothing but a hard-fork is able to undo a transaction. This type of confirmation is implemented, for example, in PoS systems where time is divided into rounds and it is guaranteed that transactions from previous rounds cannot be undone. Deterministic finality exists, however, also in PoW: to implement “pruning” of Ledger data, we must have a guarantee that sufficiently old transactions are committed. This guarantee allows us to discard data about transactions that occurred deeper than a certain point, and keep only the set of UTXOs available at that time, and part of a full registry of some fixed size. In an “end of the world” scenario, where a very deep reorganization would have to undo an already-finalized transaction, the network would come to a halt and users would be forced to manually resolve the conflict as they see fit.

However, the depth of finality must be large enough, otherwise short-term 51% attacks can bring the network to a halt. In Kaspe ($KAS), for example, this value is set to 24 hours.

https://coinmarketcap.com/currencies/kaspa/

The depth varies from system to system (for example, because systems with lower bandwidth can afford to have longer finality windows without excessively increasing the hardware requirements on which the network node runs), but the order of magnitude is always days. Systems on PoW are not able to safely provide fast finality without creating extreme vulnerabilities.

Consensus Nakamoto (NC).

The next best option is Nakamoto consensus (NC) type confirmations. In theory, NC guarantees that the probability that an attacker with 49% of the network’s power can undo a transaction decreases exponentially with time. This form of guarantee is weaker because:

It provides no defense against attackers with 51% power;
Even if an attacker with 51% does not exist, the guarantee is “only” probabilistic.

Since we have no way to accurately measure time within a consensus (the timestamps in blocks can be manipulated), the only available way we can approximate time periods is by counting the number of blocks.

Thus, NC security claims that the success rate of a 49% attacker decreases exponentially depending on the number of blocks stacked on top of the target transaction block. And here there is one very important subtlety: this property takes place only if the proportion of “orphan” blocks in the network is very small. This is the reason why traditional blockchains don’t scale: increasing the speed or block size will lead to more orphan blocks and worse security. The reason we say that Caspa solves the cryptocurrency trilemma is that the GHOSTDAG protocol manages to remove this obstacle: since the blocks in it do not become “orphans”, the increase in the block generation rate does not worsen the security of the network.

So when we say that Caspa has “instant confirmations”, we mean that it is the only technology on PoW that provides Nakamoto consensus type confirmations as fast as the network allows. In all other PoW technologies, the block creation rate must be low enough to avoid orphan blocks. For example, the Kaden network is divided into several traditional chains (shards), so although it can, in theory, generate up to 20 blocks per second, each individual chain has a 30-second block generation time, which cannot be reduced without compromising security. While ChainWeb allows multiple chains to be “glued together” so that an attacker must attack them all together, the user still has to wait for confirmation on a specific chain containing their transaction. That is why, despite the high overall block generation rate, the confirmation time there remains long, and ChainWeb cannot cope with the solution of the trilemma.

Another interesting example is Hathor. Roughly speaking, Hathor networks form a DAG (directed acyclic graph) of transactions, similar to Iota’s Tangle 1.0. However, to avoid survivability issues, they also create a traditional chane, a block of which can point to a transaction from the DAG (and the reward per block incentivizes miners to find blocks for that chane). For a transaction to be considered NC-safe here, it must be referenced by a block deep enough in the chane. Thus, the Hathor architecture cannot provide fast Nakamoto consensus type security either.

Taking all of this into account, it is clear that, for example, Bitcoin’s “six block rule” is not so much a rule as a recommendation. Does it always apply? I would say no. For example, if someone transfers me an insane amount of bitcoins valuable enough to fund a 51% attack 20 blocks long, I will wait longer. In fact, for insanely large amounts, I wouldn’t count on Nakamoto’s consensus at all, but rather wait a few days for the finality rule to take effect (and of course this is all extremely simplistic. First, a 51% attack requires much more than money: scarce specialized equipment, for example. Also, successfully double-spending bitcoins 20 blocks deep would probably devalue the entire crypto market in general to the point where the attack would end up being very unprofitable. But you get my point).

A common feature that I see in many technologies is that the user interface of the respective wallet or ledger explorer marks a transaction as “confirmed” the second it appears on the blockchain. This interface is very much misleading. “Guarantees” in this case are meaningless. I suspect that some projects use this trick because it makes their technology seem faster than it actually is, but this is very reckless behavior because it gives users the false impression that the transaction is “confirmed” too soon. when in fact it is still unstable. So it’s only a matter of time before someone sells something of value, part with the buyer because the transaction is “confirmed”, and then find out that the block was lost, retroactively (which is not negligible if the transaction is located in the newest block). ). I want you to realize this: bad UI solutions designed to make the technology seem faster than it is lead to scenarios where the user loses money even if both sides of the transaction were fair. For this reason, Caspa wallets display transactions as “confirmed” only after the depth of the blocks in which they were carried out is at least ten seconds.

Rational confirmation

What is “transaction confirmation time”?

Now we come to the weakest form of confirmation, which I call “rational confirmation”. In this type of confirmation, you are given no guarantee that the attack is impossible or requires more resources and/or luck. But it does guarantee that the attack is “irrational”: although the opponent can very easily launch an attack, it will hurt him more than it will hurt you.

The advantage of the rational approach is that it does not depend on Nakamoto’s consensus and thus can be very fast.

The downside is that it is much more influenced by external factors (e.g., incentives for party A to harm party B even at the expense of harming itself), and these external factors are much harder to predict and analyze.

As an example, consider a very good idea: proof of double spend (DS) cryptocurrency Nexa.

Before I continue, and to relieve unnecessary tension in advance, I will emphasize again that it is not my intention to argue that DS evidence is bad. They aren’t. They are awesome. It’s a neat, easy-to-understand idea that clearly demonstrates both sides of the trade-off in rational proofs, and it’s only given here as a good example. Everything I argue applies to any form of rational deterrence (say, social slashing in PoS systems) as a form of security. I furthermore limit my discussion to only one of the two forms of DS evidence developed by Nexa, namely “DS detection” (“DS detect”).

The idea behind the DS proof is simple: when Alice pays Bob, say, one Nexa for a cup of coffee, she does so with a special kind of transaction. In this transaction, Alice locks up, say, 5 Nexa on deposit. If Alice tries to spend that same Nexa to buy a cup of coffee from Charlie, some miner will notice the double spending. The miner can then publish a confirmation of this double spending to reclaim Alice’s deposit. Bob, knowing about this protocol, gets the following guarantee: as soon as Alice’s transaction hits the mempool, even before it is in the blockchain, he knows that if Alice tries to double-spend, she will lose 5 Nexa. So, yes, Alice can use the same Nexa to buy a cup of coffee from both Bob and Charlie, and, yes, the payment will only go to one of them, but as a consequence, Alice will be penalized 5 Nexa.

This provides an interesting compromise. On the one hand, the guarantee is not a function of time, but is applied instantly (and this is the type of confirmation in question when it is stated that “Nexa offers confirmations with zero latency”). On the other hand, it is much weaker than the Nakamoto consensus guarantee. It does not prevent an attack, but “only” deters one from it. In addition, the value of the deposit may not reflect the rational aspect of the problem: there may be external factors that make it profitable for Alice to pay 50,000 Nexa to cause Bob a loss of 10,000 Nexa. For example, Alice could be an evil business tycoon who wants to kick Bob out of business in order to demolish his shack and build a shopping center or skyscraper there. Another example: Alice can be a miner with 10% of the network hashrate, then she can pay Bob 1 Nexa for his coffee, and still mine the block in which she placed a) a conflicting transaction in which she pays 1 Nexa to herself, and also b) proof of your own double spending. If Alice manages to mine the next block, she will get a cup of coffee for free. If she fails to find the block, she will pay for the cup of coffee she drank, but her attack will remain hidden and she will not be penalized for trying. In other words, the 10% miner is attacking the DS evidence, which gives him a 10% chance of double spending, but does not expose him to any risk. The only way to avoid such an attack is to wait and see the transaction on the blockchain, i.e. return to using the Nakamoto consensus, along with its characteristic confirmation time.

To conclude the discussion of DS proofs, if I had to express everything in one sentence, I would say that they allow sellers to get immediate confirmations, but require them to request deposits. A very large deposit (on the order of 51% attack cost) makes their business unprofitable, and the security guarantee weakens as the deposit decreases.

From a more general perspective, rational acknowledgment protocols like DS-discovery allow recipients to take risks for the sake of improving their own “responsiveness”. That’s not a bad thing; it’s always nice to have options.

So, to summarize, there are three types of confirmations: deterministic, NC, and rational. Each of them provides guarantees weaker than the previous one, but in return may provide other advantages. For example, the Nakamoto consensus can be decentralized, while there are currently no decentralized technologies that offer fast objective finality, and rational confirmations can be instantaneous, while the Nakamoto consensus requires waiting for a transaction to be included in a block, and burying that block under the next few.

When you see someone talking about “confirmation time,” you should always be careful about what type of confirmation is being discussed at that moment, and I hope the ideas in this article will help you become more critical in your discussions.

Key Findings:

Unlike TPS/BPS, confirmation time is subjective.
There are many different types of “affirmations” and some forms of them are weaker than others.
It makes no sense to compare wait times for different types of confirmations and ignore the guarantees they provide.
Only strong forms of confirmations depend on the consensus layer variant. Weaker forms are implemented on top of L1 and are largely independent of them.
Unfortunately, in many technologies, the interface of wallets and the like displays a transaction as “confirmed” prematurely, misleading users as to how long it takes for confirmation to actually occur.

Read more articles about cryptocurrencies and mining at COOL-MINING.ORG.

Do you like to read similar articles about cryptocurrencies and mining, do you want to support me as an author or ask questions? Be the first to know the news, subscribe to my telegram channel CRYPTO WIKIES | Bitcoin & Altcoins Mining