I don't understand why you are so fixated on choosing your own private key that is memorable. Why not instead generate random private keys until you generate something that you find memorable. That is far more secure than you choosing something memorable.

It can be stolen the moment you decide to spend the coins and have to enter you private key into some software. Even if you are keeping the coins in long term storage, at some point in the future you will want to move those coins out of storage to do something with them. Whenever you do that, you expose your private key and it can be stolen.

Similarly, the same argument can be made for randomly generating a private key and keeping it on a storage medium that never touches the internet.

There is also still a significant privacy loss even if you are only using that address for receiving. For starters, everyone that sends you money will know how much money you have. Furthermore you are reducing the privacy of everyone that transacts with you because anyone will be able to look at their transactions and immediately know who they were paying and how much.

addwitnessaddress was primarily a shim to facilitate testing of segwit. It was not really meant to be widely used by users for segwit.

Segwit addresses beginning with a '3' are actually P2SH addresses. This means that the address itself is mapped to a script (after all, it is Pay-to-script-hash), not to a private key. From there the parts of the script itself are mapped to a private key. However dumpprivkey does not go that deep, it only takes things that are mapped directly to a private key, which are P2PKH addresses and public keys. Segwit addresses are not mapped to a private key because they are really just P2SH addresses. So using dumpprivkey with segwit addresses will return an error (as will using any other P2SH address).

To get the private key of the address, you need to take the address that you used addwitnessaddress on originally and call dumpprivkey on that address.

The page number and location that you find memorable, even if a "huge" string of numbers, is probably something that many other people would find memorable. Regardless of what number you choose, it will not be as secure as randomly generating a private key. What you are doing is similar to brain wallets which are notoriously insecure. Except your method is less secure as it does not include any key stretching or additional things to possible add randomness (e.g. hashing) that brain wallets do.

There's nothing stopping you from randomly generating a private key and then figuring out its location on directory.io. Or randomly generating the page number and randomly generating the key index on directory.io so that you can memorize them for your key. That would be more secure than you choosing the location manually. You can even keep generating random numbers until you find one that is memorable to you. That is much more secure than you choosing your own private key.

Furthermore you are still vulnerable to many attacks (even the same ones that you thought you weren't vulnerable to) with your scheme.

First of all, you are essentially sending your private key to a remote web server (directory.io). The owner of that website can see that your browser would be visiting the same page over and over again. It would not be hard for them to just search through the private keys on that page and see which ones have coins and then steal them. In fact, any man in the middle could do this. The site doesn't even use https so anyone sniffing traffic on your internet connection (e.g. shared wifi) would be able to see exactly what page you are on and then just scan those private keys.

Secondly, you still need to load that private key into a wallet software in order to spend from it. You will probably have the private key on your clipboard, and the private key will be held in insecure places and in insecure memory. With a proper wallet software that generated your private key, the private key will remain in that software's memory (unless you export it). Your private key would then be able to be stolen by keyloggers and clipboard loggers which constitutes far more viruses than coin stealing viruses as coin stealing viruses much find specific files to steal your coins. This means that your key is much more vulnerable to viruses on your computer. Additionally you would still be vulnerable to traditional coin stealing viruses because most wallet software will write imported keys to a wallet file so normal coin stealing viruses can go steal those wallet files.

Thirdly, because the private key is in an unencrypted form, if the private key is stolen, then the thief can spend your coins immediately. With wallet encryption, if your coins are stolen, you still have time to move them as strong encryption and a strong password will protect your private keys.

Lastly, you would be reusing the exact same address over and over again which will lead to significant privacy loss. There's a reason that nearly all wallet software gives you a new address every time you want to receive coins and every time it makes a change output.

What is the code that you are using to generate an address?

Yes, it will.

I don't remember the actual behavior. I don't think it will upgrade the database.

Using directory.io to choose your private key is a horrible idea, regardless of whether you are online or offline. Private keys are only secure if they are randomly generated using a cryptographically secure random number generator. By using directory.io (or any other list of private keys) to select your private keys manually, you are significantly reducing your security because humans are notoriously bad at securely generating random numbers. You as a human do not provide enough entropy to actually choose a random number randomly, which means that whatever private key you choose will be insecure and more likely to be easily brute forced.

Who said that it was supposed to be useful to the poor? You don't need to be poor to have a bad internet connection.

A factory reset often does not wipe the flash storage completely. It will format it, but the data is still there and could be theoretically retrieved. The only way to be sure that your private keys do not exist on the device are to delete the file and overwrite it with 0's or random data. Unfortunately that is a bit hard to do on a phone.

For most use cases, unless you think the person you are selling the phone to both a) has the expertise to perform data recovery on a phone and b) knows you had coins on the phone, it should be safe. Additionally, if your wallet has a passphrase on it and is encrypted, then your private keys should be safe.

Yes, that should be correct.

The satoshi datadir is the folder on your F:\ drive that has all of the blockchain data. You can check to see what Bitcoin Core is using as its datadir by opening Bitcoin Core and going to Help > Debug Window > Information. The datadir is listed there.

Yes, 1 is the value that will trigger the crash.

That is the right setting but the wrong value. Just set it to be 0 instead of 1. We will be released 0.15.0.1 shortly which contains a hotfix for this bug.

No, not that conf file. That's the Bitcoin Core conf file which the user must create. What I am looking for is the Qt QSettings storage which is not something done by Bitcoin Core but rather handled by the Qt framework.

You need all of that data in order to use the wallet software that you have chosen to use.

The satoshi datadir is Bitcoin Core's datadir. It is where the 144+ GB of data is stored.

Just because Bitcoin Core does not do it doesn't mean that it is not allowed on the network. Just look at how NetMsgType::TX is handled: https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L1762. Nowhere in that does it require it to have received an inv with the txid. The inv with the txid is only there to avoid sending txs to peers that don't need them and thus save on bandwidth.

A node can and will accept an unsolicited transaction, i.e. it will receive and handle a transaction that was not announced to it with an inv message. There is no need to send an inv message to announce the txid first, just that it is more efficient to do so instead of just sending a tx.

You can't do that in Bitcoin Core. However there are other tools and software that allow you to broadcast a transaction. You can use submittx to do this: https://github.com/laanwj/bitcoin-submittx

You will be able to use both in the same wallet.

GUI support for multiwallet is not yet complete and not available in 0.15.0. It should hopefully be complete for 0.16.0.

No, that is unnecssary.

Run Bitcoin Core manually. First stop both Bitcoin Core and Armory. Then start Armory and go to File > Settings and uncheck the option "Let Armory run Bitcoin Core in the background". Then stop Armory. Start Bitcoin Core and let it fully sync. Then start Armory again.