When it comes to imported keys and address types, legacy wallets behave unintuitively (this is partially why they are slowly being phased out). The main thing is that the address type is not controlled by your import but rather by runtime options to Bitcoin Core itself. With importmulti, the type of addresses the descriptors that you import will create is completely irrelevant. The keys are imported into the keystore directly, and then the typical key to address type mutation is done when an address is requested. This is controlled by the -addresstype and -changetype command line options (or bitcoin.conf options), or by address type and change type options for the particular action you are doing.

If you want only p2pkh addresses, you need to tell Bitcoin Core to do that by setting -addresstype=legacy and -changetype=legacy when you start Bitcoin Core (or add them to your bitcoin.conf without the leading dash (-)).

This warning is because a private key is not available for that address so the wallet thinks it is not spendable.

Even with a watchonly descriptor wallet I cannot replicate this issue.

Does this occur with other types of wallets (e.g. legacy or normal descriptor)?

I tried following these steps but did not see anything abnormal. Perhaps post some screenshots?

Not necessarily. Since I wrote this post, there have been changes to the wallet. Notably, a new type of wallet known as a descriptor wallet has been added. Descriptor wallets use a different method for managing keys and they do not have keymeta records.

This is an interesting question and I took far too long to figure it out.

The transaction hex is

There are 3 key differences in the prerelease version:
1. The transaction and block versions are not included in the serialization for hashing
2. The nSequence is found in the CTxOut rather than CTxIn
3. OP_CODESEPARATOR is 0xa9 and OP_CHECKSIG is 0xaa

The last point was harder to find as the source for script.h is not available. However it can be easily bruteforced.

All of the above. If it's been too long since a flush, it will be flushed. If the cache is near or past its maximum (controlled by the -dbcache option, which can be dependent on available RAM), it will be flushed. And of course it's always flushed during the clean shutdown process.

It likely wasn't re-downloading anything (unless you are saying you observed network activity). Rather it was re-applying the chainstate updates that were lost during the power loss. These chainstate updates are cached in memory before being committed to disk, so a sudden power loss will lose those updates. These updates are the effect of processing blocks - it's really just re-processing those blocks. The caching is done for performance since waiting for things to flush to disk can be a significant bottleneck in syncing.

Not everything has to be object oriented. There's no point in having a class when there are no variables that those functions are managing, and there's never a need to make multiple of them.

To be clear, there is no error message when you open your wallet file? And you followed my instructions exactly? The only problem is that the wallet is empty and you are expecting it to not be?

Please post your debug.log.

What makes you think that?

It's just standard network software code. There's nothing special about Bitcoin or P2P software in this regard. It just combines client side software with server side software. Of course it requires having multiple threads/processes, but you should already be doing that for server side software anyways.

As with any client software, outgoing connections are made with random ports assigned by the operating system. Using standard system calls, a TCP connection will be opened by the OS using whatever port the OS decides. It works in the same way any software would to make connections to a server.

As with any server software, incoming connections are handled using standard system calls (such as accept, poll, select, etc.) and then passed off to other threads for processing. It works in the same way that any server software does to accept incoming connections.

Yes. It is simply a warning informing the user of the disk space requirements if you want the full blockchain, but there is no hard requirement that would make the software not run if it there isn't that much space available. Of course it will shut itself down if it actually runs out of disk space, but that's entirely different.

Why? That was not the instruction.

Because wallets generate some temporary files, wallets are in their own directories which are located either in the datadir (as you have done) or in a wallets folder inside of the datadir. There is no nesting further than that.

If you did not see a bunch of garbage characters in notepad (as in it opened and it looked like normal text), then the file is not a wallet file. If you made any changes, then it would be corrupted and unopenable.

---

Please follow these instructions and stop doing whatever it is you think is correct.

In Bitcoin Core, go to File > Close All Wallets. Then shut down Bitcoin Core. Go to your data directory and delete (or move out of the datadir) all wallet files and all directories containing wallet files. Inside of the datadir, create a folder named wallets. Inside of the wallets folder, create a folder with the name you want your wallet to be named. Inside of this new folder, copy the wallet.dat that you have. Start Bitcoin Core, there should not be any wallet loaded. Go to File > Open Wallet and choose your wallet. Please inform us whether this worked or if there was an error. If there was an error, then tell us what the error is. Even better would be to post a screenshot of the error.

To be clear, you created a new wallet named "Alix" and then replaced its wallet.dat file with one you already had? If so, did you do the replacement while Bitcoin Core was still running, or did you shut it down first?

---

To restore a wallet, go to the Bitcoin Core data directory and the folder named "wallets" inside of it. Make a new folder with a name that you want the restored wallet to be named. Inside of that new folder, place your wallet.dat file, named wallet.dat. Then start Bitcoin Core. In the GUI, if you go to "File" and "Open Wallet", you should see the name of the folder you just made in that list. Click it and it will open the restored wallet. If you are using the command line, then you can use loadwallet <name> where <name> is the name of the folder you created.

There's nothing wrong with this. That's a normal log line informing you where to find BerkeleyDB's error log file.

If there is an actual error, please describe it instead of picking out the things that you think are relevant.

That's normal. It's just telling you where the error log file is. There is no error.

The default RPC port for regtest is 18443, but you are using 18444.

You can turn off all network connectivity by clicking on the connections icon in the bottom righthand corner and that will instruct Bitcoin Core to not try to make any network connections. Then it isn't constantly "trying to sync". The out of sync modal will remain since it is unrelated to the network connection status, but that does not mean it is actually doing anything in the background.

I was not around when BIP 39 was first specified, so I cannot say why it was not implemented then, but I can speculate based on what I know. However I can say why it is still not implemented today.

Firstly, Bitcoin Core is an open source software where the developers work on things that they care about. There is no roadmap nor is there a project manager saying "go implement that". So if no developer wants to implement a feature, then the feature does not become implemented. So clearly, developers do not want to work on BIP 39. So we need to see why multiple independent developers do not want to implement BIP 39.

When BIP 39 first came out, Bitcoin Core had not yet implemented BIP 32, which is a prerequisite for using BIP 39. BIP 32 was first specified in 2012, but the Bitcoin Core wallet did not receive support for it until 4 years later in 2016. In that time, there had been multiple attempts to implement BIP 32, but those were much more complicated. What ended up being merged was the absolute bare minimum that could be considered BIP 32 support. The wallet was able to generate private keys deterministically, and that was about it. It did not allow users to set the BIP 32 seed, users could not import xprvs or xpubs, and users could not change the derivation path used. It ended up being this bare minimum and taking so long just for the bare minimum simply due to how the wallet is structured. It would take a lot of work to overhaul the wallet structure to actually support BIP 32 properly, so what we got was the absolute bare minimum, and that's what we have even till today, for the most part.

Only after BIP 32 was implemented could we start looking at BIP 39. The technical challenge post BIP 32 is not the big, although BIP 39 would still require significant changes to support. However by this time (in 2016), BIP 39 was already showing its weaknesses. Electrum used BIP 39 for some time, but they moved to their own mnemonic system (which is not really specified). One of the major issues of BIP 39 is that it is touted as a full wallet backup but fails to provide several key pieces of information. BIP 39 fails to provide the derivation paths used, and it fails to provide the type of scripts and addresses to use. The latter point was less evident prior to Segwit, but when Segwit was released in 2016, people began to realize the importance of specifying address types in backups.

People often point out the lack of version numbers in BIP 39, and usually this is referenced as a solution to the aforementioned derivation paths and address types. Personally, I don't think that versioning would help with that, but versioning would certainly help if there were improvements to BIP 39 such as using a different KDF.

Another frequently mentioned issue is the choice of KDF. The authors of BIP 39 chose to use PBKDF2, however this has long been considered to be a fairly weak KDF. I have heard some developers (of other wallets) indicate they don't want to use BIP 39 because of this, but I don't have a strong opinion on that.

There is also the fact that BIP 39 itself says that software should still accept mnemonics with invalid checksums, which is a really weird design decision to make. The checksum could definitely be better and the BIP should not be recommending that invalid checksums be basically ignored.

Lastly, the other main reason that Electrum moved away from BIP 39 was due to the requirement of fixed wordlists. In order for BIP 39 to generate the BIP 32 seed to use, it uses PBKDF2 on the mnemonic itself. This means that the mnemonic isn't really an encoding of the raw entropy used to generate it and that the same entropy used to create mnemonics with different wordlists (e.g. for other languages) would result in different wallets. This significantly reduces the portability and usability of BIP 39.

So with all of these shortcomings in mind, BIP 39 is not really the ideal single string wallet backup solution that people want, and so many developers feel like it is not worth it to invest the time to implement something that has been shown to be insufficient.

Now the question is what will we implement in lieu of BIP 39. This is something that I have been actively working on for the past several years. Pieter Wuille came up with the idea of strings of text called Output Script Descriptors which describe everything needed for a wallet to actually regenerate all of its keys and addresses. Unlike BIP 39, descriptors explicitly specifies the type of addresses (output scripts really, hence the name) to generate. They also explicitly provide the BIP 32 derivation paths. These two facts resolve the two major complains with BIP 39 - the lack of derivation paths , and the lack of address types. Furthermore, descriptors can be extended in the future with new types of descriptors. This can be done easily and was recently done to add taproot support. Bitcoin Core's wallet was completely overhauled so that we could use these descriptors as the basis of the wallet itself.

Currently, descriptors are not like BIP 39 in that they are much longer and aren't a mnemonic. I intend on proposing a generic mnemonic scheme which would allow for descriptors to be represented as a mnemonic, but that's still a ways off. There is still work to be done with descriptors themselves. BIP 39 is also insufficient for a generic mnemonic scheme since the way it is specified is really specific to entropy and generating a random seed for use in something like BIP 32. We would have to make a wholly new mnemonic scheme.

First of all, Schnorr signatures do not require that multisigs must use key aggregation. You can still have a traditional multisig where keys are listed explicitly and each key has a signature. There's nothing that prevents that. Specifically with Taproot, OP_CHECKMULTISIG was replaced with OP_CHECKSIGADD because it is much more efficient. Taproot also allows for more keys to be in the multisig and OP_CHECKSIGADD allows very large multisigs to be efficiently verified.

Furthermore, Schnorr signature merely allow key and signature aggregation schemes to work. This is just a property of the algorithm. There is no required method for key aggregated multisigs. There are many different ways you could do key aggregation; some are unsafe and some are safe (with rigorous mathematical proofs to back them up).

To be clear, a collision attacks is where an attacker can find any 2 inputs to the hash function which result in the same hash. Typically these are random inputs and it requires ~2^80 hashes. The important thing is that it is not finding another input which has a particular hash - that would be a preimage attack, and in the case of finding a different input, a second preimage attack. Preimage attacks require 2^160 hashes for hash160.

No, the address is an encoding of the hash itself and hashes cannot be reversed.

Yes, but it is probably not necessary. In the context of P2PKHn addresses, I think a collision attack is just kind of bad. What would be really bad is a second preimage attack as that would mean finding another keypair with the same hash. It's a different story for P2SH, which I will explain below.

A collision attack is unlikely to affect existing addresses as their current use is nowhere near the 2^80  upper bound for brute force collision attacks.

Trying to find a collision with any address in use might seem like a collision attack, but because the number of addresses to search is so much smaller than 2^80, it's more akin to a (second) preimage attack.

Collision attacks become problematic when someone is able to convince someone to accept coins with a particular address. This is unlikely for P2PKH, but could be a problem for P2SH. Suppose you and I are doing business together and we want to have some coins sent to a multisig address. I generate a keypair, you generate a keypair, and we make a multisig script. This gets hashed with hash160 and becomes a P2SH address. Now suppose that, in secret, I had actually generated tons of key pairs, and in parallel, constructed a different P2SH script where I am the sole signer. By generating new scripts with random keypairs, if I make 2^80 of them, I should be able to create two scripts which have a hash160 collision. One script will be the multisig between you and me, and that's what I give you. The other script is just me as the signer. Now when a payment is made to the supposed multisig address, I can take those coins because I have a script where I am the only signer and its hash matches that of the output.

This is the danger of a hash160 collision. It has to do with P2SH and how a malicious party could produce a colliding script with different spending conditions. Because it is more concerning for P2SH, P2WSH and Taproot both use SHA256 (or hash256) which is expected to need 2^128 hashes to produce a collision.