This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1825329.0

Duplicate

Since you have such a low amount of ram, you need to set some parameters to reduce ram usage. Go to the Bitcoin Core data directory and either make or edit the bitcoin.conf file. Add in it these lines:
and then start Bitcoin Core. It should use less RAM and thus not crash.

That's all you need to do. When you open Core, you should not see any out-of-sync overlay or a green bar at the bottom. If you hover over the checkmark at the bottom right hand corner, it will tell you how many blocks it has synced. Compare that to a block explorer to check if you are in sync.

If Core is in sync, then Armory somehow got off sync. With Core running, start Armory. Go to Help > Rebuild and Rescan Databases and click Yes. Then restart Armory. This should fix your problems.

Well unfortunately right now it won't work if you are missing blocks, so you will need to redownload those blocks. I don't think there is any mechanism yet to redownload only the blocks that are missing, so you will need to redownload the whole thing.

Your node is behind by ~1.5 weeks. You need to be fully synced in order to see recent transactions. Shut down Armory and open up just Bitcoin Core and let it sync. If Bitcoin Core is synced, then Armory's databases have an issue, in which case you will need to rebuild and rescan the databases.

Yes. However the xpriv is the master private key, so you should not be sharing that with anyone.

You cannot receive Bitcoin directly to an xpub. You use the xpub to derive new addresses which you use to receive Bitcoin. However, Bitcoin Core uses hardened xpub keys so you can only derive addresses by using the xpriv to derive the private key and then get the address from that.

The wallet.dat contains your private keys. When you change your password, the private keys you have already used stay in the wallet so that you can spend your Bitcoin. However the look-ahead keypool is refreshed so that any new addresses you request after the password change are not in the old wallet with the old private keys. This means that if you don't spend your Bitcoin after you change your password, anyone with a copy of the original wallet with the old password can still steal your Bitcoin if they have the old password.

Your transaction pays a low transaction fee rate. Read the thread I linked to above.

I do not know. I have never heard of that service, never used it before, and not affiliated with it in any way whatsoever. I cannot answer your questions about that service.

Your transaction likely paid a low transaction fee. Can you please post the transaction id?

See https://bitcointalk.org/index.php?topic=1802212.0 for what you can do about your transaction.

A reindex may fix the problem. However you still may need to redownload the entire blockchain.

You would need to know what industry each address corresponds to, and that is something that can't really be found out.

There have been significant performance upgrades so it will appear to run faster but not use more bandwidth.

Segwit was originally developed as a hard fork. It only became a soft fork after luke-jr figured out that the way it was as a hard fork could be fairly trivially done as a soft fork.

Can you please explain how Segwit is more complex than FlexTrans (with specific details about the proposal, not just hand wavy analogies)? I don't think it is more complex, in fact, I think it is simpler than FlexTrans as everything in the transaction is in a known location, you don't need to go searching for tags.

BIP140 does not do as much as Segwit or FlexTrans does.

First of all, that would mean that the inflation rate is not stable, it would depend on the number of transactions. Secondly, it becomes extremely difficult to predict roughly when a certain blockchain event will occur, like the halvings. Next, this is something that is very easily gamed. A miner could make and broadcast a ton of transactions so that they can lower the difficulty and thus mine more blocks and earn more money. Faster blocks also means more orphans.

Lastly, and most importantly, the number of unconfirmed transactions and what the unconfirmed transactions are varies from node to node. There is no way to fix the difficulty to the number of unconfirmed transactions because every node would then calculate the difficulty differently since not all nodes would have the exact same transactions in the mempool. If you were to tie it to the size of the block, then that is extremely easily gamed by a malicious miner because then they could risk no money of their own, and just make massive blocks to decrease the difficulty.

It depends on what wallet software you are using for your digital bitbox. Most wallet software allow you to sweep or import private keys into your wallet.

Well that's interesting and probably a bug. It looks like this happens because the script is verified after signing, and a partially signed script is not valid.

Edit: Can you try this with older versions of Core, particularly 0.11.x and 0.10.x? The change to verify scripts was first introduced in 0.11.0, so I want to see if that is what's causing the issue.

Explain WHY it won't work. Just saying that it won't work with no additional reasoning as if you are some all-knowing power better than everyone else is not conducive to discussion. Explain WHY, give reasoning, give an argument.

This email should have what you want: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011591.html

I don't think that list of moderators has changed.

I think the reason that your emails are being rejected is that you are not adding anything to the topic. Your posts are not constructive, you don't provide any reason except "You're stupid/wrong/insane". This is both toxic and not conducive to discussion, so your mails are being denied. You say that it won't work, but provide no additional reasoning or arguments to back up that statement. The mailing list is for discussion, so you have to have arguments that people can discuss, not just "You're wrong".

Chains of unconfirmed transactions can be invalidated by malleating a transaction in that chain and having that malleated transaction confirm. So it is possible that people send an exchange like Mt. Gox Bitcoin being spent from an unconfirmed transaction, and one transaction in the chain is malleated thus invalidating the whole chain and the service never actually receives the Bitcoin.