Similar question as with D17612

very nice to have this in our own lib but we do lose the empirical validation of the bip39 lib, i.e. this has been used for years in wallets without any known issues in "truly random" seed generation.

not necessarily related to the diff -- why is it better to keep all of these hash functions in webassembly? afaik we are the only cryptocurrency doing this.

is a higher resolution image available? it does look a little grainier than the last one, but not bad.

@bot preview-e.cash

rebase

update logic lost in rebase

rebase

nice looks much better.

Some alt options on this diff

greening this as I don't want to block it when I go to bed, but the package-lock.json changes should be backed out before landing

mb this issue is just from me running it locally?

In D17549#399466, @emack wrote:

I assume the flakiness of the test you're referring to is when the int test is waiting for the spinner to disappear but it doesn't, and the await waitFor() call just hangs there holding up the entire test suite?

// Wait for Cashtab wallet info to load
await waitFor(() =>
    expect(screen.queryByTitle('Loading...')).not.toBeInTheDocument(),
);

In D17549#399468, @Fabien wrote:

So before this patch it's broken and after this patch it's not, great.
May I ask how it's broken and how it's fixed ? Because I can't spot the change in behavior.

In D17540#399207, @emack wrote:

Actually, I did an actual check on the bundle size, one meg over 227 megs is negligible in the grand scheme of things. Non-issue unless the whole bundle is getting to a point where it may start to affect performance?

add cumulative, make sure tooltips are always on top

toHex it is