search

LNP-BP / LNPBPs

LNP/BP standards for bitcoin layer 2 & 3 protocols
https://standards.lnp-bp.org
202 stars 39 forks source link

Adding multi-key commitments to LNPBP-1 from LNPBP-2 #48

Closed dr-orlovsky closed 3 years ago

dr-orlovsky commented 3 years ago

Right now public key commitments (tweaks) under LNPBP-1 and 2 use different tags. However, with key homomorphism and Taproot we will never know whether some key is composed of multiple keys; and we can see single-key commitments as an edge case of multi-key commitments with N=1. So the proposal is to standartize commitment procedure with arbitrary number of keys in LNPBP-1, and use LNPBP-2 only for describing of how this keys can be deterministically extracted from a given Bitcoin script.

LNPBP-1 says how to tweak (in a secure manner) single public key; LNPBP-2 says about tweaking scripts, so when multiple public keys in a script are found, we commit to their sum (while still tweak only one of them, pointed by the user). The procedure use different tags, however it seems that this is the same procedure if we just have a single key we still may to follow it with a simple fact that the “sum” of the key is the key itself. This will simplify code logic and looks like more strealined way of doing things

UkolovaOlga commented 3 years ago

Comments from the discussion

S> Yes, it seems pretty logical to group these two procedures together, since one is a special case of the other. As a side note, I would like to clarify whether the user who commits to one/many private keys can somehow “check” at a later date how many keys he has used? Will this information not be lost if the procedures are merged?

M> It is seen from the bitcoin script, which is shipped (before the output is spent) as a part of the client-validated state.

F> There is a point that is not clear to me in lnpbp-1. In the second point of the specification paragraph it states: "Compute HMAC-SHA256 of the lnbp1_msg and P, named tweaking factor: f = HMAC_SHA256(s, P)" However s is not previously defined, so I guess it refers to the message string oflnbp1_msg. If so for clarity in this sentence we could put directly lnbp1_msg instead of s.

Moreover this could also cause extra confusion in the context of lnpbp-2 where S is used to indicate the sum of all public keys in a script

Related issues and PRs:

https://github.com/LNP-BP/LNPBPs/issues/40 https://github.com/LNP-BP/LNPBPs/pull/62 https://github.com/LNP-BP/rust-lnpbp/pull/120