Everything's coming up M̶i̶l̶l̶h̶o̶u̶s̶e̶ LukeDashJr
Ocean graduated to >1%. The used to be in "other," now they have their own slice of the pie chart
source: https://mempool.space/mining
Discussion
Hashers, switch to Ocean!
- you make more money
- you filter out spam (if you choose to)
- you have greater control over your blocks
- Ocean currently has almost 10 exahash
- if they get to 14 exahash they will be securely a top 10 mining pool
Do you know if there's a way to issue a BOLT12 reward payment invoice to them without revealing my node's public key?
No. Maybe I should make a clone of rack.supertestnet.org but for bolt12
That might be neat. Since it's an ongoing "subscription" like payment, a new bolt12 invoice would have to be created if one of the proxies became unavailable, right?
I think so, but it might be good to find out why you want to avoid letting them know your node pubkey in the first place. I initially assumed you wanted to do this because bolt12 offers reuse the same pubkey multiple times, which is bad for privacy. But rather than use a proxy, a simpler way to fix that is to make a new bolt12 offer after every payment. Bolt12 generators tend to make a new pubkey for each offer you generate.
Hrm. When I create a bolt12 invoice using Core Lightning CLI commands, when I run the invoice through a decoder, it shows my node pubkey. Maybe I did something wrong or misread the decoded output
After reviewing the bolt12 spec (https://github.com/lightning/bolts/blob/master/12-offer-encoding.md) I find that bolt12 offers are less private than I thought. The spec says a bolt12 offer "MUST set offer_issuer_id to the node's public key" unless it is "connected only by private channels." This design seems like a misguided specification for anyone whose goal is to conceal their node id. I recommend against using any bolt12 generator that reveals your node id. But the spec seems to *want* nodes to do that, so I'm not sure there are any that attempt to conceal that data. Not sure what to recommend here except maybe just don't use bolt12 until its privacy protections improve, or an implementation comes out that avoids revealing your node id.
Apparently I misread the spec. Someone highlighted this set of phrases:
```
if it includes offer_paths:
MAY set offer_issuer_id.
otherwise:
MUST set offer_issuer_id to the node's public key to request the invoice from.
```
Then they pointed out the direct implication: if you include an offer path (aka blinded path) you do not have to set offer_issuer_id at all
So the spec does not say the only exception is if you are connected only by private channels; a broader exception is there: use blinded paths.
Related lyrics, I asked if Eclair's implementation of bolt12 hides your node id when creating a bolt12 offer with blinded paths, and the docs seem to say it does:
```
If you specify blindedPathsFirstNodeId, your public node id will not appear in the offer: you will instead be hidden behind a blinded path starting at the node that you have chosen. You can configure the number and length of blinded paths used in eclair.conf in the offers section.
```