Please read Satoshi's paper, section 11:
https://bitcoin.org/bitcoin.pdfThe probability of an attacker to success (q
z) is just a function of p (% hashrate of honest miners) and q (% hashrate of the attacker). The block interval is NOT part of the equation.
This is correct.
However, this presumes an attack is already happening, and does not speak directly to the security of the chain. By modifying our behaviour to be dependant on the cost of an attack over some period we can directly measure this security and compare chains. You actually acknowledge the solution when you point out Feathercoin's low hashrate.
The original statement:
Now since litecoin has 30 less value and 4 times more blocks to secure the received transaction that is equivalent to 1 bitcoin block you have to wait 120 litecoin blocks. So bitcoin is much more secure.
This is true if we measure security as 'chance of a transaction of size X being reversed'.
The cost of an attack in some unit ($ for convenience) on some network (N) is dependent upon market_cap_in_$ and transaction_size_in_$ (normalising out conversion between units). It is also dependent on the supply_rate_in_$. The main competition is the supply rate, so for a transaction of size X_in_$ we need to use supply_rate_in_$ to calculate some t.. If we set t high enough we can ensure it's never profitable to attack provided we wait out that duration.
If I made transactions of equal value on both the Bitcoin and Litecoin network, the incentive for someone to attack the network is far greater on the Litecoin side, since the cost of an attack is far less for the same X. This presumes a perfect market where the profitability of mining is the same on both networks and competitive hardware is accessible.
If we want to measure t in blocks we have to convert using the block interval.
Going back to blockchain decentralisation:
The security of the network measured against the above strategy is determined by the hashrate and not directly by number of blocks. Mining pools were invented to decrease variance in reward. Since this variance is somewhat dependent on the size of the reward blocks (constant stream = no variance, target time of 1yr = lots of variance) by increasing frequency of blocks (and decreasing variance) we increase mining decentralisation as long as some miners are okay moving to smaller pools or going solo (or moving to P2Pool).
This is actually essentially what P2Pool does, and is immune to the orphan problem since a) it effects the whole network equally (though there is potential for a greedy miner attack) and b) any valid Bitcoin block is immediately distributed. Sadly without using GHOST there is a strong practical limit due to orphans produced by propagation time.