Anything that would cause this function: https://github.com/bitcoin/bitcoin/blob/02464da5e4aa8c19d4fff3859dcdee822e2af78c/src/wallet/wallet.cpp#L1052 to return false. So it seems the only criteria are that the transaction is not in the mempool and it is not confirmed. So clearing the mempool by restarting the node should work (if you are using any version greater than 0.13.2 i.e. a build of master, then you need to delete mempool.dat in the datadir).

No, that means that something else is blocking it from being abandoned. I'm pretty sure it still works in pruned mode as I'm pretty sure I did it before.

Right click the transaction and choose "Abandon transaction" or use the abandontransaction command in the rpc console.

Or you can use something like pywallet and remove the transaction from your wallet file manually.

Your derivation paths are wrong. MultiBit uses BIP 44 for derivation paths, not the normal BIP 32 derivation paths. It should be m/44'/0'/0'/k/i

In your original MultiBit wallet, go to Tools > Repair Wallet (or something like that) and see if that works.

Log files please.

Uncheck the option to allow Bitcoin Core run in the background. Stop Armory, Start Bitcoin Core, then restart Armory. You may need to go to Help > Rescan and Rebuild Databases.

Try broadcasting the transaction manually. Open up Bitcoin Core and go to Help > Debug Window and then click on the Console tab. Then copy and paste this command:
This will broadcast your transaction through Bitcoin Core. The big string of hex is the raw hex of your transaction which I pulled from your log file.

Please report back if the command was successful or if there was some error (an error will be output in red in the debug console)

I can also attempt to broadcast this from my node if you want.

Start Armory with the --db-type=DB_BARE and --ram-usage=1 options set. You will need to delete the databases folder again as it will build a new, lighter database (and thus requiring less RAM and CPU to build).

First, I recommend that you set Bitcoin Core to be run manually instead of managed by Armory. This will fix a lot of issues. In order to do so, go to File > Settings and uncheck the box labeled "Let armory run Bitcoin Core in the background".

Then to fix your problem, go to Help > Rescan and Rebuild databases in Armory. Then stop Armory and Bitcoin Core if both are running. Then start Bitcoin Core, let it sync, then start Armory.

Armory will rescan the blockchain and rebuild its databases so that should fix the problem if your transaction has already confirmed.

Note that by having Bitcoin Core run manually that every time you want to open your wallet, you must start Bitcoin Core first and then start Armory.

Did it say that it was reindexing or syncing? If it was reindexing, it was not actually syncing, although I don't know why it was reindexing unless you have -reindex in the startup command or reindex=1 in your Bitcoin.conf. Are you sure that it is using the right data directory if you set a custom one?

If you double check that the datadir is correct, the bitcoin.conf and the startup command don't have reindex anywhere in them, then it will use the blockchain that is already there.

Yes. It will by default pickup wherever the previous version left off. It should always do that unless something is broken, i.e. wrong datadir or reindexing.

What OS are you using? If you are using Ubuntu, you can install it from the PPA.

Yes, you can transfer the wallet.dat files between computers and they will work with other installations of Bitcoin Core that are the same version or greater than the Bitcoin Core installed on the original machine. However if you move it to a newer version of Bitcoin Core, you may not be able to move that wallet back to the old version as changes to the wallet can make downgrades impossible.

I currently have an open PR for translations: https://github.com/goatpig/BitcoinArmory/pull/89. The plan is to have this in for 0.96 so if people could test it and review it, that would be great.

I wrote a tool a while back that takes a raw transaction and will modify it to boost the fee: https://github.com/achow101/feebooster. This tool has a few bugs and nuances that make it so I don't recommend people to use it, although you can if you know how raw transactions work. I just ran your transaction through my tool to create the raw unsigned transaction.

Just by examining the network traffic, I don't think they would be able to tell that you are running a node as the traffic should be encrypted. However, they would be able to see that you are connecting to a VPN and may be able to terminate that connection if they so chose. They would also be able to see that you are downloading and uploading a ton of data to and from that VPN.

I highly advise that you not do this. First of all, you are probably violating your schools AUP (aka ToS or T&C) by running a Bitcoin node that can accept incoming connections. Secondly, port 22 is probably already taken as that is the standard port for SSH. It is highly inadvisable to take up a standard port with something that is not doing what that port has been standardized for. Lastly, if you accept connections of port 22, you have a higher likelihood of not getting any incoming connections because port 22 is a nonstandard port for Bitcoin nodes.

You can still run a full node even without accepting incoming connections. You should still be able to make outgoing connections. You don't need to have any incoming connections to be a full node as you are still receiving and verifying every single block and transaction and then relaying them to your peers.

If you really want to run a Bitcoin node on port 22, start Bitcoin Core with the -port=22 command line option or add to your bitcoin.conf file. However, don't expect this to work as it is extremely likely that an SSH daemon is already using port 22 and that will prevent you from being able to use it.

You need to have the private keys corresponding to those addresses. The extended public keys (aka mater public key, any key can be a master key) are just normal ECDSA keys and they have a private key from which they are actually derived. You must have that private key (which can also be a master private key) in order to spend the Bitcoin associated with an address. The only special thing about HD wallets is the fact that the private keys are derived from previous private keys except for the first (the seed, or master private key of a HD wallet).

If you are using non-hardened keys, then you just need to follow the steps specified in BIP 32 in order to derive addresses from a public key. If you use hardened keys, then you can only derive private keys; the master public key will not work. With hardened keys, you derive the private keys from the master private key and then derive the addresses from those private keys.

This is part of the math of deterministic wallets. With non-hardened keys, the public key derived from a parent public key will have its private key be able to be derived from the private key of the parent public key. That is how wallets get the private keys in order to spend, they must know the master private key.

What do you mean? The extended public and private keys are normal ECDSA keys. They have corresponding normal addresses. Given an address, you cannot tell what wallet it is in, what private key its private key was derived from, what public key its public key was derived from, and whether its even part of a deterministic keychain at all.

The old transaction is considered a double spend so it will never be able to confirm. That transaction should already have been rejected by virtually all nodes, it only shows in block explorers because they show those transactions for information purposes.

My address is in my profile and under my avatar.

Changing the currency used for pricing is not going to magically make the prices lower. Cryptocurrencies and blockchains are not some kind of magical catch all that solves all financial related problems.

The reason medicine costs so much is due to regulation and competition. The lack of competition and the lack of anti-monopoly regulation simply causes prices to rise as businesses charge more and more because they can. This is simply economics, it has nothing to do with currencies.

You're confusing Segwit with Lightning. Segwit does not touch confirmations or anything like that, it only affects the data itself. The number of confirmations required will still be the same.

Lightning is different and allows instantaneous transactions because the transactions actually happen off chain. The guarantee that your transactions are final are done through incentives and retaliation. The only onchain parts of lightning are the opening and closing of payment channels.

Depends. They need to know what key derivation paths that your wallet uses. Then they have to derive the addresses and send the Bitcoin. Wallets will not accept the extended master public key when sending so it requires advanced knowledge.

You need to be able to delete transactions from the wallet or clear all unconfirmed transactions. Unfortunately, I don't think Electrum has this functionality, so you won't be able to do this without jumping through a lot of hoops.

Try contacting the two users I linked, not just using that link.