Was there a pop up saying that your Electrum was outdated? I assume your prior version wasn't below 3.3.4?

The likely scenario I can think of is that you clicked on one of the top few results of Electrum if you've Googled it. Your Electrum was compromised when you installed the github version which is only 4.0.5.

There is nothing to be done, unfortunately. It's a good practice to be downloading and verifying the PGP signature of the binaries because these phishing attempts are very common. They cannot be held responsible, there is nothing they can do if users were to accidentally get phished because they didn't verify the binaries.

I personally have only read Electrum's source code fully, because it's written in Python and it's relatively less bulky than most other implementations. For that matter, I think it's a good practice to inspect what you're running on the computer. But the truth is, it's just too unrealistic. It's a time consuming process and most programs are a mix of languages and for which some are not proficient at. If you're reading the code but you don't know what's going on, the process is probably not going to be of any use and just a waste of time.

Beauty of open source lies primarily in the fact that people can have access to the source code and there are probably some that are honest and are quick to point out of any mistakes as well as transparent commits (in the case of projs on github). If you don't have the skills or the time to audit it (which can be rather time consuming for some bulky codes), then you'll be better off just validating the binaries. You'll probably not be able to identify anything wrong with the source code, it can be well obfuscated.

As for the study, isn't it geared towards softwares which integrate open source resources? Wouldn't the onus be on the corporations to be auditing their own software and/or update the modules appropriately?

---

I think auditing the code and compiling it yourself is good practice, if you can read it in the first place. **Given how well the Electrum phishing worked, I would think that most people wouldn't bother to even validate the binaries, let alone see the code.

Those were test accounts, which were (presumably) created by Satoshi. So technically, he's the first user because he controlled the test account at that time.

It's not insecure per se, it's just not the best security practice. The relevant files needed for the operation will be stored in the folder which is the same as the Electrum portable exe.

The main problem arises when you're plugging your drive and running it on different computers. The rationale why portable exes are considered to be more dangerous is because users tends to run it on insecure computers that could extract the wallet files or have malwares and potentially providing an avenue for malwares to spread through your disk drive and eventually to your own computers when you plug it in.

However, if you're looking for portability, consider using a hot wallet on your phone instead. It's way more secure.

---

Btw using a hard disk for Electrum isn't necessary, a removable USB flash drive will be more than sufficient.

Not needed. Most wallets, like Electrum, actually doesn't care about the checksum (other than the fact that it'll put a small warning) but it won't prohibit the user from continuing. It'll be good to enforce a valid checksum as it'll make missing phrases "slightly" easier to bruteforce and allow the user to identify if their phrases are entered wrongly. Of course, as mentioned, the longer seed phrases has a longer checksum length and thus bring about better error identification.
That isn't really 2 of 3 FA since you need the entire seed to use the keys so it'll be theoretically more like 3 of 3.


Wow, that's pretty interesting.

You have to determine the source of the compromise. Was it compromised solely because of the information being used for the Ledger Live leak or because of some other sources? How do you know your phone was hacked?

I would recommend for you to wipe your computer and your phone. I suspect that there is a high chance that you have a malware on the devices as opposed to your accounts being SE'ed. Ledger should generally be safe from such attacks. Seeds are never exposed outside of your devices and please don't key it into your computer either.

Yes. Sirius was the second member and was in control of the domain and hosting for an extended period of time. After that, Theymos took over as the administrator in 2012 IIRC.

Unencrypted format is in
5XXXXXXXXXXXXXXXXXXXXXX DATETIME
LXXXXXXXXXXXXXXXXXXXXXX DATETIME
KXXXXXXXXXXXXXXXXXXXXXX DATETIME

You likely have it encrypted and I thought the format was different since it's an uncompressed key and I've only dealt with compressed ones. I can't find any reliable tool to decrypt the file without installing MultiBit. You can try using BTCRecover[1] since it does support MultiBit Classic files if you know the password to the wallet file. It's definitely more complicated than using MultiBit Classic but it's a good way to try.


[1] https://github.com/3rdIteration/btcrecover/blob/master/TUTORIAL.md#running-btcrecover

I don't find it too much of a problem. As long as you have a passphrase, the attacker would have a hard time trying to get your seed.

There are a lot more choices than those two companies, maybe you could try exploring your options. Regarding the attack, what makes you think that your devices would be more protected than your hardware wallet? Attacking Trezor requires the attacker to specifically extract the encrypted seed from the secure elements by desoldering it and using specialized tools, after that start to crack your keys. I've seen more vulnerabilities affecting mobile devices than most hardware wallet and they don't require special skills.

I feel like most attacks are often blown out of proportion and companies has been relatively quick (at least those competent ones) to respond and provide a mitigation to it.

Then the address will be invalid and transactions generated for it will be invalid as well. Addresses has a checksum and replacing or reducing any characters will result in it being invalid. The chances of you replacing or removing a character and still matching the checksum is actually fairly low.

Very low.
If you know what you're doing, you probably don't have to fear too much. I always like to 'test' my wallet by sending a small amount and transferring around. It isn't necessary at all but helps with giving you a peace of mind.
Use RBF so you could still replace the transaction with something with a higher fees.


Correct.

---

Which bech32, the number of errors you make would probably give you a cushioning of 4 characters at least. As the number increases, it should tend towards the probability of 1 in a billion.

Certain links are autonuked by one of the bots being operated here. There are new links popping out every now and then so I imagine that it's difficult for them to nuke all.

Recently, they're obfuscated to use hyperlink or copy certain posts and insert their link in between. I've reported quite a few of them but it takes time for them to be removed.

Hopefully not, secp256k1 has a lot more benefits than that .

Thanks! Someone mentioned (I think a few weeks ago) that secp256k1 isn't that susceptible to certain sidechannel attacks but I couldn't find any literature on that. I didn't do any in depth research on the feasibility on the various other sidechannel attacks. But I suspect an attack could also be mounted on the encrypting/decrypting process of the wallet instead of the signing itself or through the RNG. Don't quote me on this, just a thought.

I've read through the firmware of ColdCard briefly and they did actually implement a few measures to reduce the signature.

I think that there are some conceptual misunderstanding here, I'll try to explain the process the best I can.

Mining involves the miner with his ASICs hashing the block headers twice to produce a hash. The block is valid when it's hash meets the target as specified by the network. The components of the block headers are as follows:
- Version (not really standardized due to ASICBoost)
- Previous Block hash
- Merkle Root Hash (Depends on the Transaction set)
- Time Stamp (Variable)
- Target in nBits (Fixed)
- Nonce (Variable)
The mining pool's job is to determine the transaction set and assemble them. Firstly, the mining pool will select a set of transactions and calculate the transaction fees. The pool will then use this amount, the pool will generate their own transaction and specify an output that is their address for which the amount must be less than < 6.25BTC + TX fees, there is no lower limit. After that, the pool will send the Version, Block hash, coinbase transactions, merkle tree, target and current time. The mining software will add the extranonce within the coinbase transactions before forming the merkle root hash. The mining software will then feed the relevant information to the ASIC itself.

Now, to the main part which how the ASIC actually mines. Depending on your ASIC, it will increment the nonce by itself. The extranonce allows the ASICs to calculate more hashes at once without wasting time to calculate the entire merkle tree again. ASICs are actually so specialized that most of them are designed to only vary and hash the final 4bytes which contains the nonce.

---

To point out the mistakes:

1. The mining software you're using likely doesn't connect directly to the network directly. You need to have access to the previous block hash, list of transactions and the target. To do this, something must be used to process the information which is usually either your own Bitcoin Core (for a solo miner) or a mining pool.
2. The previous block hash always changes every ~10minutes so there's likely no advantage in doing so.
3. Mining software does not store the coins in the wallet. As mentioned, a coinbase transaction is included in the block. The transaction contains the newly generated coins as well as the transaction fees and you can specify the output as your wallet. It does not happen after you find a block.
4. There's no verification node. Your ASICs determines the target and compares the hashes generated. If the hashes meets the minimum target, your block is valid. Your software will send the nonce used, timestamp, etc to the server and the server will relay the valid block with the headers, transactions etc.

Fees actually acts as a disincentive for spammers, that's why minimum relay fees was introduced. The fee market makes spam attacks more expensive and with lesser funds, the spam attack isn't competitive. I would say the reason why fee is necessarily is to reduce the shock to the system during the decrease in the halving. It creates a free market for the fees.
Still possible. It just requires the participation of the miners. The transactions described likely belongs to the miner mining it.

---

If you're responding to the fiat shill, then take it with a grain of salt. Tax and fees are intrinsically different, with fees, you're expected to pay someone or an intermediary and given that the miners uses their POW to mine blocks and include your TXes into the blockchain, I would think that it's like Western Union, Paypal, MasterCard, Visa which all charges a fee. You wouldn't call that a tax would you?

Side channel attacks. Most of your devices are not specifically hardened to withstand side-channel attacks by reducing the potential attack vectors associated with the sidechannel, (eg. EM wave leakage, timing attacks). There has been a study conducted on this[1] but, interpret it as you want, it isn't that recent or conducted on major wallets. I wouldn't consider it to be THAT big of a threat but if we were to compare the specifics, might as well mention it.

I understand that Trezor and some of the secure chip used were vulnerable to such attacks as well. They've fixed the problem and most of them requires tearing entire device apart and the victim's participation while it's hooked up to an oscilloscope.

** I'm not sure if someone conducted similar experiments on Electrum but I'd like to see if there is one.


[1] https://eprint.iacr.org/2016/230.pdf

If you have to adopt centralised services just to use Bitcoin for your payments, then you might as well use PayPal.

Coinbase is by no means a suitable alternative to rising fees and any other services like it doesn't serve as a suitable solution in the long run. Services like that will provide you with lower fees since the transfer is done within their own database, but you're sacrificing the transparency and the privacy of the individual. There's no company that would ever provide you with free services to transfer, there must be some strings attached. If you want to focus on low fees, I rather focus the efforts on LN and similar implementations.

---

Coinbase is a prime example of a company that doesn't give it's user the control of their own coins. They often freeze accounts on the basis of tainted coins which are often built on unfounded allegations.

As said, Ledger uses many different addresses and thus the disparity lies primary with the fact that your funds are split between each address that you use. Ledger also sends funds into your Change addresses which are never shown as your receiving address.

You can export the master public key [1] and use it to search for the funds in the addresses generated with the corresponding seed. I wouldn't recommend doing this as the blockexplorers can know the group of addresses that are linked together, with the IP and the browser fingerprint being leaked.

Using a Ledger with an Electrum wallet should be sufficient to identify addresses that contains the funds and use it to search on the blockexplorers.

[1] https://support.ledger.com/hc/en-us/articles/360011069619-Extended-public-key

Private key, yes.
Should have 51 or 52 characters, does it start with a 5, L or K?
You shouldn't. The older Multibit wallets likely won't allow you to transfer the funds.
Yes. You should be able to extract is relatively easily if it's unencrypted. The format should have your addresses listed in one column and the private keys in the other, assuming multibit classic.
Electrum. You only need your private keys.

Possibly cents. It's important to note that opening or closing a channel would incur some fees for it's an onchain transaction. My funding transactions are always executed at lower fees so my recent funding transaction was about $0.1 or so for $100 of TX. The fees for transacting within the Lightning network is practically negligible.

IMO, if you really want to determine a fair fee, you have to evaluate the costs per transaction in terms of the resources used. For LNs, they are usually fairly low cost to run as compared to on-chain transactions. As such, if you're talking in the context of LN, then the fair fee to charge is probably just several cents.

---

On-Chain transactions are out of the question and I believe you're not talking about it in this thread.

Well, then I guess you're better off with airgapped storage. It really boils down to if you trust the HW wallet manufacturer in this case, if you don't want to trust anyone else. At the same time, you have to make the same assumption about your cold storage wallet as well as the OS.

I wouldn't say that it's hard to prove. I'll be able to see the various commits to the github page if I were watching it and it makes inspecting the code before updates much easier.

Might have some spyware, after all they tend to include a ton of spyware. I'll wipe them and just install Linux. The popularity and the design behind Linux based OS makes the chances for persistent malware infection harder.
Your use case would probably make hardware wallets more attractive.

If you'd like, you can just purchase 2 Raspberry Pis and use them as cold wallets. My personal preference would just be to put some funds in a hot wallet and bring it around. Even if I were to lose them, I wouldn't lose all my funds.