Right, getaddressinfo was merged for 0.17, not 0.16. It's validateaddress for 0.16.

Get an address from your wallet and go to the debug window. Then type
Find the field for and tell us what it says. I suspect it will say false.

Since you say that your wallet is old, there's a good chance that you still are using uncompressed public keys which are not allowed by segwit. This has nothing to do with a wallet being non-HD; it just means that you are using a wallet that does not support compressed public keys.

To use compressed public keys (so that you can use segwit), you can upgrade your wallet to use compressed public keys by starting Bitcoin Core with -upgradewallet. Note that this will not make your wallet HD, it will only upgrade it to support compressed public keys. Then you will need to flush and regenerate the keypool. Unfortunately I don't think there's a way to do that right now besides just generating a few hundred addresses. At some point it will start giving you p2sh wrapped addresses instead of legacy addresses as the keypool runs out of the old uncompressed public keys.

If your wallet is not encrypted, you can encrypt it and that will automatically flush and regenerate the keypool for you.

edit: validateaddress, not getaddressinfo

The 3rd option proxies all of your traffic. The 4th option only proxies TOR connections. So setting the 4th option allows you to connect to node's that are listening over TOR while connections to IPv4 and IPv6 nodes happen over your normal connection. The 3rd option will proxy ALL connections.

Yes.

The first option enables UPnP which will automatically tell your router (if it supports UPnP) to allow connections through to Bitcoin Core's P2P port. Typically routers will block such connections. Such routers will need port forwarding enabled for the P2P port. UPnP does that automatically.

The 2nd option disables the incoming connections entirely.

No. The security risk is the same.

You can use a tool like https://github.com/laanwj/bitcoin-submittx to broadcast it. However your transaction probably won't be relayed and probably won't propagate well since it is non-standard.

You have two programs that are trying to use the same port. You can't do that. One of your bitcoind instances will need to use a different rpcport (-rpcport) and normal p2p port (-port)

The transaction won't be in most node's mempools (note that there is no "the mempool"). Most nodes will not accept a transaction whose locktime has not yet passed.

No. Transactions that have been in a node's mempool are automatically evicted after a certain amount of time (default is 2 weeks). You could rebroadcast the transaction routinely, but in your case, that won't help.

Not a concern because it won't be accepted to the mempool in the first place.

Yes. If a block contains a transaction that has a lock time that has not yet passed, it will be invalid.

Yes. Your digital signature protects the locktime, just like all other parts of the transaction. Changing the locktime would make the signature invalid thus making the entire transaction invalid.

Yes, You can spend the same output in a different transaction thus invalidating the locktimed transaction.

Yes (aside from the estimates; it's hard to predict the future).

Yes.

By constructing the coinbase transaction of the genesis block and hashing it. Because the genesis block only contains one transaction (the coinbase transaction), the merkle root hash will be the same as the hash of the coinbase transaction.

To construct the coinbase transaction, you will need more information, such as the transaction version number, any other data that is going into the coinbase script, and the output value. The pubkey will be used in the output script.

Because it is necessary in order to generate the coinbase transaction whose hash is the merkle root.

You have to actually mine the genesis block. You can do that with a while loop in chainparams.cpp that calls CheckProofofWork (with some modification). Or just use a script like https://github.com/lhartikk/GenesisH0 to do it for you.

Just knowing those 5 things is not enough to construct the block header. Furthermore, knowing the merkle root means that there is no need to know the phrase or the pubkey; those are part of the coinbase transaction which is part of the merkle root.

In addition to the nonce, time, and merkle root, you also need the nBits, the block version number, and the previous block hash. For the genesis block, it is version one, nbits of 0x1d00ffff, and previous block hash of 0000000000000000000000000000000000000000000000000000000000000000. Following the format for the block header, you get a block header of 0100000000000000000000000000000000000000000000000000000000000000000000003ba3edf d7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b 7c. This is then hashed with SHA256d to get 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 which is the block hash. It is interpreted as a little endian 256 bit integer, and displayed as a big endian 256 bit integer so you get 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f. Note that the hash is always in little endian byte ordering when used in other block headers.

AFAIK not many people are doing stuff with sidechains so it's fairly quiet. Elements is still being worked on, I don't know what the current state of it is.

Assuming that you are running Bitcoin Core, you can use the getblockheader command to get the block header for a given block hash. To get the raw block header so you can hash it, you would do

What do you mean by "print coins"? Anyways, such questions are off topic for this thread.

Yes.

Special settings for what?

Yes. The xpubs are derived from your seed at different paths, so they will be different.

First of all, do not necropost (posting in topics that have not had a post in a long time), especially with your own issue, not an attempt to help the OP. I've moved your post into its own thread.

Bitcoin Core is not called Qt, and the Qt version is completely irrelevant. What is the version of Bitcoin Core (which is not Qt).

How do you know that it is hanging? Sometimes Bitcoin Core can take a long time to start up, but that does not mean that it is hanging.

Of course there won't be a balance, the blockchain isn't synced yet.

Don't do that, you'll end up corrupting things further. You cannot just remove and replace files while they are still in use by the software.

Please post the contents of your debug.log file.

No.

Hardware wallets ONLY execute things from their firmware; you cannot get a hardware wallet to execute arbitrary code (barring some major vulnerability). Furthermore, hardware wallets are not just generic storage devices, so a computer infected with malware can't read or write arbitrary data to a hardware wallet as it would with any normal storage device.

Some hardware wallets (like the Ledger Nano S) have apps that can be loaded onto the device to run things. If the app were malicious, maybe it could do something which is like ransomeware. However apps are isolated within the device itself (at least for the Ledgers) and don't have access to read and write arbitrary data to and from the devices internal memory (barring some vulnerability).

In theory, if the user is incredibly stupid, some malware could flash a new firmware to the device (which requires the user to push physical buttons on the device itself in order for a new firmware to be flashed) which then results in the stored seed being stolen. In practice, no, there isn't.

Yes. The DNS seeders maintain their own databases of nodes and have their own crawlers. They crawl the network to find nodes. Of course nodes are removed from the database as nodes drop offline so it doesn't grow infinitely big.

Looks like it is.

Bitcoin Core uses a thing called DNS seeders. These are not websites; they don't serve HTML. They are just special domains where asking for the domain's DNS records (i.e. resolving the domain name) will return you the IP addresses of several nodes that you can connect to. These nodes are then connected to get more IP addresses to connect to.

If the DNS seeders are offline, there are a set of hard coded seed nodes as well. The same thing is done with the hard coded seed nodes as with the ones returned by DNS seeders. The only reason to use DNS seeders is that they are more up to date and accurate. Hard coded seeds are only set prior to release, so they could be outdated.

Renaming a program is not going to change the behavior of the program, which is what you want to do (change it from using mainnet to using testnet).

To start bitcoind in testnet mode, use -testnet.

That they use the same bitcoin.conf file is known, you can use the -conf option to choose a different config file for one of your nodes.

Your proposal is not all that new, it's very similar to BIP 37. BIP 37 uses bloom filters to allow a node to only receive transactions that the node wants. It is specifically used by lite wallets in order to avoid downloading the entire blockchain. However BIP 37 has its downfalls; specifically it is computationally expensive for the full node serving the data, and it does not preserve privacy well (an issue specific to wallets).

However, there is one problem with your idea: what do you choose to filter? And with a filter, how do things not in the filter get transmitted through the network to the miners? How do you guarantee that someone will relay your transaction? The flood protocol practically guarantees this. But having everyone filter out transactions to relay would result in a lot of transactions being missed and thus not relayed.