I'm not sure I follow. Do you mean finding the ephemeral key used in signing? Finding an ephemeral key would only allow an attacker to calculate a single one of the private keys in the multi-sig, not all of them (assuming of course you do not reuse your k value across all your keys, which no good wallet software would do anyway).

You can still brute force multi-sig addresses in far less time than brute forcing all the individual private keys by simply finding any script which hashes to the same output as the multi-sig script. So for a P2SH output, where the script hash is RIPEMD160(SHA256(script)), then you have a script hash which is 160 bits, which is obviously far less than trying to brute force 256 bits.

Unless you are meaning finding an individual private key which can be used as I've explained above in order to create a script with a hash which matches that of your multi-sig? And actually, since there are 2⁹⁶ private keys on average per address for the same reason, then I suppose the chance is in fact identical.

Depends on your bank and your jurisdiction. Some banks will happily let you open accounts, set up credit cards, take out loans, even take out mortgages, all over the internet. Often a picture of your ID is enough, and if they want more such as tax numbers, recent bills, etc., then these can be often be obtained by an attacker with a copy of your ID/passport/whatever and your other personal details.

Several.

Yes, it is true that you must be fully KYCed to use the fiat banking system. But the whole point of bitcoin is to get away from that. I use bitcoin precisely because I don't want a bunch of unknown third parties monitoring everything I do with my money, requiring their permission in order to do it, being censored and having my transactions refused if they don't like what they see, and then sharing that data with anyone and everyone they like. If you link your bitcoin addresses to your real identity, then you remain under constant surveillance. My stance on privacy is well known, and by subjecting yourself to KYC you have exactly zero prviacy.

It is also a massive security risk. Centralized crypto services have leaked, sold, shared, or been hacked for sensitive data an inordinate number of times. Every big exchange is guilty of this. Ledger themselves are guilty of this. Would you be happy with your real name and address being leaked across the entire internet next to a list of all your crypto addresses and their balances? Not only can anyone in the world monitor exactly what you are doing with your money, you become a target for both electronic and physical attacks to have your coins stolen.

KYC can ruin your life. Even without the crypto side of things, KYC documents are sold on black markets constantly. Having your identity stolen can leave you hundreds of thousands of dollars in debt for loans or credit cards you had nothing to do with. The latest studies have shown that identity theft costs US citizens alone over $50 billion a year:

https://javelinstrategy.com/2022-Identity-fraud-scams-report
https://javelinstrategy.com/research/2023-identity-fraud-study-butterfly-effect

I'd also point you towards this thread: Why KYC is extremely dangerous – and useless

Because the most efficient way to attack a private key is not to blindly brute force 256 bits, but rather to solve the ECDLP and reverse the elliptic curve multiplication, calculating the private key from the known public key. Such an attack would require (at least for the foreseeable future) on average 2¹²⁸ operations.

The security of the secp curves is defined in Standards for Efficient Cryptography. SEC 2: Recommended Elliptic Curve Domain Parameters. (Table at the bottom of page 4.)

You are correct. The network has no concept of which addresses happen to belong to hot wallets or cold wallets, which wallets are currently connected to or disconnected from the internet, or even if an address is not part of any wallet at all and no one knows the private key. All transactions are public, regardless of the addresses involved.

Also correct. You cannot say that just because an address is dormant that those bitcoin are lost, and the 4 million or so number that gets thrown about various blogs is a complete guess. The number of provably lost bitcoin which can never be spent due to technical reasons is very small, around 2,828 BTC.

The oxygen example is an extreme one. Because I'm a nerd who loves this kind of stuff - some very rough calculations would put a small 5m*5m*3m room at 75,000 liters, 21% O₂ gives 15,750 liters, with the molar gas volume of 22.4 liters at STP giving 703.125 moles of oxygen, times Avogadro's constant giving 4.234*10²⁶ molecules of oxygen. If you give each molecule a 12.5% chance of being gathered in a specific corner of the room (given that there are 8 corners), then your chance of them all being gathered in same corner is going to be 0.125^(4.234*10²⁶). My software won't calculate that number. I get as far as about 10^{-1,000,000,000} and then it gives up and says zero. Heh.

So yeah, a bit on the extreme side, but the principle is the same as I outlined above. Even if everyone in the world did literally nothing but constantly generate new wallets for millions of years, we still wouldn't get a collision. It is safe to assume the chance of a random collision is zero, just as it is safe to assume the chance of randomly suffocating is zero.

---

It's probably worth pointing out that if you think a 12 word seed phrase is insecure, then swapping to 24 words doesn't change anything. Bitcoin private keys "only" provide 128 bits of security at most, regardless of the number of bits in the seed phrase used to generate them. If you think all private keys are insecure, then your best mitigation to this (other than learning the math to see why they are not insecure) would be to use a multi-sig set up.

Yes. "Add to/Remove from coin control" has replaced "Spend from".

https://github.com/spesmilo/electrum/pull/8156

Well, whether or not there is much to gain depends on how long the fork lasts for.

Also a possibility, as I've discussed earlier in this thread: https://bitcointalk.org/index.php?topic=5452676.msg62269397#msg62269397

Lmao, you probably need to stop believing everything you hear on Fox News.

https://apnews.com/article/fact-check-target-swimsuits-transgender-pride-collection-892500330955

Satan's really toned it down recently, eh? He used to be all about eternal suffering in a lake of fire; now he just puts rainbows on onesies.

He's lying. Taking your own randomly generated seed phrase and changing the last word will never result in you stumbling across another active wallet.

This is an utterly irrelevant number when compared to the number of valid seed phrases.

Let's say we have 8 billion people in the world. Instead of 2 or 3 wallets, let's say that every one of those 8 billion people is generating a thousand new wallets every second. Let's also say that each one of those 8 billion people continues to generate a thousand new wallets a second every second for a million years.

8 billion * 1,000 * 60 * 60 * 24 * 365 * 1,000,000 = 2.5*10²⁶

Number of valid 12 word seed phrases = 3.4 * 10³⁸

So in my scenario, after a million years we will have generated approximately 0.00000000007% of all possible seed phrases.

There will never be a seed phrase collision.

They have said that first your seed phrase is encrypted, and then that encrypted seed phrase is split in to a 2-of-3 Shamir's scheme, with one share given to each of those companies. They have not however, as far as I am aware, said anything about how your seed phrase is actually encrypted, what encryption algorithms are being used, how the encryption key is generated, or who stores it.

If two of the three companies return their shares to your new Ledger and you combine them, then all you can do is recover your encrypted seed phrase. Without the decryption key, you cannot restore your wallet. Where does the decryption key come from? Who is providing it? We simply do not know.

My bad, I misunderstood.

The spillover is accounted for within the prefix bytes, so it doesn't spill out beyond this.

For example, if you take an xpub an decode to hex, your first 8 characters will be 0x0488B21E. This is the lower limit. Decrease by 1 to 0x0488B21D and your resulting string will start with "xpua". However, you can increase all the way up to 0x0488B224 and still have an "xpub". So any string which starts with "0x0488B21E" will always be "xpub", since even if every other byte is 0x00 or 0xFF, it still falls within the necessary range. Note that this works only because these strings are of fixed lengths. If you start adding or subtracting bytes, then the process fails.

So let's say I wanted to come up with a hex string which would have a prefix which encoded "oeLeo", followed by 14 bytes. I set my 14 bytes as all zeroes, and arrive at the following string:


If I increment my prefix by one, I get the following:


So I can use the prefix 0x046491a9c3, knowing that every possible value of the following 14 bytes still falls within the necessary range.

It's actually pretty accurate.

On my home hardware attempting to descramble a seed phrase from 12 known words, I can test around 115k possibilities a second. 12! / 115,000 = 70 minutes. Given that on average you need to attempt 50% of the possibilities to find the correct one, the average for me to descramble a seed phrase is 35 minutes.

But yes, your other points are correct. It is a pointless scenario because the security of your coins should never rest on an attacker having access to your seed phrase but being unable to descramble it.

You can find a list of all the extended key prefixes for both public and private keys here: https://github.com/satoshilabs/slips/blob/master/slip-0132.md#registered-hd-version-bytes

We now know this to be incorrect, though. As Ledger have said (and as I've linked to earlier in this thread), you can still recover your seed phrase via Ledger Recover even if you lose your hardware wallet and buy a brand new one. This means the decryption key does not need to be extracted from the SE, or is even stored on the SE in the first place. It must be stored by a third party for them to be able to give it to you when you activate a brand new device. Someone somewhere holds the power to decrypt your seed phrase and steal all your coins. The fact that Ledger won't even tell you who that entity is or what security is being used to store your decryption key is highly suspect.

There is firmware on both, but the firmware updates you install via Ledger Live predominantly target the MCU. The errors you get with an outdated device are either "MCU firmware is outdated" or "MCU firmware is not genuine".

Yes, I don't see why not. In Ledger's own words, from a now deleted tweet:


I don't see why it would be any different elsewhere. Any company can deploy any code they like to their own products. Your only real protection against this is a permanently airgapped device which has no way of broadcasting transactions without your involvement.

I think it's worse than that. Your shards, alongside their decryption key, have to go from secure element, to MCU, to Ledger Live on your internet connected computer, then across the internet to a variety of third parties. That's the same security (or lack thereof) as a hot wallet.

Open source, entirely airgapped, and statements from their devs on Twitter publicly calling out nonsense such as Ledger Recover and Trezor's blockchain analysis support. I would still prefer to use an airgapped and encrypted device to make my own cold storage, but Passport is the only hardware wallet I would recommend at the moment.

As nc50lc points out, this sounds like it might be a problem with compressed/uncompressed addresses.

Download this site from Ian Coleman run it offline: https://github.com/iancoleman/keycompression

Enter your private key in WIF format (which is the format you have them in - starting with K/L and 52 characters) in the first box at the top and it will return both the compressed and uncompressed address related to that private key. Check if either of them is correct.

They certainly wouldn't. I suppose I couldn't prove it without engineering firmware which does exactly that, but have a look at the hardware architecture here: https://developers.ledger.com/docs/embedded-app/bolos-hardware-architecture/https://developers.ledger.com/docs/embedded-app/bolos-hardware-architecture/

The buttons feed in to the MCU, not to the secure element. The MCU is where the firmware is installed. If Ledger can write firmware which says "Perform action x if confirmed by a button press", then I see no reason they can't write firmware which simply says "Perform action x".

If you use Ledger Live, then this is a given, since it connects to Ledger servers. And remember they are offering insurance with Ledger Recover, so they are 100% keeping track of your balances.

As I said, the vulnerability is unfixable. It still exists and will always exist on these devices. Coldcard is certainly airgapped, but it is not open source as Pmalek points out and the company behind it spread lies about competitors for their own gain. I personally wouldn't use it.

If I had to buy a hardware wallet right now, I would buy a Passport. But I'd much rather continue to use a separate airgapped, encrypted device, running a FOSS OS and wallet.

This is the exact point I've been making:

Oh, don't get me wrong. I am under no illusion that a new device makes zero technical difference to existing devices. Even without this firmware being deployed to existing devices, it is now abundantly clear that Ledger have been lying for years about the capabilities of their secure elements. I was simply pointing out that if I was a Ledger employee/board member, then I would have done the tiniest bit of research first, realized that 99% of existing customers hate this idea, and suggested launching it on a new device only and saying nothing about our existing devices.

It's good that they weren't this smart, though, since it's served as a big wake up call for people to stop trusting these shady third parties. Unfortunately it seems many people are simply jumping from one shady third party (Ledger) to another shady third party (Trezor).

All their devices suffer from unfixable seed extraction vulnerabilities, which they deliberately sweep under the rug and do not tell their users how to mitigate against. They also have a very pro-government, pro-censorship, pro-surveillance, and anti-fungibility ethos, as shown by their support of AOPP and their partnership with Wasabi and blockchain analysis.