What software are you using to decrypt the key?

Because you are printing out the address of chSalt, not its contents. You are doing this everywhere that you have &. Why are you even putting & in front of things? Putting a & in front of a variable name gets a pointer to that variable, not any of its values. If you wanted to dereference a pointer to get the value it points to, you use *. But none of these are pointers, they are references which are treated exactly the same way as values. If you run it again, you will get different results because of different memory locations.

---

What are you trying to even accomplish?

Yes.

Within CMasterKey, vchCryptedKey is the encrypted master encryption key. This key is decrypted using a key derived from the user's passphrase (with key stretching parameters specified withing the CMasterKey. The decrypted encryption key is now a CKeyingMaterial and stored as vMasterKey in CWallet.

Encryption keys (along with some metadata) are stored in the wallet.dat file. They are encrypted by a key derived from the user's passphrase.

This is very likely to be a bug in Bitcoin Core. There is already an open issue for this problem: https://github.com/bitcoin/bitcoin/issues/16778.

Old release binaries are available at https://bitcoincore.org/bin/ and https://bitcoin.org/bin/. Some may be in the insecure folder. The oldest available is 0.8.6.

I also publish my gitian build results on my own repo: https://github.com/achow101/bitcoin/releases. The oldest there is 0.9.something.

Do you see any of the files that were replaced mentioned in the debug.log?

You can check in the debug.log file. It'll say something about reindexing there.

IIRC, reindexing can result in the block files having different modification times, even if they weren't actually modified.

Did you have to reindex after restoring the backup?

What is your question, and what does it have to do with Bitcoin?

If this is just a general python question, try asking on https://stackoverflow.com/

Public key recovery is a function of ECDSA and is not restricted to any particular curves. It is a property of the signature algorithm (ECDSA), not of the curve. So yes, you can do public key recovery with any curve if they are using ECDSA.

The Schnorr signature scheme that is described in the proposed Schnorr BIP doesn't allow for public key recovery even though it uses the same secp256k1 curve that is currently used by Bitcoin.

This will never happen. Any sort of telemetry will get shot down immediately and never be merged. Pretty much every contributor will Concept NACK it. Such a PR probably wouldn't even last an hour before it was closed.

Besides the fact that there are privacy concerns, there is also the issue of who is going to host the database that receives the data? What happens if that person stops working on Core (or dies)? How will those servers be paid for?

For the most part, you won't be dealing with those abbreviations. The higher level policy language doesn't have those and the available policies actually have human readable names.

Even so, the actual miniscript language itself is far more readable and understandable than Bitcoin script itself. When you have a complex script, it is going to be very hard to actually reason about what it does. The miniscript representation of it will be far easier to understand as you can actually part it into an AST and break it down into individual parts to read. And even then, those annotations aren't even necessary for understanding what the policy is, that's why there is a policy language that omits them.

Also, there's like 5 or 6 abbreviations and you can quickly memorize them. It really isn't that complicated. If you think that Bitcoin script will be "way easier to read", I don't think you've even tried to use miniscript or have tried to make a complex script.

You can get a list of available RPCs from Bitcoin Core directly using the help command, and the help documentation for each command using help <command> where <command> is the command you are interested in.

In order to load a wallet, you use the loadwallet command. In order to send RPCs to that specific wallet, you use the -rpcwallet=<wallet name> option in bitcoin-cli where <wallet name> is the name of the wallet you want to access. To use the sender wallet, you would have -rpcwallet=sender, for the receiver, -rpcwallet=receiver. And for the default wallet (the one in regtest/wallets/wallet.dat), use -rpcwallet= as the default wallet has no name.

You are wrong and it is clear you didn't read the thread at all. OP can use bitcoin-cli to interact with blockchain.com's RPC interface which they made to be compatible with Bitcoin Core's. Installing bitcoind does not run bitcoind nor does it download the blockchain. He isn't using bitcoind at all. bitcoin-cli doesn't need access to the blockchain either, it's just a dumb client.

Yes.

They are all being sent to a new address. But that new address is part of your wallet. A wallet is a collection of multiple addresses and their scripts and keys. Bitcoin Core does not treat eat address separately, they are all bundled together as a single wallet. Since you are sending coins from one address in your wallet to another address, the net value going in and out (ignoring fees) does not change with that transaction, so it lists the amount of that transaction as 0.

You are sending money back to yourself, of course it's going to register as 0 amount.

Amount is calculated by: amount_in - amount_out - fees. amount_in is the total value of the outputs that belong to you. amount_out is the total value of the inputs that are yours. fees is the transaction fees paid. You have 2.4 + 47.59993360 = 49.99993360 in as that's the amount you are sending + the change output; no Bitcoin is going to anyone else. You have 50 out as that is the value of the input that is being spent.And -0.00006640 as the transaction fee itself. So the final amount is 49.99993360 - 50 - -0.00006640 = 0.

In order to get an amount that is not 0, you need to send Bitcoin to an address that is not part of that wallet. You can easily do this by creating another wallet using createwallet, getting an address from it, and sending coins there.

You can install the snap package or  download the linux tarball and extract it. Either way, the blockchain won't be downloaded nor will Bitcoin Core automatically start after installing.

The bitcoin.conf file is used to store command line arguments so you don't have to keep typing them. In order to use blockchain.com's RPC, you have to provide specific command line arguments. If you instead put them in a bitcoin.conf file that is in the default datadir location (~/.bitcoin), then using bitcoin-cli without command line options will use the options in the conf file. Otherwise there is no need for the bitcoin.conf file.

Yes. IIRC the only installer that has the option of starting after install is the Windows installer.

Even if it does start after install, just watch ps (on linux) or whatever task/activity/process manager comes with your OS and check that neither bitcoind nor bitcoin-qt is running. If it is, you can kill it and just delete the datadir. It takes a while to download the blockchain, so if you kill it within a few minutes of starting, it won't have downloaded much.

What OS are you trying to install on?