it requires implementing BIP32 also
for smartcards, the problem with BIP39 is that it requires you hash the *mnemonic as text* and not converted to a binary format or anything, which means you now need space for a 12kb wordlist
Discussion
my first computer hand 16kb, it could have done it
people are making devices with less than 16kb of rom/flash???? where do you even get such a small chip these days?
i guess it must be custom silicon, still... 64kb should be minimal in most cases for the software
these devices do secp256k1 signatures tho, right?
how do they do that without a big chunk of memory for precomps if they are so weeny?
surely they could dial back the precomps a bit to free space to store HD and mnemonic dictionary?
dedicated accelerators
expensive ASIC circuits then i guess
I can’t comment much on these, but for performance benchmarks for example, the Nitrokey HSM (which uses a javacard AFAIK), does 80ms/ECC signature operation
pretty fast for something without a dedicated power supply, i think my recent generation Zen processor does them in about 11us, i forget, hmmm imma check so i can speak confidently...
yes, about 11us for the bitcoin core library and 80us for the btcd library
I can get about 10k signature verifications per core per second on a 5950X, so about 100us per verification
this is using the unoptimized decred secp256k1 impl and fiatjaf’s go-nostr
oh yeah, sorry, i'm quoting hash/sign/verify here, i haven't actually benched it on here this is a test that signs and verifies using each library, on 9999 events, and probably forming the canonical message and hashing it is part of the operation
i'm really not bothered to test that stuff so much as verify that i've improved upon that shitty implementation, and i have, dramatically, 7x improvement, and since that improvement is likely more than just one thing i've improved, it's probably a net win of more than 20x in total
i am totally pissed at the C and C++ and Rust guys laughing at us Go programmers... on the basis of work done by DECRED devs
fuckin ridiculous
yeah, iirc my canonical marshal/hash operation costs about 4us on libsecp256k1 and 11us using go-nostr library, it's retardedly slower... hang on what are the figures i did bench this
https://github.com/mleku/nostrbench
yeah, 1 microsecond for the json op and half that for the binary encoder, and the easyjson is 1.7us idk what the hash function is and that's for the standard object format not the canonical array, which is more complex
my encoders are the fastest you can get in Go and yes i promise not to change them at this point
the downside: part of why it's faster is it isn't using strings, the runtime storage for id, pubkey and sig are raw binary, so it's kinda funny that's still faster than a runtime format that keeps them as hex strings to convert to hex... yes, i use the SIMD xxhex library from templexxx and minio/sha256 hash library for the hash functions, though that's nothing to do with the codec exactly
i'm pretty sure with my codec we have no excuse to not wipe the floor with the repeat myself a thousand time fanbois
the problem is they want to cut costs
everyone uses crappy javacards which have massive overhead per operation, and the applets take up huge space
there’s also the fact that PBKDF is slow and would take up to a minute with those crappy cards
that and most cards being 72k/144k EEPROM for everything including app code (and they want to cut costs by using less EEPROM) and there isn’t much space for the wordlist