Enable SOLO mining mode on our Pool

[GitGab19]

Discussing with some other FOSS mining projects in the space made us realize that there's still a need in the market for SOLO mining endpoints.

Plebs are typically pointing their hashers to solo-ckpool or public-pool, when they are not running their own Bitcoin node and stratum server (or similars) locally.

Given that we recently started to host a mainnet instance of the Pool (together with the usual instance running on testnet4) on our VPS, we could extend our Pool to make it work as a SOLO mining endpoint.

The aforementioned solutions get the Bitcoin address to be used for the block reward through the Sv1 miner.authorize.username field, and we should take it from the corresponding Sv2 user_identity field of the OpenExtendedMiningChannel message.

This feature looks to me like something quite trivial to add to our current Pool, which could be than used by other projects in the space, giving us an additional way to stress-test and improve our current Pool.

[plebhash]

I agree this should be relatively trivial to implement, and a meaningful step forward in terms of adoption of SRI across the Bitcoin ecosystem.

But I have two things I wanted to point out about this.

First: conflating Pool and Solo terminology leaves room to a lot of potential confusion.

Second: hosted solo servers are a sketchy practice with heavy trust assumptions. I've been seeing lots of tweets from skot calling out scam projects that pose themselves as solo mining servers while actually mining for the scammer. In an ideal world, solo mining should be a fully sovereign activity, with no trusted third parties (but I guess there's no pitch for Sv2 use-case there, because binary and encryption only shine over the internet).

I don't necessarily have good answers or solutions to any of these points. These are important community trends and it would be dumb not to ride those waves and explore those clear avenues for adoption.

But I feel these points are worth mentioning anyways, because choosing to go in this direction despite these issues should be a conscious decision.

[GitGab19]

Good points, and I agree with you, we should consider them while taking a decision on this.

First: conflating Pool and Solo terminology leaves room to a lot of potential confusion.

How would you solve this?

Second: hosted solo servers are a sketchy practice with heavy trust assumptions. I've been seeing lots of tweets from skot calling out scam projects that pose themselves as solo mining servers while actually mining for the scammer. In an ideal world, solo mining should be a fully sovereign activity, with no trusted third parties (but I guess there's no pitch for Sv2 use-case there).

We can add a check in our tProxy which looks for the address contained in the coinbase_tx_suffix field of the NewExtendedMiningJob and compares it with the one set by the user. By doing it, we avoid any eventual scams.

[plebhash]

First: conflating Pool and Solo terminology leaves room to a lot of potential confusion.

How would you solve this?

As I said above, I didn't necessarily have the solution to these problems when I wrote that message. My original intention was more to bring them to awareness. But ok, if I had to brainstorm a potential solution, what comes to mind is:

Instead of calling this app SRI Pool, we rename it to SRI Mining Server.

• for the Pool use-case, in a way this still aligns with the notion that Pools usually deploy multiple mining servers on their infrastructure, as well as the fact that we're already making sure each deployment only assigns a subset of the available search space to its clients (via server_id config parameter)
• for the Pool use-case, we would still remain feature incomplete... some partial share accounting (from channels_sv2) but no reward distribution... that should go without saying but still emphasizing here for clarity
• for the Solo use-case, there would be no room for semantic confusion or misinterpretation, because this app would not be a "Pool" anymore... it would just be a job-generating Mining Server that makes sure each different user gets the entire block revenue if they find a solution

Anyways, I'm not strongly opinionated about this. Just trying to brainstorm an answer to @GitGab19 quesiton.

I would also be ok with not renaming anything, and I think there's reasonable arguments for that, especially in terms of leveraging terminology and narratives that are already well-established, regardless of their technical inaccuracies.

But on the spirit that Sv2 is trying to do things "the right way", this might also be a good opportunity to innovate?

cc @pavlenex

Second: hosted solo servers are a sketchy practice with heavy trust assumptions. I've been seeing lots of tweets from skot calling out scam projects that pose themselves as solo mining servers while actually mining for the scammer. In an ideal world, solo mining should be a fully sovereign activity, with no trusted third parties (but I guess there's no pitch for Sv2 use-case there).

We can add a check in our tProxy which looks for the address contained in the coinbase_tx_suffix field of the NewExtendedMiningJob and compares it with the one set by the user. By doing it, we avoid any eventual scams.

True, but that is still leaves some open questions:

First, we're only sure there's no room for scams if we assume that SRI tProxy is being used on the client side, while any other alternative Sv2 client (proxy or firmware) would still be potentially vulnerable... The ecosystem would need to get awareness of this kind of use-case, so adopters build UXs that allow for an explicitly defined "solo mode" that also enforce similar safety mechanisms.

Second, this can only be enforced over Extended Jobs, as Standard Jobs don't carry any information about the coinbase tx payout outputs. And for that, I can imagine the following mitigation:

We simply don't allow Standard Jobs on our "solo mode" implementation.

• If a scammer wants to exploit Standard Jobs, they would need to go out of their way and modify our implementation to support it, or build one from scratch.
• the tradeoff: that forces low-hashrate devices (which are very common in this "lottery" use-case) to always use Extended Channels, which leaves Standard Channels (which are meant precisely for low-hashrate devices) out of the picture.
• additionally: we would still need to make some efforts for educating the community, so that firmware and proxy implementers enforce proper UX that forbid usage of Standard Channels for solo mining purposes, protecting users against the unlikely (but possible) scenario where scammers deploy custom solo servers that leverage Standard Channels.