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.
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.
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.
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:
sis not defined here. As per the code, it means thelnbp1_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
same comment for
sThe 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.