[Enhancement] BTC confirmation counting reduction
Currently the required confirmations to process a BTC tx is math.ceil(value/block reward), this leads to an undesirable effect where trades which are of similar nominal value experience a disproportionate amount of user experience relative to the security benefit.
Example:
User1 trades 24 btc (~1m): 4 confirmations required 40 minutes
User2 trades 240 btc (~10m): 39 confirmations required 6.5 hours
User3 trades 2400 btc (~100m): 384 confirmations required 2.66 days
Here we can see User1 experience a wait time of roughly 40minutes where as User2 experiences a wait time of about 6.5 hours. The implication here is that because of the 9m trade value difference between User1 and User2 we must account for a reorg attack that is 39 blocks deep, suggesting that a trade 10x in value is 10x more risky (not true). This is simply unreasonable and provides no additional security for the nominal amounts involved while sacrificing a huge amount of user experience, an attacker that has the ability to reorg 39 blocks on BTC main net would need to spend multiples more than the amounts involved in order benefit anything at all, let alone only set his sights on attacking TC.
I propose a tiered system where TX amounts fall into tranches instead of relying on the nominal size of the TX.
Example:
1 Confirmations required: 0 < x < 1m 10 minutes
2 Confirmations required: 1m < x < 10m 20 minutes
3 Confirmations required: 10m < x < 100m 30 minutes
6 Confirmations required: 100m < x < 200m 1 hour
1440 Confirmations required: x > 200m? //At a certain point (24 hours?) the "51% attack" becomes the main chain?
The idea here is that we are more realistically assessing the likelihood of an attacker reorging the chain based on dollar values, the amount of confirmations should scale disproportionately only as the TX amount comes closer to the value of performing a viable sustained 51% attack on the chain.