Inbound events by relay, stream queue lengths, and processing workers.
Obviously some spikes are bad, haha. These were largely intensional.. side effects of other work and battle testing.
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
I feel for the poor hobbyist relay and app/service providers.. but for science here’s a graph.

I’ve been seeing more automated queries (subscription flooding) the past couple days from the network. And really crap code like instant and endless disconnect reconnects.
It’s from different sources too. Maybe a new tool people are using or something.
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.
Nostr Network without context

Ok, so here is a draft NIP for a Proof of Work Service Provider. All Feedback welcome!
Would love to hear from relay operators, open source relay contributors, client apps, Nostr users.
Basically, it allows for you to generate an event POW before signing as part of a relay membership or pre-paid credit system. Ultimately to succeed, Nostr apps would need to offer it.
I have a fully functional rust implementation I’ll likely open source (if enough interest), that just needs the payment integration code - and a bunch of testing.
https://gist.github.com/blakejakopovic/6c0ea718c0f956c461e9e8952d8c6533
I’m unsure how something doesn’t exist already. I’d much prefer to use an existing solution.
Main considerations are manual reconciliation/troubleshooting, over the wire/fallback failures, having to run entire nodes, etc.
Secondary issue is how do I easily link a payment to a Nostr pubkey. Using a human editable comment isn’t great, issuing per payment invoices isn’t amazing. Ideally they could just ZAP a known pubkey to top up the account. Then just draw down.
#[0] have an aggregate sum event POW of 47,000. Next highest is 17k. Then 10k.
Looks like it could be a decent spam filter or consideration. If you get to X POW, and haven’t been blocked or marked as spam yet.. you likely aren’t a problem account.
Unsure yet how to best use agg pow for identity - as POW 1 is exponentially easier to produce than POW 2. And a sum ignores that fact.. but a median perhaps could be an ok derivative.
Maybe a little harsh. If something better existed, or was easy to use/setup, it would win and should be recommended first.
Your assets should always be kept in risk tiers. Petty cash, physical cash transaction accounts, etc all are higher risk - employee theft, lost wallet, stolen bank card, etc.
Basically to start I feel it’s easier to pre-paid for credits (just lightning sats). But I would need a way to deduct from the total paid for a specific pubkey.. as a pubkey is effectively the payer.
For example:
I pre-pay 5000 sats (linked to my pubkey)
I then pay 10/sat to publish my event to a relay - which is not an invoice, just a draw down from that pubkeys 5000 - so they now have 4990 sats pre-paid credits.
Account keeping should be virtual and not full wallets or anything complex.
Asking again as undecided.
I need a lightning based payment API, and virtual account (or credits per pubkey) service.
Users can deposit into a pubkey’s virtual wallet/account. User withdrawal isn’t required. They top up when out of credits by depositing again.
When a user makes a request (e.g. for POW, or to publish an event), I can use an API to check and deduct/hold an amount/fee - or basically transfer it into an primary owner account (atomic db update is ideal).
Once successful, users account has fee removed. Primary owner account has the fee added. Refunds are possible for failures post-payment.
Suggestions welcome - but seeking exact API or service that’s ideally used in production by someone, not just “use LNbits or BTCPAY”. Thanks for feedback!
Damn. All my messages on Damus will now have a ‘Show more’ 😂.
Needed improvement however.
Any relay operators interested in offering basic (not vanity.. just 15-25) PoW event generation using the same client websocket connection with a new POW command?
It uses AUTH to confirm pubkey owner. Then accepts requests with a target POW. I’ll draft a NIP if interest and early testing goes well.
Working on drawdown based lightning payment integration next.
Basically, while not fancy, it’s possible relays can help self-fund if people pick them as their remote POW generation service, and the relays just add a service fee.
Once it is more widely available, then it would become a free market too - but people could still support their preferred relay by using them.
PV nostr, diving into NIP-13 today. Do any "PoW providers" exist already? Thinking about creating one for monetizing https://badges.page You could add optional Proof of Work to badges for a fee without having to run the computation yourself 🤔
I’ve built a bare bones PoW service and that accepts an event and target POW and returns the event id with matching or higher POW.
It’s missing a payments system, and I think it will need to use AUTH to ensure it can deduct the funds from the right pubkey. AUTH isn’t well supported yet.. but also trying to find time.
DM me if you wanna chat about it more. It would be nice to draft a NIP with a standard request and response for this stuff.
Appears to be a coordinated zapping spree by humans.. 😆
Which feed? The people you follow? Any specific app?
I just reviewed and updated the relays I connect to for NostrGraph.
Unsure if real ZAPs that weren’t broadcast well, or ZAP spam events? I’ll look again tomorrow..
