No. Most people have way more than just "a few" Bitcoin addresses, they are only considered "generated" when they have funds being sent to them which is not a valid metric by any means; most people use change addresses which are also newly generated. It's nothing indicative of the adoption rate.

Not really, there hasn't been any serious vulnerabilities affecting Bitcoin nor any hard forks recently.

I would still urge you to upgrade though, there really isn't many good reasons for using such an old version especially given the various performance enhancement and bug fix that happened through the 2 years after that version was released.

Wallet.dat can be modified to display anything you want. The wallet.dat doesn't contain Satoshi's address and it was merely modified to show the address and its transactions. Any wallet.dat you see floating around is likely one that's modified and it's done for scammers to sell them and trick them into thinking the wallet.dat is authentic.

No. Full nodes shouldn't be compensated. Unlike POW for the miners, there isn't any trustless way to validate if a full node is contributing (nor any suitable metric to gauge) to the network. Whilst it does help to decentralise the network more, it doesn't offer much more tangible benefits which warrants a compensation.

I don't foresee having a declining node count to be THAT big of a problem given that many volunteer's like me are running full nodes at home still with our old HDD and a Raspberry Pi. The overheads are a lot lower than what others perceive.

Hmm I haven't resync on Windows for quite a bit but IIRC, removing the data directory should result in the client asking you to specify one during startup. Try renaming the %appdata%/Bitcoin to something else and start Bitcoin Core. If it prompts you to specify an alternative data directory, go ahead and do so. If it doesn't then just rename the folder back and it'll work the same.

I've specified it in my post actually. Go to Settings>Options at the top and you should see the options to change the config. You can access bitcoin.conf through there too and know which configs are active.
Always backup your wallet.dat first. After moving your data directory, you have to modify the config file to specify the new path of the data directory to follow. Or else, the client will simply make a new data directory in the original place and start synchronizing again.

No, you'll likely corrupt the data directory and you'll have to synchronize again.
If you're not very familiar with the syntax for Bitcoin.conf, you can try activating pruning by going to Settings>Option and checking the checkbox to prune the storage.
Yes but I highly recommend against this.
You can point the data directory at an external harddrive by moving and pointing the data directory at the external drive. Use the config file for that.

Did your friend send you the coins using Coinbase's internal offchain transaction or on-chain transaction? Ask him if he could provide the TXID for the specific transaction.

It's highly likely a problem with coinbase and you should try contacting their support first.

Electrum's Help Doc is pretty comprehensive and useful for beginners. Try looking there first and feel free to ask if you need help. https://electrum.readthedocs.io/en/latest/cmdline.html

Monitoring deposits based on the TXID is not the most efficient way about doing it. It would just cause unnecessary delay for the user and it would be a headache for them if the user decides to RBF due to low fees and whatnot.
It would be annoying for the company to handle hundreds of support messages regarding uncredited deposits due to the malleability issue.

There's a strange message at the top of Bitcointalk:


Is it a local issue? Or is it a problem with the rendering of the page by Chrome? Tried clearing cache and cookies but it's still the same.

Those nodes are likely a similar implementation to the one's bitnodes[1] is running currently. I haven't run it yet though I might be doing so in the future (when I have time). It's pretty weird how it connects with different user agent though, does masquerading as different UA provide different results?

I think the full banscore calculation system is found here[2]. Most of the criteria seems to be related to sending invalid messages which increases the banscore.

[1] https://github.com/ayeowch/bitnodes
[2] https://github.com/bitcoin/bitcoin/blob/8235dca6210dab8e9657c0b592ab928554155082/src/net_processing.cpp#L1114

OP_return doesn't need the nodes to keep it's UTXO and it's better in terms of reducing Bitcoin bloat.

OP_return has a larger data field, than let's say an address due to the need for a valid checksum at the end. If anything, the burn addresses introduce much more bloat (both in terms of UTXO and the limited character space) to Bitcoin Blockchain. It's the only way to provably burn coins with 100% certainty.

OP_Return scripts function differently from your normal output scripts. It doesn't act like an address and any funds sent to OP_Return gets burned as the UTXO is not added into the list. The node shouldn't check for the validity of any scripts that is denoted by op_return.

No one has actually mistakenly sent funds to an OP_Return address without knowing what they're doing. On the client side, the wallet would've prevented it and the user would have to explicitly specify that they want to embed a message through the use of OP_Return.

You can reduce such occurance by reducing the ETA. I use mempool mainly and go for 1MB when I need it urgently.
Nope. Each block theoractically can accommodate 1MB of transaction. It simply means whether your transaction would be confirmed within the next X mb worth of blocks. It isn't accurate as with any fee prediction but it is a different way to present things.

I'll say it's as good as it can get. Fee estimation utilises the mempool's recent fee statistics to guesstimate the suitable fee for you. Unfortunately, this entails having the downside of the software to not be able to predict future fees.

When I pay lower fees, I find it better to assume the worst case scenario since it's more likely for the mempool to spike suddenly (like what just happened) within the timeframe. There's no model to predict the fee market and that's the best estimate that can be given. If the algorithm were to be more forgiving, people would complain that they're paying more than required for most of their transactions.

It's not whether you can; it's that you shouldn't.

Address reuse isn't recommended for privacy reasons in the first place and I don't think any hardware wallets were designed specifically to encourage that.

You shouldn't import addresses that were generated outside of the hardware wallet itself. The address could very well have been compromised beforehand and it would negate all the benefits of a hardware wallet.

Obvious question but have you tried changing your circuit? I've noticed that my connection can be quite slow at times. Changing the circuit a few times has always solved it.

@LoyceV, wrong topic perhaps?

Firstly, it would require a hard fork. You know that doesn't resonate well with some people and it would inevitable lead to parties supporting/opposing it.

Anyways, I would expect botnets to have tailored malwares if that would ever occur. It's also quite a problem to determine if a node is truly helping the network or just collecting the incentives. It's not possible/resource intensive to make sure everyone is actually running a node (ie. not just serving the block when asked or just broadcasting their useragent without having any blocks in reality, etc). I don't expect to see this happening at all; Bitcoin works fine as it is now and centralisation is not the greatest problem that we have in terms of having people run validating node (pruned or not).