Avatar
Blake
b2dd40097e4d04b1a56fb3b65fc1d1aaf2929ad30fd842c74d68b9908744495b
#Bitcoin #Nostr #Freedom wss://relay.nostrgraph.net

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 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!

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.

Replying to Avatar verbiricha

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.

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..