The other day I spun up an 8 CPU, 32GB RAM server and used it to do vanity #npub mining.
In my haste of excitement in generating (after a few hours) the "zap me" prefixed pubkey, I without thinking put it out here for sale.
Rightfully so, I was criticised about it as technically the privkey was viewed. Although, I have zero intention of spying and (hopefully my OSS projects speaks to this) it was still a mistake on my part as there needs to be a trust layer.
So, I forked Rana and spent the day to rebuild part of the rust script to instead of printing the hex/nsec privkeys in the console, it will not reveal them in the terminal and instead will TLS encrypt email it to an intended target address.
This way, myself (and anyone else) can use their resources to mine vanity npub for folks, but never view/store the privkeys when there's a match. Since it's a fork, the code change is publicly viewable and verifiable: https://github.com/Spl0itable/rana
If there are further ways to build that trust layer around this "Mining as a Service", I'm open to it. Please let me know. I'm looking forward to mining some vanity npub and allowing folks to further customise how they use #Nostr.
The problem is it still has the same risk factors.
Ideally Nostr sec keys are generated offline and never see a networked device - just like Bitcoin. Then only that device can remote sign - with sec key never leaving the device.
Even if you never would, you could still have access to someone’s DMs for the life of their account. Or ask them for more money, or their friends by impersonation.
This will never work sadly.
The risk factor falls onto the end user who've been sent the keys. What's their OpSec like. Is their email secure? Will the email be deleted responsibly after they've sufficiently saved the keys? No different expectations from self-custody wallet.
I'm not following the part about DMs? How would they be viewable to me if I don't know their privkey?
Or did you mean from the first time? Because I agree there, which is entirely the point of this post because I forked the mining script to not view the keys as described. Reread what I wrote about it and check the fork 🤙
I meant the vanity mining as a service part. It isn’t a code problem, it’s a which bits have existed at any point in time somewhere you don’t control.
It’s not as pretty, but this may interest you. May still offer a way to provide value and make money. https://gist.github.com/blakejakopovic/6c0ea718c0f956c461e9e8952d8c6533
Thanks for sharing that I'll definitely check it out, though, I'm still not sure where there is compromise here.
There'd need to be an attacker with physical access to my machine conducting a buffer overflow to try and pull out the keys from memory. Or more likely, the email of the target is comprised in some way.
Other than those scenarios, I don't see how the key could be extracted by a bad actor during the mining -> email process?
