nLockTime isn't really intended to be used by the average user as it isn't all that practical to use in the first place. The feature is still flawed in a sense that the mempool doesn't keep transactions that has an nLocktime. If your inputs are spent anytime before your nLocktime expires, the transaction that you've created would be completely useless. It isn't all that useful unless you want to spend funds in the future and you want to delete your private keys.

You can easily craft a raw transaction in your client and modify the last few bytes to set the nlocktime before sending. Bitcoin Core, by default has an nLocktime for every transaction, where the nLocktime doesn't actually do anything to prevent the transaction from confirming.

Loan repaid: 8c00220ef0cccc4fb3c2e120101300983fc26eb0ba589086c5a51a89161970a7.

When the miner attempts to roll back the blockchain, the price would likely crash and the amount of Bitcoins and the ASICs that they have would instantly have zero value. It isn't easy for legal power to have such an effect on miners; I don't think laws could force miners to do things that they don't want to.

Craig isn't very smart at all and I doubt he considered the possibility of all the courts reaching the same decision unanimously in the first place.

You're correct. Bitcoin Core still doesn't allow the client to import the private key and spend funds based on the UTXO set. I believe they don't intend for Bitcoin Core to be used if the client doesn't have a history of the transaction relating to the addresses. It would definitely be useful but I doubt this feature is at the top of their priorities right now.

The term is used mostly with ambiguity. Most commonly, as long as a client can independently verify the chain, they are termed as full node. SPV client requests the block headers of the blockchain from the full node. The block header itself contains the merkle root for the SPV to compute and validate transactions.

Pruned nodes can't provide the full history for the SPV client and wouldn't be useful if the client inquires for block headers beyond its current block file buffers. Thus, they implemented a flag (BIP157 BIP 159) in the node's advertisement to tell the peers that they would not be very useful as they're pruned. The SPV node would then have to connect to a node with a full blockchain if they require older block headers.

Bitcoin or any other cryptocurrencies functions primarily using the communication between computers. This means that as long as there is a way for communication to be established, Bitcoin can function.

Blockstream may allow Bitcoin to function by the use of satellite but most people wouldn't be able to access it. If people can't be connected to the network to transact, then it is pretty useless for it to exist in the first place. Saying that Bitcoin is fully functional without internet at its current state is quite a stretch.

51% attack is not about the block time. As long as you have 51% of the total hashing power, the attack can be executed.

If you observe, exchanges mostly requires those coins with a faster block interval to have a higher confirmation than those who don't. Reason being, forks are more prone to occurring with faster block times than a coin with a slower one.

It's a rather controversial topic to discuss about. The thing about block interval is that the security of the network is taken into consideration. With a faster block, there is a risk that the propagation of the block within the network is too slow and that miners ends up mining a lot of orphans and causing more forks. Since Satoshi never publicly stated his rationale for the 10 minute block interval, it is widely assumed to be arbitary. Arguably, with better internet connection right now, the block interval can be lowered but there are still quite a few concerns.

You really wouldn't want to use a hierarchical deterministic wallet as your cold wallet. Paper wallets are designed for a one-use case for which a paper wallet should not be used again after a transaction is made from it (which will empty out its entire wallet). If you're looking for a secure wallet, you can try using a Ledger. It's much easier to use and its pretty much as secure as a paper wallet.

Hmm what version are you using?

Segwit Nested in P2SH addresses are not compatible with uncompressed addresses. If a segwit-P2SH address is generated from an uncompressed keypair, it would be rejected by the nodes since it is nonstandard right now.

Electrumx is a server that normal electrum clients connect to. The server acts as a backbone for the Electrum clients and allows the user to retrieve specific information about the network, get the transactions for their wallet etc.

People connecting to your server doesn't necessary meam that they trust you. Most actually just randomly choose one that works. If they care about their privacy and stuff, they would run their own. Security wise, it offers the same security as SPV clients unless they run their own server. Electrum still retrieves block headers from several nodes.

The error is regarding the state that your client is in. With the pruning enabled, the client actively deletes information that are irrelevant to your old wallet and the older blockchain files. With that, if you import an entirely new wallet, there is no way for the wallet to get all the transactions that are in your wallet currently.

You'll have to synchronize your wallet again, without pruning if you want to swap out your wallet files regularly.

IIRC, there was a gaming program that secretly did this without their user knowledge and everything came clean after some users tried to investigate further. Some of this virus err on the side of caution and usually only mine when they do not detect any keystroke after sometime and if the user isn't observant, they would just assume that the program naturally uses a significant part of their GPU and it isn't something to worry about.

I'm not sure why no one has mentioned it but:

It's not easy to actually detect mining virus. Unlike the wallet stealing malware which specifically actively looks out for any suspicious programs that seeks for wallet files, a mining virus is much harder to detect in the sense that they can attempt to conceal their activities within a legitimate program. For example, they can spawn a process that uses a high CPU resource and it still wouldn't be that suspicious since many programs has a high CPU utilisation.

It would take a reverse engineering of the program to determine if its a false positive or not.

Could you send to bc1qupxdkw5p5vx093sphecla9zgydaq3r265y6pdr instead? Its pretty hard to sign message with a phone.

Request For a No Collateral Loan from DarkStar
Required BTC Amount: 0.05BTC
Estimated Loan Duration: 2 weeks
BTC Address: bc1q5t0yg4cwnfs3pgg60jk5rra0md8fdx5p585rz2
Signed Message: I don't have my wallet rn. I can add a signed message later if you want.

You could always run a node without enabling mining. To enable mining, all that they have to do was to put setgenerate to true and it would start mining.

There is a chance. ECDSA hash signatures can be reverse engineered to produce the private key if the variables used in the signature generation is not random enough. In addition, the private keys can also be derived from the public key by a sufficiently powerful quantum computer and the luxury of the time.

With the current state of technology (and the latest Bitcoin Core) , its nothing to be worried about and there isn't more risk from this than to send a transaction.
It isn't a security issue but more of the fact that there isn't any standards for signing messages with bech32 addresses yet.

Initialblockdownload is adopted by the client to download a large number of blocks at a faster rate. Currently, Bitcoin Core downloads the block headers first to allow it to request blocks simultaneously from all the peers that it is connected to.

To answer your question, the client will not download blocks from its peers unless the work in the chain that the peers have is higher than the one defined in the chain which is currently located here [1] as of now. It helps to prevent sybil attacks (to a certain extent) which tricks your client into downloading blockchains that has too little work (ie. Chains that are shorter difficulty wise).

[1] https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L87

Your debug.log should be in the same folder as your blockchain data. Open the debug.log with notepad and paste the last few lines of data here. Could you include more detail like what OS you're using?