@franky1, it's clear that you are not really listening.
Here in this comment:
[...] and services can also delay the withdrawal of the funds so the attacker wont try instigating the attack until after the withdrawal clears to ensure when they finally go backward X blocks they get to truly double spend. it then becomes unworthy of attacking the network just to get a refund, because CEX have other mitigating factors
Isn't this exactly that 'extend the confirmation time' idea I was talking about? You
know that this isn't going to do anything to prevent an attack on that scale,
no.. its about YOU need to run scenarios based on the CURRENT mitigating delays services put on the deposits and withdrawals to cause a attacker to have to wait out clearing their settled other currency.. to then go backwards..
its not about asking services to change things from now on..
you are saying that "no, it isn't about extending the confirmation time," and then in the same breath you saying that it is about "delay services" instead. Unless you can somehow explain to me that "delay services" isn't about 'extending the confirmation time,' I will regard you as being dishonest.
again.. these delaying things are actually standard practice that have and are ALREADY been in practice for decades.. again ill explain, its not about services suddenly needing to implement new delays to mitigate a new attack.. its about the mitigations already in practice for decades that already mitigate the attack you want to discuss
Okay, I will accept that maybe you sincerely thought that I was talking about "implementing
new delays." So I'm giving you the benefit of the doubt, even though you still ought to have paid better attention.
We are both talking about exchanges (and such) delaying the confirmation time (beyond the standard 6 blocks), which is indeed a standard and well-known thing that they can do. And each individual exchange/trader is indeed able to do it independently, and temporarily, whenever they want to.
Regardless, I've explained why that wouldn't help anything in a
long-range attack. Now, you both ask me to once again do the (easy) catch-up math, and you also explicitly state that an attack would require several reorgs, "otherwise they wouldn't be able to steal enough to make it affordable."
This all shows that you either don't know what a long-range attack is, or have somehow missed the point, even after this long conversation.
Okay, I'll forgive you for that, but then you better listen more carefully now:
In a normal replay attack, an attacker tries to pay for other assets/currency/etc. with BTC, then reorgs the ledger, and then quickly tries to cheat another party to sell some other assets/currency/etc. for the same BTC, before they notice that a big reorg has happened, thus "replaying" the same BTC.
If this were the kind of attack we were talking about here, then
you would be right: The attacker would not be very likely at all to make this attack worth it, namely since exchanges and such would likely notice the large transfers on the blockchian and choose to temporarily require a longer confirmation time (more than 6 blocks, i.e.), until that large transfer is more sure to be finalized. (This is the "delay services" that you are also talking about; we are talking about the same thing here.)
However, this is
not the kind of attack that I'm talking about. Note that in my Bob–Eric example, Alice ends up with BTC,
not other assets/currency/etc. And note also that Alice is making exactly
one reorg of the ledger in this attack. (And note that she could have made many more trades in principle, even in
parallel rather than one at a time, and trade more BTC each time.)
This kind of attack is known as a long-range attack, where the goal is not to replay non-BTC assets/currency/etc, but to steal BTC alone.
Now, it is normally assumed that Bitcoin would crash as a result of such an attack (unless honest miners somehow manages to regain a majority of the hash rate after the attack and then soft-fork the blockchain back to the original chain), which means that long-range attacks haven't been much feared before, since they have thus also been deemed as very unlikely to be profitable for the attacker, and therefore "who would do it?"
The so-called 'Goldfinger attack,' however, gives a potential reason why attackers might do it anyway: Either they could be politically motivated, and/or act on behalf of some government/institution, or the attackers could perhaps take large short positions (I assume you know what that is). In particular, if they do the latter, this might then potentially make up for the fact that Bitcoin would crash as a result of such a long-range 51% attack (or another potent 51% attack, more on that in a minute).
Because if the attackers have a reverse stake in Bitcoin, and will thus profit from a crash, then this turns it into a win-win situation, as I have already explained: Either Bitcoin doesn't crash, in which case the attackers can now spend all their stolen BTC at will, perhaps after some whitewashing first, or they profit from the crash itself due to their reverse stake.
And as you know by now, I point to the fact that rather than trying to take such a large short position in order to make this work, the attackers might instead be (or be funded by) stakeholders in a rival blockchain, and one that does not use a PoW protocol itself, hoping to profit from the fall of the competitor.
Now, I must also add to all this: A long-range attack is not necessarily the
only kind of 51% attack that could work for such a (rival) Goldfinger attack. A sustained 51% attack that DoS'es Bitcoin for months or years might also do the trick. But let's put this discussion on the shelf for now until you have shown that you now finally understand how a long-range Goldfinger attack could be profitable for the attackers (assuming that they can profit from a crash of Bitcoin in the first place, of course, and also assuming Bitcoin does not take any new steps to mitigate such an attack).