Armory does not check block consensus rules. It will be able to work with alternate implementations that are based upon Core. AFAIK, Armory would work with BU, Classic, and XT even after they hard fork.

Of course it won't show up in the blockchain if it is unconfirmed. If you mean blockchain.info, then that means that the transaction fee paid by that transaction is too low, even for blockchain.info's node settings. As you can see from the images you posted, the transactions have a low fee warning from Electrum, so obviously the problem is that he paid too low of a transaction fee.

Read https://bitcointalk.org/index.php?topic=1802212.0 for what can be done about the transaction.

No, they were saying that 2²⁵⁶-1 is the biggest possible number which a hash could be, indicating that the hash is a 256-bit hash. The target is 2²⁵⁵.

It's just a weird way of saying that the hash is a 256-bit hash.

Since BU is based on Core, you can just copy your wallet.dat file from Core to a BU instance and be able to spend the Bitcoin from there.

It says on average, so given a big number of tries, half of them would be greater than 2²⁵⁵ and half would be less. I don't think saying "every other try" is the right wording for this.

No one really represents Core. The closest you could get to "who represents Core" I suppose would be everyone listed on https://bitcoincore.org/en/team/ but any decision about what goes into Core is made by the entire group, plus a number of contributors not listed on that page.

Nothing really. There is no obligation for Core to do anything and nothing that requires them to do anything. There is a moral obligation for them to do "what is right for Bitcoin", but that is subjective.

Core did not renege on any deal or agreement, nor was such an agreement made by the group "Bitcoin Core developers". What you are talking about is the Hong Kong Agreement. There, some people who contributed to Bitcoin Core (note that they are contributors and only represent themselves, not the Bitcoin Core project) estimated that Segwit would be ready in April 2016 and agreed to publish a proposal for a hard fork that they could recommend within 3 months of Segwit's release into a version of Bitcoin Core. Note that they estimated Segwit to be ready by April 2016 and the proposal to be published by July 2016. Those were estimates, not hard deadlines.

Unfortunately testing and implementation of Segwit took a lot longer than estimated and it ended up being released in November 2016. However, because April 2016 was not a deadline but rather an estimate, the agreement was not broken. 3 months after Segwit was released, Luke-Jr (one of the contributors who signed the agreement), published a hard fork proposal which he could recommend to Core. The Core contributors who signed the agreement did not renege on their end of the deal, but at this point, I think the some of the miners who signed it have. Note that because the Core contributors who signed the agreement did not and do not represent the entire Bitcoin Core project, Core itself is not bound by the agreement and had no obligation to release on the estimated schedule outlined by the agreement and no obligation to accept and implement the hard fork proposal.

Either Segwit will be dropped as "the community doesn't want it" or the dates will be changed.

You can import the private key, but importing is not recommended. If you have any Bitcoin on that address, you can sweep it into Electrum, meaning that Electrum will automatically transfer all of the Bitcoin associated with that address to an address in your Electrum wallet.

Bitcoin Core can be run in pruned mode where most of the blockchain is deleted. It results in ~5 GB of space taken up, but it still requires that the entire blockchain be downloaded and verified. It does deletion on the fly so you won't have more than 5 GB on disk at any given time.

That time is not how long it will take to sync the blockchain, but rather that the newest block Bitcoin Core has is dated 3 years and 14 weeks ago. A full sync, depending on your hardware, can take anywhere from a few hours to a few days.

The torrent and bootstrap.dat file are useless as it will take longer to sync with them than it will to allow Bitcoin Core to sync normally. The blockchain is currently ~110 GB.

You will have to export the private keys from your wallet and import them into another wallet.

If you don't want to wait for the entire blockchain to sync, you can use a lightweight wallet like Electrum instead. However you will be giving up some security and privacy for convenience.

Now, I don't know. You will need greater than 4 GB to run Bitcoin Core at default settings.

Bitcoin Core is because it is also a full node. Verifying and relaying every single transaction and block is quite resource intensive.

Are both of your computers crashing? Bitcoin Core will crash with the 4 GB RAM one as 4 GB is no longer enough memory to keep a node running. It will run into an OOM error and crash.

Core shouldn't be crashing on the 16 GB RAM one unless there is some other issue at hand.

Your machine ran out of memory.

Add the following to your bitcoin.conf file. The file can be found in %appdata%/Bitcoin. If the file does not exist, make it (it's just a text file, with out the .txt extension).

This should decrease the RAM usage so that it does not run out of memory.

They won't know, and that's a problem. Your only solution to guarantee that you are using the chain that you want to is to set up your own node and set your SPV wallet to only connect to that.

They don't. SPV wallets don't verify consensus rules and trusts that the node(s) it is connected to is following the rules that you want. During a hard fork event, you probably don't want to be sending or receiving any Bitcoin as it will be difficult to know what chain your wallet is even following.

If by custom BTC address you mean a vanity address which begins with a letters that you want, then no. No major wallet supports generating vanity addresses, however there are software that do generate vanity addresses which you can then import into a wallet.

Import the private key into any software wallet and then you will be able to spend the Bitcoin.

Please post the debug.log file.

What are the specs of the machine you are using?

What is the output of autogen.sh and configure commands? I'm guessing that you did not install the build dependencies like autoconf, autoreconf, and automake. Follow the build instructions that IngerDev linked to.

Then you probably shouldn't be creating a web wallet since you will be in control of people's money.

Generate a 256-bit ECDSA private key. Derive the ECDSA public key from that private key. Hash the public key with SHA256. Hash the SHA256 hash with RIPEMD160. The resulting hash is called the hash160. Prepend the hash160 with a 0x00 byte. Hash the that with SHA256, and hash that hash again with SHA256. Take the first four bytes of the resulting hash and stick it onto the end of the modified hash160. Encode the result with Base58. Note that Bitcoin uses a slightly different Base58 encoding than the normal Base58 conversion.

See https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses for more details and an example.

When you decode the Base58 address, hash everything but the last 4 bytes twice with SHA256. Then compare the first 4 bytes of the hash to the last 4 bytes of the Base58 decoded address. If they match, the address is valid.

Yes, but you probably want to have something that happens on your server instead of someone else's.

You need to know how ECDSA works. If you are planning on making a fully fledged web wallet, you will need to know how transaction signing works, how transactions are serialized, how to calculate proper transaction fees, how to handle double spends, how to handle transaction malleability, among a ton of other things. If you are asking these kinds of questions, I advise you to first study existing wallet software and how they work before you even consider making your own.

A miner figures out what inputs result in a hash that is less than the target. A full node will take those inputs and check that they actually hash to less than the target. Full nodes also check that the transactions included in the block are valid transactions, among other things. Note that miners actually are a subset of full nodes. Miners need to be running full nodes in order to know what transactions and blocks are valid in order to mine a valid block. The mining hardware itself does not run full node software but rather the computer they are connected to that provides the work for the ASICs to do.

The calculation that miners do is dependent on the block they are mining. Once a new block is found, they will have to change nearly all of the inputs in order to mine the next block. Otherwise they will be mining an alternative block to the one that has already been found, and that will likely result in them wasting hash power on a block that basically no one will accept.

No. Labels and accounts are an internal thing only. It has nothing to do with the actual Bitcoin network or the blockchain.