Can a transaction in a 6 block confirmation removed

[blckhawk]

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.

[1714746519]

1714746519

[1714746519]

1714746519

[franky1]

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

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

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.

[Aanuoluwatofunmi]

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?

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.

[o_e_l_e_o]

mathematically guaranteed to overtake any deficit... but the question you ignore is WHEN

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.

[Blitzboy]

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.

[franky1]

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.

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..

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.

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)

[Cookdata]

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.

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.

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).

[sokani]

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.

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.

[o_e_l_e_o]

-snip-

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).

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

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.

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

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:

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.

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.

[Eternad]

Let say if a transaction is being sent immediate you can't reversed it because you had initiated the transaction

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.

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.

[franky1]

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

[o_e_l_e_o]

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

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.

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.

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?

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

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

[The Cryptovator]

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.

[wallet4bitcoin]

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?

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.

[livingfree]

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.

[nelson4lov]

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?

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.

[franky1]

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

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.

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

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.

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?

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

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

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

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)

[o_e_l_e_o]

20% pool A - average block speed 2min-20 min

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.

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

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.

other pools dont impede work done by another pool

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

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

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.

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

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

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

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

[stompix]

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

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?

there would be 5 pools all competing to make a block within that time. and every block session there is a winner.

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!