LIP: 0038
Title: Introduce BLS signatures
Author: Andreas Kendziorra <andreas.kendziorra@lightcurve.io>
Discussions-To: https://research.lisk.com/t/introduce-bls-signatures/282
Status: Draft
Type: Informational
Created: 2021-04-13
Updated: 2023-02-22

Abstract

This document specifies how to use BLS signatures within Lisk. In particular, it specifies how to create and validate compact aggregate signatures with BLS. The specification consists mainly of a choice of a ciphersuite, i.e., the choice of a concrete BLS variant including the choice of several parameters. Moreover, some guidelines on how to use it within a blockchain created with the Lisk SDK are given.

This document does not specify any concrete applications of BLS signatures nor does it impose any protocol changes. It is purely informational on how to use them if desired. Specific applications need to be defined in separate LIPs.

Copyright

This LIP is licensed under the Creative Commons Zero 1.0 Universal.

Motivation

The purpose of this LIP is to be prepared for use cases where multisignatures for large sets of signers are required but the size of concatenated Ed25519 signatures is too disadvantageous. Cross chain transactions for a trustless interoperability solution are likely candidates for such use cases.

With the BLS variant we choose, several signatures of the same message can be aggregated into a single compact signature with a size of 96 bytes. If we consider, for example, a transaction that requires signatures from 68 active validators, concatenated Ed25519 signatures would sum up to more than 4.35 kB which is about 45 times larger than an aggregate BLS signature.

Very recent advancements have pushed the BLS signature scheme to a state that gives sufficient confidence in the theory of BLS signatures and in its implementations: The IETF standardization process was initiated and driven forward, several implementations were developed, matured and partially audited, and last but not least, the Ethereum2 Beacon Chain that started running recently adopted BLS, which results in real-world usage of both the BLS scheme as specified in the latest standard draft (version 4 at the time of writing) and the BLS implementations. Note that filecoin is using BLS signatures as well. However, their specification is based on an outdated BLS specification draft.

Specification

The BLS signature scheme as specified in the IETF draft BLS Signatures draft-irtf-cfrg-bls-signature-04 is used. More specifically, the ciphersuite BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_RO_POP_ is chosen. This ciphersuite uses the proof of possession scheme and the minimal-pubkey-size variant. Public keys use 48 bytes and signatures 96 bytes.

The ciphersuite exposes the following functions:

KeyGen
SkToPk
Aggregate
Sign (identical to CoreSign)
Verify (identical to CoreVerify)
AggregateVerify (identical to CoreAggregateVerify)
FastAggregateVerify
PopProve
PopVerify

The function AggregateVerify is, however, not used here. How and when the remaining functions are used is specified in the following subsection.

Usage

Keypair Creation

A secret key is created using KeyGen. The input for KeyGen must be an infeasible to guess octet string of length at least 32. See the appendix for a recommendation on how to choose this input and on key management.

The public key for a secret key sk is created by SkToPk(sk).

Signing and Verifying

(Note: The following function definitions are superseded by the ones in LIP 0062.)

Let message be a binary message, tag the correct message tag for message as specified in LIP 0037, chainID the correct chain ID of the chain and sk a secret key. Then, the signature is computed by signBLS(sk, tag, chainID, message) as defined below. The resulting signature sig in combination with the message message and the matching public key pk is verified by verifyBLS(pk, tag, chainID, message, sig). In the following, let tagMessage be the function defined in LIP 0037.

def signBLS(sk: bytes, tag: bytes, chainID: bytes, message: bytes) -> bytes:
    taggedMessage = tagMessage(tag, chainID, message)
    return Sign(sk, taggedMessage)

def verifyBLS(pk: bytes, tag: bytes, chainID: bytes, message: bytes, sig: bytes) -> bool:
    taggedMessage = tagMessage(tag, chainID, message)
    return Verify(pk, taggedMessage, sig) == VALID

Public Key Registration and Proof of Possession

In order to use a BLS keypair (sk, pk) for on-chain signatures, the public key pk of the keypair must first be registered on-chain via some transaction. Otherwise, every transaction or block that needs to verify a signature for pk via Verify or FastAggregateVerify must be rejected.

The Lisk protocol could contain several transaction types that perform such a registration. In particular, there could be different registration transactions for different keys, e.g, one for validator public keys and one for public keys of regular accounts. This LIP does not specify any registration transactions. Such transaction types must be defined in separate LIPs. In the following, we just assume there exists such a transaction type which we call register public key transaction. To register the public key of the key pair (sk, pk) by a register public key transaction, registerPublicKeyTransaction, the transaction must contain pk and a proof, prf, generated by PopProve(sk). If prf does not satisfy PopVerify(pk, prf) == VALID, then registerPublicKeyTransaction is invalid and must be rejected. Once registerPublicKeyTransaction is included, transactions and blocks that require to have a valid signature for pk can be included in the blockchain.

Example (validator registration): Validators will be required to register their BLS public key on-chain, which may be included in the validator registration transactions. Hence, a validator registration transaction needs to contain the BLS public key, pk, and a proof, prf, generated by PopProve(sk), where sk is the matching secret key. During the validation of the validator registration transaction, it must be checked that PopVerify(pk, prf) returns VALID.

Aggregate Signatures and their Verification

We only consider signature aggregation for the case where several signatures for the same message are aggregated.

Each aggregate signature needs to be accompanied by some information that specifies the set of public keys that correspond to the aggregate signature. Here, this is realized using a bitmap. Assume that keyList is a list that includes all potential public keys that could participate in the signature aggregation. The entries must be pairwise distinct. Moreover, let pubKeySignaturePairs be a list of pairs of public keys and signatures where all signatures belong to the same message, and all public keys are unique and contained in keyList. Then, the corresponding aggregate signature and bitmap can be computed via createAggSig(keysList, pubKeySignaturePairs) as in the pseudo code below. To verify if a signature is an aggregate signature of a binary message message, the function verifyAggSig can be used. verifyAggSig(keysList, aggregationBits, signature, tag, chainID, message) returns True if and only if signature is an aggregate signature of the message message for the message tag tag, the chain identifier chainID and for the public keys in keyList defined by aggregationBits.

def createAggSig(keysList: list[bytes], pubKeySignaturePairs: list[tuple[bytes, bytes]]) -> tuple[bytes, bytes]:
    aggregationBits = byte string of length ceiling(length(keyList), 8) with all bytes set to 0
    signatures = []
    for pair in pubKeySignaturePairs:
        signatures.append(pair[1])
        index = keysList.index(pair[0])
        # set bit at position index to 1 in aggregationBits
        aggregationBits[index // 8] |= 1 << (index % 8)
    signature = Aggregate(signatures)
    return (aggregationBits, signature)

Here, ceiling is an auxiliary function defined below.

def verifyAggSig(keysList: list[bytes], aggregationBits: bytes, signature: bytes, tag: bytes, chainID: bytes, message: bytes) -> bool:
    taggedMessage = tagMessage(tag, chainID, message)
    keys = []
    for i in range(8 * len(aggregationBits)):
        # if i-th bit of aggregationBits == 1
        if aggregationBits[i // 8] & (1 << (i % 8)) == 1:
            keys.append(keysList[i])
    return FastAggregateVerify(keys, taggedMessage, signature) == VALID

(Note: The definition of the function verifyAggSig is superseded by the one in LIP 0062.)

If one wants to additionally validate that the participating public keys satisfy a certain weight threshold, the function verifyWeightedAggSig can be used. The function takes additionally a list of weights, weights, where the i-th entry specifies the weight for the i-th public key in keysList and a weight threshold threshold.

def verifyWeightedAggSig(keysList: list[bytes], aggregationBits: bytes, signature: bytes, tag: bytes, chainID: bytes, weights: list[int], threshold: int, message: bytes) -> bool:
    taggedMessage = tagMessage(tag, chainID, message)
    keys = []
    weightSum = 0
    for i in range(8 * len(aggregationBits)):
        # if i-th bit of aggregationBits == 1
        if aggregationBits[i // 8] & (1 << (i % 8)) == 1:
            keys.append(keysList[i])
            weightSum += weights[i]
    if weightSum < threshold:
        return False
    return FastAggregateVerify(keys, taggedMessage, signature) == VALID

(Note: The definition of the function verifyWeightedAggSig is superseded by the one in LIP 0062.)

Note that the public keys in pubKeySignaturePairs need to be distinct when calling createAggSig. Otherwise, validation via verifyAggSig and verifyWeightedAggSig will fail.

Auxiliary Function

ceiling

Returns the ceiling of the division between two positive integers.

def ceiling(x: uint32,y: uint32) -> uint32:
    if y == 0:
        raise Exception('Can not divide by 0.')
    return (x + y - 1) // y

Rationale

Variant minimal-pubkey-size

We choose the variant minimal-pubkey-size because this one is used in Ethereum2 and filecoin and therefore the only variant that found considerable adoption. This means in particular that only the minimal-pubkey-size functionality of BLS libraries is significantly used and tested in practice and can be relied on.

Proof of Possession scheme

Choice of Scheme

We use the proof of possession scheme as we only need the use case of aggregating signatures of the same message, and this scheme allows us to use FastAggregateVerify for this case. FastAggregateVerifyrequires only two pairing operations whereas AggregateVerify requires n+1 pairing operations where n is the number of individual signatures that are aggregated. Note that pairing operations are very expensive.

Why Proofs of Possession?

Using FastAggregateVerify without requiring proofs of possession is insecure as it allows rogue key attacks. See this blog post for how rogue key attacks work for BLS signatures. To see why simply signing the public key is not a sufficient proof of possession method that defends against powerful attackers (chosen message attack model), see section 4.3 of this paper.

Backwards Compatibility

This LIP is purely informational. Therefore, it does not imply any incompatibilities.

Appendix

Key Management

We propose two ways to manage the keys: using a passphrase and storing the encrypted secret key. Moreover, we discuss below for which use cases the methods are preferred.

Using a Passphrase (BIP 39 Mnemonic)

This approach is similar to the key derivation method for the EdDSA account key pair in Lisk.

To create a new key pair, a passphrase is created according to the BIP 39 specifications, where an initial entropy of 32 bytes is used. In Node.js, this initial entropy can be created, for example, via crypto.randomBytes. The resulting passphrase consists of 24 words.

The passphrase is used as the input for KeyGen to derive the secret key, where the passphrase is treated as a single ASCII-encoded string with the space symbol (0x20) between two words. The user needs to remember or store safely the passphrase.

Storing Passphrase on a Remote Server

If the secret key is needed on a remote server, the encrypted passphrase must be stored on the server. The passphrase should be encrypted by AES-256-GCM, and the encryption key should be derived by Argon2d. The password used to derive the encryption key should conform to common guidelines for strong passwords. On the user interface level, the user should be warned otherwise.

Storing Encrypted Secret Key

To create a new key pair, an initial randomness of at least 32 bytes is created, e.g., via crypto.randomBytes. This randomness is used as the input for KeyGen to derive the secret key. The secret key is encrypted via AES-256-GCM, where the encryption key is derived by Argon2d. The password used to derive the encryption key should conform to common guidelines for strong passwords. On the user interface level, the user should be warned otherwise. The user needs to store the encrypted secret key (and ideally backs up the encrypted key) and needs to remember or store the password safely.

Choosing the Key Management Method

Using a passphrase is suitable for users that need their key pair only on local machines, e.g., for singing transactions. Users only need to remember or securely store the passphrase for this approach. Storing the encrypted secret key is suitable for users that need the key pair only on some remote server, e.g., a forging node on a remote data center. If the key pair is needed on local machines and on remote servers, there is a tradeoff between the two approaches. The first one requires to remember or store secretly a passphrase and a password, but does not require to store and backup any encrypted data locally. The second one requires to store and backup an encrypted file, but needs to remember or secretly store only one password.

Test Vectors

`Sign`

The Eth2.0 specification tests for Sign should be used. However, an implementation for this proposal should NOT fulfill the test for the zero secret key. To be conforming with the BLS specifications for Sign, the following must hold instead (note that this is the expected output for any message):

sk = 0x0000000000000000000000000000000000000000000000000000000000000000
message = 0xabababababababababababababababababababababababababababababababab
Sign(sk, message) == 0xc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

`Verify`

The Eth2.0 specification tests for Verify should be used. Additionally, the following cases must hold:

# pk does not represent a point on the curve E1
pk = 0xa53d21a4cfd562c469cc81514d4ce5a6b577d8403d32a394dc265dd190b47fa9f829fdd7963afdf972e5e77854051f6f
message = 0xabababababababababababababababababababababababababababababababab
sig = 0xae82747ddeefe4fd64cf9cedb9b04ae3e8a43420cd255e3c7cd06a8d88b7c7f8638543719981c5d16fa3527c468c25f0026704a6951bde891360c7e8d12ddee0559004ccdbe6046b55bae1b257ee97f7cdb955773d7cf29adf3ccbb9975e4eb9
Verify(pk, message, sig) == INVALID

# pk represents a point on the curve E1 but is NOT an element in the group G1
pk = 0x960003aaf1632b13396dbad518effa00fff532f604de1a7fc2082ff4cb0afa2d63b2c32da1bef2bf6c5ca62dc6b72f9c
message = 0xabababababababababababababababababababababababababababababababab
sig = 0xae82747ddeefe4fd64cf9cedb9b04ae3e8a43420cd255e3c7cd06a8d88b7c7f8638543719981c5d16fa3527c468c25f0026704a6951bde891360c7e8d12ddee0559004ccdbe6046b55bae1b257ee97f7cdb955773d7cf29adf3ccbb9975e4eb9
Verify(pk, message, sig) == INVALID

`Aggregate`

The Eth2.0 specification tests for Aggregate should be used. Moreover, the following additional cases should be covered:

# signatures for the message
# 0xabababababababababababababababababababababababababababababababab
# and the secret keys sk1=1 and sk2=r-1 where r is order of the groups G1 and G2,
# i.e., r = 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001.
# Hence, the aggregate signature must be the identity element in G2.
signatures = [
  0x979451d90ade914f7a6ffc5062914af990af297abdebf81dcebcaff93a5cb959e7f5db624bc8abb8cdb2660374c86a350bc0f071f2d0655a5edbf6b9208a6649d3309b8692d2f55bde74c52cc2de0fed2bb60b4c45935b11c32827da1b80cb8f,
  0xb79451d90ade914f7a6ffc5062914af990af297abdebf81dcebcaff93a5cb959e7f5db624bc8abb8cdb2660374c86a350bc0f071f2d0655a5edbf6b9208a6649d3309b8692d2f55bde74c52cc2de0fed2bb60b4c45935b11c32827da1b80cb8f
]
Aggregate(signatures) == 0xc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

# one signature that does not represent a curve point on E2
signatures = [0xc10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000]
Aggregate(signatures) == INVALID

# third signature does not represent a curve point on E2
signatures = [
  0xb6ed936746e01f8ecf281f020953fbf1f01debd5657c4a383940b020b26507f6076334f91e2366c96e9ab279fb5158090352ea1c5b0c9274504f4f0e7053af24802e51e4568d164fe986834f41e55c8e850ce1f98458c0cfc9ab380b55285a55,
  0xb23c46be3a001c63ca711f87a005c200cc550b9429d5f4eb38d74322144f1b63926da3388979e5321012fb1a0526bcd100b5ef5fe72628ce4cd5e904aeaa3279527843fae5ca9ca675f4f51ed8f83bbf7155da9ecc9663100a885d5dc6df96d9,
  0x948a7cb99f76d616c2c564ce9bf4a519f1bea6b0a624a02276443c245854219fabb8d4ce061d255af5330b078d5380681751aa7053da2c98bae898edc218c75f07e24d8802a17cd1f6833b71e58f5eb5b94208b4d0bb3848cecb075ea21bffff
]
Aggregate(signatures) == INVALID

`FastAggregateVerify`

The Eth2.0 specification tests for FastAggregateVerify should be used. However, an implementation for this proposal is not required to fulfill the test for infinity public key (one public key is the identity point of the curve). The behaviour for this input is undefined: The specifications for the proof of possession scheme, as well as the section "Public Key Registration and Proof of Possession" are demanding that PopVerify must return VALID for all public keys used as input for FastAggregateVerify, which is not the case for the mentioned Eth2.0 test.

Moreover, the following case should be covered:

# Invalid case: aggregate public key is identity element.
# The public keys are derived from the secret keys sk1=1 and sk2=r-1 where r
# is the order of the groups G1 and G2\. The signature is the correct aggregate
# signature of the given message for the two keys. The public keys are valid,
# but their sum (the aggregate public key) is the identity element in G1\.
# Therefore, signature validation must fail.
pks = [
  0x97f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb,
  0xb7f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb
]
message = 0xabababababababababababababababababababababababababababababababab
signature = 0xc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
FastAggregateVerify(pks, message, signature) == INVALID

`SkToPk`

sk = 0x263dbd792f5b1be47ed85f8938c0f29586af0d3ac7b977f21c278fe1462040e3
SkToPk(sk) == 0xa491d1b0ecd9bb917989f0e74f0dea0422eac4a873e5e2644f368dffb9a6e20fd6e10c1b77654d067c0618f6e5a7f79a

sk = 0x4dcffb43f4730ddb9364ef30a6b9b3e0343582e5df6bcd315f201cb3234adae3
SkToPk(sk) == 0xa6b6a639f7fa0b64ad3a93be965e9cc34e1d9d0f0427c14c38fc80934a937c5fa745a3cb285f64d4d1c06d0825504488

sk = 0x18a4b157ca6d83fe3081bbf6a63edbacf543a1c2a4b0befe68f912597f2c71c1
SkToPk(sk) == 0x884b52f84e801d2453edb023928c79125a5e4384c108dd8f17b7f2a20772c7dc4b9635602937df1b87d8b7284870c932

sk = 0x47b8192d77bf871b62e87859d653922725724a5c031afeabc60bcef5ff665138
SkToPk(sk) == 0xb301803f8b5ac4a1133581fc676dfedc60d891dd5fa99028805e5ea5b08d3491af75d0707adab3b70c6a6a580217bf81

`PopProve`

sk = 0x258787ef728c898e43bc76244d70f468c9c7e1338a107b18b42da0d86b663c26
PopProve(sk) == 0x84f709159435f0dc73b3e8bf6c78d85282d19231555a8ee3b6e2573aaf66872d9203fefa1ef700e34e7c3f3fb28210100558c6871c53f1ef6055b9f06b0d1abe22ad584ad3b957f3018a8f58227c6c716b1e15791459850f2289168fa0cf9115

sk = 0x47b8192d77bf871b62e87859d653922725724a5c031afeabc60bcef5ff665138
PopProve(sk) == 0x88bb31b27eae23038e14f9d9d1b628a39f5881b5278c3c6f0249f81ba0deb1f68aa5f8847854d6554051aa810fdf1cdb02df4af7a5647b1aa4afb60ec6d446ee17af24a8a50876ffdaf9bf475038ec5f8ebeda1c1c6a3220293e23b13a9a5d26

sk = 0x263dbd792f5b1be47ed85f8938c0f29586af0d3ac7b977f21c278fe1462040e3
PopProve(sk) == 0xb803eb0ed93ea10224a73b6b9c725796be9f5fefd215ef7a5b97234cc956cf6870db6127b7e4d824ec62276078e787db05584ce1adbf076bc0808ca0f15b73d59060254b25393d95dfc7abe3cda566842aaedf50bbb062aae1bbb6ef3b1f77e1

`PopVerify`

Valid cases:

pk = 0xb301803f8b5ac4a1133581fc676dfedc60d891dd5fa99028805e5ea5b08d3491af75d0707adab3b70c6a6a580217bf81
proof = 0x88bb31b27eae23038e14f9d9d1b628a39f5881b5278c3c6f0249f81ba0deb1f68aa5f8847854d6554051aa810fdf1cdb02df4af7a5647b1aa4afb60ec6d446ee17af24a8a50876ffdaf9bf475038ec5f8ebeda1c1c6a3220293e23b13a9a5d26
PopVerify(pk, proof) == VALID

pk = 0xa491d1b0ecd9bb917989f0e74f0dea0422eac4a873e5e2644f368dffb9a6e20fd6e10c1b77654d067c0618f6e5a7f79a
proof = 0xb803eb0ed93ea10224a73b6b9c725796be9f5fefd215ef7a5b97234cc956cf6870db6127b7e4d824ec62276078e787db05584ce1adbf076bc0808ca0f15b73d59060254b25393d95dfc7abe3cda566842aaedf50bbb062aae1bbb6ef3b1f77e1
PopVerify(pk, proof) == VALID

Invalid cases:

# public key is identity point in the group G1
pk = 0xc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
proof = 0xc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
PopVerify(pk, proof) == INVALID

# pk does not represent a point on the curve E1
pk = 0xa53d21a4cfd562c469cc81514d4ce5a6b577d8403d32a394dc265dd190b47fa9f829fdd7963afdf972e5e77854051f6f
proof = 0x88bb31b27eae23038e14f9d9d1b628a39f5881b5278c3c6f0249f81ba0deb1f68aa5f8847854d6554051aa810fdf1cdb02df4af7a5647b1aa4afb60ec6d446ee17af24a8a50876ffdaf9bf475038ec5f8ebeda1c1c6a3220293e23b13a9a5d26
PopVerify(pk, proof) == INVALID

# pk represents a point on the curve E1 but is NOT an element in the group G1
pk = 0x960003aaf1632b13396dbad518effa00fff532f604de1a7fc2082ff4cb0afa2d63b2c32da1bef2bf6c5ca62dc6b72f9c
proof = 0x88bb31b27eae23038e14f9d9d1b628a39f5881b5278c3c6f0249f81ba0deb1f68aa5f8847854d6554051aa810fdf1cdb02df4af7a5647b1aa4afb60ec6d446ee17af24a8a50876ffdaf9bf475038ec5f8ebeda1c1c6a3220293e23b13a9a5d26
PopVerify(pk, proof) == INVALID

# proof is not a point on the curve E2 (tampered proof)
pk = 0xa491d1b0ecd9bb917989f0e74f0dea0422eac4a873e5e2644f368dffb9a6e20fd6e10c1b77654d067c0618f6e5a7f79a
proof = 0xb803eb0ed93ea10224a73b6b9c725796be9f5fefd215ef7a5b97234cc956cf6870db6127b7e4d824ec62276078e787db05584ce1adbf076bc0808ca0f15b73d59060254b25393d95dfc7abe3cda566842aaedf50bbb062aae1bbb6ef3b1fffff
PopVerify(pk, proof) == INVALID

# proof is a point on the curve E2 but not the matching proof for pk
pk = 0xa491d1b0ecd9bb917989f0e74f0dea0422eac4a873e5e2644f368dffb9a6e20fd6e10c1b77654d067c0618f6e5a7f79a
proof = 0x88bb31b27eae23038e14f9d9d1b628a39f5881b5278c3c6f0249f81ba0deb1f68aa5f8847854d6554051aa810fdf1cdb02df4af7a5647b1aa4afb60ec6d446ee17af24a8a50876ffdaf9bf475038ec5f8ebeda1c1c6a3220293e23b13a9a5d26
PopVerify(pk, proof) == INVALID

`signBLS`

sk = 0x263dbd792f5b1be47ed85f8938c0f29586af0d3ac7b977f21c278fe1462040e3
tag = 0x4c534b5f54585f # ASCII-encoding of "LSK_TX_"
chainID = 0x9ee11e9df416b18bf69dbd1a920442e08c6ca319e69926bc843a561782ca17ee
message = 0xbeaf
signBLS(sk, tag, chainID, message) == 0xa6f889695b4ee393c6ede6af2215019cf9d7e004781b98ea12d6b227212126687ecde1c2a08e38e2d5c18eab2881879102e91ac5f0e9813126d6d68262af149ba6c25ffb88e6688fec49b5199cec863c0eb54110fdb6d92c6570f3ca9c1910b9

`verifyBLS`

pk = 0xa491d1b0ecd9bb917989f0e74f0dea0422eac4a873e5e2644f368dffb9a6e20fd6e10c1b77654d067c0618f6e5a7f79a
tag = 0x4c534b5f54585f # ASCII-encoding of "LSK_TX_"
chainID = 0x9ee11e9df416b18bf69dbd1a920442e08c6ca319e69926bc843a561782ca17ee
message = 0xbeaf
sig = 0xa6f889695b4ee393c6ede6af2215019cf9d7e004781b98ea12d6b227212126687ecde1c2a08e38e2d5c18eab2881879102e91ac5f0e9813126d6d68262af149ba6c25ffb88e6688fec49b5199cec863c0eb54110fdb6d92c6570f3ca9c1910b9
verifyBLS(pk, tag, chainID, message, sig) == True

`createAggSig` and `verifyAggSig`

We use the following list of keys for all test below:

KEYS_LIST = [
  0x9998f02d85e3851a430333350ed6cc1c0afbd72ee52cf8ad2f23d394f3937bfdc92e056dce713b9d45dac7b106d82883,
  0xa491d1b0ecd9bb917989f0e74f0dea0422eac4a873e5e2644f368dffb9a6e20fd6e10c1b77654d067c0618f6e5a7f79a,
  0x8f116ba0b305fb734405dd0968e255ad06a34d0cacfeece4c320502824da4a2ff90a978bfcffa1206ecae27f62bac645,
  0xb301803f8b5ac4a1133581fc676dfedc60d891dd5fa99028805e5ea5b08d3491af75d0707adab3b70c6a6a580217bf81,
  0xb53d21a4cfd562c469cc81514d4ce5a6b577d8403d32a394dc265dd190b47fa9f829fdd7963afdf972e5e77854051f6f,
  0xa6b6a639f7fa0b64ad3a93be965e9cc34e1d9d0f0427c14c38fc80934a937c5fa745a3cb285f64d4d1c06d0825504488,
  0xb0b2b9b812972e5e629810f0b841391933822d166995530770b5e875a73d945969986e3041a93db90160ea8510439c3e,
  0x95324a8c4a890e8c1e83c96c6c639254937c9c9cee789556606744b07e98292e292c8c150efd9506b0b5547fea3fdf9f,
  0x884b52f84e801d2453edb023928c79125a5e4384c108dd8f17b7f2a20772c7dc4b9635602937df1b87d8b7284870c932
]

`createAggSig`

pubKeySignaturePairs = [
  [
    pk = 0xa491d1b0ecd9bb917989f0e74f0dea0422eac4a873e5e2644f368dffb9a6e20fd6e10c1b77654d067c0618f6e5a7f79a,
    sig = 0x91347bccf740d859038fcdcaf233eeceb2a436bcaaee9b2aa3bfb70efe29dfb2677562ccbea1c8e061fb9971b0753c240622fab78489ce96768259fc01360346da5b9f579e5da0d941e4c6ba18a0e64906082375394f337fa1af2b7127b0d121
  ],
  [
    pk = 0xb301803f8b5ac4a1133581fc676dfedc60d891dd5fa99028805e5ea5b08d3491af75d0707adab3b70c6a6a580217bf81,
    sig = 0x9674e2228034527f4c083206032b020310face156d4a4685e2fcaec2f6f3665aa635d90347b6ce124eb879266b1e801d185de36a0a289b85e9039662634f2eea1e02e670bc7ab849d006a70b2f93b84597558a05b879c8d445f387a5d5b653df
  ],
  [
    pk = 0xb53d21a4cfd562c469cc81514d4ce5a6b577d8403d32a394dc265dd190b47fa9f829fdd7963afdf972e5e77854051f6f,
    sig = 0xae82747ddeefe4fd64cf9cedb9b04ae3e8a43420cd255e3c7cd06a8d88b7c7f8638543719981c5d16fa3527c468c25f0026704a6951bde891360c7e8d12ddee0559004ccdbe6046b55bae1b257ee97f7cdb955773d7cf29adf3ccbb9975e4eb9
  ]
]
createAggSig(KEYS_LIST, pubKeySignaturePairs) == [0x1a00, 0x9712c3edd73a209c742b8250759db12549b3eaf43b5ca61376d9f30e2747dbcf842d8b2ac0901d2a093713e20284a7670fcf6954e9ab93de991bb9b313e664785a075fc285806fa5224c82bde146561b446ccfc706a64b8579513cfc4ff1d930]

pubKeySignaturePairs = [
  [
    pk = 0xb0b2b9b812972e5e629810f0b841391933822d166995530770b5e875a73d945969986e3041a93db90160ea8510439c3e,
    sig = 0x996297e8b63de37e207ee092e769af55b38755472423260b2d4c1312957f38e8d9cce0c5ffe0142b7b4492334feaefc9142f250305aa6f352d8d2a0f85d9706a7a0cd5e5e4055aafe775b97705e46e815b1a21dc2682450e71dbd79ad89db5c0
  ],
  [
    pk = 0x884b52f84e801d2453edb023928c79125a5e4384c108dd8f17b7f2a20772c7dc4b9635602937df1b87d8b7284870c932,
    sig = 0xb83429c1d6c890dbd8fa21c4c8489eb33c3004252a4c8524e4e7742a57d172d076a7def01eff1741af9971ce562f01e505dbe4c654572b5ccb4db213ceb941809fa5dd0732e8f06586ac9274b5f417808f6d58f3af5966a98117149e6bf54458
  ]
]
createAggSig(KEYS_LIST, pubKeySignaturePairs) == [0x4001, 0x89a3b2642b285b129ff9196fa310eea2fb77468b3919f6530ebef402a5c7d589b3d6cfa0bb884b38b365047a7a6a216614a72941479d2753438b3657a430318f43dbfd895632db1c23d988097115fe1d0c4aa5d2ef42da50b8027bd2e410d781]

`verifyAggSig`

aggregationBits = 0x4001
signature = 0x89a3b2642b285b129ff9196fa310eea2fb77468b3919f6530ebef402a5c7d589b3d6cfa0bb884b38b365047a7a6a216614a72941479d2753438b3657a430318f43dbfd895632db1c23d988097115fe1d0c4aa5d2ef42da50b8027bd2e410d781
tag = 0x4c534b5f43455f # ASCII-encoding of "LSK_CE_"
chainID = 0x9ee11e9df416b18bf69dbd1a920442e08c6ca319e69926bc843a561782ca17ee
message = 0xbeaf
verifyAggSig(KEYS_LIST, aggregationBits, signature, tag, chainID, message) == True

Files

lip-0038.md

Latest commit

History