Hello, I was synchronizing a node with bitcoin core but bitcoin core has "core dumped" (between block 750,000 and 800,000 so I really don't want to have to download everything) and when restarting bitcoin- qt shows me "replaying blocks: 0%" and in debug.logs I have:

2024-04-27T00:30:15Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=58, size=100189578, heights=803877...804359, time=2023-08-19...2023-08-22)
2024-04-27T00:30:15Z Checking all blk files are present...
2024-04-27T00:30:15Z Initializing chainstate Chainstate [ibd] @ height -1 (null)
2024-04-27T00:30:15Z Opening LevelDB in /media/myname/DD Externe/chainstate
2024-04-27T00:30:17Z Opened LevelDB successfully
2024-04-27T00:30:17Z Using obfuscation key for /media/myname/DD Externe/chainstate: 5f4cbf4f04be336c
2024-04-27T00:30:17Z Replaying blocks
2024-04-27T00:30:17Z Rolling forward 00000000000000000003448732b35cd9bb92eff0328bfc3e1800cd95d23721b8 (788897)
2024-04-27T00:31:59Z Rolling forward 000000000000000000001bff2639e28de97f48ec1497fda22bcfcf44ce196bede (788898)
2024-04-27T00:33:02Z Rolling forward 0000000000000000000560890080e8dc8c30196783035ff4adb1ab5dd979f8ee (788899)
2024-04-27T00:33:41Z Rolling forward 00000000000000000001e2993abf7288aed1671a3c5f6e3ecd09347aacd16595 (788900)
2024-04-27T00:37:03Z Rolling forward 00000000000000000002731186762fba5cde45adc550f0308c9790f9d768dcad (788901)
2024-04-27T00:39:35Z Rolling forward 00000000000000000001e9818fd9be9145fd07bd60f44dc8d13fd466cb27c103 (788902)
2024-04-27T00:41:25Z Rolling forward 000000000000000000026ea74cd2b8fadebf4d5d4ee65186902490455d7bf706 (788903)
2024-04-27T00:42:23Z Rolling forward 0000000000000000000207548eddccce21d03c9787ade227c8a448d61136e195 (788904)
2024-04-27T00:44:15Z Rolling forward 00000000000000000003e92043d36b45494d987aa6fb385e8c8dbb0e8230f177 (788905)
2024-04-27T00:45:24Z Rolling forward 0000000000000000000023f3a017220f051a884fea43464a1cb18d5bda687c2e1 (788906)
2024-04-27T00:46:25Z Rolling forward 00000000000000000003f69bd245bc16fefd07fd50258963da39bcb19b885cae (788907)
2024-04-27T00:47:47Z Rolling forward 00000000000000000003ee8da7e286f4e7d28164b4d6e86620b64dcba186cc68 (788908)
2024-04-27T00:48:55Z Rolling forward 00000000000000000003be44f3fd8a38e93fe75a9809b1e7d198ac4532642e9f (788909)
2024-04-27T00:49:37Z Rolling forward 0000000000000000000418be070a760599d0bd4622409aa9f3c90d6351edab9f (788910)
2024-04-27T00:50:02Z Rolling forward 0000000000000000000005e50b30f6f8cca43caefd662070bda4c04ac39c5a794 (788911)
2024-04-27T00:50:14Z Rolling forward 00000000000000000005a6c463bbd5731479466691ff59bed40442f5142a8037 (788912)
2024-04-27T00:50:50Z Rolling forward 00000000000000000005ba649f99cf5d3c92f6853c091e667810fc1137eaf2e4 (788913)
2024-04-27T00:51:11Z Rolling forward 000000000000000000016a58e2418c5f64530636a223d4ad49fdea005783af8b (788914)
2024-04-27T00:51:49Z Rolling forward 0000000000000000000322eed119fddb71c66bdf379d3a75182769afd3a8ca01 (788915)
2024-04-27T00:52:24Z Rolling forward 0000000000000000000445f79006668cdc199dee1baf61224c5b2d85f2b88ceb (788916)
2024-04-27T00:52:53Z Rolling forward 00000000000000000002db386cd6493e47781c4c3bd61095b43e720e79610037 (788917)

As you see bitcoin core seems to check for corrupted blocks (or something like that), but one thing worries me: it's this line 2024-04-27T00:30:15Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks =58, size=100189578, heights=803877...804359, time=2023-08-19...2023-08-22)

from what I see if bitcoin core wants to "roll forward" to block 804359, with a speed of 2 blocks per minute it would take me 6 days, it is much faster to redownload the blockchain from block 788897, this is is it possible?

NB : I run on bitcoin core 27

Is it possible to tell your own node to forget the transaction, then connect to your node from electrum, for example, to resend it?

Is increasing the block size really a solution? Let's imagine that the block size is increased significantly. Even then, each transaction will take around 10 minutes to be validated on the network (and this is an average, it can sometimes take up to 1 or 2 hours), so I don't see how increasing the block size would solve the scalability problem. In fact, on average, the amortised analysis will tell us that the network will be capable of carrying out thousands/millions of transactions per second, but we'll still have to wait for the transaction to be finally validated. A more logical solution would be to reduce the time between blocks (without touching the supply, all we would have to do is divide the reward for blocks by 100 if we want an average time of 6 seconds per block, for example), but this is obviously unthinkable given the decentralisation problem it would pose. But if one day the price of hard disks were to be divided by 100, or by 1000, would that still be a problem? A 100TB hard drive for $50, for example. As we saw above, you'd need to get a network that's scalable enough for 9 billion people, and without doing any calculations that seems very complicated to me. I prefer a second-layer solution like LN, but for the moment there's no miracle solution.

Oh thank you so much I missed that. Don't worry, it's not my password or my seed.

As you can see I can't click on "next"

How to generate a 24 words seed with a passphrase ? I just tested to select "add words" and put a password when I import a seed but it's impossible to click on next.

Sure, it's something unlikely but nothing is impossible, RSA was considered secure before Schorr's algorithm, anything can happen, maybe a method to find collisions will emerge who knows? Also I used SHA-256 as an example but it's not the only algorithm used by Bitcoin that could potentially one day become obsolete, I'm thinking in particular of the elliptic curve used, or RIPEMD

I don't know if this is already the case, but I think the Bitcoin developers should code the changes to be made in case an algorithm used by Bitcoin becomes obsolete. I'm thinking in particular of SHA-256, what would happen if tomorrow this algorithm became completely obsolete? Shouldn't there be an alternative solution before that happens? I'm not necessarily talking about including this "new replacement code" in the Bitcoin code, but at least having the code on hand, ready to replace the current code. What do you think?

it's a shame that electrum doesn't offer 24 word seeds by default, I know it's possible by entering commands in the console but I'm afraid of compromising security, or doing something stupid, it's a bit off topic but do you know if they have an update planned?

I think that when the technology of data storage has evolved by changing scale, i.e. for example when the price of 10TB is at the current price of 1TB, it may be possible to increase the size of the blocks as this will not harm decentralisation, however we may be close to the theoretical limit in data storage

Thanks for your answers, I understand that it is really unlikely that this will happen but wouldn't there be a way to improve BTC's algorithm to consider a large and fast variation of its hashrate (maybe with an average time of the last 50 blocks or any suitable system), some kind of security system to prepare BTC to fight against any eventuality. It seems that Ukraine has been without electricity for a few days and we can see a quite big variation in the hashrate of BTC since November 22nd, I don't know if it is due to Ukraine but we can imagine a situation where Europe and USA would be deprived of electricity and that would cause a big problem in the hashrate. Since 2009 this situation has not happened but the more time passes the more likely it is to happen, especially with the recent news. Another nice solution would be to better distribute the miners geographically but I'm sure that will happen over time, maybe even placing some in orbit.

We can imagine a war that causes a global blackout. So if the hash rate drops by 50%, assuming the next BTC difficulty adjustment is in 2000 blocks.
As the hash rate drops by 50%, each block will be mined in 20 minutes instead of 10 minutes. So, if the hash rate drops by 80/90/95%, it is possible that there will never be a new BTC difficulty adjustment because the time to find a nonce matching the current difficulty will increase. If my calculs are correct, for a drop of 95% of hashrate, each blocs will be mined in 200 minutes, so 277 days to reach a difficulty adjustment (considering 2000 blocs remaining).

There are an error ?