You can't. Bitcoin transactions are final once confirmed.

Update your software.

How do you know that you were a victim of that vulnerability? Was your wallet encrypted? If so, you were not a victim of that vulnerability. Did you have your web browser open to random, unknown, and possibly malicious sites? If not, then you were not a victim of that vulnerability. Just because there was a vulnerability does not mean that you were automatically a victim of it. It is also possible you just have malware on your computer and that is stealing your money, in which case you will need to remove said malware.

Currently LN software only work when segwit is activated. There is no "without segwit".

No, it was not.

Use a custom datadir for one of the nodes. Both will attempt to use the same datadir and that will be very problematic because they are two distinct blockchains.

0.16.0 will be released soon after PR #11403 is merged. When that will actually be, we don't know and cannot give a date.

Oh, you meant looking back through the last k blocks. That was not clear in the OP.

This would not necessarily work since a coinbase transaction can pay to multiple outputs, i.e. pay multiple people simultaneously instead of just one person/entity.

Edit: My reading comprehension is way off today.

The private key is enough to determine the segwit address, although you may need to tell whatever other wallet software you choose to use to generate such a segwit address.

It's extremely unlikely that every single user is going to attempt to open lightning channels simultaneously on the day that a fully released software for LN is available. It is extremely unlikely that every single user is going to attempt to close their lightning channels simultaneously. As with literally every other release of a new technology in Bitcoin, it's going to take months, probably years, before LN is actually widely used. Just look at how long it took for P2SH to become widely used. And how long it has taken for segwit. This situation you are describing is extremely unlikely to happen.

This behavior is known as fee sniping and there are things that are working already to protect against it. First of all, by having more fees in unconfirmed transactions than can be cleared by a block, miners will be more incentivized to mine those unconfirmed transactions because they can make just as much or more money than by fee sniping. Secondly, many wallets are now implementing anti-fee sniping measures such as locktimed transactions. By setting a transaction's locktime to be the block height when a transaction was created, the wallet prevents a miner from being able to orphan that block and fee snipe and include new transactions because the new transactions cannot be included in that replaced block. So this reduces the amount of money that can be gotten by fee sniping which makes miners less incentivzed to do so.

It's impossible to know how many miners there are and impossible to detect if someone is is pretending to be multiple miners so that they get paid more and everyone else gets paid less.

Segwit does not use that as the scriptPubKey. Only segwit output scripts use BIP 143.

You are missing something. The first input is not a segwit input, so the hash calculation for that was ignored and skipped over. The second input is a segwit input, and is P2WPKH. This means that the scriptSig will be empty. The txwitness field contains the signature for the second input.

The comments are not part of the backup nor are they part of the blockchain or stored anywhere else. The comments are local to your wallet file only, and if you do not have the original wallet file, then the comments are gone.

First of all, the idea is not new and has been proposed multiple times throughout the years. But those proposals never actually go anywhere.

I see at least two things wrong with this proposal right of the bat.

First is this idea of balances. You are effectively introducing an accounts system, but Bitcoin does not work on an accounts system. Introducing an accounts system also introduces several other issues. First and foremost is transaction replay. Suppose, after a masterblock, your balance is 1 BTC and you want to send me 0.1 BTC. Since you are using a balance and not the UTXO set system, I can just keep replaying that transaction sending me 0.1 BTC. To the network, it looks like you just keep sending me 0.1 BTC, there is no way to differentiate between you sending me 0.1 BTC and me replaying the same 0.1 BTC transaction. Secondly, as you mention in the document, this doesn't work with scripts like multisig. In order to support those you have to have even more stuff that makes this more complicated. Then there's the problem with making transactions. Now you need to have multiple transaction types, one for spending from a balance, one for spending from balance with weird scripts, and the normal transaction type. This is complex and prone to error.

Instead of this balances thing, it would be much easier to effectively have one giant transaction in that masterblock which spends all previous UTXOs and creates new UTXOs. Those with the same scripts are combined so that each output has a unique script and the value of the output is the sum of all of the UTXOs for that script. This avoids all of those problems I mentioned earlier.

Next, there is a problem for new nodes. When you start up a new node, how does that node know that it is using the correct blockchain? How does it know that the balances are correct? There isn't anything that prevents an attacker from creating essentially a fake masterblock and giving it to new nodes. Since new nodes don't have the full block history, how can they be sure that the masterblock is actually valid?

It's better to do this on the bitcoin-dev mailing list.

That is orthogonal to BIP 49. That is something to do with BIP 39 and is unrelated to key derivation. Unfortunately BIP 39 does not have a versioning scheme to give seeds version numbers.

There's already several threads about Bitcoin and quantum computers. Please learn to Google or use the search function.

Locked.

That's the powlimit variable found here: https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L83. To increase it, just make the number bigger.

Have you audited your general purpose laptop and all of the chips it is using? It is far easier to audit the hardware wallet if you know what you are doing. Furthermore their firmware and bootloaders are mostly open source (for the Trezor, they are all open source, for Ledger, only partially) whereas the firmware for your laptop is most definitely not.

It looks like your wallet.dat file is corrupted. Did you move the file while Bitcoin Core was running?

If you have a backup of your wallet.dat file, you should restore that backup. You will need to stop Bitcoin Core, copy the wallet.dat in the datadir to somewhere else (don't delete it), copy your backup wallet.dat into the datadir, and start Bitcoin Core.

Not necessarily. You may need to increase what the maximum target value is (i.e. decrease minimum difficulty) if you are also changing the target interval time between blocks.

If the reindex fails, you should delete the highest numbered blk*.dat and rev*.dat files in the blocks/ folder in the datadir.

This rarely happens and is usually not Bitcoin Core's fault. In many cases, it is just spurious/random corruption (cosmic rays, random bit flipping, etc.). Other times it is a hardware problem.

Have you tried deleting the highest numbered blk*.dat and rev*.dat files and then reindexing (deleting those files will force a reindex anyways)? This will remove the corrupted block (and a few others) which will then be redownloaded after the reindex completes.