Procol doc nits and framing issues for LNPBP-2

The following are some few nits and questions I came up with while reviewing LNPBP-2.

Nits:

With the following updates [11] LN will likely will change a single P2WPKH (named to_remote)... to -> With the following updates [11] LN will likely change a single P2WPKH (named to_remote)...
an arbitrary public key (even with an unknown corresponding private key), if OP_RETURN scriptPubkey is used; to -> an arbitrary public key (even with an unknown corresponding private key), if OP_RETURN type scriptPubkey is used;
Computes en elliptic curve point and its corresponding public key S as sum of elliptic curve points corresponding to the original public keys. to -> Computes a public key S as the sum of original public keys. (Rationale: as elliptic curve points are the public key, repeating them twice seems redundant).
on the second step of the protocol (according to LNPBP-1 specification [12]) HMAC-SHA256 is provided with the value of S (instead of P), i.e. hence we commit to the sum of all the original public keys;

Maybe adding the Hmac equation here HMAC_SHA256(SHA256("LNPBP2") || SHA256(<protocol-specific-tag>) || msg, S) can be more expressive.

on the forth step of the protocol the tweaking-factor based point F is added to the P (a single original public key), resulting in key T to -> on the fourth step of the protocol the tweaking-factor based point F is added to the P (a single original public key), resulting in key T, i.e. T = P + G * HMAC_SHA256(SHA256("LNPBP2") || SHA256(<protocol-specific-tag>) || msg, S)

Constructs and stores an extra-transaction proof (ETP), which structure depends on the generated scriptPubkey type: to -> Constructs and stores an extra-transaction proof (ETP), which is a structure that depends on the generated scriptPubkey type and consists of: a).... b)...

There is also a minor markup formatting issue here, making the resulting paragraph structure bit confusing.

The revel protocol is usually run between the committing and verifying parties; however it may be used by the committing party to publicaly revel the proofs of the commitment. These proofs include: to -> The revel protocol is usually run between the committing and verifying parties; however, it may be used by the committing party to publicly revel the proofs of the commitment. These proofs include:

The proposed cryptographic commitment scheme is fully compatible with any other LNPBP1-based commitments for the case of P2PK, P2PKH and P2WPH transaction outputs, since they always contain only a single public key and the original to -> The proposed cryptographic commitment scheme is fully compatible with any other LNPBP1-based commitments for the case of P2PK, P2PKH and P2WPKH transaction outputs, since they always contain only a single public key and the original

The author does not aware of any P2(W)SH or non-OP_RETURN P2S cryptographic commitment schemes existing before this to -> The author is not aware of any P2(W)SH or non-OP_RETURN P2S cryptographic commitment schemes existing before this

Reference implementation

https://github.com/LNP-BP/rust-lnpbp/blob/master/src/cmt/txout.rs

It would be better to give https://github.com/LNP-BP/rust-lnpbp/blob/master/src/bp/dbc/lockscript.rs & https://github.com/LNP-BP/rust-lnpbp/blob/master/src/bp/dbc/keyset.rs as the reference implementation link as this is where the majority of the LNPBP-02 logics are lying.

Questions:

Constructs necessary scripts and generates scriptPubkey of the required type. If OP_RETURN scriptPubkey format is used, it MUST be serialized according to the following rules:

only a single OP_RETURN code MUST be present in the scriptPubkey and it MUST be the first byte of it;

it must be followed by 32-byte push of the public key value P from the step 2 of the algorithm, serialized according to from [15]; if the resulting public key containing the commitment is non-square, a new public key MUST be picked and procedure from step 4 MUST BE repeated once more.

It would be nice to explain the rationale of requiring squared public key specifically for OP_RETURN type outputs as it's not enforced in any other part of the protocol. In the implementation here https://github.com/LNP-BP/rust-lnpbp/blob/2f6fee732417aad5c71fcd0120ed0db4b1e61061/src/bp/dbc/scriptpubkey.rs#L239 this behavior is not reproduced as the pubkey serialization output is in compressed form.

TODO: Schnorr compatibility

If I understand correctly in order to be schnorr compatible we need to enforce all the pubkeys to be squared. do we need any other consideration also?

Code Review

The composition assignment for P2PK and P2PKH are reversed here https://github.com/LNP-BP/rust-lnpbp/blob/2f6fee732417aad5c71fcd0120ed0db4b1e61061/src/bp/dbc/scriptpubkey.rs#L111-L112

if the number of original public keys defined at step 1 exceeds one, LNPBP2 tag MUST BE used instead of LNPBP1

This behaviour is not reproduced in the code here https://github.com/LNP-BP/rust-lnpbp/blob/2f6fee732417aad5c71fcd0120ed0db4b1e61061/src/bp/dbc/keyset.rs#L122 The tag is kept as LNPBP-1.

So these are some minor issues I observed in the specification and the implementation and they provide some scope of improvement. If consensus on the suggested changes is achieved I can start making small PRs to fix them.

LNP-BP / LNPBPs

Procol doc nits and framing issues for LNPBP-2 #41

Reference implementation

Questions:

Code Review