Is it true that bitcoin could be extremely slow?

Question

I am trying to understand the algorithm of bitcoin.

Let A be a node, and let (...,T_0,T_1,T_2) represents a block chain that A has at some time.

Here, T_i designates a block which was created at the time T_i, meaning that the block T_n was created before the block T_{n+1} was created.

Now, say miners C and D created two different blocks T_3 and T_3’ within 10 minutes. Then, A appends these two blocks to the current block chain and store them separately. Following the above notation, these two chains are (...,T_0,T_1,T_2,T_3) and (...,T_0,T_1,T_2,T_3’).

Now, say E sent F some bitcoins and made a transaction which is included in the block T_3.

After some time, if the blockchain (...,T_0,T_1,T_2,T_3’) is chosen to be the correct one, the chain (...,T_0,T_1,T_2,T_3) is removed from server. (Actually, at this point, these two separate blockchains do not appear in this way. That is, they would appear like (...,T_0,T_1,T_2,T_3’,T_4’,...,T_n’) and (...,T_0,T_1,T_2,T_3,T_4,...,T_n) because as time passes new blocks are added.

Assume that the transaction that E sent F some bitcoins was not included in any other blocks except the block T_3. (This is possible if E sent F very small amount of money, so if this transaction costs really tiny small fee, miners would not choose this transaction to be included in their block).

In this case, if E wants to send some bitcoins to F, does he have to make a transaction all over again?

Answer 1

In this case, if E wants to send some bitcoins to F, does he have to make a transaction all over again?

Not necessarily. A blockchain reorganization will cause transactions that were not confirmed in the "winning" blockchain to remain unconfirmed and placed back into the mempools of nodes which switched blockchains. So the transaction will still be in nodes' mempools and could still be picked up by a miner. If the fee was very low, the situation would be the same as having a "stuck" transaction.

Answer 2

Now, say miners C,D created two different blocks T_3 and T_3’ within 10 minutes. Then, A appends these two blocks to the current block chain and store them separately. Following the above notation, these two chains are (...,T_0,T_1,T_2,T_3) and (...,T_0,T_1,T_2,T_3’).

This situation when there are multiple chains of the same length simultaneously co-exists is called a fork. The research paper at http://homepages.gsd.inesc-id.pt/~ler/docencia/rcs1213/papers/P2P2013_041.pdf shows that the probability of fork depends on

1. the propagation delay of a block in the network which implicitly depends on the size of the block(1 Mb in bitcoin(without segwit2)) which effects
2. the expected duration of consecutive block generation time(10 min in bitcoin).

It also shows the probability of fork proportional to (avg. block generation time)/(avg. propagation delay). Considering the number in bitcoin the probability that the length of fork i.e n value, in this case, will reduce exponentially.

In this case, if E wants to send some bitcoins to F, does he have to make a transaction all over again?

Adding to @Andrew chow's answer, if the txn from E to F is propagated to sufficient fraction of miners who extending the chain (...,T_0,T_1,T_2,T_3,T_4,...,T_n) then it is likely that they will include the txn(E -> F) in the chain as it is yet unspent.

Assume that the transaction that E sent F some bitcoins was not included in any other blocks except the block T_3.

Additionally, the main reason for a txn not getting included in the block are
1. It is not propagated to sufficiently many miners.
2. Since a block is limited in size, and the inclusion of txn is purely dependent on the miner mining the block, a miner may prefer a txn with higher txn fee over any other.