It might be a problem with the server that you're connecting to. Is the bubble at the bottom right green?

You can try changing the server by clicking the bubble, going to the server tab, unchecking the select server automatically option and right click on another server to choose it as the server for your Electrum client.

When you close the client, the client stops synchronizing with the network. Until you open the client again, the network is still functioning and new blocks are still being generated. As such, the client wouldn't know if there were any transactions corresponding to your addresses until it can synchronize and retrieve the latest blocks. The process may take sometime, depending on when you last opened your client.

The whole point of Bitcoin is for it to be trustless. Someone still has to manage the files and everyone's definition of who is trustable is different. Who should be the one assigning the trusted people? It's fairly easy for that person to push an agenda through and manipulate the entire system. If I needed to trust someone, I might as well go for Paypal.
How would you get the chainstate without indexing the blockchain? Trusting another person to obtain the chainstate is considered fairly unsafe as the information inside can be manipulated. You need the entire blockchain to ensure the validity of the chain. If not, you might as well just use an SPV client.

SPV client would be a better alternative. If you don't validate the blocks fully, you are essentially an SPV client and you don't have to download any blocks at all.

Speaking from my experience as a trader from Localbitcoins, the main reason is probably because it is intrinsically difficult for the support to solve any dispute. The problem with gift card is that the seller could give the trader an used gift card and try to pass it off as legitimate. Due to the structure of the various sites, it is not possible for the gift card to be tracked and thus it is difficult to see who is telling the truth. It's more likely due to the hassle of managing such issues rather than its legitimacy.  I've bought tons of gift card from there for personal use and I've never experienced any problems after redeeming them.

I doubt satoshi has ever envisioned for Bitcoin to be this popular. It is very difficult for Bitcoin to be accepted widely by governments due to the inherent conflicting interest (ie. tracking vs anonymity). While satoshi did say that block size increase could be an option, it doesn't seem logical in the long run for people to use SPV clients while few run full nodes. Satoshi probably didn't thought of scalability thoroughly.

Depends on what you mean, the signature encompasses the whole transaction which includes the receiving address. Changing any of the variable (even changing the fees by 1 satoshi) requires all the cosigners to sign again.
Yes. P2SH allows the user to set a myriad of conditions for the inputs to be spent (ie. nlocktime, n-of-m multisig). Failure to meet the conditions means that the outputs can't be spent. Generally, the condition is mostly just the majority signature is needed (ie 3 of 4 or 4 of 6) or else, it can also be 1 of 4...
Yes. For a transaction to be valid, each of the required co-signer needs to sign the transaction. Signature can never be reused or there is really no point for P2SH to exist.

If you want, you can just copy out your whole Bitcoin data directory, then delete your wallet.dat from your copied data directory. Use a torrent program to share the file. You do need quite a number of seeders since the data directory (blockchain) is relatively big and a large number of seeders is required to spread the load evenly. It might be quite hard to get enough people to seed the file especially since it is not to their best interest to keep two blockchains on the same computer.

If you want to use CPFP, run without walletbroadcast=0. If you want to just remove it completely, use -zapwallettxes.

Either option will work; CPFP will cost slightly more and it would take less time while retaining the same transaction, zapwallettxes will take some time (for the transaction to be dropped from mempool) and it wouldn't cost more to send again.

Did you launch the wallet with -walletbroadcast=0? If yes, then you should launch it normally without any arguments as the wallet won't broadcast any transactions to the network and your transactions won't be seen by others.

You can follow BitMaxz advice and launch it with -zapwallettxes which will remove all the unconfirmed transaction. You will have to wait for the transaction to be dropped by the nodes around the network and you can send a new transaction.

Yes, you can. If you've fully synchronized the blockchain, the chainstate would've been assembled already. The pre-verified data directory can be copied from disk to disk and you don't have to synchronize again.

The result you will get is just a (double) hash of the hash of another block header. This won't yield you anything at all.

You need to hash an actual block header (complete with all of the components of the blocks you are mining) for the block to be valid. The network will obtain the block header and hash it. If it doesn't meet the target, then it would be rejected.

Bitcoin uses SHA256D. The actual hash is just SHA256(SHA256 (Block Header)). The block header consists of the version, nounce, timestamp, merkle root, hash of previous block and target.

The miner assembles a set of transaction and hashes them. This creates a merkle root which is ultimately included in the block header of the block. With the block header, the hash of the block is obtained by hashing the block header. Only if the hash meets the target of the network, then it would be considered valid.

This doesn't emcompass the whole process but it does roughly cover the idea about how the transactions is used in the block hashing.

The miner has the rights to the number of transactions and which transaction he wishes to include. The least number of transaction is 1 and the maximum is up till the block weight is reached.

Yes. But for various wallets with numerous addresses with a large number of UTXO, it wouldn't be ideal since you have to sift through all the various UTXOs and select only the ones that you would like to spend and this could take quite sometime. OP wants a method for which the UTXO could be marked within the wallet and it would never be spent.

That's the only way it could work which is very inefficient and is arguably a form of censorship. Stopping the spam transactions is impossible and it wouldn't be ideal either way.

The longest valid chain is followed by the client. If you somehow have a miner work on the orphan chain and manage to overtake the other chain (difficulty-wise), then the chain that was orphaned would become the longest chain and it would be accepted universally. You can't combine the two different chains.

If not, you can just use the commands in the client to reject the other chain. This would only apply for you and you would be on a different fork than the rest of the network.

The root of the problem doesn't lie with the signature campaigns themselves. Certain campaigns which I was in previously (and arguably now) promotes posts with good quality with sufficient moderation by the signature manager. They screen each individual participant before and during the campaign. Some campaigns just straight up don't care; the managers don't look at the posts before sending payments and accept every participant. If anything, signature campaigns should be restricted and I frankly don't mind that much if they are removed completely. Might sound hypocritical but I'm all for improving the forum even if it means that incentives to post will be removed.

Your solution won't work if the signature manager doesn't view each thread individually / see the flags on the thread. If you want any meaningful discussions, you should go to the serious discussions subsection. While its not as active as others, thats the only place where you won't see any sig spammers.

When you are mining with a pool, the pool provides the miners with the block header that the pool has determined. This includes the merkle root (hash of all transactions), its coinbase and an array of other information. The miner can then assemble this to form the block header that the miner has to hash. The block header is hashed twice and checked if it meets the difficulty requirement. The miner changes a variable in the block header every time it hashes it once (timestamp or nonce etc). Doing so results in the miner generating a different hash and this happens for million/trillion times a second without the server sending any more information.

The pool does not have to continuously provide the miner with a new block header as the block data is valid for sometime before it has to be changed. Information is only sent to the server if the miner has a hash that meets the minimum difficulty that is set by the user/pool.

RBF is essentially a double spend; your UTXO is double spent to initiate the RBF, whether if its to the same address or not. You can change your output to wherever you want or change the amount. What you're thinking is FSS-RBF which is not widely adopted but it was only adopted by F2Pool at one point before everyone switched to Opt-in RBF.
Electrum would sometimes spend from another UTXO or decrease change amount if the fee is not sufficient.

My Crypto-Games nickname: ranochigo
I like Crypto-Games because: I love the wide array of crypto being supported by the site and the ability to invest in the bankroll.

Ah I see. But wouldn't that make the changing of passwords useless? If the seeds aren't changed, the derivation of the addresses for the wallet.dat (with new password) the same as the one in the older HD wallet? This would make the old and the new wallet essentially the same and anyone who gains access to the old wallets can continue to steal funds from newer address.

From what I understood, the seed is refreshed with a password change and all of the addresses used previously are exported into the wallet.dat. I'm sure I may be missing something here.