5 - ranochigo
Thanks

Download Electrum wallet from the official website, validate its authenticity. After which, install it and you can restore your wallet when prompted during the initialization process. It's not hard and you could've just googled it...

Full nodes helps to validate and relay information. In a sense, they do help to secure the network by minimizing the points of failure and adds to its redundancy. It's more beneficial for the individuals to run a full node because they'll be able to validate the information and be fully trustless. SPV clients like Electrum do not validate the entire block and trusts that the peers are feeding it honest info and that the work done by the honest portion of the network is more than those who are not.

It definitely is. For most people, running a full node is definitely not the most important thing. If you want to use it as a wallet, you can still run it pruned and discard the unnecessary files; you'll still help the network by validating the blocks and the trustless aspect is not compromised. This still means that the synchronization process will take equal amount of time as well as bandwidth.

Tl;Dr: Running a node has more tangible benefits for the individuals than for the overall network.

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.