It uses cryptographic primitives that were picked to make integration into Bitcoin Core easier. Bitcoin Core plays the Template Provider role as part of the Template Distribution protocol. There is a draft PR to Bitcoin Core to implement this role, that yours truly took over.
Although the protocol is similar to BIP324 peer-to-peer encryption, the spec was written earlier. Stratum v2 can’t switch over to BIP324 for the time being, because:
- Sunk cost / momentum
- Server authentication (sending work to the right pool)
- Message routing (this part is not very clear to me, but it may be useful for proxies to forward messages to and from individual mining machines based on the
channel_idfield in the header, without having to decrypt the payload)
Issue (2) may be addressed in the longer run with an authentication extension to BIP324.
Issue (3) - if it actually matters - may be more difficult to address, because BIP324 splits messages differently: the length is encrypted in 3 bytes, followed by a single blob with both header and payload.
Despite (1) I believe there’s still some room to tweak the Stratum v2 spec. So my question to you all is: which little nuggets from BIP324 could be ported over?
I’m looking for potential improvements that don’t require sv2 implementers to do any drastic overhaul. At the same time these changes might make a future transition to BIP324 easier.
Things that already the same (AFAIK):
- The use of ChaCha20 and Poly1305 in AEAD mode
- The use of sha256 to mix keys
Perhaps easy to implement:
- Use tagged hashes
Slightly more difficult to implement:
- Use EllSwift encoding and ECDH: RFC: Use EllSwift for ECDH by Sjors · Pull Request #66 · stratum-mining/sv2-spec · GitHub
Initially I didn’t want to propose (2), but it turned about implementations were not actually following the spec when it came to ECDH, so it might be worth changing the spec to remove the ambiguity.
This rest of this list is so small it’s probably not worth bothering.