Topic: Can a transaction in a 6 block confirmation removed (Read 391 times)

This is just stupid!
It would mean that all five pools will get between 5 blocks in a 2-minute to 20-minute interval, so even at the lowest luck possible you're going to get 5 blocks in 20 mins, which would mean 250% of the normal block time. Not even going to consider the 2 minutes because it clearly shows you just took 20% out of 10 minutes. Seriously? After so many years around here, you still can't figure out how percentages and mining works?


Again, dumb as f**** because if every pool would be able to pull a bock in between 2 minutes or 20 minutes it won't mean the average is 10 minutes, because it's not the median of the speed at which each miner gets a block, it's the fastest time one can solve the next block.
So if for block 1 A does it in 2 minutes and B in 18, C in 10 and D in 10, then for block 2 A in 10 mins, B in 10 minutes, C in 2 and D in 18 the average time for blocks 1 and 2 is not 10 minutes, it's 2!

On your stupid model even if you would erase 80.0% of the hash rate the last pool would still be able to complete blocks at the same speed, so basically there will never be a difficulty adjustment even if 99.99% of the hashrate is gone!

Wrong again.

If a pool has 20% of the global hashrate, then they would expect to find 20% of the blocks. 20% of the blocks is 1.2 blocks an hour, meaning their average block interval would be 50 minutes.

Of course it does. If you take away 3 pools with a combined 60% of the hashrate, then the remaining 40% of the hashrate cannot continue to find blocks at a 10 minute average interval. You seem to have a fundamental misunderstanding about how mining and the difficulty/target work.

I never said they did. You simply don't understand what you are talking about.

Nope, never said that either.

In your example, if pools CDE turn malicious, then pools AB remain entirely honest and of course continue with their combined 40% of the hashrate. However, blocks will be found significantly slower since we've just lost 60% of the global hashrate.

And how exactly do you propose the the network continues with a 10 minute block average after losing 60% of its hashrate?

Re-orged blocks have a clear parent which they have been built upon, which you can trivially find by looking at their block headers (which will contain the block hash of the parent they are building on). They are not orphans. Orphan blocks have no known parent.

Yet another source to prove you are incorrect: https://en.bitcoin.it/wiki/Orphan_Block

a pools work on its own block. meaning if there are 5 pools
EG
20% pool A - average block speed 2min-20 min
20% pool B- average block speed 2min-20 min
20% pool C- average block speed 2min-20 min
20% pool D- average block speed 2min-20 min
20% pool E- average block speed 2min-20 min
there would be 5 pools all competing to make a block with in that time. and every block session there is a winner.
its not(unlike what OELEO subtle insinuates) where the network hashrate work together on a single block or whatever silly analogy his is plying about having a competing attacker subtracts hashrate from the pools making them slower or where out of the aaverage 6 blocks an hour a attacker pool owns 3-4 out of 6 blocks

in a re-org event. an attacker pool doesnt show as any blocks in the network until the attacker gets height, and suddenly a re-org of many blocks takes over the chain. where the blocks leading back to the target block chosen to be edited sudenly all appear as being done by the attacker pool.. but only if the attacker pool has acheieved heeight by having enough of its own hashrate to compete to race and overtake the honest network

anyway back to the example of the 5 pools (A-E)
taking pools CDE away. does not make pools A and B to suddenly take 5-50 minutes
the pools still solve their blocks at their candidate block attempts same times they would have.. because they are doing their same work.. other pools dont impede work done by another pool
 the difference is which block out of the candidate blocks becomes the accepted winning block and what becomes the stale block(late/loser) depending on the candidates race results

i will emphasise this.. OELEO seems to think a attacker pool with XX% of network hashrate has stolen hashrate from each and every pool making each and every pools attempts slower.. im sorry to inform him that this is not how things work in reality.
pools keep their miners. so their work they do within their pool stays the same. meaning if they averaged 2-20minutes before they average the same after.. if they averaged 8-12minutes before they average the same after..

its the attacker pool that has to accumulate its own hashrate to produce blocks within a suitable time to outpace the honest network. meaning having its own hashrate to compete

you need to learn the difference between POOL hashrate and network hashrate...
network hashrate drop does not cause honest pools hashrate to drop.. pools still perform the same work for their block candidate


you really do need to learn the word orphan..
orphan means loss of parent.. its a word in the english language that has existed for centuries
if a parent has never been declared then its just an invalid block.. or in old english 'b*stard'
stale means out of date. (loser of a race)

The reason why a lot of publication say it is impossible is because of the amount of resources it would take to rollback the changes. Once blocks are stacked and linked to one another, altering a historical block will force all the hashes of proceeding blocks after it to change as well. That's a very expensive operation to compute and there's no guarantee that it would be successful as there's too much uncertainty. This is why most payment networks or several providers just need 3 confirmations to confirm deposits.

TLDR: possible theoretical but very difficult and expensive to do practically.

By the books, it's said that 6 confirmation is already a secured transactions. That means that even if there's a chance of being able to do that, but at what cost?

I don't think that someone who wants to reverse that is willing to put up a lot of money that can cost millions just for it to have it experimented.

In other chains where 51% of ownership(attack) is possible but if it's Bitcoin, we all knew how secure its network.

Although the posibility exists, it has never been attempted. The process involved requires 51% of the miners to agree to reversing that block transaction.It is extremly expensive to have such resolve and may not be advised as it will not be worth the troubles but there exists the possibility. However, no one wants/has successfully attempted such and it will not be in the best interest of the technology and its trust system.

To simplify, once Bitcoin transactions receive enough confirmations on the blockchain, they become irreversible. In fact, it's quite uncommon to hear of transactions being reversed after six confirmations. Six confirmations are generally considered a secure threshold, meaning the transaction is unlikely to be reversed. However, it's important to keep in mind that although extremely rare, there's a theoretical possibility of reversing a transaction even after six confirmations. This could happen if a majority of the network's mining power collaborates in a "51% attack." Yet, due to the decentralized nature of the Bitcoin network and the immense computational power needed, the likelihood of such an attack is very low.

This is a completely flawed analogy. If you take 60% of the hashrate away to mine a malicious chain in secret, then why on earth would the remaining 40% still be able to find blocks at the same speed? That is absolutely not how bitcoin works, like, at all.

If you take 50/60/70% of the hashrate away to mine on a different chain, then the remaining hashrate will absolutely find blocks more slowly. You honestly think if 70% of the hashrate disappeared right now to mine a different chain in secret, that the average block time would still be 10 minutes with only 30% of the hashrate remaning?

Your terminology is also wrong: https://bitcoin.stackexchange.com/questions/5859/what-are-orphaned-and-stale-blocks

oeleo you were presumptive that of the 6 blocks an hour seen by the network. 3.6 blocks belonged to attacker and 2.4 blocks belonged to honest pools

however the real scenario is that a attacker pool is making its own chain.. unseen, separately..
there are other aspects you need to consider..

such as.. imagine a 100m olympic running race.. most runners run between 9-11 seconds..
take 3 out of 5 runners away from the race and put them into a new circuit.. does not mean the remaining runners suddenly run slower at 25 seconds

its two separate races. where suddenly the non olympic circuit suddenly announces on the news a new world record. and suddenly the world starts watching and recording and keeping records of the non-olympic race they never seen before
yep.. the new path is only seen when it passes the height(record) of the honest network to become the chain the network then follows.

meaning a attacker pool having 50%, 60%, 70% of the network is not taking 50%, 60% 70% of block shares away from the network each hour. its letting the honest nodes do as they do unhindered, uninterrupted. with honest pools making their blocks.. and then.. suddenly boom. re-org. and an orphan event of many blocks happen

usually in an attack scenario an attacker pool would not even announce its initial blocks until it reached height. because the obvious.. they were not at height initially thus treated as stales

yep stales are old blocks late to the party so just disregarded..
orphans are the blocks rejected when their is a re-org and a new parent many confirms back becomes the fork to follow. and the children of the old path have no parent anymore. thus orphans.. thus rejected
new children from the new parent are adopted as the path the network follows due to being the tallest height

it seems you are trying to knitpick silly details like numbers but getting it wrong. seems you just want to prove me wrong but fail then cry when i prove you wrong yet you then say im the one trying to 'rant that everyone is wrong' acting like your a victim

actual point is. if you got things right there would be no reason to correct you.
i know you prefer "yes people" that only comment to you to agree and admire and obey your comments. but this is the real world. expect when things are wrong to be corrected. dont cry about it dont think its a rant. just see where you got it wrong and then remind yourself, your human. not a god.
stop expecting to only get positive loving happy admiration replies from people that treat you like a cult leader

Exactly, I have same experience like this during the mempool is full of unconfirmed transactions. My transaction dropped because it falls out on the range of transactions to be purge.

I have no idea on how double spend works on unconfirmed transactions but this the risk of the casino that credits unconfirmed deposits. A user can double spend his unconfirmed deposits if he lose already his balance on gambling.

You've completely misunderstood my point (as usual) and just launched in to another rant where everyone except you is wrong about everything (as usual).

Only if the attacker is bringing entirely new hashrate to attack the network. And which attacker exactly has 400 EH/s of hashrate sitting idle waiting to attack the network? The far more likely scenario is that hashrate which already exists and is currently mining honestly would turn malicious, in which case my example above is completely accurate. The combination of the 60% malicious hashrate and the 40% honest hashrate would continue to mine on average 6 blocks an hour, meaning the attacker would mine 3.6 and the honest hashrate would mine 2.4, on their respective chains.

Again, this is only in the scenario an attacker with 400 EH/s comes out of nowhere to attack the network, and not in the event that honest hashrate turns malicious. These are two entirely separate scenarios.

You were the one which started talking about hashrate on mining pools realizing they were mining maliciously and swapping back to honest pools:

In this situation, my example is completely accurate. If you are now changing to the scenario where an attacker comes out of nowhere with new hashrate, then the calculations are obviously completely different, but you don't seem to realize that these are two entirely separate scenarios.

After resolving the transaction issue by using Replace by Fee (RBF) and finally getting the transaction to the recipient wallet, I would advise that you discontinue using Trust wallet because it's close source and your wallet can easily be compromised. Atomic wallet is also a closed source wallet that got hacked few months ago and crypto assets worth billions of dollars was stolen by the hacker, so this is just a kind advice. Also, you shouldn't get a false sense of security that your wallet is safe when you import your Trust wallet seed phrase into Electrum, Sparrow or Blue wallet. Download either of the above mentioned wallet that suit your taste and preference, generate your seed phrase and move your funds from Trust wallet to your preferred wallet.

LOL. 
Perhaps you should play with advanced options on your Bitcoin wallets, eletrum wallet is simple as that to see if you can pay more for a transaction or not. Sometimes, we overpay for transaction fees so they can get mine as quickly as possible, and with that in mind, there is a likelihood of overpaying for fees you didn't have in mind, when that happens, the transaction becomes broadcasted and with the first confirmation, that's it; Imagine realizing you paid 1.0005 for a fee, this is even more common when you set your wallet transaction in BTC instead of mBTC,. Just because it has not happened doesn't mean it wouldn't just as described above. In addition, I also stated the chances of getting back the reward are low that is why I put it in parenthesis(low chance).

nope

if the normal network makes 6 blocks an hour. but is only 50% of total power.. then the other EQUAL 50% would be expected to on average mine the same amount of blocks

point being the attacker pool would need ALOT more then just an extra 1% of hashpower to mine backward 6 blocks then catch up to normal network within a certain amount of time.. a 1% gain would take DAYS to re-org

think about it 50 or 51%
imagine its noon(mid day, 12:00) and both attacker and normal are at block 6
at (average, not exact) 12:10 attacker remakes block 1. normal network adds block 7
at (average, not exact) 12:20 attacker remakes block 2. normal network adds block 8
and so on

thus the attacker needs alot more than equal or equal +1%
and i did not imply a 1 hour limit.. thats all your doing.. i suggested a 80% could do it in 2-3 hours..

also to add to your mis-understanding of this quote again

you are saying the attacker is only making 3.6 blocks of the 6 block average of the network.. wrong
the attacker is making its own list of blocks initially at faster rate compared to the normal network

its not 3.6 blocks of the average of the network... its 6+ blocks of their own chain whilst the normal chain is making 6 blocks

meaning separate chain, separate list of blocks and both making 6+ blocks an hour side by side(for MORE THAN AN HOUR) until the attacker gets height before normal chain for the attackers chain to be the default chain to follow.. which then breaks the old block many many confirms ago. and ORPHANS off all the child blocks of the normal chain after. because the parent is no longer there. there is a different parent(the attacker is the adoption parent)

Under normal circumstances, a transaction is regarded as irrevocable once it has gotten six confirmations.

Although the "weight" comparison helps to grasp, it falls short of fully capturing the security of the Bitcoin network. A transaction would need more computing effort and energy to be reversed the more confirmations it has received. Theoretically, a double-spend assault might be launched by a party that controlled at least 51% of the network's hash rate. But wait a minute.

Do you have any idea how many resources are needed to acquire and keep that level of power, especially when there are international miners involved? Both practically and financially, it is not doable. Get your facts straight and avoid letting hazy interpretations lead you astray. One of the world's most secure payment methods is still bitcoin.

On the contrary - you are the one ignoring the time scales when you stated someone with 50% of the hashrate will "never catch up" to a 6 block deficit, and will "always be 6 blocks behind". This is simply not true.

If you want to start placing time restraints the then question changes dramatically. A 51% attack (or even a 60%, 70%, or 80% attack) will not be successful if you place a sufficient limits on how big the deficit is and how much time the attacker can sustain that hashrate.

As an example, let's say an attacker has 60% of the hashrate, and wants to overcome a 6 block deficit in an hour. With 60% of the hashrate, they would expect to mine 3.6 blocks per hour. They would therefore have only a 7.3% chance of mining 7 or more blocks within an hour. However, the honest miners would expect to find 2.4 blocks in an hour, and would have a 90.9% chance to find at least 1 block in that hour and therefore stay head of the attacker. Multiply these probabilities (which is fudging the numbers slightly, but the premise remains the same) and a 60% attacker still only has a 0.67% chance of overcoming a 6 block deficit if you limit the attack to an hour.

It's not possible to reverse a transaction once it has been confirmed, you only received the information on your transaction after it was confirmed that 6 confirmation, this only means that after your own block confirmation, other 6 transactions had been confirmed and it does not reduce anything strength to your security measures in reversing the already confirmed transaction, then know this that bitcoin transactions are irreversible once confirmed.

mathematically guaranteed to overtake any deficit... but the question you ignore is WHEN
the more confirms back impeeds how fast you then catch up. its not an instant re-org. it takes multiple blocks to go through

the thing is. how long can you retain a large percentage before those independent miners on attacker pool see attackers attempt and jump ship away from attacker pool. or can the attacker pool afford to self power XX% of their own miners to perform a successful re-org of 6 six confirm tx within only 3-4 hours before the network responds to harness their excess hashpower to counter the attacker.

It's possible to a certain level, bitcoin transactions are supposed to be immutable to prevent scams that use this method. As many have mentioned already, it requires you to have a lot of computational power and as more blocks are built on top of it, the more the transaction becomes more irreversible. If you have the resources to rewrite the codes up to the block that has the transaction. I wanna ask OP though, why are you asking about this? And it's such a specific number of block confirmation and not a generalized amount or even just one block confirmation.

It is possible if the miner willing to return the excess amount.

For example, in 2013 someone paid 111BTC as fees but the miner eleuthria returned 102BTC back to the originating address.

But it's unlikely to happen anymore so don't screw up when calculating the fees especially who uses core wallet.

Whatever tx fee or fee rate attached to your tx goes to the miner, even if you estimated wrongly and overpaid, there is no such return, the fees is what miners use to decide the priority of transactions in the mempool, they can't decide if you willingly overpaid or not. In a tx what returns back to you is change, if there is any. If you are spending a particular utxo, but you are not spending all of it, one of the outputs returns to you as change. Tx fee is simply inputs - outputs, that is what finally goes to the miner.

Theoritically, it is possible if attackers have enough hashrates.
Practically, it is impossible because cost is high, nearky impossible to have such high dominating hashrate and benefit is not high

Use either two following tools to have estimating exercises.

• https://jlopp.github.io/bitcoin-confirmation-risk-calculator/
• https://web.archive.org/web/20181231045818/https://people.xiph.org/~greg/attack_success.html

In addition to what others have explained above; Just imagine you have 6 containers loaded with cars, that are all stacked at the top of each other and your car is stuck at the bottom of the first container, do you think it will be possible to get your car out the first container so easy, you will have to take down the first 5 containers before you can get to the last one, that is what the description is explaining, the more block is stack on top of each other, the less chances of it been reverse back.

With the current computational mining power of Bitcoin being distributed to different miners, the chances are low until you have more than about 51% of the power before that can happen. As long as you don't have that power or other miners ready to join hands with you, that is a mission impossible because once a transaction is confirmed, that is the final, it is good as dead living that no longer breathe, that block will remain sealed forever. However, if it's an overpaid fee in a transaction, perhaps you made a mistake during the course of a transaction, they may (low chances) return the fees to you for the error.

The correct term here is stale blocks. Orphaned blocks refer to blocks without a known parent (as the word "orphan" implies), which is something different.

Also, a transaction which is included in the losing chain will only go back to unconfirmed if it is in neither of the block at the same height or the block at height +1 in the winning chain. Otherwise it will remain confirmed despite the chain split.

No, it won't. Broadcasting an RBF replacement does not make the original transaction invalid whatsoever. The original transaction remains entirely valid and could still be included in a block if a miner chose to do so or did not learn about the higher fee paying replacement.

Your numbers are all wrong.

If you take the equations from section 11 of the whitepaper and plug in the numbers for an attacker with a probability of 0.5 of finding the next block (i.e. 50% of the hashrate), then the probability they will catch up from any deficit is 1.

You are assuming that both attacker and honest miners will mine blocks at a regular 10 minute interval. Given that there is random variance, and given an unlimited amount of time, then the attacker will in fact always catch up. With honest nodes simply following the chain with the most work, then honest miners have to stay ahead at all times, whereas the attacker only has to take the lead once for all honest nodes to then switch to their malicious chain.

Further, a 60% attack does not mean the attacker is 10% faster. If the attacker has 60% of the hashrate against an honest 40%, then the attacker is 50% faster than the rest of the network.
A 70% attack results in the attacker being 70/30 = 2.33 times faster, and an 80% attack results in the attacker being 80/20 = 4 times faster.

Again, not true. With 51% of the hashrate you are mathematically guaranteed to overtake any deficit. You certainly don't need 80%.

Not possible for the current transaction because Bump fee will be only available if its opted at the time of broadcasting since you mentioned it is not supported on Trust wallet then there is no way to do that even if the user import into electrum or any other wallet. In that case Child pays for parent (CPFP) is the only choice to increase the fee from the receiving end which is also not possible in this case here cause it is going into Binance wallet.

First of all don't use trust wallet anymore cause its closed source and don't try to import the seeds into any other open source wallet too, so the best thing to do is create a fresh wallet and move the funds from trust wallet to another.

I suggest Unstoppable wallet as best alternative to trust wallet.

a few things to keep in mind

A mining pools make about 6.25btc a block meaning cost per block is ~$185k

next is that to go back 6 blocks means you have to re mine them blocks.
if a pool only matches the speed(50%) of the rest of the network it will never catch up and always be 6 blocks behind
EG

normal 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
attack  06 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

so to over take the normal network that just continued, you will need more then the normal network speed to catch up
EG 10% faster (60% attack)
normal 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
attack   06 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

EG 20% faster (70% attack)
normal 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
attack    06 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29


EG 30% faster (80% attack)
normal 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
attack    06 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20


as you can see even after doing over 20 blocks costing millions of mining power you may only get to overtake within 20 blocks if you had like 80% of hashpower

this is why unless the pools has a large multi million dollar transaction it wants to maliciously reverse. and alot more then 50% of the network hashrate, its not worth them trying to go back so many confirms and then waste so many more blocks trying to play catch up to try to overtake the network to get their chain of edited block recognised as the chain the network should follow

It could be possible if the transaction is flagged as RBF, if a transaction is flagged it can be replaced with a new one where you pay a bigger amount of sats as transaction fee. But most of the nodes do have full RBF yet so you can check your transaction in mempool. If you see the RBF option in green color like the segwit in the picture then it is flagged RBF



I don’t think trustwallet support RBF just yet but is ok to import the seed into BlueWallet, it supports RBF and if you see the pending transaction then you can click the bump fee option and then increase the transaction fee. But if the transaction doesn’t have RBF flagged then you can double spend it by sending same amount of the bitcoin and then using a higher transaction fee than the first one initiated

Yes, you can import your wallet from trustwallet to electrum using your seedphrase and then bump the transaction using RBF to speed up confirmation.

Ideally you should sweep your coins from trustwallet to electrum and not just import it.

This does not make the former transaction invalid, the miner can still see both but will most likely choose the one that pays a higher transaction fee.

ViaBTC is a good Bitcoin accelerator and you don't give them any information about your wallet besides he txid.

Oh really!
Well I can say I did respond base on my experience so far but however, I have also added something positive to my wisdom bank and thank you for the clarification. I think is always good involving in deep discussion with those that I think are more than me. Please pardon me for that.

I did use Trustwallet to send out payment and not electrum wallet, is there a way or is it possible after importing wallet to Electrum and speeding up transaction?
Maybe I won't proceeding with it to ensure my transaction has been confirmed. Since on 14 I sent out about 62.5$ hasn't confirmed to my binance address.

Depends on how much the user send their coins, if they only send small amount Bitcoin e.g. less than 1 BTC you don't need to worry because it's high likely they will not do double spend because it's need a cost to double spend the transaction.

I think it's pointless to suggest someone to not do double spend because it's unethical or dishonest because you wouldn't know what they will do in the real life.

I'd not call it not advisable, just that you should not rely on them. They can help if things go wrong, but they are not a magic tool that will accelerate your transaction plus most of the time they have a limit on how many and which transactions to accelerate. Using RBF is going to be better IMO.

Transactions cannot be reversed but unconfirmed transactions can be double spent that's why it is important to be confirmed by at least three blocks. The sender can increase the transaction fees and also change the recipient of the funds which will make the former transaction invalid (Replace by Fee (RBF).

Some mining pools offer transaction acceleration services but is not advisable to use them because you will be relying on a third-party service provider. But you can try adopting RBF or CPFP. In Replaced by Fee the sender will have to pay a higher transaction fee to make the transaction more attractive to miners. While in Child pays for Parent it is the recipient that bears the cost of broadcasting a new transaction.

You should move this thread in Bitcoin Technical Support board. Blockchain is immutable. It's decentralized and there is no central power, that's why you can't alter the data that's stored in blocks. Imagine blockchain case like, you upload picture on your facebook and then people start to download it and upload on another websites. How can you get your picture permanently removed from the internet? Keep in mind that if you ask them, they never respond. Your only way is the network's consensus, so, the only way to remove transaction from blockchain can only be done with the network's consensus.
That's just what I know but there are people like o_e_l_e_o who definitely can give you a top-notch answer.

Electrum Wallet has an option called Cancel that cancels your transaction by making a double-spend. So, it's possible to cancel Bitcoin transaction if you use Electrum and if it is unconfirmed yet.

It is theoretically possible but rarely or never practical.
For majority of transactions it is unprofitable to even attempt to reverse it for a miner that had the means. So if you're sending something less than tens of millions of dollars, then less than six confirmations is enough for certainty.

If someone had unlimited computing power which no one has, it is possible to attempt, but considering it is unprofitable and it's not 100% guaranteed it will succeed, it's not worth it.

If it's on an electrum wallet you can use RBF to bump the transaction fee up. Since you're sending to finance using CPFP is not on the cards.

Possible, yes! Likely to happen, no!
There was a thread recently about it:
https://bitcointalksearch.org/topic/how-many-bitcoin-confirmations-is-enough-5443953


False! Unconfirmed transactions are not set in stone, it's not just about being reversed, it's about them not ever getting confirmed or being dropped out of the mempool after a while for being a low paying tx, that's the whole reason most exchanges or gambling sites wait for at least 1 to 3 blocks to confirm your deposit.
It's one thing to not be concerned when the one doing such tx is you between your wallets, a different story when accepting payments from a stranger.

This is never possible to get it reversed after 6 block confirmation..
Let say if a transaction is being sent immediate you can't reversed it because you had initiated the transaction, it may be pending for over hours but can't be reversed just I as do sent out btc since on 14 of August and it the transaction hasn't confirmed yet but looking from explorer (txt) I noticed the sender address is empty and while the receiver address has the balance inside of it but has not yet confirmed. I checked through my Binance app I couldn't see it but still pending transaction ( now it can only get to my binance app after the 6 block confirmation so this cause me not to panic anymore) but if there were ways for boosting the transaction I wouldn't mind proceed with it.

I mean in theory it is possible but you would need a lot of computing resources to do it. Which I think is not possible by a single entity because of its decentralized nature. In general 6 confirmation is considered for a transaction to be irreversible as major exchanges and big merchants atleast consider 4 confirmation to consider a transaction to be final.

Transactions with at least two to six confirmations are seemingly impossible to reverse because of the number of blocks built on them. The transaction with just one block confirmations is what bitcoiners believe is reversible because of the cases of the block in which the transaction is been orphaned. Orphaned blocks occurs when two blocks are sent simultaneously to nodes and as miners mined or build blocks the longest chain one is been picked by the nodes and the later dropped back to the mempool. So if your transaction happens to be in the short chain then it can be reversed.

So seeing this means it can only occur to transactions in the top top blocks. A 5 blocks downward transaction can not be orphaned and there cannot be reversed. So 6 block confirmation can not be reversed

I've been curious to wanting to know the possibility  to reversing or removing a sent transaction on a block which has already passed 6 block confirmation and after reading a post from a free signature space of a user which I can't remember which reads "Each block is stacked on top of the previous one. Adding another block to the top makes all lower blocks more difficult to remove: there is more "weight" above each block. A transaction in a block 6 blocks deep (6 confirmations) will be very difficult to remove.
Judging from this, the writings stated that it is difficult  and not impossible and I've been wanting to know if will be possible to reverse a transaction after a 6 block confirmation?