LNPBP-1: Public keys

1

LNPBP: 0001

2

Layer: Transactions (1)

3

Vertical: Bitcoin protocol

4

Title: Key tweaking: collision-resistant elliptic curve-based commitments

5

Authors: Dr Maxim Orlovsky <[email protected]>,

6

Dr Rene Pickhardt,

7

Federico Tenga,

8

Martino Salvetti,

9

Giacomo Zucco,

10

Max Hillebrand,

11

Christophe Diederichs,

12

Yojoe <https://github.com/yojoe>

13

Comments-URI: <https://github.com/LNP-BP/lnpbps/issues/3>

14

Status: Proposal

15

Type: Standards Track

16

Created: 2019-09-23

17

Finalized: not yet

18

License: CC0-1.0

Copied!

TOC

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 some selected original public key Po from this list (Po âˆˆ S), and a protocol-specific tag known to both parties, the commit procedure runs as follows:

1.

Reduce list P* to a set of unique public keys P, by removing all

duplicate public keys from the list.

2.

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.

3.

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

4.

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*)

5.

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.

6.

Multiply the tweaking factor f on the used elliptic curve generator point

G: F = G * f

7.

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'.

8.

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:

1.

Make sure that the provided tweaked public key T lies on the elliptic curve

and is not equal to the point at infinity.

2.

Compute

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

repeating the commitment procedure according to the rules above.

3.

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:

1.

Original message msg

2.

Tweaked public key value T

3.

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: 1. Commit the message msg to a specific public key S. 2. 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

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

1

use std::collections::BTreeSet;

2

â€‹

3

use bitcoin::hashes::{sha256, Hash, HashEngine, Hmac, HmacEngine};

4

use bitcoin::secp256k1;

5

â€‹

6

lazy_static! {

7

/// Global Secp256k1 context object

8

pub static ref SECP256K1: secp256k1::Secp256k1<bitcoin::secp256k1::All> =

9

secp256k1::Secp256k1::new();

10

}

11

â€‹

12

lazy_static! {

13

/// Single SHA256 hash of "LNPBP1" string according to LNPBP-1 acting as a

14

/// prefix to the message in computing tweaking factor

15

pub static ref LNPBP1_HASHED_TAG: [u8; 32] = {

16

sha256::Hash::hash(b"LNPBP1").into_inner()

17

};

18

}

19

â€‹

20

/// Deterministically-organized set of all public keys used by this mod

21

/// internally.

22

type Keyset = BTreeSet<secp256k1::PublicKey>;

23

â€‹

24

/// Errors that may happen during LNPBP-1 commitment procedure or because of

25

/// incorrect arguments provided to [`commit()`] function.

26

#[derive(Clone, Copy, PartialEq, Eq, Debug, Display, Error, From)]

27

#[display(doc_comments)]

28

pub enum Error {

29

/// Keyset must include target public key, but no target key found it

30

/// the provided set.

31

NotKeysetMember,

32

â€‹

33

/// Elliptic curve point addition resulted in point in infinity; you

34

/// must select different source public keys

35

SumInfiniteResult,

36

â€‹

37

/// LNPBP-1 commitment either is outside of Secp256k1 order `n` (this event

38

/// has negligible probability <~2^-64), or, when added to the provided

39

/// keyset, results in point at infinity. You may try with a different

40

/// source message or public keys.

41

InvalidTweak,

42

}

43

â€‹

44

/// Function performs commitment procedure according to LNPBP-1.

45

pub fn commit(

46

// We automatically reduce set to unique keys by using `BTreeSet` in the

47

// underlying `Keyset` data type

48

keyset: &mut Keyset,

49

target_pubkey: &mut secp256k1::PublicKey,

50

// We take a hashed version of the protocol tag for computation efficiency

51

// so it can be used in multiple commitments without hash re-computing

52

protocol_tag: &sha256::Hash,

53

message: &impl AsRef<[u8]>,

54

) -> Result<[u8; 32], Error> {

55

if !keyset.remove(target_pubkey) {

56

return Err(Error::NotKeysetMember);

57

}

58

â€‹

59

let pubkey_sum = keyset

60

.iter()

61

.try_fold(target_pubkey.clone(), |sum, pubkey| sum.combine(pubkey))

62

.map_err(|_| Error::SumInfiniteResult)?;

63

â€‹

64

let mut hmac_engine =

65

HmacEngine::<sha256::Hash>::new(&pubkey_sum.serialize_uncompressed());

66

â€‹

67

hmac_engine.input(&LNPBP1_HASHED_TAG[..]);

68

hmac_engine.input(&protocol_tag[..]);

69

hmac_engine.input(&sha256::Hash::hash(message.as_ref()));

70

â€‹

71

// Producing and storing tweaking factor in container

72

let hmac = Hmac::from_engine(hmac_engine);

73

let tweaking_factor = *hmac.as_inner();

74

â€‹

75

// Applying tweaking factor to public key

76

target_pubkey

77

.add_exp_assign(&SECP256K1, &tweaking_factor[..])

78

.map_err(|_| Error::InvalidTweak)?;

79

â€‹

80

keyset.insert(target_pubkey.clone());

81

â€‹

82

// Returning tweaked public key

83

Ok(tweaking_factor)

84

}

85

â€‹

86

/// Function verifies commitment created according to LNPBP-1.

87

pub fn verify(

88

verified_pubkey: secp256k1::PublicKey,

89

original_keyset: &Keyset,

90

mut target_pubkey: secp256k1::PublicKey,

91

protocol_tag: &sha256::Hash,

92

message: &impl AsRef<[u8]>,

93

) -> bool {

94

match commit(

95

&mut original_keyset.clone(),

96

&mut target_pubkey,

97

protocol_tag,

98

message,

99

) {

100

// If the commitment function fails, it means that it was not able to

101

// commit with the provided data, meaning that the commitment was not

102

// created. Thus, we return that verification have not passed, and not

103

// a error.

104

Err(_) => return false,

105

â€‹

106

// Verification succeeds if the commitment procedure produces public key

107

// equivalent to the verified one

108

Ok(_) => target_pubkey == verified_pubkey,

109

}

110

}

Copied!

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

1.

Ilja Gerhardt, Timo Hanke. Homomorphic Payment Addresses and the

Pay-to-Contract Protocol. arXiv:1212.3257 [cs.CR]

3.

Adam Back, Matt Corallo, Luke Dashjr, et al. Enabling Blockchain Innovations

with Pegged Sidechains (commit5620e43). Appenxix A.

4.

Pieter Wuille. Schnorr Signatures for secp256k1.

5.

Pieter Wuille. Taproot: SegWit version 1 spending rules.

6.

RGB Protocol Specification, version 0.4. "Commitment Scheme" section.

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

1) Single public key #1

Original public key:

03ab1ac1872a38a2f196bed5a6047f0da2c8130fe8de49fc4d5dfb201f7611d8e2

Tweaked public key with the commitment:

025d69da2890f85928cb492545a13bd6782168b39d52e69fadd1d3fcb3b1bf9268

Tweaking factor value:

9ff4c975950ec102b5eb39df2f976948b2c1a6e3f92ef5bf5af0e1241380dbcf

2) Single public key #2

Original public key:

039729247032c0dfcf45b4841fcd72f6e9a2422631fc3466cf863e87154754dd40

Tweaked public key with the commitment:

032fdf6c4023453b869294ddd28684f98fcaca604c2cd734c8dd64b8520547b0b4

Tweaking factor value:

11db141cfe0143f60e9e9f9db478630033fc65eb4f682905e9044c87869459a5

3) 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 set

Original 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

1) Single public key #1

Original public key:

032564fe9b5beef82d3703a607253f31ef8ea1b365772df434226aee642651b3fa

Tweaked public key with the commitment:

0285f7e0a8cdd801e5fbf84602e84de46a036ba47230b2c37f7767a496aeb4e4c5

Tweaking factor value:

5639647143cb9dc78aa5d251694fcc053f3887cf27b13750f72a42ef04f7bde1

2) Single public key #2

Original public key:

0289637f97580a796e050791ad5a2f27af1803645d95df021a3c2d82eb8c2ca7ff

Tweaked public key with the commitment:

03fcd2e4c31622fcf9fef43e70dabf1daf8abae5685b15125ba6a0e444783c5f0e

Tweaking factor value:

7551544f39a2c3a4d65c34e5915702a825ccbbb914ac581389cbbd98869b4e48

3) 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

1) Single public key #1

Original public key:

0271efa4e26a4179e112860b88fc98658a4bdbc59c7ab6d4f8057c35330c7a89ee

Tweaked public key with the commitment:

02605b2400618ca83f563e997da456c7ae99df9b38a7939ead5bc8e5b8b29f5d45

Tweaking factor value:

7090ad6b1c6093e025c3b2f1607f9aea65449139a08ee773c61990e9b6e966d3

2) Single public key #2

Original public key:

039729247032c0dfcf45b4841fcd72f6e9a2422631fc3466cf863e87154754dd40

Tweaked public key with the commitment:

032bf20cd8539c2f3154fbae01e64ea3a492bb2431080c86c3f942571f9635ece7

Tweaking factor value:

214570a96bf958124eea266593fd9daed3ee357283b4f89613f99a5d8ac8910a

3) 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]

1) Single public key #1

Original public key:

0352045bcc58e07124a375ea004b3508ac80e625da2106c74f5cb023498de0545f

Tweaked public key with the commitment:

0357f2619c2805794ef65ab7ea7a349f4c1be4cc3f576584f8270f06e830f33e36

Tweaking factor value:

14703d20ec36407889e5d7546d59edbfac4e69f211759a1bd783aa65ee1ae36c

2) Single public key #2

Original public key:

02a153dfe913310b0949de7976146349b95a398cb0de1047290b0f975c172ad712

Tweaked public key with the commitment:

0388bcce7da0bc2edd2ff553134c7ae109232f30bda347b39adca6d0d379a86315

Tweaking factor value:

627573dc2a7a57e5fe83f415d5f9d0e9ee78e51fd7990e926f09e9b8fe6a12b3

3) 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)

1) 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

2) 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.

1) 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

2) 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

3) 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

4) 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 modified 3mo ago

Export as PDF

Copy link

Contents

TOC

Abstract

Background

Motivation

Specification

Commitment procedure

Verification procedure

Reveal procedure

Compatibility

Rationale

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

Use of HMAC insead of simple hash

Public key serialization to 64 byte uncompressed form

Use of protocol tags

Protocol failures

Choice of elliptic curve generator point order n over field order p

No nonce

Reference implementation

Acknowledgements

References

License

Appendix A. Test vectors

1. Correct test vectors

2. Invalid test vectors

3. Edge cases: protocol failures