Seems like you don't have the required libraries for Ledger to communicate.

You need to run the following commands[1]:
- apt-get install libusb-1.0-0-dev
- apt-get install libudev-dev
- ln -s /lib/x86_64-linux-gnu/libudev.so.1 /lib/x86_64-linux-gnu/libudev.so
- pip install btchip-python

[1] https://support.ledgerwallet.com/hc/en-us/articles/115005161925-How-to-use-Electrum-with-your-Nano-S

Transactions CANNOT be reverted under any circumstances. If they are broadcasted, they would eventually be confirmed or invalid (if the inputs gets used in another transaction). Obviously, it won't disappear or anything; else no one would be using Bitcoin.

When the client sees another chain with a longer proof of work, they take the transactions in the orphaned chain and put them back into the mempool. For miners, they will include the transactions in their block. They are treated like a normal transaction.

The solution is incredibly easy, anyone could do it. Just code a website which allows people to transfer Bitcoins within their internal system. It doesn't matter if the person is registered or not. The main thing about the system is that the person's identity must be validated. Obviously, this could potentially compromise the person's privacy.

It can't be easily implemented into Bitcoin's protocol. Changetip works similarly to the method that I've described though its not really viable.

Nope. If the inputs to that transaction is still unspent, you can still import it into another wallet on another computer to restore it. I wouldn't recommend you to continue trying on this computer especially since this Electrum version has vulnerabilities.

IIRC, Electrum doesn't work on XP anymore. Its possible that support for Vista has been dropped along with it.

Whats your Electrum version? If its one of the earlier version, don't bother trying to use it. Close it immediately and get another computer to install the latest version. Any Electrum version below 3.0.5 has the potential to leak your seeds and ptivate keys on RPC.

If its above 3.0.5, press the bubble on the lower right. Try connecting to another. Uncheck the select a server automatically and right click on another server to connect.

The validating of transactions uses relatively little resources. If the difficulty is the same, the theoractical resources used for generating a block is the same, even if one block has a thousand transaction and the other has one. The difficulty sets a requirement for the miner to meet. The higher the difficulty, the longer it would take, if the miner has no change in hashrate and ceteris paribus.

Mining is basically just the miner hashing the block header which contains the merkle root. The merkle root is the hash of the transactions in the block. Your ASIC does not validate transactions. In fact, if you run a Bitcoin node, you are also validating transactions the same way as a miner. I doubt you can accurately measure the energy consumption of miners in Germany at all. There is no indication of the location of where the mining farms or miners is located.

By disabling SSID broadcasting, your router will not openly say that the specific WiFi network exist. The only thing this would discourage is script kiddy trying to bruteforce your password protected WiFi. However, it would still be possible for someone else to detect your WiFi with monitoring.

It wouldn't help in anonymity, especially if you have a relatively strong password. Even if it gets cracked, the only thing they can possibly see if the peers that you're connected to.

The most common issue I've seen is that the port forwarding is incorrect. Go to command prompt and type ipconfig and take note of your IPV4 address in the column with the connection you're using. That is your local IP address. Check if your port forwarding asks for any IP address, if it does, use that IP address and not your public IP address.

Go to bitnodes.earn.com and press check node at the bottom. If it shows your client version then you're good to go.

It depends on what you define as a "world" currency. In some aspects, you can consider it as a universal currency since you can accept Bitcoins anywhere at anytime as long as you have an internet connection. It could possibly be a common currency among people depending on the adoption. However, when it comes to being a legal tender across all the countries, it would just downright be impossible. Most governments are against Bitcoins mostly due to their perceived threats to national security (ie. political interest, terrorism funding).

My argument hinges on the fact that with server side validation, most people wouldn't bother to check the transaction on any other sources. I wasn't talking about how Coinbase or Ledger works. The attack would be viable for people receiving transactions (and thus the client forging and providing inaccurate information) and that seems to be the main thing that OP is concerned about.

Of course, Ledger is better in general. But when you're trying to receive transactions, the risk is there.
That's why I'm implying that they are somewhat similar in terms of this. If Ledger shows you the wrong information, I would say that they wouldn't let you withdraw anything.


Yes. Its mostly interpreted by the community as the same thing, could do better on my phrasing though.

---

---

I fully agree that Ledger/hardware wallets are better than Coinbase/Online wallets by far, as a whole. I am only focusing on the discussion on the safety of only when receiving a transactions. Assuming Ledger's web app and Coinbase, both are equally susceptible to server-side validation attack for which the host could modify information that is being displayed inside of the client. While I do agree that having a second source of information is useful, most people blindly trusts what the client says as correct.

Its inherently difficult to prove the sole ownership of your Bitcoins. A,B,C,E,F,G requires trust on either or both of the party and D just won't be sufficient.

The most accurate way is to sign a message with the address and the message must contain relevant information. However, this would just prove that you could have control of the address and the BTC associated with it. It is of course, possible for them to get someone else to sign a message using their address.

If you're strictly asking about the security of receiving transactions, then possibly more on the Ledger. To be fair, Coinbase and Ledger utilise server side validation which requires them to be trustworthy. This means that they can modify the things that they can show you since they have full control over it. In terms of privacy, Coinbase is pretty bad on that. Coinbase has suspended accounts over deposits coming in from questionable sources.

Its common for wallets to display a new address for every transaction. Address reuse has never been encouraged. Wallets do not delete addresses without you doing it.

First of all, check the address that you're trying to sweep on a block explorer. Does the amount of Bitcoins as indicated in the block explorer correspond to the amount of Bitcoins you can spend?

It might just be the Mycelium servers are being blocked. Are you in a country that heavily censors network traffic?

By modifying the Bitcoin fork. The change will ONLY affect whoever is using that client.
It is possible for any client, literally. None of the clients that I know of currently implement such features. You can always modify the code yourself to do so.  If you want to prove that someone owns a Bitcoin address, you can ask them to sign a message with a message that is agreed upon prior to signing. That could merely proof that they have control of the coin in the address at that point of time.

Btctalk name: ranochigo
Rank: Legendary
Current post count: 5610
BTC address: 1Yzig3e8vx79XyYMjJShk4yBPp1YcvPbQ

Honestly, we wouldn't know. But at least a few blocks would probably have been mined with GPUs when the network was still CPU dominant.
At least a few hundred times. I can't say for sure but I'm taking an estimate using hardware at that time.
No. At the start, this would be the case. Once everyone started to mine using GPU, the difficulty increases proportionally and the earning decreases too. GPU would definitely be able to have a higher probability of getting a block within 10 minutes. If you're talking about when Bitcoin gained some traction, I think the probabilty of finding blocks using either GPU or CPU is negligible.

If you didn't design the plugin, you probably can't test it yourself. Unless your plugin has an option to accept testnet coins, you have to code it to do so. I suspect it won't be easy with pre-made plugins.

How different is it from the current implementation? Your previous transaction still needs a signature and a script to let the people know where the coins are being transferred to. Transactions are typically sent to various addresses and it is highly unlikely that the sum of Bitcoins transferred will be spent altogether.
If you were to remove inputs and outputs completely, nodes still has to synchronize all the transactions. I can imagine it being a whole lot more resource intensive. If the client does not extract the UTXO, then they would have to search through all the transactions for the Bitcoins that is being spent in the transaction. In addition, most of the transactions would have to be searched through since they can't be "marked" as spent completely.

Of course not. It would be a terrible design flaw if that is possible.

You need to unlock your wallet first by putting in the command walletpassphrase *PASSPHRASE* *TIMEUNLOCKED*. Some commands doesn't need it to be unlocked, some do.
No one said you shouldn't have it on an online computer. Everyone did say you shouldn't use it on an infected computer.
If you'd like, run Bitcoin Core as a server for your whatever SPV client to connect to. Your trust lies with your Bitcoin Core instance. A bit more annoying to do but if you want it that way, there's that.

Pruning solves the issue with his limited storage on his macbook. I wasn't addressing his external harddrive speed since that's harder to solve.
Rescan doesn't make the client validate the blockchain. I believe that deleting the chainstate alone won't force the client to check all the blocks again. If you want to be on the safe side, delete the block index too. Either way, it would take somewhat the same amount of time to validate again as your initial synchronization.