I'm really curious about what people use, but the responses (thx!) echoed what I already knew:
- Ocean can be used, but lightning payments require you to run your Bolt12-aware LN node (CLN) (I do that)
- Braiins is a nice pool, has LN payouts with small amounts. It's account-based.
My vision: you just plug your Nostr npub into the BitAxe, and start receiving mining payouts as Zaps. 100% permissionless and Nostr-integrated (a benefit compared e.g. with using Braiins).
I'm working on this, have a rough prototype (msg me if you want to try it).
The next vision: the BitAxe can store the payouts by itself (as cashu), and you can redeem at will (or automatically periodically). 100% permissionless and 0 setup.
This ties together with Hashpool nicely, nostr:nprofile1qqsdxpfv503a2ga3ajqxw843hws9z7302ghpj4mcmjpa6qagmp9pwrs8222jg , but my focus is on small home miners (small payouts) and nostr integration, and cashu is less of a priority. Hashpool with the ecash based marketplace has more benefit for large miners, I think.
I think the best benefits of hashpool are for small miners.
Look at cashu payment requests. It's exactly what you are building but with ecash. I vibe coded this 90% of the way but threw the code away. I could probably get it working in another day of work.
https://github.com/cashubtc/nuts/blob/main/18.md
https://github.com/vnprc/hashpool/blob/master/PAYMENT_FORWARDING.md
I would deploy it but the sticking point right now is how to associate a mining channel with a payment request. Can it fit into the name field? I don't want to add an account system. If we had a static cashu payment field for each npub that might work.
With the current architecture each payment request would require a proxy pool deployment. Not the best UX.
I could solve it with an Sv2 protocol extension but I would prefer a dumber and easier solution.
Cashu payment requests sounds interesting!
Associating a miner with a Nostr npub, and that with a payment request is an additional indirection step (extra complexity), but it has several advantages: access to user profile, user-option to choose cashu-vs-lightning payout, option to create zap/nutzap events, option to message users, etc.
If you feel this info belongs to Nostr user profile, put it there in a proprietary field and start using it (propose standardization). Or another way is to use the Arbitrary custom data Nostr standard store this use-case specific info -- I think this is more appropriate in this case, since the payment request is use-case specific. Either way, you have to take care of setting this (contrary to e.g. lightning address, which can be set by any client).
I plan to use Arbitrary custom data for user settings like payout frequency (less often than default), payout threshold (higher than default), or payout method (zap vs. plain lightning pay vs. nutsack wallet vs. nutzap).
