Write an RFC about Stratum V2 proxy to allow clients to do merged mining without depending on the pool

[msbrogli]

Relevant links:

• Landing page: https://stratumprotocol.org/
• Live specs: https://docs.google.com/document/d/1FadCWj-57dvhxsnFM_7X806qyvhR0u3i85607bGHxvg/edit
• "Official" miner implementation with V2 support: https://github.com/braiins/braiins

[msbrogli]

Interesting article: https://medium.com/@braiins_systems/experts-discuss-stratum-v2-and-the-future-of-bitcoin-mining-d62568df73a6

[obiyankenobi]

The basic explanation on Stratum v2's website is pretty simple to understand, so I'll focus here on the parts that we would use.

[Please read Protocol Overview on the website before continuing]

At the center of it there's the Job Negotiation protocol. The idea is having this Job Negotiator (JN) role performed by a third-party node, not a miner directly. The JN communicates with the pool to negotiate a block template to be mined. This block template contains the transaction set included in the block and can also include some coinbase outputs (proposed_coinbase_outputs). For Hathor, that would be the place to add the merged mining info. It's important to notice that the pool will always add its own coinbase outputs, making final_coinbase_outputs = proposed_coinbase_outputs + pool_outputs. The mining rewards, therefore, go to the pool.

When JN and pool agree on a block template, the pool provides a mining_job_token that identifies this template. The JN then notifies the interested miners about the mining_job_token, which miners use to request a job directly from the pool using an extended channel on the mining protocol.

In Hathor's case, there's the need for an additional proxy between miners and pool, for 3 reasons:

• if a mining share is solved for Hathor's target difficulty, we should propagate the block on Hathor's network;
• most miners won't have v2 support immediately, so our proxy can provide v2 -> v1 translation;
• miner has to provide both it's pool miner id (for the btc pool) and an HTR address, in case it finds a block. This is similar to what is being implemented in this MR.

[obiyankenobi]

Unfortunately, v2 is still not completely developed, even though Slush pool already has a v2.stratum.slushpool.com endpoint. Actually, the spec is still a draft and can suffer modifications.

There's no page from Slush pool with more information about development or ETA. I sent a message on a Braiins (the company behind Slush pool and stratum v2) Telegram group and got a response from its CEO that only standard channel has been implemented, so no support for extended channels yet. There's also no ETA for completion.

[msbrogli]

Good description. It is a shame that extended channels are not available yet.

[obiyankenobi]

There's nothing we can do right now. We should monitor v2 development and possibly implement this later. Will move this to our backlog.