# LNPBP-1: Public keys

### Abstract

Cryptographic commitments embedded into bitcoin transactions is a widely-used practice. It's application include timestamping [1], single-use seals [2], pay-to-contract settlement schemes [3], sidechains [4], blockchain anchoring [5], Taproot, Graftroot proposals [6, 7, 8], Scriptless scripts [9] and many others. Nevertheless, existing ways of creating commitments have never been standardized with best practices and do not commit to the exact protocol or commitment scheme used. They are also inapplicable to situations where multiple public keys are present in some output: how to deterministically detect which key is holding the commitment.

This work proposes a standardization for cryptographic commitments that utilize the homomorphic properties of the `Secp256k1`

elliptic curve (EC) and allows to commit to arbitrary data using an EC public key or a set of EC public keys from the `Secp256k1`

curve in a deterministic and safe way.

### Background

Cryptographic commitments represent a way to commit to some message without revealing it. The procedure consists of two phases, **commit** and **reveal**. In the *commit* phase, a party (**committer**), willing to prove its knowledge of some message, computes a *cryptographic hash function* over that message producing a message **digest**, which can be provided to other party(ies). In the *reveal* phase, the *committer* reveals the actual message and each party accessing it may check that its hash is equal to the originally provided *digest*.

Key tweaking is a procedure for creation of a cryptographic commitment to some **message** using elliptic curve properties. The procedure uses the discrete log problem (DLP) as a proof of existence & knowledge of certain information about the message by some party (Alice) without exposing the original message. This is done by adding to a public key, for which Alice knows the corresponding private key, a hash of the message multiplied on the generator point `G`

of the elliptic curve. This produces a **tweaked** public key, containing the commitment. At a later time Alice may prove her past knowledge of the original message (at the time when the commitment was created) by providing a signature corresponding to the original public key and the message itself.

The main advantage of the public key tweak procedure is the fact that a tweaked key, or a corresponding signature, can't be distinguished from any other public keys or signatures; this property allows to hide the actual commitment in such a way that it can only be known to those parties which have knowledge of the secrets: the original public and/or key pair **and** a message.

This type of commitment was originally proposed as a part of the *pay to contract* concept by Ilja Gerhardt and Timo Hanke in [1] and later used by Eternity Wall [2] for the same purpose. However, these proposals were arguably vulnerable to length-extension attacks and, more importantly, were not applicable to scenarios when multiple public keys are used (for instance, multi-signature bitcoin transaction outputs). These problems were fixed as a part of the sidechain-design efforts by Blockstream [3], which proposed to utilize a HMAC function and also introduced a nonce in the concept.

Here we propose a standardization of the algorithm based on the original Eternity Wall and Blockstream work, enhanced with Pieter Wuille's Tagged Hashes procedure, coming from a specification on Schnorr signatures in Bitcoin [4], also used in the Taproot proposal [5]. This procedure prevents cross-protocol collisions, such that the original message's byte sequence can't be reinterpreted under another protocol.

### Motivation

Publication of cryptographic commitments to the Bitcoin blockchain is a widely used mechanism, allowing timestamping of the commitment: it can be used to prove the fact that some information was known before a certain period in time without revealing the actual information. Use of elliptic curve homomorphic properties allows to perform such commitments without increasing the size of the transaction, by leveraging existing transaction outputs and not polluting blockchain space with excessive OP_RETURNs. However, as of today, there is no single standard for such commitments. While different practices for that purpose exist (see [1, 2, 3]), they contain multiple collision risks, such as the possibility of length-extension attacks and cross-protocol replay attacks. Or they can't be applied in situations where multiple public keys are used ( multi-signature or custom bitcoin scripts). This standard combines existing best practices into a single algorithm, that avoids all of those issues.

### Specification

#### Commitment procedure

For a given message `msg`

, a list of public keys from the `Secp256k1`

curve `P* := {P1, P2, ..., Pn}`

, `n > 0`

, with a selected original public key `Po`

from this list (`Po ∈ P*`

), and a protocol-specific `tag`

known to both parties, the **commit procedure** runs as follows:

Reduce list

`P*`

to a set of unique public keys`P`

, by removing all duplicate public keys from the list.Compute sum

`S`

of all unique public keys in set`P`

; fail the protocol if an overflow over elliptic curve generator point order happens during the procedure.Construct a byte string

`lnpbp1_msg`

, composed of the original message prefixed with a single SHA256 hash of`LNPBP1`

string and a single SHA256 hash of the protocol-specific`tag`

:`lnpbp1_msg = SHA256("LNPBP1") || SHA256(tag) || msg`

Serialize the aggregated public key

`S`

into a 64 byte array`S*`

of uncompressed coordinates x and y in big-endian order and use`S*`

to authenticate`lnbp1_msg`

via HMAC-SHA256. The resulting value is named the**tweaking factor**`f`

:`f = HMAC-SHA256(lnpbp1_msg, S*)`

Make sure that the tweaking factor is less than the order

`n`

of a generator point of the used elliptic curve, such that no overflow can happen when it is added to the original public key. If the order is exceeded, fail the protocol indicating the reason of failure.Multiply the tweaking factor

`f`

on the used elliptic curve generator point`G`

:`F = G * f`

Check that the result of step 6 is not equal to the point-at-infinity; otherwise fail the protocol, indicating the reason of failure, such that the protocol may be run with another initial public key set

`P'`

.Add the two elliptic curve points: the original public key

`Po`

and the point`F`

, derived from the tweaking-factor. This will result in a tweaked public key`T`

:`T = Po + F`

. Check that the result is not equal to the point-at-infinity of the elliptic curve or fail the protocol otherwise, indicating the reason of failure, such that the protocol may be run with another initial public key list`P*'`

.

The final formula for the commitment is:
`T = Po + G * HMAC-SHA256(SHA256("LNPBP1") || SHA256(tag) || msg, S*)`

#### Verification procedure

**Verification procedure** for the commitment (i.e. tweaked public key `T`

) can be performed with the provision of the list of public keys `P*`

, the original public key `Po`

and the message `msg`

(assuming that the verifying party is aware of the protocol-specific `tag`

and `LNPBP1`

tag) and runs as follows:

Make sure that the provided tweaked public key

`T`

lies on the elliptic curve and is not equal to the point at infinity.Compute

`T' = Po + G * HMAC-SHA256(SHA256("LNPBP1") || SHA256(tag) || msg, S*)`

repeating the*commitment procedure*according to the rules above.Make sure that

`T' = T`

and report verification success; otherwise report verification failure.

#### Reveal procedure

Thus, **reveal data** required for the commitment verification constists of:

Original message

`msg`

Tweaked public key value

`T`

Original set of public keys

`P`

and a key`Po`

from that set.

The used protocol tag `tag`

must be known to all parties participating in the protocol.

### Compatibility

The proposed procedure should be compatible with previously-created pay-to-contract-style commitments based on SHA256 hashes under the assumption of SHA256 collision resistance. Utilization of a double tagged hash protocol prefix guarantees randomness in the first 64 bytes of the resulting tweaking string `lnpbp1_msg`

, reducing probability for these bytes to be interpreted as a correct message under any of the previous standards.

The procedure is well compliant with Taproot SegWit v1, since it operates with a sum of the original public keys, and the Taproot intermediate key is a sum of all used public keys, so it can represent a correct input for the protocol.

The tweaked procedure may result in a public key that may, or may not have its *y* coordinate being a quadratic residue (in terms of BIP-340 [4]). This may present a compatibility issue for using this scheme in Taproot/Schnorr-enabled outputs and protocols. Nevertheless, this issue may be mitigated by running the procedure a second time and replacing the original public key with its own negation, if the resulting tweaked version was not square.

The proposal relies on a tagged hash prefix similar to the one used in BIP-340, [4], which helps to prevent protocol collisions.

### Rationale

#### Commitments with a set of public keys, not a single key

The protocol was designed to support commitments to multiple public keys in order to be usable with non-P2(W)PK outputs. For instance, with Lightning network all outputs in the commitment transaction are non-P2WPK, so all existing key tweaking schemes are not usable within LN structure.

#### Use of HMAC insead of simple hash

Reason: prevention of length-extension attacks

As this protocol aims to be a generic scheme, the message `msg`

can be of any length. If we would just use a simple hash (e.g. SHA256), users of `LNPBP-1`

could **potentially** be vulnerable to length-extension attacks, if they are not careful. To be on the safe side, we use HMAC-SHA256, which is resistant to length-extension attacks, but computationally more expensive. However, this protocol aims to be used in client-side validation applications primarily and should therefore run many orders of magnitude less often then complete validatation of all public blockchain data. The computational overhead of HMAC on a client node is therefore considered negligible, for the targeted use cases.

#### Public key serialization to 64 byte uncompressed form

Reason: HMAC needs a byte array as input

HMAC requires a byte array as input for the `key`

argument to authenticate a message. This `key`

is not intended to be an EC key, it can be anything. Its purpose is to add entropy to the resulting hash value to counter length attacks on the underlying message.

We use HMAC's `key`

argument for two purposes:

Commit the message

`msg`

to a specific public key`S`

.As entropy for the security of HMAC-SHA256 against length extension attacks.

For the serialization of the public key `S`

, we rely on the *de facto* standard format for uncompressed public keys in Bitcoin, which is followed by libraries like rust-secp256k1. However, this results in a 65 byte array with the first byte being the prefix having the value `0x04`

, denoting an uncompressed public key. However, the first byte doesn't add any entropy and a `key`

larger than 64 byte causes HMAC-SH256 to do an additional round of hashing. Therefore, we use `rust-secp256k1`

' s `key.serialize_uncompressed()`

function, but strip the first byte from the resulting value, so we end up with a 64 byte array of:

32 bytes representing the x coordinate in big-endian order,

followed by 32 bytes representing the y coordinate in big-endian order.

#### Use of protocol tags

Reason: prevention of cross-protocol collision attacks

The use of protocol-specific, double tagged hashes was originally proposed by Peter Wuille in [4] and [5] in order to prevent potential replay-attacks for interpreting messages under different protocols. The choice of a duplicate SHA256 prefix hash was made according to Peter Wuille because it is not yet used in any existing bitcoin protocol, which increases compatibility and reduces chances of collisions with existing protocols.

#### Protocol failures

The protocol may fail during some of the **commitment** procedure steps:

when the

*tweaking factor*`f`

exceeds the order`n`

of the generator point`G`

for the selected elliptic curve.when the multiplication of the Secp256k1 generator point

`G`

on the*tweaking factor*`f`

results in`F`

being equal to the point at infinity.when the summation of the members of public key set

`P`

at any stage, or the addition of the point`F`

with the original public key`Po`

, results in the point at infinity.

The probabilities of these failures are infinitesimal; for instance the probability of the SHA256 hash value of a random message exceeding `G`

order `n`

is `(2^256 - n) / n`

, which is many orders of magnitude less than the probability of a CPU failure. The probability of the second or third failure is even lower, since the point at infinity may be obtained only if `F`

is equal to `-G`

or `-P`

, i.e. the probability of private key collision, equal to the inverse of Secp256k1 curve generator point order `n`

. The only reason why this kind of failure may happen is when the original public key set was forged in a way that some of its keys are equivalent to the negation of other keys.

These cases may be ignored by a protocol user -- or, alternatively, in case of the protocol failure the user may change `P`

's value(s) and re-run the protocol.

Protocol failures during the verification procedure may happen only during its repetition of the original commitment. This means that the original commitment is invalid, since it was not possible to create a commitment with the given original data. Thus, such failure will simply indicate a negative result of the verification procedure.

#### Choice of elliptic curve generator point order `n`

over field order `p`

`n`

over field order `p`

While it is possible to ignore elliptic curve overflow over its order `n`

during public key addition, since it does not provide a security risk for the commitment, it was chosen to stick to this scheme because of the following:

Current implementation of Secp256k1 library (libsecp256k1) fails on overflow during key tweaking procedure. Since this library is widely used in the Bitcoin ecosystem (and Bitcoin Core), it is desirable to maintain LNPBP-1 compatible with this functionality.

Probability of an overflow is still infinissimal, being comparable to probability of

`3.7*10^-66`

, for a tweaking factor not fitting into the elliptic curve field order`p`

.

#### No nonce

In certain circumstances a simple hash based commitment might be vulnerable to brute force vocabulary attacks, if the syntax and semantics of the invoking protocol are known to the attacker. This is usually countered with adding additional entropy (e.g. a nonce) to each hash. In our case the public key `S`

already provides enough entropy, which - when added via HMAC-SHA256 to the whole `msg`

– sufficiently counters such vocabulary attacks, preventing an attacker from successfully guessing the original message, even for short and standard messages.

### Reference implementation

### Acknowledgements

Authors would like to thank:

Alekos Filini for his initial work on the commitment schemes as a part of early RGB effort [6];

ZmnSCPxj for bringing attention to possible Taproot-compatibility issues [7];

Peter Wuille for a proposal on the tagged hashes, preventing reply-type of attacks [5];

Authors of Sidechains whitepaper for paying attention to the potential length-extension attacks and the introduction of HMAC-based commitments to the original public key [3];

Dr Christian Decker for pointing out on Lightning Network incompatibility with all existing cryptographic commitment schemes.

### References

Ilja Gerhardt, Timo Hanke. Homomorphic Payment Addresses and the Pay-to-Contract Protocol. arXiv:1212.3257 [cs.CR] https://arxiv.org/pdf/1212.3257.pdf

Adam Back, Matt Corallo, Luke Dashjr, et al. Enabling Blockchain Innovations with Pegged Sidechains (commit5620e43). Appenxix A. https://blockstream.com/sidechains.pdf.

Pieter Wuille. Schnorr Signatures for secp256k1. https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki

Pieter Wuille. Taproot: SegWit version 1 spending rules. https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki

RGB Protocol Specification, version 0.4. "Commitment Scheme" section. https://github.com/rgb-org/spec/blob/old-master/01-rgb.md#commitment-scheme

### License

This document is licensed under the Creative Commons CC0 1.0 Universal license.

### Appendix A. Test vectors

All tests done with protocol-specific `tag`

value equal to `ProtoTag`

. Values for public keys are given in standard compressed pre-Shorr's Bitcoin encoding format; values for tweaking factors are given in little-endian byte order.

#### 1. Correct test vectors

**1.1. Zero-length message**

Single public key #1

Original public key:

`03ab1ac1872a38a2f196bed5a6047f0da2c8130fe8de49fc4d5dfb201f7611d8e2`

Tweaked public key with the commitment:

`025d69da2890f85928cb492545a13bd6782168b39d52e69fadd1d3fcb3b1bf9268`

Tweaking factor value:

`9ff4c975950ec102b5eb39df2f976948b2c1a6e3f92ef5bf5af0e1241380dbcf`

Single public key #2

Original public key:

`039729247032c0dfcf45b4841fcd72f6e9a2422631fc3466cf863e87154754dd40`

Tweaked public key with the commitment:

`032fdf6c4023453b869294ddd28684f98fcaca604c2cd734c8dd64b8520547b0b4`

Tweaking factor value:

`11db141cfe0143f60e9e9f9db478630033fc65eb4f682905e9044c87869459a5`

Set of five public keys

Original public key:

`02383b24fbea14253ac37b0d421263b716a34192516ea0837021a40b5966a06f5e`

Key set:

`02383b24fbea14253ac37b0d421263b716a34192516ea0837021a40b5966a06f5e`

`025b178dfaa49e959033cc2ba8b06d78b8b9242496329a574eb8e2b4fad4f88b6f`

`03ec8b1cf223dc3cd8eb6d7c5fb11735e983c234b69271a3decad8bbfb2b997994`

`021ce48f4b53257be01ccb237986c1b9677a9e698fb962b108d6b2fbdc836727d8`

`0388a0fc8d3ba29a93ad07dbad37a6d4b87f2e2672b15d331d1f6bf4f2c9119ffe`

Tweaked public key with the commitment:

`03c153beef57c268ee9a2a68940f2aa7b052ce14c676a27cfe5010c53b41476238`

Tweaking factor value:

`a18417ae90cf36a45311ccc3a911a8ebb1b7afa02c6d79d1d1bd08b2abf67e94`

4). Set of same five public keys, using different original key from the setOriginal public key:

`025b178dfaa49e959033cc2ba8b06d78b8b9242496329a574eb8e2b4fad4f88b6f`

Key set:

`02383b24fbea14253ac37b0d421263b716a34192516ea0837021a40b5966a06f5e`

`025b178dfaa49e959033cc2ba8b06d78b8b9242496329a574eb8e2b4fad4f88b6f`

`03ec8b1cf223dc3cd8eb6d7c5fb11735e983c234b69271a3decad8bbfb2b997994`

`021ce48f4b53257be01ccb237986c1b9677a9e698fb962b108d6b2fbdc836727d8`

`0388a0fc8d3ba29a93ad07dbad37a6d4b87f2e2672b15d331d1f6bf4f2c9119ffe`

Tweaked public key with the commitment:

`03a224242255c9a024d4e2723c17faa09082b60bf91cea23ce558c9cff3a9627bf`

Tweaking factor value:

`a18417ae90cf36a45311ccc3a911a8ebb1b7afa02c6d79d1d1bd08b2abf67e94`

**1.2. Message consisting of a single zero byte**

Single public key #1

Original public key:

`032564fe9b5beef82d3703a607253f31ef8ea1b365772df434226aee642651b3fa`

Tweaked public key with the commitment:

`0285f7e0a8cdd801e5fbf84602e84de46a036ba47230b2c37f7767a496aeb4e4c5`

Tweaking factor value:

`5639647143cb9dc78aa5d251694fcc053f3887cf27b13750f72a42ef04f7bde1`

Single public key #2

Original public key:

`0289637f97580a796e050791ad5a2f27af1803645d95df021a3c2d82eb8c2ca7ff`

Tweaked public key with the commitment:

`03fcd2e4c31622fcf9fef43e70dabf1daf8abae5685b15125ba6a0e444783c5f0e`

Tweaking factor value:

`7551544f39a2c3a4d65c34e5915702a825ccbbb914ac581389cbbd98869b4e48`

Set of five public keys

Original public key:

`03ff3d6136ffac5b0cbfc6c5c0c30dc01a7ea3d56c20bd3103b178e3d3ae180068`

Key set:

`03ff3d6136ffac5b0cbfc6c5c0c30dc01a7ea3d56c20bd3103b178e3d3ae180068`

`02308138e71be25e092fdc9da03d5357421bc7280356a1381a6186d63a0ca8dd7f`

`03575fc4e82a6deb65d1e5750c85b6862f6ec009281992e206c0dcc568866a3fb1`

`0271efa4e26a4179e112860b88fc98658a4bdbc59c7ab6d4f8057c35330c7a89ee`

`0289637f97580a796e050791ad5a2f27af1803645d95df021a3c2d82eb8c2ca7ff`

Tweaked public key with the commitment:

`0289d1313a940f7b668804e223662edce2a7138914894607cd4bf641cc584936f3`

Tweaking factor value:

`87a5728772e0d14c9938c50ab29b215d5a0d9f59be7b40d16cc4bcac22e027b1`

**1.3. Message of text string ****test**

Single public key #1

Original public key:

`0271efa4e26a4179e112860b88fc98658a4bdbc59c7ab6d4f8057c35330c7a89ee`

Tweaked public key with the commitment:

`02605b2400618ca83f563e997da456c7ae99df9b38a7939ead5bc8e5b8b29f5d45`

Tweaking factor value:

`7090ad6b1c6093e025c3b2f1607f9aea65449139a08ee773c61990e9b6e966d3`

Single public key #2

Original public key:

`039729247032c0dfcf45b4841fcd72f6e9a2422631fc3466cf863e87154754dd40`

Tweaked public key with the commitment:

`032bf20cd8539c2f3154fbae01e64ea3a492bb2431080c86c3f942571f9635ece7`

Tweaking factor value:

`214570a96bf958124eea266593fd9daed3ee357283b4f89613f99a5d8ac8910a`

Set of five public keys

Original public key:

`03f72a42169a0475c4a342f8da97a1c0bce830183efecd0a3d81637b05d7c0d81a`

Key set:

`03f72a42169a0475c4a342f8da97a1c0bce830183efecd0a3d81637b05d7c0d81a`

`02383b24fbea14253ac37b0d421263b716a34192516ea0837021a40b5966a06f5e`

`025b178dfaa49e959033cc2ba8b06d78b8b9242496329a574eb8e2b4fad4f88b6f`

`03ec8b1cf223dc3cd8eb6d7c5fb11735e983c234b69271a3decad8bbfb2b997994`

`03f0d2dd91c4bcb630616ea9e3b2e95ec7f6f431d81bd627b62d04ac81b91af8c7`

Tweaked public key with the commitment:

`02da1eea3c29872e9d770efe66bfde4ad2b361f0644e81d1b4d95338eb75b813f1`

Tweaking factor value:

`63ea2d88f3b3969573ef530132989a9281cb499d6bfda4bfc0ade2cbd7bdf26e`

**1.4. Binary messsage, hex encoding (little-endian byte order)**

Original message for the all cases in this section: `[0xde, 0xad, 0xbe, 0xef]`

Single public key #1

Original public key:

`0352045bcc58e07124a375ea004b3508ac80e625da2106c74f5cb023498de0545f`

Tweaked public key with the commitment:

`0357f2619c2805794ef65ab7ea7a349f4c1be4cc3f576584f8270f06e830f33e36`

Tweaking factor value:

`14703d20ec36407889e5d7546d59edbfac4e69f211759a1bd783aa65ee1ae36c`

Single public key #2

Original public key:

`02a153dfe913310b0949de7976146349b95a398cb0de1047290b0f975c172ad712`

Tweaked public key with the commitment:

`0388bcce7da0bc2edd2ff553134c7ae109232f30bda347b39adca6d0d379a86315`

Tweaking factor value:

`627573dc2a7a57e5fe83f415d5f9d0e9ee78e51fd7990e926f09e9b8fe6a12b3`

Set of five public keys

Original public key:

`03a9c44838c0ac7417497f770ebd013c91ac715665ec01e740be0e14f44cab2474`

Key set:

`03a9c44838c0ac7417497f770ebd013c91ac715665ec01e740be0e14f44cab2474`

`03ad42e3bd69e30d32d088173e02b9d1cd00e4f7d945aad5c1a6c9439fdc8c5e80`

`03713e80a43b19d6f7b46ec5a474e86c8f5769f85f4fcb9a0be76d095b1e2b7981`

`025d9e055d7e7a85f097e981779c6e1c40d74b0563e631128c06623609b99a8f87`

`0323e518565f25038f16fdf7686ed4dd9a59b02ef95d2d7aa5be948f38701376b7`

Tweaked public key with the commitment:

`02d739f0fdd7bc395482c52e1ef1547a3c6fc6e2f1393430e74c55624f26023bd7`

Tweaking factor value:

`d5218633603181303d06320365fc84d06e0c2bb36c0989ee678a57b799f457a7`

**1.5. Keyset changes**

Commitment creation and validation filters repeated keys and does not depend on the key order (since elliptic curve addition is commutative)

Set of five public keys containing duplicated keys

Message (binary string, little-endian byte order):

`[0x00, 0xde, 0xad, 0xbe, 0xef]`

Original public key:

`025d9e055d7e7a85f097e981779c6e1c40d74b0563e631128c06623609b99a8f87`

Key set:

`03a9c44838c0ac7417497f770ebd013c91ac715665ec01e740be0e14f44cab2474`

`03ad42e3bd69e30d32d088173e02b9d1cd00e4f7d945aad5c1a6c9439fdc8c5e80`

`03ad42e3bd69e30d32d088173e02b9d1cd00e4f7d945aad5c1a6c9439fdc8c5e80`

`03713e80a43b19d6f7b46ec5a474e86c8f5769f85f4fcb9a0be76d095b1e2b7981`

`025d9e055d7e7a85f097e981779c6e1c40d74b0563e631128c06623609b99a8f87`

`0323e518565f25038f16fdf7686ed4dd9a59b02ef95d2d7aa5be948f38701376b7`

`025d9e055d7e7a85f097e981779c6e1c40d74b0563e631128c06623609b99a8f87`

Tweaked public key with the commitment:

`027f07015596c7a3af8a1da9e4fe1de0695278f94278ce01534b7ac7a530b43399`

Tweaking factor value:

`bc47cf269e70e5e654f3079f7316ddd988c529bf7d8c0efb0ec0759719afaeaa`

Set of five public keys in changed order

Message (binary string, little-endian byte order):

`[0x00, 0xde, 0xad, 0xbe, 0xef]`

Original public key:

`025d9e055d7e7a85f097e981779c6e1c40d74b0563e631128c06623609b99a8f87`

Key set:

`03713e80a43b19d6f7b46ec5a474e86c8f5769f85f4fcb9a0be76d095b1e2b7981`

`03a9c44838c0ac7417497f770ebd013c91ac715665ec01e740be0e14f44cab2474`

`025d9e055d7e7a85f097e981779c6e1c40d74b0563e631128c06623609b99a8f87`

`0323e518565f25038f16fdf7686ed4dd9a59b02ef95d2d7aa5be948f38701376b7`

`03ad42e3bd69e30d32d088173e02b9d1cd00e4f7d945aad5c1a6c9439fdc8c5e80`

Tweaked public key with the commitment:

`027f07015596c7a3af8a1da9e4fe1de0695278f94278ce01534b7ac7a530b43399`

Tweaking factor value:

`bc47cf269e70e5e654f3079f7316ddd988c529bf7d8c0efb0ec0759719afaeaa`

#### 2. Invalid test vectors

All these cases are cases for validation procedure, which must fail.

Case #1: commitment key created with a different original public key

Message: zero-length

Original public key:

`03ab1ac1872a38a2f196bed5a6047f0da2c8130fe8de49fc4d5dfb201f7611d8e2`

Tweaked public key with the commitment:

`02a8e7b5f006e3c96eb1e336d40a6956dd9c4889dbfb4542b50da0c90cd2ab64fd`

Case #2: original key and commitment are valid, but the message was different

Message:

`test*`

Original public key:

`032564fe9b5beef82d3703a607253f31ef8ea1b365772df434226aee642651b3fa`

Tweaked public key with the commitment:

`0240c2f382fc5335879c3607479c491dbd9bfb47d32c375f7d99e6d210a91f8780`

Case #3: commitment was created with correct message and original public key, but using different protocol tag

Message (binary string, little-endian byte order):

`[0xde, 0xad, 0xbe, 0xef, 0x00]`

Original public key:

`029a541ac6af794615935c34d088edc824c4433a83bdb5a781030c370111cf5b3a`

Tweaked public key with the commitment:

`0304d89459380b9d8ff2ebaaf2e20f47ce92dcf0b9dbfde9dbe866513a7819b79c`

Case #4: one of original public keys is absent

Message:

`test`

Original public key:

`03f72a42169a0475c4a342f8da97a1c0bce830183efecd0a3d81637b05d7c0d81a`

Key set:

`03f72a42169a0475c4a342f8da97a1c0bce830183efecd0a3d81637b05d7c0d81a`

`02383b24fbea14253ac37b0d421263b716a34192516ea0837021a40b5966a06f5e`

`03ec8b1cf223dc3cd8eb6d7c5fb11735e983c234b69271a3decad8bbfb2b997994`

`03f0d2dd91c4bcb630616ea9e3b2e95ec7f6f431d81bd627b62d04ac81b91af8c7`

Tweaked public key with the commitment:

`02da1eea3c29872e9d770efe66bfde4ad2b361f0644e81d1b4d95338eb75b813f1`

#### 3. Edge cases: protocol failures

Keyset constructed of a key and it's own negation.

Expected result: must fail commitment procedure with error indicating that the operation resulted at the point-at-infinity.

Message:

`test`

Original public key:

`0218845781f631c48f1c9709e23092067d06837f30aa0cd0544ac887fe91ddd166`

Key set:

`0218845781f631c48f1c9709e23092067d06837f30aa0cd0544ac887fe91ddd166`

`0318845781f631c48f1c9709e23092067d06837f30aa0cd0544ac887fe91ddd166`

Last updated