There's no extension for Electrum's wallet file.

For Windows:

The place where Electrum stores it's wallet file will depend on whether you're running it as a portable version or an executable/installer and if it's the former, the data folder should be stored in the same directory as your portable exe and the wallet files are inside the data folder.

If you want an easier way, go to File>Open and see the directory where the wallet files are stored. I would recommend for you to just back up the seed (if you want to save a backup) or to use File>Save Backup to backup the wallet file.

---

If you want to restore the wallet file, the initialization screen will give you a choice to create a new "Default_wallet" or choose your own wallet file.

I see, has there been a research done to evaluate the ecological impacts with the displacement of wildlife and the destruction of flora and fauna? Some solar farms uses the heat from the sun instead of silicon solar panels (photovolatic) as a more efficient way to generate electricity (the one with a bunch of mirrors) and they do cause quite some ecological impact, dams and wind turbines has resulted in some wildlife species being affected as well. I think that would be a primary concern together with the carbon emissions.

I would think mining is ideal for places which already runs on renewable energy and has completely shifted from fossil fuels. If a portion of the energy production is still from fossil fuels, then it would make sense if you still consider the opportunity cost incurred in terms of the carbon emissions from coals and natural gas. AFAIK, most countries hasn't reached that stage yet and the power loss from long distance power transmission isn't that bad.

Thanks, I didn't think you were talking about funding in terms of it's R&D.

That's an interesting perspective to consider as well. I wouldn't consider "green" energy as carbon neutral or completely environmentally friendly. Arguably, such infrastructure would benefit the economy primary. Green and renewable energy are ideal when they are able to replace the needs for traditional fossil fuel as a source of electrical generation. In fact, most solar farms, wind turbines, hydrodams, are not very environmentally friendly due to the fact that they will also contribute to the diminishing ecosystem or the production involves processes that are not carbon neutral.

In terms of economic impact, such projects will contribute significantly but if you're considering from the ecological perspective, I don't think the building or expansion of such infrastructure will actually benefit the environment at all and would perhaps bring about less than expected benefits for the economy, given that Bitcoin miners are seeking lower electrical rates and the construction and development of such facilities would bring about an increase in electrical prices and I doubt they will ROI in the short run.

The ECDSA private key can be anything from 1 to (approx.) 1.15*10^77, and that is converted to hexadecimal format when you're talking about the actual format generally used. Public key is generated with the private key, it's generator point and is from the secp256k1 curve. If you want to generate a legacy address, check the Wiki out[1]. For bech32 address, it's quite long and I'll link you to that[2].

Correct. If the RNG is flawed, it could result in the addresses that are generated to not be random enough and thus would be susceptible to being compromised. The key space is so big so it's hard for collisions to happen given enough entropy.

Do the addresses have transactions within or is it empty? If it's empty, then it's perfectly normal because block explorers will always display addresses that are empty as it's easy to validate the addresses' validity.




[1] https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
[2] https://bitcointalk.org/index.php?topic=4992632.0

51% attacks cannot steal other people's coins. The most they could do is to prevent their transactions from confirming. Other than that, double spending requires the attacker to have the ability to create an alternative transaction which would require the private keys to create the transaction.

It's not safe. The reason why Bitcoin isn't attacked is just simply a result of the cost-benefit involved. The cost is way too high for most to execute and for those that could, the profits gained from such attack wouldn't outweigh the cost. The blockchain didn't get stronger per se, it just makes such attacks less economical.

In most cases, the user spends the outputs from a few different addresses in the same transaction. This results in the blockexplorers having a fair degree of certainty that the addresses belongs to the same user. It's important to note that this isn't always the case as privacy implementations like CoinJoin will skew the results and people can always "trick" the blockexplorer using these heuristic as well, and it's thus a so-called spendlink.

For the above method, blockexplorers can only determine with a varying degree of certainty depending on how many times the addresses are reused or the outputs are spent in the same transaction.

The problem doesn't exist exclusively with seed wallets. Older Bitcoin Core implementation doesn't encourage address reuse as well and thus the outputs could be spread across different addresses.

Bitcoin transactions consists of inputs and outputs. Transactions are spent by referencing UTXOs (unspent transaction outputs) and for which, they are encumbered with the requirements to spent it, scripts that fulfill certain criteria, such as signatures or conditions, P2SH, P2PWKH, P2PKH etc.

Most block explorers represent the inputs as addresses for a simplified view. They are just representation of the UTXOs that are being referenced and "used" in a transaction. The outputs are the new UTXOs generated complete with the new requirements to spend them. You can spend UTXOs that have different signature requirements for which in the case of P2PKH/P2PWKH, you have to be able to produce the signatures which would in turn validate that you are able to spend those UTXOs.

There are no limits to the number of outputs that you can have as well. Most commonly, there would be 2 addresses being represented and that is because one of them is used as the change.

I think it's a pretty common myth but the construction of most renewable energy will actually incur some form of environmental degradation, CO2 or not. Solar panels don't just lay around and the manufacturing of the panels will essentially produce some pollution and it will take some time for the benefits of a solar panel to outweigh the environmental costs of it. It's obviously not without it's problem.

It would be wrong to assume that just because some mining operations uses renewable energy, all of the energy inputs are green energy. The issue on hand is that the electrical energy that could otherwise have been used for other purposes were used for Bitcoin mining. I wouldn't say it's completely invalid to attribute the CO2 production to Bitcoin mining because they use a ton of electricity and the production of which produces greenhouse gases.

No, CO2 production will never stop. But if Bitcoin mining doesn't use electricity, then the reliance on coal energy and/or natural gas would be lesser since that the energy requirements of the country would be lower.

To some extent, the above argument will hold water. But it's important to consider the transaction volume of Bitcoin on a daily basis.

You have to calculate the feerate in terms of sat/byte to be greater than the value paid in the initial transaction.

The replacement transaction also have to have a greater total fee than the initial transaction and paying at least 1sat/byte more than the previous transaction. It will not work if you only pay 0.5sat/byte more than the previous transaction as the increment must minimally be the node's mintxrelayfee.

It's coin control active.

Basically what this does is that it specifies the output that you're selecting to spend which isn't necessary at this point since you only have one. Just go to the Send tab and send your coins without the coin control. Feel free to just click reset, go to your Send tab, specify the address and press max to transfer all your funds.

Since it's a 2FA (I presume), you will also send a small amount of Bitcoins to TrustedCoin as a fee for their service. If you don't want this, you have to restore the wallet using the seed that you were given. Be aware that you'll have to prepay for subsequent transactions and it'll be a waste if you don't intend to use your 2FA wallet after this.

I would agree that cold storage is safe enough for normal use. I can't agree that cold storage are safer than HW wallets.

Certain hardware wallets are designed to specifically reduce the signature to make sidechannel attacks impractical, especially when normal cold storage are not specifically designed for those. Inclusion of secure chip allows the device to be bricked and the seeds to be irretrievable when a certain number of tries for the PIN has been registered. Rigorous audits done by researchers to try to breach the priv keys. Plausible deniability that some hardware wallet includes helps to minimize the losses from a $5 wrench attack, etc.

It wouldn't be fair to say that they aren't at least as secure as cold storage wallet, despite the additional steps taken to try to mitigate the possible attack vectors. Not a fan of ColdCard's PR but I like ColdCard as a HW wallet and it's arguably designed to mimic a cold storage wallet while adding extra security features.

---

I think any further discussions will lead to it being offtopic. I think this is better discussed as a separate topic by itself.

I might be mistaken but isn't the command only used for RPC interface? Like wouldn't it be the case if OP has bind=127.0.0.1 instead?

The images that OP sent appears to show that the client is listening to 0.0.0.0:8333. Even if it isn't the client should connect to other peers and it wouldn't matter in that case?

In case the advice doesn't help, I think it would be good for OP to paste the logs from debug.log and if there's any connection being dropped by the peers.

Good point. But again, not the first time a large scale database leak with very sensitive information has occured. Let's see how this pans out in the future.
I think that's a sweeping statement. They're designed to be better than any implementations that a normal user can handle whilst being hassle free to use. A database leak cannot negate the possible benefits a hardware wallet can have.
No one flaunts their hardware wallet or at least I've never seen someone doing that. It's fair to say Ledger didn't invite someone to leak their database but they didn't take the proper security precautions. I would always make purchases online with the presumption that whatever I provide will become public and that has led me to take some measures to mitigate the impacts of any database leaks.

To make it clear, I don't support Ledger as well but they are a hardware wallet maker who is able to do their job decently well.

It's 034acce93c52ec4ceef893014f139ca3a8ac817cef1bd397d328981b68d6bf7b67.

The formatting for Blockchain.com is always kind of weird when copied. This is a compressed public key.

48 - OP_Pushbytes_72

3045022100a4122309203bfcfe8f9ea9f7b2d503895fc0669300d5b26fb15d88b5626f3a8d02202 7b2ed245627fc0edc5d26b61dd7ac501ec7152ec405d93500cfd1ee1007e6ee01 - ECDSA signature

21 - OP_Pushbytes_33 for compressed public keys


034acce93c52ec4ceef893014f139ca3a8ac817cef1bd397d328981b68d6bf7b67 - Public key

Note that a compressed public key is always 33 bytes while uncompressed is 65 bytes.

If KeepKey is still surviving, you bet Ledger will still exist for years to come.

I feel most of these hacks and leaks usually dies down after awhile and it would get mentioned briefly in the future but the noise would probably not amount to too much bad publicity (bad publicity is still publicity) . It didn't directly affect the security of their product and they can just sweep it under the rug saying that it's their fault and better security measures blah blah..

I feel like Ledger has a pretty decent profit margin for their devices and that the lack of alternatives with their aggressive marketing campaign is just going to push more users to Ledger. Perhaps a little down in sales for awhile but it'll probably go back to normal after this blows over.

Think the point of OP is that if you accidentally set the email to someone else's email address/an unused email, they can reset the password easily and gain access to your account. That's why having a confirmation/validation email sent to your account's email is important.
If you think about it, having log in attempts being sent to your Email would result in some form of privacy loss. Perhaps if you're less wary about the loss of privacy, it's okay but logging IP addresses and sending them over the email can be dangerous for some.
There is a warning email sent to you IIRC.

Then the weak point would be with the Email addresses and if it gets compromised and with the emails being tied to the account permanently, it would be fairly dangerous.

---

If you want to ask why they are usually compromised, its usually due to password reuse due to multiple sites and that some can be crossmatched with previous database leaks of Bitcointalk. Bruteforce is out of the question as you can probably tell, Recaptcha is painful for bruteforcing.

Bitcoin Core doesn't keep a transaction index of transactions that are not pertinent to the addresses generated by your client by default. By enabling txindex (txindex=1) will make Bitcoin Core build the transaction database index and index them for the transactions to be found easily.

But AFAIK, Bitcoin Core won't specifically calculate the balance or organise the TXes related to "all the addresses" because addresses isn't really represented as such in the protocol level. You can try crawling through the Blockchain and see if you can index them yourself.

You have to also consider the electrical consumption of the nodes on the network if you want to be absolutely spot-on when talking about the numbers. I would think they are negligible when compared to the electrical consumption of the ASICs, so let's take that out of the picture.

I don't think electrical consumption (and its impact) is a good point to be made against POW Cryptos in general. Fact is, most of the alternative currency use far more resources and have far worse impacts when you compare it to the environment degradation as a result of Bitcoin mining. Fact is, most of the calculations are done with the presumption that miners don't use the more efficient ASICs and that the miners are using coal as a source of energy. In reality, those ASICs which are less efficient are already phased out. In addition, AFAIK most of the miners are situated near renewable and clean sources of energy and some of them are obtained from the surplus from such facilities.

For a network that "processes" or rather, has a transaction volume of tens of billions of dollars (even when Bitcoin was at 10k), I think it's reasonable to have that levels of electricity consumption. When the critics complain about the electrical consumption, ask them whether their proposed alternative could provide similar levels of security and characteristics that Bitcoin currently has.

First of all, back up your wallet.dat file. Don't store anything on the server without a backup.

It's zero because your client isn't synchronized yet. Are you connected to any peers? Use bitcoin-cli getnetworkinfo.

Could you check how much disk space do you have? Use df -h and check if you have at least ~350GB of disk space available. Some budget VDS barely have 50GB.

Honestly, one of the reasons why they decided to pursue Segwit was that it allows for the network to be soft forked so that older clients could be compatible as well. A hard fork like a sudden block size increase would result in everyone having to upgrade before it can start producing bigger blocks. Having to reject older peers wouldn't really benefit or harm the network and would just result in a portion of the network being disconnected from the rest.

I don't see the rationale in refusing connections just because they are running an older version. The incentive for them to upgrade is there and it allows them to upgrade at their own convenient time.