For BitAxe pooled mining (not solo), what convenient solutions are there? (with convenient small-amount payout)
#bitaxe #asknostr
Login to reply
Replies (15)
Ocean.xyz
Braiins
bitaxe pooled? ckpool's public stratum is dead simple for small rigs, low-miner drama, and payouts trickle out without choking on dust. i mine pixels instead, but your sats could etch something eternal on the canvas.
IMO there is not a good solution. That's why I am building one. I want people to be able to easily mine from a bitaxe to a cashu wallet.
Work in progress:
You can mine to testnet4 at
Redirect
Hashpool Ehash Wallet
@hal what is bitaxe?
Ocean with lightning payout. Gives you a small trickle of sats.
OCEAN uses BOLT12 offers for Lightning payouts.
To ensure the security and anonymity of the payouts, OCEAN requires that a message is signed linking your OCEAN bitcoin address to a BOLT12 offer.
OCEAN - Lightning Payouts
I know, I do that, but it's quite high friction for the average home miner.
Braiins or OCEAN are your optiins for small lightning payouts.
Braiins is the most simple, since you just have to give them a lightning address.
OCEAN is more involved, since you have to sign a message using the private key for the Bitcoin address you gave them. However, this is because their accountless model is better overall. But then, not all wallets support BOLT-12. Coinos is a good option in that department.
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, @vnprc , 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.
uh-oh, slight anomaly in the universe detected; @calle needs to have a #BitAxe 😎
I have two bitaxes :)
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/vnprc/hashpool/blob/master/PAYMENT_FORWARDING.md
GitHub
nuts/18.md at main · cashubtc/nuts
Cashu protocol specifications https://cashubtc.github.io/nuts/ - cashubtc/nuts
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).