You should just copy the entirety of the Bitcoin Core datadir. However note that if you do that, you may end up with weird and unknown behavior on your Bitcoin Cash node if you have any blocks from after the fork. It may be better to copy the blocks folder and let Bitcoin ABC reindex the chainstate so that it can be on the correct blockchain.

Why do you need to do 80 transactions? You can send one transaction that spends all of your coins to whatever addresses you want; addresses don't matter. The only reason to not do that is for privacy, in which case whatever you do on Bitcoin you will have to do on BCH.

Yes, you can fork the Breadwallet source code and add support for BCH. There isn't anything that's stopping you from doing so. How you are going to do that is up to you and for you to figure out.

AFAIK there are no proprietary APIs, the whole thing is open source under the MIT license.

Trezor has already released an updated firmware that fixes this problem: https://blog.trezor.io/trezor-firmware-security-update-1-5-2-5ef1b6f13fed

They have also released a full report detailing the vulnerability: https://blog.trezor.io/fixing-physical-memory-access-issue-in-trezor-2b9b46bb4522

Lastly, the medium post that is often referred to is vague, describes the attack that was already fixed, and does not describe any new attack or any details of how the attack used for <1.5.1 firmware versions would work on 1.5.2. It is highly suspicious, does not follow responsible disclosure, is asking people for money for the attack, and in general, does not appear to be credible at all. Independent researchers had discovered the vulnerability too and the fixes for it were in the public github repository, so it seems that that person simply looked at the commits that fixed the problem and decided to FUD about it.

Yes. If your wallet is an HD wallet (wallet files used in 0.13.0+ are not automatically upgraded to be HD so an old wallet used in 0.13.0+ can still be used in previous versions) it will not work on older versions of Bitcoin Core. Those versions will tell you that the wallet file is too new for it and it will fail to start.

Consensus has nothing to do with this. If the wallet software is based off of Bitcoin Core 0.13.0+, then it should be able to use the HD wallets.

The wallet format itself is not different. All that changed was that a new key-value pair was added to mark a private key as the master HD key. Everything else is the same. The version number is also bumped to make it so that older wallet versions know that they don't support that wallet.

The difficulty on testnet can vary wildly. There may be times that you are able to CPU mine on testnet, other times you won't be able to as the difficulty increases.

Yes. You should also see the strings version, ckey, mkey, minversion, pool, keymeta, hdchain, etc. These strings mark what type of entry a key-value pair is. You can also use BDB's db_dump utility to see what the key-pairs are.

Bitcoin Core encrypts keys individually, i.e. the entire file is not encrypted. Each encrypted key is the roughly the same length, as are most other pieces of data in the wallet. You can tell if it is corrupted by looking at the unencrypted data and seeing if that looks corrupted. If keys themselves are corrupted, then you can't tell until you try decrypting them.

Don't use rpcuser and rpcpassword. As I said, they are deprecated now and will be removed in the future. All bitcoin.conf options can be specified on the command line.

Those parameters are for deploying soft forks in Bitcoin. If your altcoin does not plan on deploying soft forks or these soft forks specifically, then you don't need those parameters. However removing those parameters means that you will need to change a lot of other code to not be checking for whether those forks are active or not.

Your scriptPubKey is wrong. You are using pushdatas to push the hex numbers 5 and 10 to stack. To push just 1 byte, you don't need to use OP_PUSHDATA1. You should only be using OP_PUSHDATA1 when you have more than 75 bytes of data to push. opcodes 1 through 75 (0x01 - 0x4b) just mean "push that number of bytes to the stack".

Also, Bitcoin Core will not be able to sign your transaction because it does not know what kind of script your scriptPubKey is so it does not know about what needs to be done in order to sign it properly.

Pull requests welcome. If you think it is broken, fix it. I see no issues with it.

I don't think the price calculation should be removed as that is the explicitly stated purpose of the site anyways.

Try using the WIF compressed key instead.

Go to Help > Rescan and Rebuild Databases. Then restart Armory.

It's already happening. It was already working and happening when it was announced. It isn't just hype; there are instructions for how to set up your own stuff now since it is already broadcasting now. People have already set up receivers and are receiving blocks.

The satellite is best for places where you have a low bandwidth and poor internet connection. That type of internet connection is too poor to support running a full node, but is fine for sending transactions as transactions are small. The satellite then allows you to receive blocks through something other than a poor internet connection.

That's not true at all. Most wallets are developed on and designed for linux systems as most developers prefer using linux. Linux is often the best supported system since that is where development and testing happens. For both Bitcoin Core and Armory, wallets are developed on Linux and only tested on Windows and OSX briefly and by few people. OSX is often most heavily neglected.

This topic has been moved to Trashcan.

Duplicate

That pull request has already been merged into Bitcoin Core. It will be part of the 0.15.0 release. This means that if you run Bitcoin Core 0.15.0, you will be disconnecting all segwit2x nodes.

A large part of the technical community opposes segwit2x for a variety of technical reasons. Furthermore, Bitcoin Core will not be supporting Segwit2x. The hard fork will likely still happen, just not very cleanly. If segwit2x continues to refuse to implement replay protection, refuses to set the hard fork bit, refuses to change their network magic, etc, then their hard fork will cause a lot of problems. This could result in network partitioning and replayed transactions (and thus potentially fraud). Since it is basically guaranteed to be a messy chain split, they should be working to make it as clean as possible, after all, they are the ones diverging from the status quo.

Note: I am not a PHP programmer

Your probably want to do something like this:

Yes, you need that much space for the full blockchain. Bitcoin Core is a full node; it downloads and stores the entire blockchain so that it can fully verify every single block and transaction on the network. This provides you the best security and privacy for a desktop wallet (besides privacy in transactions themselves).

You can run Bitcoin Core in pruned mode so it will not take up so much space on your hard drive. However this still requires you to download the blockchain (but not store it) and sync in order to use Bitcoin Core.

Check that Bitcoin Core is fully synced. Stop Armory and run just Bitcoin Core. If you don't see a green progress bar, hover your mouse over the checkmark or spinning circle in the bottom right hand corner and see if that matches the block height reported by block explorers like blockchain.info. It should be at least 480,891.