An efficient and privacy-preserving asynchronous payment method based on blockchain

Abstract

The application discloses a kind of high efficiency and privacy protection asynchronous payment method based on block chain, belong to the field of block chain privacy protection technology.This method supports the case where multiple transactions are generated in the system to protect user privacy.The signature of all transactions of the user is aggregated into a single aggregate signature for aggregate verification.This method extends the single verification of locally verifiable signature to subset verification.Later, without knowing all user transactions, the subset of transactions that need to be delayed can be decompressed from this aggregate signature.The method deploys a server to provide a time key so that the delayed payment service provider can only rewrite the on-chain transaction at a specific point in time.Follow-up changes to the transaction through the trapdoor of chameleon hashing only require node network verification, saving time and arithmetic capability compared to generating a new transaction.The method has practical security features and more acceptable efficiency in terms of computational complexity and communication overhead.

Description

Technical Field

[0001] This invention relates to an efficient and privacy-preserving blockchain-based asynchronous payment method, belonging to the field of blockchain privacy protection technology. Background Technology

[0002] Unforeseen events and other factors can have unpredictable but not surprising impacts on e-commerce. With limited close-range interaction, consumers have extra disposable income, some of which invariably flows into the e-commerce market. In light of this, fintech companies have quickly moved to make this a more attractive proposition for consumers – the Buy Now, Pay Later option, or BNPL for short. This service allows consumers to pay in installments, typically several equal parts, and receive the product immediately. BNPL providers will eventually integrate with digital wallets, including cryptocurrency wallets. After seeing how digital assets and blockchain technology have penetrated most businesses, it's not surprising to see BNPL platforms also enabling their customers to use cryptocurrencies. Klarna's customers will be able to purchase digital assets. Affirm has added cryptocurrency, allowing customers to buy and sell digital currencies on their app.

[0003] Existing blockchain-authorized BNPL activities, such as the Pay Later Project (PLP), Atpay, and Apenow, all execute through smart contracts to provide deferred payment services to consumers. Smart contracts allow for internal constraints requiring consumers to pay BNPL service providers at specific times. However, the transparency of data on the blockchain leads to serious privacy issues. Because transactions provided by consumers to smart contracts are visible to all nodes in the blockchain network, deferred payment transactions are as public as regular transactions. This is unacceptable in real-world e-commerce applications, as malicious third parties could analyze consumers' finances based on their deferred payment transactions. Furthermore, the additional time overhead incurred by newly created deferred payment transactions undermines the scalability of blockchain-supported BNPL services. Every deferred payment transaction generated by a consumer appears as a new transaction in the blockchain network, and these newly generated transactions must again undergo a series of processes, including acceptance, mining, propagation, and verification by the node network. This process requires significant processing power and time, placing a burden on the blockchain, especially for installment payments. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies and, to solve the technical problems of privacy protection and efficiency faced by existing blockchain asynchronous payment systems, to creatively propose a highly efficient and privacy-preserving asynchronous payment method based on blockchain. This method supports efficient asynchronous payments without disclosing user privacy.

[0005] The innovation of this method lies in protecting user privacy even when a user generates multiple transactions within the system. All user transaction signatures are aggregated into a single aggregate signature for aggregate verification. This method extends single verification of locally verifiable signatures to subset verification. Later, without the service provider knowing all user transactions, the subset of transactions requiring deferred payment can be decompressed from this aggregate signature. This method deploys a server to provide time keys, ensuring that deferred payment service providers can only rewrite on-chain transactions at specific points in time. Subsequent modifications to transactions via a chameleon hash trapdoor require only node network verification, saving time and arithmetic resources compared to generating new transactions. This method offers practical security features and acceptable efficiency in terms of computational complexity and communication overhead.

[0006] It should be noted that the goal of this invention is to construct an asynchronous payment system with the following characteristics. First, it protects the privacy of user transactions, preventing malicious third parties from abusing their deferred payment transaction information. Second, it has reasonable performance overhead and scalability as the number of users increases. A key foundation of existing work on deferred payments is smart contracts, which monitor the behavior of consumers and BNPL service providers through internal constraints. However, since smart contracts are public, anyone in the blockchain network can observe their inputs, execution, and outputs. Therefore, smart contracts are no longer sufficient as they are unsuitable for protecting the privacy of user transactions. In this work, this invention proposes a deferred payment paradigm based on public-key cryptography using locally verifiable signatures to guarantee user privacy. Furthermore, to maintain scalability, a chameleon hash trapdoor is used to modify deferred payment transactions without creating additional new transactions, thereby improving the efficiency of the blockchain. However, enabling BNPL service providers to modify transactions at specific times remains challenging without using smart contracts. To address this issue, this invention also combines timed release cryptography and an editable blockchain to support deferred payments. Specifically, by deploying servers that provide keys, providers of deferred payment services can only modify transactions at specific time intervals.

[0007] To achieve the above objectives, the present invention adopts the following technical solutions.

[0008] First, the relevant concepts will be explained.

[0009] Definition 1: Certificate Authority

[0010] The certificate authority is the blockchain administrator, who initializes the system and broadcasts system parameters to other participants.

[0011] Definition 2: User

[0012] Users are participants on the blockchain, and they can choose between two types of payment methods. One is instant payment, through which transactions cannot be overwritten. The other is asynchronous payment, which allows a designated provider to rewrite the transaction content.

[0013] Definition 3: Provider

[0014] Providers are participants on the blockchain who offer asynchronous payment services to users and collect their fees after a specified period.

[0015] Definition 4: Server

[0016] The server is a participant on the chain; it broadcasts specific time points and provides additional auxiliary information to the provider.

[0017] Definition 5: Miner

[0018] Miners are participants on the chain, independent yet interconnected nodes. They verify transactions and add them to the existing distributed public ledger.

[0019] In this invention, certificate authorities are considered fully trusted, and miners are considered majority trusted, just as in a normal blockchain system. Adversaries are categorized into three types based on their capabilities: intentional but curious providers, honest but curious cloud users, and external adversaries. A detailed description of the threat model follows:

[0020] Intentional but curious provider: The provider acts as both receiver and provider in the system. As a semi-curious participant, the provider expects to decrypt information outside of the expected time interval and attempts to correct erroneous transaction amounts.

[0021] The Cloud: Honest Yet Curious: The cloud server holds the private key and is responsible for providing time keys and auxiliary information at fixed intervals throughout the process. The cloud is semi-trusted and follows the protocol, but may attempt to launch attacks to compromise confidential information.

[0022] External attackers: External attackers are neither the intended recipients nor aware of the private key held by the cloud server, but they can eavesdrop on system communications and obtain the password text by launching ciphertext-only attacks.

[0023] An efficient and privacy-preserving asynchronous payment method based on blockchain includes the following steps:

[0024] Step 1: System initialization. Specifically, this includes system settings, user key generation, provider key generation, and server key generation.

[0025] In this system setup, the Trusted Center (CA) acts as a trusted key management center; the CA is fully trusted, and the communication channels between the CA and any other entity are secure. During user key generation, the CA generates a master key and public parameters for each user.

[0026] Users generate their own key pairs using the master key and public parameters provided by the trusted center.

[0027] In provider key generation, the trusted center generates the master key and public parameters for it;

[0028] The provider generates its own key pair using the master key and public parameters provided by the trusted center.

[0029] In server key generation, a trusted center generates the master key and public parameters for it.

[0030] The server generates its own key pair using the master key and public parameters provided by the trusted center.

[0031] Step 2: Transaction generation.

[0032] During this phase, each user generates two types of transactions: editable transactions and immutable transactions. Editable transactions allow for modification at a specific time. Afterward, the server generates a time key and auxiliary information. Users can generate ordinary transactions as in a traditional immutable blockchain, or they can use this scheme to generate deferred transactions.

[0033] In normal transactions, users generate transactions and corresponding signatures using keys and traditional hash functions;

[0034] For deferred transactions, users generate transactions and signatures using a key and a chameleon hash function;

[0035] By generating aggregate signatures, users spread public keys, transaction sets, and aggregate signatures to the blockchain ecosystem;

[0036] The server generates a time key and auxiliary information, which will be released at a specific time for the provider to verify the signature and perform decryption.

[0037] Step 3: Transaction rewriting.

[0038] During this stage, the provider decompresses a subset of transaction signatures requiring asynchronous payment and performs decryption based on the time key and auxiliary information provided by the server. Editable transactions can be rewritten by a designated provider.

[0039] The provider holds the time key and auxiliary information provided by the server, and obtains the key and the subset of transactions that need to be rewritten. The provider then uses this key to rewrite the transactions.

[0040] The provider generates a random number and a signature, and then broadcasts the public key, transaction, and signature.

[0041] Step 4: Transaction verification.

[0042] Users can generate two types of transactions in the blockchain. Therefore, two types of verification are considered at this stage: immutable and editable transaction verification.

[0043] The immutable transaction verification process involves miners receiving a set of immutable transactions associated with a user's public key, a transaction set, and an aggregate signature. Miners verify these transactions by running an immutable blockchain verification process. If verification is successful, the miner adds the corresponding transaction to a block; otherwise, the miner rejects the transaction.

[0044] Editable transaction verification: After receiving the user's public key, transaction, and associated editable transaction signature, the miner verifies the transaction. If verification is successful, the miner will rewrite a local copy of the transaction; otherwise, the miner will reject the transaction.

[0045] Beneficial effects

[0046] Compared to existing technologies, this method has a communication cost in the KB range and reduces time overhead by more than four times compared to locally verifiable signatures and the Go-Ethereum private test network. Attached Figure Description

[0047] Figure 1 This is a schematic diagram of the method of the present invention. Detailed Implementation

[0048] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments.

[0049] like Figure 1 As shown, an efficient and privacy-preserving asynchronous payment method based on blockchain includes the following steps:

[0050] Step 1: System Settings.

[0051] Specifically, given the system's security parameter 1 λ Perform the following steps:

[0052] Generate common parameters:

[0053]

[0054] pp CH ←CH.Setup(1 λ );

[0055] hk←HGen(1 λ );

[0056] Return pp = (pp DS ,pp CH (,hk);

[0057] Generate master key pair:

[0058] Select random number

[0059]

[0060] sk α =(pp DS ,α);

[0061] Choose a collision-resistant hash function H:{0,1}*→Z p ;

[0062] Returns msk=sk α and mpk = (pk α H).

[0063] Among them, pp DS The common parameters of the digital signature algorithm are represented by p, where p represents the order and G represents a group of order p. T Let pp denote the generating group of G, and g denote the generator of G; CH The common parameters of the Chameleon Hash algorithm are represented by CH; hk represents the sampled hash value of the common parameters; HGen represents the hash generation function; pp represents the common parameters; pk represents the common parameters. α Represents the public key. These are the components of the public key; B represents the upper limit of aggregable signatures; sk α This represents the private key. Z represents a bilinear mapping. p Represents the integer field; Z represents p The non-zero element; msk represents the master public key.

[0064] User key generation.

[0065] Specifically, given the common parameter pp, perform the following steps:

[0066] Initialize the signing key pair:

[0067]

[0068]

[0069] Initialize the chameleon hash key pair:

[0070] (sk h ,pk h )←CH.KeyGen(pp CH );

[0071] Initialize the timed release key pair:

[0072] pk tre =(sg,sα′g);

[0073] Generate local verification key:

[0074] pk local =(Π,hk,g α );

[0075] Return sk u =(sk β ,sk tre ) and pk u =(pk β ,pk h ,sk tre ,pk local ).

[0076] Among them, sk β It is the user's signature private key, PK β It is the user's signature public key, β and α′ are generator, sk h It is a chameleon hash private key, PK h It is a chameleon hash public key, sk tre It releases the private key periodically, sk tre It is a timed release of the public key, PK. local It is the local verification key, Π is the bilinear group parameter, and sk u It is the user's private key, PK u It is the user's public key.

[0077] Provider key generation: Given the public parameter pp, perform the following steps:

[0078] Initialize the signing key pair:

[0079]

[0080]

[0081] Return sk p =sk p′ and PK p =pk p′ .

[0082] Among them, skp′ It is the provider's signing private key, pk p′ It is the provider's signing public key, μ is generator, It is a component parameter of the provider's signing public key, sk p It is the provider's private key, pk p It is the provider's public key.

[0083] Server key generation: Given the public parameter pp, perform the following steps:

[0084] Initialize key pair:

[0085]

[0086] pk α′ =(pp DS ,g←G,Z=α′g);

[0087] Return sk S =sk α′ and PK S =Z.

[0088] Among them, sk α′ It is the server's signature private key, PK. α′ It is the server's signature public key, α′ is The generator, Z = α′g, is a component parameter of the server's signature public key, sk S It's the server's private key, PK. S It is the server's public key.

[0089] Step 2: Transaction creation.

[0090] Specifically, given the master public key mpk and the key sk u and SK h Decryption time T and transaction identifier ID and its content tx ID The message. Perform the following steps:

[0091] Select a random number r;

[0092] Calculate the hash value:

[0093] h←CH.Hash(pk h ,(ID,tx ID ),r);

[0094] Generate signature:

[0095]

[0096] Check if the equations are equal:

[0097]

[0098] If they are equal, randomly select r0 and calculate r0g and r0sα′g;

[0099] Calculate parameter K:

[0100]

[0101] Calculate the ciphertext:

[0102]

[0103] Returns the hash value h, the random number r, and the signature σ. ID And ciphertext C.

[0104] Step 3: Signature aggregation.

[0105] Specifically, given the public key pk u and signature σ i Perform the following steps:

[0106] Determine if the equations are equal:

[0107] e(σ,g α g h ) = e(g,g);

[0108] If they are equal, calculate the parameters:

[0109]

[0110] Calculate the aggregate signature:

[0111]

[0112] Otherwise, return the failure symbol ⊥.

[0113] Step 4: Extraction stage.

[0114] Specifically, given the public key pk S and PK u key sk S Transaction set {tx i} i∈[1] Perform the following steps:

[0115] Determine if the equations are equal:

[0116]

[0117] If they are equal, generate auxiliary information:

[0118]

[0119]

[0120] The parameters are obtained by calculating the polynomial P.

[0121]

[0122] calculate:

[0123]

[0124]

[0125] Output auxiliary information:

[0126] aux j =(aux j,1 ,aux j,2 );

[0127] Otherwise, return the failure symbol ⊥.

[0128] Where T represents the decryption time, aux j,1 and aux j,2 Auxiliary information j Components Let l represent the parameters in polynomial P, and l represent the number of aggregated messages.

[0129] Step 5: Decryption phase.

[0130] Specifically, given the public key pk S and PK u Aggregated signature Including the transaction identifier ID and its content tx ID The message, random number r, auxiliary information aux, ciphertext C, and time key k t Perform the following steps:

[0131] The message hash set is calculated as follows:

[0132] {h m} i ←CH.Hash(pk h ,{m} i );

[0133] Determine if the equations are equal:

[0134]

[0135] e(g α ,aux1)=e(g,aux2)

[0136] A return value of 1 indicates that the signature is valid;

[0137] The ciphertext C is parsed as:

[0138]

[0139] Calculate parameters K′ and K:

[0140]

[0141] Through calculation Restore sh h ;

[0142] Return sk h ;

[0143] Otherwise, return the failure symbol ⊥.

[0144] Where m represents the message, ρ represents the composition parameters of the ciphertext C, and H1 and H2 represent the two hash functions.

[0145] Step 6: Adaptive Phase.

[0146] Specifically, given the public key mpk and the private key sk p This includes the transaction identifier ID and its content tx ID The message contains a hash value h, a random number r, and includes the transaction identifier ID and its content tx′. ID The message. Perform the following steps:

[0147] Calculate the random number r':

[0148] r′←CH.Adapt(sk h ,(ID,tx 1D ),h,r,(ID,tx′ ID ));

[0149] Generate signature:

[0150]

[0151] Return r′ and σ′.

[0152] Here, CH.Adapt represents the adaptive algorithm of Chameleon Hash.

[0153] Step 7: Verification phase.

[0154] Specifically, given the public keys mpk and pk u This includes the transaction identifier ID and its content tx ID The message, hash value h, random number r, signature σ ID Perform the following steps:

[0155] If all of the following conditions are true, then return b = 1:

[0156] CH.Verify(pk h ,(ID,tx ID ),h,r′)=1;

[0157]

[0158] e(σ′,g i g h′ ) = e(g,g).

[0159] Otherwise, return b=0.

Claims

1. A blockchain-based, efficient, and privacy-preserving asynchronous payment method, characterized in that: Certificate authorities are considered to be fully trusted, miners are considered to be mostly trusted, and adversaries are divided into three categories based on their capabilities: intentional but curious providers, honest but curious cloud users, and external adversaries. Intentional but curious providers: Providers play the roles of both receivers and providers in the system; As a semi-curious participant, the provider expects to decrypt the information beyond the anticipated time interval and attempts to correct the erroneous transaction amount; The honest yet curious cloud: The cloud server holds the private key and is responsible for providing time keys and auxiliary information at fixed intervals throughout the process; the cloud is semi-trusted and follows the protocol, but will attempt to launch attacks to compromise confidential information; External attackers: External attackers are neither the intended recipients nor aware of the private key held by the cloud server, but they can eavesdrop on system communications and obtain the password text by launching ciphertext-only attacks; Step 1: System initialization, including system settings, user key generation, provider key generation, and server key generation; In the system setup, the trusted central authority acts as a trusted key management center; the trusted central authority is completely trusted, and the communication channel between the trusted central authority and any other entity is secure; in user key generation, for each user, the trusted central authority generates a master key and public parameters. Users generate their own key pairs using the master key and public parameters provided by the trusted center. In provider key generation, the trusted center generates the master key and public parameters for it; The provider generates its own key pair using the master key and public parameters provided by the trusted center. In server key generation, a trusted center generates the master key and public parameters for it. The server generates its own key pair using the master key and public parameters provided by the trusted center. Step 2: Transaction generation; During this phase, each user generates two types of transactions: editable transactions and immutable transactions. Editable transactions provide the ability to be modified at a specific time. Afterward, the server generates time keys and auxiliary information. In normal transactions, users generate transactions and corresponding signatures using keys and traditional hash functions; In deferred transactions, users generate transactions and signatures using a key and a chameleon hash function; By generating aggregate signatures, users spread public keys, transaction sets, and aggregate signatures to the blockchain ecosystem; The server generates a time key and auxiliary information, which will be published at a specific time for the provider to verify the signature and perform decryption. Step 3: Transaction rewriting; During this stage, the provider decompresses the subset of transaction signatures that require asynchronous payment and performs decryption operations based on the time key and auxiliary information provided by the server; The provider holds the time key and auxiliary information provided by the server, and obtains the key and the subset of transactions that need to be rewritten; then, the provider uses this key to rewrite the transactions; The provider generates a random number and a signature, and then broadcasts the public key, transaction, and signature. Step 4: Transaction Verification; At this stage, two types of verification are considered: immutable and editable transaction verification; The immutable transaction verification process involves the miner receiving a set of immutable transactions associated with the user's public key, transaction set, and aggregate signature. The miner verifies the transactions by running an immutable blockchain verification process. If the verification is successful, the miner adds the corresponding transaction to the block; otherwise, the miner rejects the transaction. Editable transaction verification: After receiving the user's public key, transaction, and signature associated with the editable transaction, the miner verifies the transaction. If the verification is successful, the miner will rewrite the local copy of the transaction; otherwise, the miner will reject the transaction.

2. The efficient and privacy-preserving asynchronous payment method based on blockchain as described in claim 1, characterized in that, Editable transactions can be rewritten by a designated provider.

3. The efficient and privacy-preserving asynchronous payment method based on blockchain as described in claim 1, characterized in that, The system settings are as follows: Given the system's security parameters 1 λ Perform the following steps: Generate common parameters: pp CH ←CH.Setup(1 λ ); hk←HGen(1 λ ); Return pp = (pp DS ,pp CH (,hk); Generate master key pair: Select random number sk α =(pp DS ,a); Choose a collision-resistant hash function slice: {0, 1}*→Z p ; Returns msk=sk α and mpk = (pk α H); Among them, pp DS The common parameters of the digital signature algorithm are represented by p, where p represents the order and G represents a group of order p. T Let pp denote the generating group of G, and g denote the generator of G; CH The common parameters of the Chameleon Hash algorithm are represented by CH; hk represents the sampled hash value of the common parameters; HGen represents the hash generation function; pp represents the common parameters; pk represents the common parameters. α Represents the public key. These are the components of the public key; B represents the upper limit of aggregable signatures; sk α This represents the private key. Z represents a bilinear mapping. p Represents the integer field; Z represents p The non-zero element; msk represents the master public key; User key generation is as follows: Given the common parameter pp, perform the following steps: Initialize the signing key pair: Initialize the chameleon hash key pair: (sk h ,pk h )←CH.KeyGen(pp CH ); Initialize the timed release key pair: pktre=(sg,sα′g); Generate local verification key: pk local =(∏hk,g α ); Return sk u =(sk β ,sk tre ) and pk u =(pk β , pk h , pk tre , pk local ); Among them, sk β It is the user's signature private key, PK β It is the user's signature public key, β and α′ are generator, sk h It is a chameleon hash private key, PK h It is a chameleon hash public key, sk tre It releases the private key periodically, PK. tre It is a timed release of the public key, PK. local It is the local verification key, ∏ is the bilinear group parameter, and sk u It is the user's private key, PK u It is the user's public key; The provider key is generated as follows: Given the common parameter pp, perform the following steps: Initialize the signing key pair: Return sk p =sk p′ and PK p =pk p′ ; Among them, sk p′ It is the provider's signing private key, pk p′ It is the provider's signing public key, μ is generator, It is a component parameter of the provider's signing public key, sk p It is the provider's private key, pk p It is the provider's public key; The server key is generated as follows: Specifically, given the common parameter pp, perform the following steps: Initialize key pair: pk α′ =(pp DS ,g←G,Z=α′g); Return sk S =sk α ′ and pk S =Z; Among them, sk α′ It is the server's signature private key, PK. α′ It is the server's signature public key, α′ is The generator, Z = α′g, is a component parameter of the server's signing public key, sk S It's the server's private key, PK. S It is the server's public key; The transaction is created as follows: Given the master public key mpk and the key sk u and SK h Decryption time T and transaction identifier ID and its content tx ID The message; perform the following steps: Select a random number r; Calculate the hash value: h←CH.Hash(pk h ,(ID,tx ID ),r); Generate signature: Check if the equations are equal: If they are equal, randomly select r0 and calculate r0g and r0sα′g; Calculate parameter K: Calculate the ciphertext: Returns the hash value h, the random number r, and the signature σ. ID And ciphertext C; Step 6: Signature aggregation; Specifically, given the public key pk u and signature σ i Perform the following steps: Determine if the equations are equal: e(σ,g α g h )=e(g,g); If they are equal, calculate the parameters: Calculate the aggregate signature: Otherwise, return the failure symbol ⊥; During the extraction phase, given the public key pk S and PK u key sk S Transaction set {tx i } i∈[1] Perform the following steps: Determine if the equations are equal: If they are equal, generate auxiliary information: The parameters are obtained by calculating the polynomial P. calculate: Output auxiliary information: to j (to j，1 ,to j，2 ); Otherwise, return the failure symbol ⊥; Where T represents the decryption time, aux j，1 and aux j，2 Auxiliary information j Components Let l represent the parameters in polynomial P, and l represent the number of aggregated messages. During the decryption phase, given the public key pk S and PK u Aggregated signature Including the transaction identifier ID and its content tx ID The message, random number r, auxiliary information aux, ciphertext C, and time key k t Perform the following steps: The message hash set is calculated as follows: {h m } i ←CH.Hash(pk h ,{m} i ); Determine if the equations are equal: e(g α ,aux1)=e(g,aux2) A return value of 1 indicates that the signature is valid; The ciphertext C is parsed as: Calculate parameters K′ and K: Through calculation Restore sk h ; Return sk h ; Otherwise, return the failure symbol ⊥; Where m represents the message, ρ represents the composition parameters of the ciphertext C, and H1 and H2 represent the two hash functions; In the adaptive phase, given the public key mpk and the private key sk p This includes the transaction identifier ID and its content tx ID The message contains a hash value h, a random number r, and includes the transaction identifier ID and its content tx′. ID The message; perform the following steps: Calculate the random number r′: r′←CH.Adapt(sk h ,(ID,tx 1D ),h,r,(ID,tx′ ID )); Generate signature: Return r′ and σ′; Wherein, CH.Adapt represents the adaptive algorithm of Chameleon Hash; During the verification phase, given the public key mpk and pk... u This includes the transaction identifier ID and its content tx ID The message, hash value h, random number r, signature σ ID Perform the following steps: If all of the following conditions are true, then return b = 1: CH.Verify(pk h ,(ID,tx ID ),h,r′)=1; e(σ′,g i g h′ )=e(g,g); Otherwise, return b=0.

Images