Questions about const_sv2 crate

[GitGab19]

this discussion should guide the documentation of const_sv2, as described on #845

[GitGab19]

I just finished the first analysis on const_sv2 crate, looking at its lib.rs, and I have many points to discuss, so I'm going to list them all here:

• EXTENSION_TYPE_NO_EXTENSION
  • This is my interpretation: "Identifier for the extension_type field in the SV2 frame, indicating no extensions."
  • Reading the extension_type description is making me feel it's not the correct interpretation
  • I noticed it's only used in sv2_ffi crate here, but I still don't get if we really need it or not (cc @Fi3)
• SV2_FRAME_HEADER_LEN_OFFSET and SV2_FRAME_HEADER_LEN_END
  • What are these two constants for? They are not used anywhere, I only noticed they are equally declared in sv2_ffi, do we need them?
• ENCRYPTED_SV2_FRAME_HEADER_SIZE and NOISE_FRAME_HEADER_SIZE
  • they are only imported in framing_sv2, assigned to an alias here, which is then imported in codec_sv2
  • I can't see the reason to not import them directly into codec_sv2 if they are needed there
• NOISE_FRAME_HEADER_LEN_OFFSET
  • What is this constant for? It's imported in framing_sv2 in the same way here, but then its alias is never used anywhere else.
• NOISE_FRAME_MAX_SIZE
  • What is this constant for? It's not used anywhere
• pub const RESPONDER_EXPECTED_HANDSHAKE_MESSAGE_SIZE: usize = ELLSWIFT_ENCODING_SIZE;
  • Does it make sense to create an alias of ELLSWIFT_ENCODING_SIZE here? I think it should be created where the constant is imported. cc @lorbax
• MAC
  • Is it different from the pre-existing AEAD_MAC_LEN? cc @lorbax
• NOISE_SUPPORTED_CIPHERS_MESSAGE
  • This was related to AESG, can we remove it now we decided to not support it anymore? cc @Fi3
• CHANNELS_BITS
  • There's an entire section here dedicated to channel bits as booleans. What are they? I don't understand how they could be useful. Maybe they are just part of some very old version of the specs which I don't know about. cc @Fi3

[Fi3]

1. Ext type no ext is 0, when you receive a frame with 0 as ext type you parse it as an sv2 frame with a message in the non ext namespace so Mining, JobDeclaration, TemplateDistribution. It is a constant and should stay there.
2. If no used we can remove
3. make sense
4. if not use just remove it
5. same
6. or we can use just one name for everything?
7. I would just use the name AEAD_MAC_LEN everywhere, also we can remove the comment about AES since we dropped support for it
8. double check that we don't do anymore algo negotiation, if we don't just remove it. We removed AES but not sure if we still have in place the procedure to select the encryption algo.
9. https://github.com/search?q=repo%3Astratum-mining%2Fsv2-spec%20channel%20bit&type=code they need to stay there are still used