In order to send a transaction, one has to validate 2 previous transactions. Why is it 2, instead of 1 or 3, 4, 5?
1 is impossible here. It would be just a blockchain, not a tangle. But it's a good question why not 3 or 4. "Simplicity" maybe one of the reasons. Another one is less work for tip selections.– alexpodsFeb 19, 2018 at 22:17
it does not directly transforms into a "blockchain". it would be a linked-list-like structure with a PoW-spam mechanism unlike blockchain which needs PoW for consensus– instantlinkMay 12, 2018 at 14:35
@instantlink by the common definition, a blockchain is simply a securely linked chain of blocks: en.wikipedia.org/wiki/Blockchain– kfxMay 13, 2018 at 10:40
@kfx right. the structure would be same. Yet the model is still different– instantlinkMay 14, 2018 at 19:18
Let me complement the whitepaper based answer with a bit more explicit technical arguments.
Confirming just one transaction would lead just to a linked list of transactions - in other words, a blockchain.
Confirming more than two transactions would (1) increase the work required to select valid tips and (2) increase the probability than an invalid tip is selected. Both are bad things. Assuming valid tips are selected, the network would indeed become more secure. However, similar increase in security can be achieved by a simpler and more flexible method: by increasing the amount PoW needed to verify each transaction. For example, to achieve 50% increase in security (as defined in terms of computational power needed by an attacker to sustain a majority attack), the system may require that either 3 transactions are verified in instead of 2, or that the PoW complexity is increased by 50%.
The only real benefit would be that each transaction indirectly verifies 3n instead of 2n transactions n levels beneath it. However, 2n is still a pretty big number, so this isn't likely to be a significant improvement.
In short, the requirement to confirm 3 or more transactions would have bad side effects, and would give no significant benefits that could not be achieved by other methods.
In the whitepaper it's written
The edge set of the tangle is obtained in the following way: when a new transaction arrives, it must approve two (1) previous transactions.
1: This is the simplest approach. One may also study similar systems where transactions must approve k other transactions for a general k ≥ 2, or have an entirely different set of rules.
So simplicity would be a general point.
In approving more than 2 transactions, which ones would you choose? With each additional referenced transaction, you're increasing the chance of referencing an invalid transaction.
Look at What happens to a Subtangle if it attaches to an invalid transaction? for further reading (and the referenced issues there).
Look at the answer by kfx for (1), for (2), tip selection is not random, it is discussed in the whitepaper (and also the iota medium blog blog.iota.org/…), you can find explanations of the tip selection algorithm in other answers, such as iota.stackexchange.com/questions/1329/…. It is still subject to changes.– XilisFeb 27, 2018 at 14:35
GREAT question! This was actually JUST discussion in the Iota Foundations most recently published research paper! The idea is this: confirm more transaction then you are creating to reduce the number of tips ( tips are unconfirmed transactions ).
By making the required confirmations, 1 then the IOTA's ledger would not be called a tangle, it would be called something like a tree or a root system because every transaction would just keep linking together making long strings or confirmations. Sometimes a transaction you would have one transactions simaltaniously confirmed twice and then the chain would branch off.
By making two required confirmations, you allow a chain of transactions over time that has interlinks to eachother all over the place. Keep in mind, it is unincentivised to confirm old transactions, that is why we sometimes have to reattach a transaction to the Tangle.
In the IF's research paper, they considered requiring any where between 2 - 10 transactions, even 2.5 confirmations per transaction! To summaries the results: by having a transaction confirm more than 2 transactions, there was less unconfirmed transactions/tips; this should be obvious. By confirming 3 transactions you theoretically reduce the number of tips by 25% (compared to 2 confirmations) and this was verified to be true in their paper. By requiring 6 transactions, you theoretically reduce the number of tips by 40%. Now 6 transaction is 300% the effort for a 40% reduction in tips; thats not really a good deal. The most effective amount to reduce the number of tips is 2, possibly 3 confirmations per transaction. Now this could change in the future.
The IF is doing research on all sorts of tip selection algorithms and number of tip confirmations. As they verify their original theory with simulation, they may come up with outstanding new efficient methods of tip selections that could be integrated into the tangle!
Hope this helped!
validated != confirmed. Tips are not validated transactions that validate 2 previous tips (they become unconfirmed and validated transactions then). tips itself dont confirm a transaction its the Random Walk Monte Carlo algorithm which also does the tip selection. You can indirectly try to confirm a transaction by promoting it, so you try to validate tips that have a walk to your transaction.– DudeMay 17, 2018 at 23:15