The same way you make a P2PKH vanity address (begins with a '1'); generate random private keys, calculate their public keys, hash the public keys, and encode it using bech32. You will need some software that can do that, but I don't know of any that currently exist.

No.

You make a block that follows different consensus rules and is consensus incompatible with the current blockchain such that it will be rejected by nodes not running your software.

It's the beginning of every bech32 address, the ones that start with a "b".

Yes. You can make a vanity address with any type of address.

Read BIPs 173: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki and 141: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

Bitcoin Core is unable to write to your wallet file. Make sure that your user has the permission to write to the wallet.dat file.

No, there is no way for that currently.

Yes, it is pay to pubkey. The P2SH part obscures that because the pubkey is part of the redeem script. The reason for doing P2PK instead of P2PKH is that it takes up less space than P2PKH nested in P2SH.

No, they are not. Each address has exactly one corresponding public key, and each public key has exactly one private key. The seed is used to derive the private keys.

It doesn't know, it just guesses. Private keys and their addresses are derived in the same order and thus are given out and used in the same order. So when you restore a seed, the wallet will scan the blockchain for transactions and generate some number of addresses ahead of the last address known to have a transaction currently in the scan. This number of addresses is called the gap limit, and is typically 20. Every time a transaction is found corresponding to an address in the gap limit, it will refill the gap limit by generating more addresses.

Read BIPs 39 and 32. BIP 39 specifies how the mnemonic is generated and then interpreted as a seed value. BIP 32 specifies how that seed value is used to generate the master private key and then how all other private keys are derived from that master private key.

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?