In terms of convenience, Electrum wins Core with no questions. Electrum allows the user to export the keys and to store a physical copy of the seeds thus giving them the reliability of physical backups. It's not possible with wallet.dat.

In terms of security, Core would win. Core allows the user to encrypt their wallet and thus giving them a better security. While Core allows the user to export its HD key, the wallet still has to be backed-up relatively frequently whenever the password is changed. It does seem more of a hassle to manage the wallet.dat.

I would trust Electrum more. I am confident that I can manage my own seeds well without the use of passwords and it can be stored relatively easily without considering the degradation of storage media for the wallet.dat files.

Try clicking the little coloured bubble at the bottom right and select another server by left clicking it and selecting use as server. The server you're using might not be working.
Not really. If you know which are the addresses that contains the Bitcoins, you can just go to coinb.in/#newTransaction and create a new transactions from your addresses to another address. You will be given an unsigned transaction and you can simply go to Tools>Load transaction>From text and paste your raw unsigned transaction. Validate the information shown by Electrum and broadcast it on coinb.in/#broadcast. You can send it to your hardware wallet or whatever.
Its not fully synchronized yet but you can send funds.
Ledger is a decent hardware wallet if you are willing to pay the price. Otherwise, I trust my cheap little raspberry pi with Electrum on it.

Disconnecting your laptop doesn't help with anything at all. Malwares can still send information when it goes online. Once a computer has access to the internet, its security just decreases as opposed to another computer which has never been connected to the internet.

Just one is enough, node connection are bi-directional and both nodes sends and receive information.
It's true with most/all coins. Orphan chains happens pretty often and it doesn't make sense for the coinbase maturity to be zero or small; the coins that would've otherwise been spent several times could turn out to be invalid. It would result in a relatively easy double spend (accidential or not). Bitcoin's coinbase maturity is 100 blocks but most mining pools absorbs the risks and rewards their miners at 6 confirmations as orphans that are greater than that rarely happens, if any at all.
There should be a keypool to your wallet. The getnewaddress doesn't generate addresses on the fly but rather it just reveals an address from the keypool each time you use the commands.
What client are you using? If you're using the original Bitcoin client (or its fork) to mine, you can manually include transactions into the blocks. Check if the mempool of the mining node lists that specific transaction you're trying to include.

Ah I see. Yeah, you can't do it unless you want to validate every single stuff again.
In an MITM attack, the attacker would likely be able to control what you can see and what you can't. They can lead you on a separate network and they can send you blocks and transactions that are different from the mainchain. You won't be able to see any other blocks if the attacker can isolate you away from the others.

Given that the client does not always go back to use its blockchain after the initial synchronization and building of the chainstate, it is possible for only the chainstate to be modified and the client would not notice this at all.
At start up, the client does not validate every single block. The client stores the relevant information in the chainstate for which it can be fabricated. The attacker can modify the chainstate without affecting future blocks.

Depends on how you see it. The attacker can easily fabricate a blockchain that has thousands of low difficulty block and that they could trick you into accepting transactions which are otherwise invalid with a simple MITM attack with sybil nodes. Transactions can be valid but they can be valid only on specific forks on the chain. You aren't validating the blockchain that you've received so the UTXO database could easily be fabricated still.
No. It is simply impossible to verify its authenticity based on hashes of the file since the files are likely to have different hashes from various sources, though they may all not be malicious. The only way for you to verify is to verify each and every block by yourself.

Is there any transactions in the memory pool and/or did the previous blocks had any transactions in them (other than the coinbase transaction)? If there are no transactions that has ever been made, it is impossible for the client to recommend any fees to be used. The whole point of floating fee is for it to be based on the miner's preference on the previous blocks mined and the currently backlog of transaction. You can't use floating fee if that is the case.

No need.
https://bitcointalk.org/index.php?action=credit;promote
~0.002BTC +
Yes.

Thanks! My address is: 33sVQc3h4mJGdWsjSyeqMXsU59jjtCfZrG.

The date of repayment will be on or before 28/12/2018.

I'm looking for a 0.4BTC loan for a period of 3 weeks. The interest rate will be 8% (ie. 0.032BTC). LMK if anyone is interested in funding the loan and I'll send the address privately.

Signed message:
This message is to confirm that I, ranochigo has requested for a 0.4BTC loan for a period of 3 weeks on 6/12/2018.

Address: 1Yzig3e8vx79XyYMjJShk4yBPp1YcvPbQ

Signature: Hwcqe1TlXn+cZaAe78UysPbk0oMmI1R+/aAeREIWy3oHdDp+Av4SEDfOtxWsHdSHuseHImMne76pRycEsdYwpnc=

No. The block headers contains the merkel root which contains the transaction hashes which are assembled. They do not contain specific transaction information persay.
Protocol rules: https://en.bitcoin.it/wiki/Protocol_rules.

Pools should be running a node, probably not a reference implementation though. Pools do not have to run a node explicitly, the only thing that they need is the transaction information, previous block hash and all that. These can be easily obtained from various sources.

At least one. The block must have a coinbase transaction. The output of the transaction doesn't matter but the coinbase transaction must exist.
They hash the block headers which contains a wide array of data and the result is the block hash.
A block is valid if the nodes in the network think that it is valid. If the miner follows the protocol rules, then those who also follow the protocol rules should agree that the block is valid. If not, then they would be on a different fork since they don't accept that block while those who do builds on it.

The requirement for the block to be valid is quite broad, the crux of it is just that it follows the protocol rules which all of the reference nodes follow.
Technically, it used to be. However, when pools came out, people found it more worthwhile to be mining together instead of separately. Most of the miners now don't run a node anymore due to the numerous benefits of pools.

There's two ways, UNIX time stamp or Block height.

With the UNIX code, the nodes will check the transactions in the block against the timestamp of the block. If the timestamp of the transaction is lower than the timestamp of the block, the whole block becomes invalid. Blocks can be up to 2 hours inaccurate.

For the block height, the transactions that is in the block must at least meet the block height of the block that it is in. If not, it is invalid.

Bump!

You can't find any pattern in Bitcoin (specifically address generation). The only reason why AI can figure out images is because they have a distinct pattern; human faces has specific features and cars has a standard look to it. Unfortunately, Bitcoin addresses is completely random so you can't use patterns to decipher anything.

Are you blind?

You don't have to have a synchronized time with others to use Bitcoin. Accuracy of the time is not a part of Bitcoin, it is usually wildly inaccurate. The network uses a network-adjusted time system. This means that the whole network can be up to 2 hours inaccurate (in unix time). If you are looking to adjust your clock, Bitcoin is not a good choice.

I'm looking for someone with an US address, no PO boxes or freight forwarders, to help me reship some stuff.

I'll provide you with the items (shoes) and you would have to send them to me overseas. I need someone who is relatively trustable.

It's possible. The firmwares that the ASICs are on is definitely exploitable. The main reason is the motivation. I doubt anyone would just ruin the coin just like that. Most ASIC farms are actually fairly small and it isn't that big to be able to ruin a mid-sized coin.

It has. Bugs in the client could cause the client to accept and relay transactions that are otherwise invalid. If not, 51% attack can't do that much.

Its not. The 1st was due to the bug in the client. The second was due to the miners mining incompatible block (no 51% attacks whatsoever) that resulted in the splitting of the chain. The older clients were following one and the newer clients were following the other. While 51% can result in forks, the new fork must still follow the consensus rules, no matter how much hashrate they own. A block can only have that many Bitcoins and block rewards and signatures must be valid, etc. If not, the blocks wouldn't even be accepted and the 51% attack would be as if it has never happened.

It has never happened. The only time anything like this happened was with the bug[1] that resulted in block rewards that was over the limit. It was forked off and everyone switched. And you're right, you can't make transactions that are invalid into a valid one.
[1] https://nvd.nist.gov/vuln/detail/CVE-2010-5139

Not very useful. The inability of the client to independently validate every aspect of the purpose of trustless in Bitcoin and it is no different from a SPV client.
Yes. If you are not 100% sure of the information that you're fed, the only thing you can do is to trust the person who provided you the information, which is risky.
51% attacks can't print money out of thin air. They still need UTXO to spend and follow the network rules regarding the block rewards. You simply have to overtake another chain and that wouldn't be noticable at all, until the attack is over. 51% attacks uses long block reorgs to evade detection.
Because you can't be sure that whoever you are connected to is not malicious.
It will definitely not thrive. It is simply not possible for the network to only run on pruned nodes. Without full nodes that keeps all the data, it would be impossible for any node to retrieve the exact transaction data about any transaction back in time. If this continues on, then the problem would only get worse. It would be inherently difficult for anyone to prove that they have made a transaction 2 years ago, should a contract last that long.

---

Unless, as Bob said, it is possible if there is enough redundancy with the historical nodes but it is simply impossible for those nodes to have sufficient redundancy because no one wants to run them and if they do, there will be a high cost to it.