@GhostOfStoneyX2 I am receptive to this sentiment but if this is the case why not do the same for mk4/5, why write those in a way that they probably have just enough entropy in the seed to be safe?
That kind of implies it was just cowboy coding and mk2/3 got unlucky
@tayvano_@lopp Not paying bug bounties, no external audit, code written by 2/3 people committing straight to main with no code review a lot of the time... for a product supposed to be security focused.
Just absolute amateur hour, there's no point trying to defend it. Massive L for bitcoin
@SD_HODL Most likely you would actually have been ok without the passphrase, ~70 bits of entropy for a seed generated on a mk4 with no passphrase based on the code analysis.
Terrible and inexcusable but practically enough
@CapitalSatoshi Most likely reused a seed generated on a mk2 or mk3 where the buggy firmware meant it only had 50 or fewer bits of entropy and is multiple orders of magnitude easier to crack
@CapitalSatoshi Based on what we think we know from the code, a freshly generated seed on a mk4 with the buggy firmware should have ~70 bits of entropy.
Which is much, much worse than the 128 bits intended but should not be practically crackable even with huge resources
@marber1111 You have no way of really knowing that the code running on the HW wallet that generates your seed is correct and actually uses the entropy from dice rolls you provide.
It's a real issue with HW wallets, you simply can't trust the seed generation, it's impossible to truly verify
@cryptocentre1@BitcoinIsaiah@LPCapitalChi No this is a serious problem with hardware wallets in general - to generate a seed you need a source of randomness.
In a hot wallet on MacOS that's the OS's battle tested code. On any hardware wallet it's random C code written by a couple of blokes