Quote from: franky1 on August 09, 2024, 01:51:33 AM

yes if there was a fatal flaw that explodes engines or makes miners defunct to cause hashrate to drop. then yes this can also cause the underlying value to drop and thus the market price to go down when the public stop demanding bitcoin

Good, at least we agree on that, then.

Quote from: franky1 on August 09, 2024, 01:51:33 AM

however a ethereum group cant change the network just by having control of blocks. they still have to obide by the design of the network, if they tried to design a new algo that had a flaw. they would just create a new altcoin. and it would be that altcoin that fails(explodes)

We are not talking about them changing the algorithm. We are talking about replay attacks (steals).

Quote from: franky1 on August 09, 2024, 01:51:33 AM

bitcoin has had 15 years of safety checks of the main safety features, heck even satoshi himself left a p2pk address with some bitcoin on it that is in a re-used address thus leaving some data leakage of keys. and no one has been able to steal satoshis coins from the known address he send coins to hal and sent coins back as change

so trying to imply that a ethereum group can steal other peoples coins is a sign you have not researched bitcoin nor its risk mitigations [...]

This is simply false. It is not only widely accepted that replay attacks can happen (as long as the attacker has the money/power to do it), but they have also happened in reality to smaller PoW coins.

Somebody else, please back me up on this.

Quote from: franky1 on August 09, 2024, 01:51:33 AM

you need to realise in the many many months pre-atack the ethereum group shift over to bitcoin they would work as honest miners whilst they wait for leadership announcement. and then even when ethereum leadership announce an attack date. the result would be that the attackers would be working on a blocklist that is not visible to the honest network for multiple blocks and is not guaranteed to take over the honest network and pursist
also the attempt to re-spend old confirmed funds would only be worthy if the value involved was significant, to which services would log which funds are being undone and mitigate the user re-spending those funds

Here you are ignoring/not considering this earlier reply:

Quote from: mjdamgaard on August 08, 2024, 12:31:54 PM

[...] But in fact they can make several replays per reorg:
Suppose Alice trades 1 bitcoin with Bob for some tokens or some USD, then trades that for "another" bitcoin from Claire (meaning that Claire's ownership of the coin isn't dependent on the first transaction with Bob), then trades that bitcoin away again to Doris, then buys "another" bitcoin from Eric. And suppose that Alice is then able to rewrite this recent part of the ledger afterwards. Then Alice can keep the transactions with Claire and Eric, i.e. where a bitcoin is transferred to a wallet of Alice's, but replace the transactions with Bob and Doris with two other transactions where the bitcoins are instead transferred to two other wallets of Alice's. At the end of this, she will have 3 bitcoin in 3 separate wallets: the one she started with and the ones from Claire and Eric.

And she could in principle have kept repeating this process (before rewriting the ledger) as many times as she can find traders whose ownership over the traded bitcoin isn't dependent on earlier trades with herself (i.e. she can only replay each single bitcoin once).

Now turn this example into Alice instead being a great number of people, who are backed by billions of dollars in total to do this attack.

And furthermore consider the fact that it is typical to see around $15B being traded each day. (And again, you agreed that Ethereum investors could in theory afford an attack lasting for several months, once they've paid the CapEx.)

And like I've said: the confirmation period unfortunately cannot be changed retrospectively, at least not with pure PoW.

And you are ignoring/not considering my earlier point that when the attackers profit from (or believe that they are profiting from) a crash, they don't have an incentive to keep any other assets/products, but can keep their stolen bitcoin after the attack. (It's a win-win: Either bitcoin keeps its value, and they get rich, or it crashes, which is what their benefactors is trying to reward.)

Quote from: franky1 on August 09, 2024, 01:51:33 AM

there are many mitigating circumstances and features and economics at play, even things like a pool needs to have their block visible and unorphaned for 100blocks before they can spend the rewards. however the honest network can reject the malicious pools blocks by simply not accepting the blocks that dont have the previous hashID of the blockheight
EG
if malicious pool started a (backward 1 block re-org) attack at block 850,000(editing 849999) but only got to catch up at block 850,070,
(meaning honest networks hash ID chain of 849,999->850,070 wont match the malicious pools hash chain of 849,999-850,070)
the block 850,071 that gets ahead and is published to the network from malicious pool wont have the 'previous hash id' of the honest networks version of 850,070 so the honest network would reject the malicious pools 850,071

This idea goes against the principles of PoW. Somebody else, please back me up on this.