Protocol framing issues in LNBP-1

[rajarshimaitra]

Hi, in order to undertand the full scope of RGB, I was parsing through the LNBP protocols and rust-lnbp library. Below are some of the framing nits and protocol documentation issues I encountered in LNPBP-1. Probably I am missing something but It would be nice if they can be clarified:

Compute HMAC-SHA256 of the lnbp1_msg and P, named tweaking factor: f = HMAC_SHA256(s, P)

s is not defined here. As per the code, it means the lnbp1_msg. May be changing it here would be nice, or it can produce unnecessary confusion.

Same issue in the code documentation here
https://github.com/LNP-BP/rust-lnpbp/blob/2f6fee732417aad5c71fcd0120ed0db4b1e61061/src/bp/dbc/pubkey.rs#L116-L117

Utilization of duplicated protocol tag hash prefix guarantees randomness in the first 64 bytes of the resulting tweaking string s, reducing probability for these bytes to be interpreted as a correct message under one of the previous standards.

• same comment for s

• The purpose of the protocol specific tag is to avoid equivalent interpretation of the same preimage between different contexts. I am not seeing how the prefix is guaranteeing randomness. At least no more random than padding the preimage with a constant. Maybe a different framing of the sentence can help?

• The "duplicated protocol tag hash" in the above sentence seems to suggest that there is double tagged hash append happening (like Taproot specification). But the protocol only suggests a single tagged hash.

Which brings me to my last query,

As per the comment in https://github.com/LNP-BP/rust-lnpbp/blob/2f6fee732417aad5c71fcd0120ed0db4b1e61061/src/bp/dbc/pubkey.rs#L136-L137

the message should be pre-tagged with the same protocol-specific hash, which then does explain the duplication part of the previous sentence, but LNPBP-1 doesn't specify anywhere that the message needs to be pre-tagged. It seems like an inconsistency between the doc and the implementation.

These are some of the minor issues I have found with LNPBP-1. It's also possible that I am interpreting these sentences wrong. Nevertheless opening this issue to initiate discussions on them.

In the coming few days I will be parsing through the rest of specifications and implementations and would report if I encounter anything.