Warning: session_start(): open(/tmp/sess_8e927aec763768088b51ba47c2cf0992, O_RDWR) failed: Permission denied (13) in /home/thepoker/public_html/kirby/toolkit/lib/s.php on line 118

Warning: session_start(): Cannot send session cookie - headers already sent by (output started at /home/thepoker/public_html/kirby/toolkit/lib/s.php:118) in /home/thepoker/public_html/kirby/toolkit/lib/s.php on line 118

Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /home/thepoker/public_html/kirby/toolkit/lib/s.php:118) in /home/thepoker/public_html/kirby/toolkit/lib/s.php on line 118
What is a confirmation?

What is a confirmation?

A confirmation is when a transaction makes its way from the transaction pool in to the blockchain.

Or in other words, it's when a bitcoin transaction becomes irreversable.

Easy.

How does it work?

Okay...

  1. When you make a bitcoin transaction, you're basically inserting a line of data in to the bitcoin network.

  2. This transaction data then gets relayed from node to node, until everyone on the network holds a copy of your transaction.

  3. But initially, new bitcoin transactions are held the "memory pools" of each node. This is like temporary memory on the bitcoin network.

  4. Transactions in these memory pools are all valid, but they're not permanently stored on the network (yet). For that to happen, they need to be written to a file called the blockchain.

    Once a transaction gets written to the blockchain, it's pretty much in there forever.

So until a transaction is "confirmed" and gets written in to the blockchain, it hasn't been permanently stored on the bitcoin network.

There are so many transactions taking place all over the network (and at the same time) that it makes it difficult for the entire network to agree on the order of each one. This is why new transactions get stored in memory pools at first, before being written to the blockchain.

Are transactions in the memory pool reversable?

Sort of.

The only way you can "reverse" a transaction in bitcoin is by trying to use the bitcoins you're sending in one transaction in a second transaction.

Example.

  1. I owe you 1 bitcoin. So I create a transaction that sends this bitcoin to your address, and I insert it in to the network.

  2. However, I decide I don't want to send you this bitcoin anymore. So before this transaction propagates the entire bitcoin network, I also create a second transaction that sends this bitcoin to a different address (one that I own), and I insert it in to a different node on the network.

    You can't delete a transaction from the memory pool; the only thing you can do is try and "overwrite" it.

  3. As a result, there are now two competing transactions on the bitcoin network that are trying to send the same bitcoin to different addresses.

    For this to have a chance of working, I have to insert the second transaction in to the bitcoin almost instantly after the first. Nodes will reject "duplicate" transactions, so if the first transaction gets relayed to every node on the network by the time I try and insert the second, it's not going to get very far.

  4. Now, the transaction that becomes permanent will be the one that gets written to the blockchain first. It could honestly be either one; it all depends on which node is able to successfully add their memory pool to the blockchain first…

Even if you try and reverse a transaction in the memory pool (by sending a second one in at the same time), there's no guarantee that you're going to be able to shaft the original recipient… the first transaction could just as easily be the one that makes it in to the blockchain.

So how do transactions get in to the blockchain?

Here we go…

"Miners" are nodes on the bitcoin network who work to get transactions from their memory pools in to the blockchain.

Now, mining is an article (or three) in itself, but it basically boils down to this:

Mining (basics).

If you run the bitcoin software and turn mining "on", your node will do this:

  1. Grab transactions from the memory pool.
  2. Hash them all together with another number, which will return a random number as a result.

    SHA256 spits out much bigger numbers than this, but don't worry about that – this is just an example.

  3. But the goal is to get a result that is below a certain target value.

    The target is obviously a much bigger number too.

  4. So your node will keep trying different numbers until it find one that works. And if your node is successful, those transactions will get added as a new block on to the blockchain (and you will earn some bitcoins as a reward).

And that's how transactions get from the memory pool in to the blockchain.

Bitcoin deals with huge numbers, so finding a number that works takes a lot of processing power and luck. Therefore, although anyone can find a number that works at any time, all the competition makes it very difficult for a single person to do it.

This is why mining exists – to make it so that no one is able to single-handedly control the transactions that get added to the blockchain.

But anyway, back to confirmations...

Why is a confirmation useful?

Because when a transaction makes it in to the blockchain, it cannot be overwritten or removed.

So effectively, if someone is waiting for a "confirmation" they are waiting for the news that the transaction has become permanent, and that the bitcoins they have just been sent are not going to end up somewhere else.

What does it mean when a transaction has 2+ confirmations?

The first confirmation is when a transaction makes it in to the blockchain for the first time. All additional confirmations are simply when new blocks get mined on top of it.

Expert gif.

So...

  • 1 confirmation = when a transaction first gets mined in to a block in the blockchain
  • 2 confirmations = when another block gets mined on top of the block that transaction is in
  • 3 confirmations = when another block gets mined of top of that

And so on...

So when you see that a transaction has "X confirmations", it makes more sense to think of it as being X blocks deep in the blockchain.

Why would anyone want to wait for 2 or more confirmations then?

Because even if a transaction gets in to the blockchain, it's actually possible for it to make its way back in to the memory pool.

I know, I somewhat lied about transactions not being able to make it out of the blockchain.

You see…

  1. Ocassionally two (or more) miners will mine a block at same time. If this happens, both of these blocks will get relayed around the network.

    New blocks get relayed just like new transactions.

  2. Nodes will try and build upon whichever block they receive first, which means that half the network will be trying to build on one block of transactions, and the other half on the other. So if you look at the overall picture of the blockchain, it will look like a "fork".

    The current state of the blockchain.

  3. But forks aren't a problem, because eventually another new block wil be mined, extending one of the chains (it doesn't matter which).

    Someone with a blue block is first to mine another new block.

  4. One chain will now be longer than the competing one, so when nodes receive this latest block, they will adopt the longest chain and ditch the shorter one (because nodes always look to work on the longest chain available).

  5. The other block will fall to the wayside, and the transactions in this block will make there way back in to the memory pool, ready to be re-mined back in to the blockchain.

So as you can see, forks are natural and harmless. However, some people like to wait for a few confirmations just to be unneccessarily sure that a transaction doesn't end up back in the memory pool because of a fork.

888 Poker.

Subscribe to thepokerbank

I'll send you an email if I add something new and interesting to the website.

Don't worry, it doesn't happen very often.


Warning: Unknown: open(/tmp/sess_8e927aec763768088b51ba47c2cf0992, O_RDWR) failed: Permission denied (13) in Unknown on line 0

Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0