Next Article in Journal
PudgyTurtle Mode Resists Bit-Flipping Attacks
Previous Article in Journal
Neural Crypto-Coding Based Approach to Enhance the Security of Images over the Untrusted Cloud Environment
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

LACT+: Practical Post-Quantum Scalable Confidential Transactions

School of Computer Science, Queensland University of Technology, Brisbane 4000, Australia
*
Author to whom correspondence should be addressed.
Cryptography 2023, 7(2), 24; https://doi.org/10.3390/cryptography7020024
Submission received: 17 February 2023 / Revised: 12 April 2023 / Accepted: 24 April 2023 / Published: 8 May 2023

Abstract

:
A “confidential monetary value” carries information about the real monetary value but does not disclose it. Post-quantum private blockchains with confidential monetary values—large-sized blockchains with large verification times—have the least scalability because they need to save and verify more information than those with “plain-text monetary values”. High scalability is an essential security requirement for decentralized blockchain payment systems because the more honest peers who can afford to verify the blockchain copies are, the higher the security. We propose a quantum-safe transaction protocol for confidential monetary blockchains, LACT+ (Lattice-based Aggregable Confidential Transactions), which is more scalable than previous post-quantum confidential blockchains, i.e., many input/output transactions with logarithmic sized complexity.

1. Introduction

Blockchain-based cryptocurrencies have become popular due to the security of decentralization, i.e., there is no single point of failure and no single authority in control. However, decentralization has a downside because it requires many honest peers to keep a copy of the blockchain and constantly verify it. Otherwise, malicious peers can alter the cash system for their gain. The number of honest peers mainly depends on the system’s scalability (size and verification time) because peers have to spend their resources like space and computational power to save and verify blockchains. Despite the security and privacy, “quantum-safe” and “confidential” cryptocurrencies have the least scalability because they need special computations and algorithms that require more space and more computational power. This paper introduces a more scalable quantum-safe confidential blockchain transaction method, LACT+, where we only need 5.7 KB to store a confidential monetary value, whereas refs. [1,2] need >30 KB and 9.6 KB, respectively.
Confidential Transactions. Cryptocurrencies are public records accessible by anyone. Even though pseudonyms are commonly used, refs. [3,4,5,6,7,8,9] show that these identities can be linked to real identities. Therefore, maintaining monetary amounts in “plain text” is a major privacy concern. Confidential transactions (CT) solve this problem by keeping monetary values confidential yet providing tools to verify that hidden coin amounts are not negative, stolen, or double spent. However, this enhanced privacy comes at the cost of scalability because these tools generate proofs that should be stored in the blockchain, and verification of these proofs takes more computational power than simply checking plain-text numbers.
Aggregable Transactions. A transaction takes a set of current coins, changes their ownership, and updates the blockchain with that information. Hence, blockchain verifiers need to know “who has coins? Furthermore, are they only spending what they have?”. Hence, they mainly need to know about current coins and who has them, not who had them. As the name implies, aggregable transactions aggregate multiple transactions into a smaller transaction, and this aggregated transaction shows “who has coins after those transactions”. For example, if P 1 sends coins to P 2 and P 3 , and P 2 sends their coins to P 4 , the aggregated transaction shows that P 3 and P 4 have coins, and forgets that P 1 and P 2 had coins. Hence, an aggregable blockchain is a single aggregated transaction of all previous transactions. This forgotten information reduces the size and verification time and improves scalability significantly. However, previous aggregable blockchains refs. [1,2,10,11,12,13,14] cannot prove that the aggregated blockchain is the aggregated version of the “right” or the consensus accepted blockchain (more theoretically, previous aggregated blockchains are not “immutable”). Hence, despite the high scalability, “peers” have to download and verify the complete blockchain.
Quantum Safety. Recent developments in quantum computing, e.g., IBM’s roadmap ref. [15], show that quantum adversaries can be a real threat even to the current standardized security level in the near future. Post-quantum (we use “post-quantum”, “quantum-safe”, or “quantum-resistant” to describe plausibly quantum-secure protocols) payments started receiving attention because many established decentralized payments are based on the discrete-logarithmic problem (DLP), which is vulnerable to quantum adversaries. Not only transparent payments, but many aggregable confidential transactions refs. [10,11,12,13,14] are also based on DLP and equally vulnerable to quantum adversaries. Ref. [1,2] introduced two quantum-safe aggregable confidential transactions that are based on the short integer solution problem (SIS) and the modular SIS. However, ref. [1] has an inefficient proof system and the transactions of ref. [2] are limited to a maximum two inputs and two outputs.
This paper proposes an immutable aggregable confidential transaction protocol, LACT+ (Lattice-based Aggregable Confidential Transactions), based on approximate modular SIS (approximate SIS), to provide post-quantum security with practical scalability.

1.1. Related Work

Let us explain the key components of decentralized aggregable payments that lead to LACT+. Note that here, we sketch a common protocol that describes refs. [1,2,10,11,12,13,14] generally regardless of their “hardness assumption”, e.g., they can be based on DLP or SIS.
Digital Coins from Cryptographic View. Decentralized payment systems store monetary values as digital coins where each coin represents some amount of the smallest unit (e.g., the number of cents). These digital coins are stored in the public domain, where anyone has access. Therefore, coins need a security mechanism to prevent theft. Let there be a digital signature scheme that signs messages when its key card (secret signing key) is presented and the public key of the key card tells anyone whether it produced the signed message or not. Users attach these public keys to their digital coin(s) and securely keep the key card(s) with them. Wherever they want to spend the coins, they create a signed receipt, and they send the signed receipt to the network. Because the public key verifies the signed receipts without key cards, the whole network can verify that the legitimate owner is spending the coin. However, once the coins are sent, the new owner attaches a new public key to the coins where only he/she has a key card to it. In that way, after sending the coins, previous owners cannot take coins back because they do not have new key cards. The signed receipts are known as digital signatures.
Transparent Digital Coin Transactions. Users create transactions when they want to send digital coins or receive them. A transaction turns a set of current unspent coins (inputs) into spent coins and produces new unspent coins (outputs). However, a transaction should not illegally generate coins—the input coins should be equal to the output coins—or allow coins to be stolen. Therefore, each transaction has a header that proves the total coin amount summation (1. summation proof) and the digital signatures of coins (2. ownership proofs). In transparent coin transactions, the summation proof is simple and only contains the number of supplied coins (e.g., mining reward) and transaction fee because the verifiers can add the numbers and can check that input coins and the supplied coins are equal to the output coins and the transaction fee. However, the ownership proof is linear in the number of unique public keys of inputs, i.e., the ownership proof of the transaction is the set of signatures of all unique input public keys refs. [16,17].
Confidential Digital Coins. Instead of plain-text coins, confidential payment systems keep coins’ value hidden. We call them “confidential coins”. A confidential coin is a commitment for the coin amount and a range proof to prove that the hidden coin amount is in the accepted range, e.g., [ 0 ,   2 64 ) . A commitment can be viewed as a safe box that hides coins and is locked with a secret key (a.k.a., blinding key or the masking key). Yet, anyone can verify that the hidden coin amount is in the accepted range using the cryptographic range proof (even though proving the range of physical coins is impossible without opening the safe-box, it is actually possible with digital coin commitments!). These range proofs are called “zero-knowledge proofs” because they do not reveal anything other than the designated knowledge statement. In this case, the proofs only show that values are in the accepted range.
Confidential Transactions (CT). There are two categories of CTs; (1) Ring CTs which obfuscate the senders and receivers with shadow participants refs. [18,19,20,21,22] and (2) Aggregable CTs which allow aggregating multiple transactions into one transaction by removing spent coin records refs. [1,2,10,11,12,13,14]. In general, confidential transactions are similar to the transparent transactions but with the following main differences,
  • they transact confidential coins, and
  • their headers contain zero-knowledge summation proofs to show that hidden input coins are equal to hidden output coins, along with plain-text supplied coins and fees.
However, Ring CTs and aggregable CTs have different ownership proofs. Ring CTs’ ownership proofs are threshold signatures or one/many-out-of-many proofs that are either linear or logarithmic in the number of unique participants, whereas, aggregable CTs’ reuse their summation proofs as ownership proofs ref. [10]. Due to this reuse and removing spent coin records, aggregable CTs provide better scalability than Ring CTs. From now on, we use CT for aggregable CTs.
Ownership + Summation Proofs. Let there be an additively homomorphic commitment u = com ( v , k ) that hides and binds ( v , k ) when v is the coin amount and k is the secret masking key. Here, “binding” means that it is computationally impossible to find another ( v , k ) pair for the same u, and “additively homomorphic” denotes that i = 0 com ( v i , k i ) = com ( i = 0 v i , i = 0 k i ) . A confidential coin is a commitment and a range proof of that commitment. For example, C = ( u , π = range 2 L ( u ) ) , and π verifies that u’s hidden coin amount is in [ 0 , 2 L ) .
Assume that a set of participants want to spend confidential coins [ u i = com ( v i , k i ) ] i = 0 and create new confidential coins [ u i = com ( v i , k i ) ] i = 0 for the supplied coins s and the transaction fee f. Then they compute a public key out of commitments such that
p k = i = 0 u i i = 0 u i + com ( f s , 0 ) = com ( 0 , i = 0 k i i = 0 k i )
because i = 0 v i i = 0 v i + f s = 0 if the owners do not illegally generate coins.
Aggregable CTs’ digital signature schemes use commitments as their public keys. However, a valid signature can be created if and only if the commitments’ value is zero refs. [1,10,11,12,13,14]. In the previous equation, if participants do not generate coins illegally, they can create digital signatures for p k using the aggregated secret key i = 0 k i i = 0 k i . Hence a signature of p k can prove (1) the summation and (2) the ownership because a digital signature can only be created if all the secret keys are known.
Lattice-based Ownership+Summation Proofs. Ref. [1] introduced the first quantum-safe aggregable CT protocol. However, ref. [1] is inefficient leading to > 30 KB commitments. Ref. [2] proposed the first practical aggregable post-quantum CT protocol, LACT, based on the Module-Ring Short Integer Problem (MSIS). LACT significantly improves efficiency by storing coins in their binary forms such that u = com ( [ b 0 , , b 63 ] , k ) instead of the full integer, when v = i = 0 63 2 i b i . LACT’s confidential integers are binary commitments and a range proof for all bits, i.e., C = ( u , π = range 2 ( u ) ) when π verifies that the bits of u’s hidden coin amount are in [ 0 , 1 ] . More concretely, LACT’s commitments are only 9.6 KB long for coins in [ 0 ,   2 64 ) .
However, summation does not work anymore because adding two binary commitments does not output a binary commitment due to carries. Therefore, LACT use carry proofs to fix the summation. Each carry proof has a commitment of carries and a range proof to show that each carry is either 0 or 1. Therefore, a LACT header contains supplied coins, transaction fee, a digital signature and a carry proof to prove the ownership and the summation of hidden coins.
Unprovable Immutability. In blockchains refs. [16,17], transaction headers are securely stored with consensus proofs to show that the community has accepted the that version of the blockchain, which is the “right blockchain”. If somebody changes the right blockchain, the consensus proofs will indicate that there was an altercation, i.e., immutability. However, current aggregable CT protocols refs. [2,10,11,12,13,14] do not provide proper immutability proofs for aggregated blockchains, only for complete blockchains. Therefore, despite the aggregation, peers have to keep all coin records for the verification, e.g., Grin ref. [23] and Beam ref. [24]—which use Mimblewimble aggregable transactions refs. [10,11,12,13] keep all transactions to provide immutability. Therefore, aggregable CTs do not reduce the overall blockchain size nor provide trustless verification for aggregable CTs in current settings.

1.2. Our Contribution

We introduce LACT+, a more efficient Lattice-based Aggregable Confidential Transaction protocol with provable immutability. Furthermore, we implement a public LACT+ C library ref. [25] and provide formal security proofs.
Approx-SIS. LACT+ uses the Approximate Module Short Integer Problem (Approx-SIS) ref. [26] which can be tightly reduced to LWE (Learning with Errors ref. [27]) or SIS ref. [28]. Approx-SIS creates shorter proofs by dropping low bits of each polynomial coefficient without affecting security when the dropped bits are smaller than some norm, e.g., each LACT+ commitment drops 14 bits from 256 × 6 coefficients and reduces the size from 8.4 KB to 5.7 KB.
More than 2 inputs/outputs. LACT’s main constraint was that a maximum of two inputs or outputs could be included in a transaction because the carries must be in [0, 1]. If there are more than two inputs/outputs, they had to be separated into multiple transactions, and each transaction includes an additional carry proof. LACT+ transactions allow having more than two inputs or outputs at a logarithmic cost, i.e., O ( log ( x ) ) for x number of in/outputs. Hence, LACT+ does not unnecessarily increase the size of the header.
Trustless Immutability. Previous aggregable CTs’ headers are malleable, or the owners of the transactions can use the same header set for different unspent coins. This allows the owners to forge many chains for the same header with different unspent coins or spent coins refs. [10,13]. Hence, preserving headers is not sufficient to provide immutability, and block creators hash the whole transaction and save the transaction hash through the consensus mechanism. Therefore, the peers must download the complete chain (note that we do not consider users who depend on “trusted” peers without verifying the blockchain as peers because they are replicas of the those “trusted” peers). Hence, except for the efficient ownership + summation proofs, the aggregation has no use to the peers who do not blindly trust other peers.
As a solution, LACT+ headers contain aggregable activity proofs ref. [29] to prevent the forging of different blockchains for the consensus accepted headers, i.e., each transaction header contains an activity proof for that transaction, and by giving the same input and output coin records, the activity proof verifies that they existed. More importantly, an aggregated activity proof can verify the activities of an aggregated CT; hence, chains’ unspent coin records cannot be forged. Not only that, activity proofs are constant sizes for any number of inputs and outputs, e.g., 49 bytes in LACT+. Hence, activity proofs do not break transaction aggregation, but at a tiny cost, peers can download a small aggregated chain and verify the existence of coins without blindly trusting other peers.
Table 1 compares LACT+ with other CT protocols.

2. Preliminary

An integer ring is Z / q Z = Z q which has integers in [ q 1 2 , q 1 2 ] for an odd prime q. A polynomial ring is Z [ X ] / ( X N + 1 ) = R with N = 2 k for some integer k > 0 . A fully splitting ring is Z q [ X ] / ( X N + 1 ) = R q where each polynomial coefficient is in Z q for a prime q = 1 ( mod 2 N ) . A polynomial is denoted with an upper arrow, e.g., a that is in R or R q . We denote vectors of n elements in bold letters ( a = [ a i ] i = 0 n ) and matrices of m vectors in capital bold letters ( A = [ a i ] i = 0 m ). Similarly, polynomial vectors are denoted as a = [ a i ] i = 0 n , and matrices are denoted as A = [ a i ] i = 0 m . a b denotes the polynomial multiplication of a and b . x a is a scalar multiplication where each coefficient is multiplied by scalar x.
Uniform sampling of some set S is denoted as s $ S . A negligible function of security parameter λ is denoted as ϵ ( λ ) = 1 / o ( λ c ) for some natural number c. The security parameter and public parameters are commonly referred as λ and p p ( λ ) . We only use the following norms: the infinity norm a = max ( [ | a i | ] i = 0 N 1 ) and the level 1 norm a 1 = i = 0 N 1 | a i | . 0 and 0 are a vector of all zero values and a zero polynomial of all zero coefficients, respectively. binary ( v ) either outputs b of L elements or b R q such that v = i = 0 L 2 i b i according to the context. rot ( v i , i ) outputs polynomial a such that the i th coefficient of a is v i , and other coefficients are zeros s.t. [ a j = 0 ] j = 0 , j i N . highbits p ( v ) and lowbits p ( v ) denote high bits and low bits of v Z q such that highbits p ( v ) · 2 p + lowbits p ( v ) = v . Furthermore, up p ( v ) = v s . · 2 p . We use these functions for polynomial vectors in an element-wise manner, e.g., highbits p ( a ) to denote high-bit polynomial vectors. Note that we use polynomial rotations to change the locations of bits. For example,
( j , i ) 0 ; j + i < N : rot ( v , j ) rot ( 1 , i ) = rot ( v , j + i ) R
( j , i ) 0 ; j i > 0 ; i < N : rot ( v , j ) rot ( 1 , N i ) = rot ( v , j i )

2.1. Common Security Properties

First, we start with the common security definitions of confidential coins, carry proofs, and transactions, i.e., the hiding property, zero-knowledge, and knowledge soundness.
Confidential coins and carry proofs should be hiding, i.e., they should not reveal the committed coin value or the carry vector. We define hiding or indistinguishability of a generic protocol P ’s outputs below.
Definition 1
(Statistical Hiding). Let D 1 be the output distribution of protocol P ( p p λ ) , and D 0 be the simulated distribution created by a simulator S ( p p λ , T ) with a trapdoor T of public parameter p p λ . For any A , P ’s outputs are hiding if
2 1 2 P r b = ? b | b $ [ 0 ,   1 ] ; θ $ D b ; b A ( p p λ , θ ) ϵ ( λ ) .
Coin and carry proofs contain range proofs. A range proof should not reveal anything about the committed value other than the range. Similarly, summation proofs of transactions should not disclose anything about the coin values other than that input coins are equal to output coins. We define these requirements for a generic protocol P and statement(s) L . For example, in range proofs, range ( L ,   b ) outputs 1 if all b i [ 0 ,   1 ] of i [ 0 ,   L ) . The statement L of a range proof is “ range ( L ,   b ) is 1 for hidden b ”. Assume the generic protocol P reveals a statement L about the outputs but nothing else. Then, P ’s outputs are zero-knowledge except for L . We state the zero-knowledge of P below.
Definition 2
(Zero-Knowledge Argument). Let D 0 be the simulated distribution of a simulator S ( p p λ , L , T ) with a trapdoor T of public parameter p p λ for L , and D 1 be the real output distribution of protocol P ( p p λ ) for statements L . For any p.p.t. A , P ’s outputs are zero-knowledge if
2 1 2 P r b = ? b | b $ [ 0 ,   1 ] ; θ $ D b ; b A ( p p λ , θ , L ) ϵ ( λ ) .
Even though coins, carry proofs, and transactions are hiding and zero-knowledge, they should be knowledge sound such that no adversary can create valid proofs for invalid hidden coin amounts or invalid carry vectors. We capture this property by using a simulator K with a trapdoor T who extracts hidden values from the proofs. This is a stronger version of knowledge soundness, called simulated witness extractability. If a generic protocol is simulated witness extractable, the simulator K can always extract valid hidden amounts and carries that satisfy the required statement(s). We state the simulated witness extraction of a generic protocol P for statement(s) L below.
Definition 3
(Simulated Witness Extractability). Let P be a generic zero-knowledge protocol for statement L such that P ( p p λ , L , Π ) verifies whether hidden values of Π satisfies L or not. P is simulated witness extractable if
P r P ( p p λ , L , Π ) = ? 1 L ( p p λ , w ) = ? 1 | Π A ( p p λ ) w K ( p p λ , T , L , Π ) ϵ ( λ ) .
Technically, these extractors do not exist outside the simulated world because public parameters are securely generated to avoid unintentional trapdoors.

2.2. Hardness Assumption

LACT+ depends on the approximate SIS problem ref. [26].
Definition 4 
(Approximate Inhomogeneous Module Short Integer Solution Problem (Approx-SIS)). The advantage of an algorithm A solving Approx-SIS of ( n , m , q , γ , γ , N ) after one execution is given by,
P r s γ H s y γ | H $ R q n × m ; y $ R q n s A ( p p λ , y , H )

2.3. Activity Proofs

Let H be a multiplicative group of prime order q 2 > 2 3 λ and H : { 0 , 1 } H be a secure collision-resistant hash function family. Casually, we use H for one randomly chosen but commonly known member of a collision-resistant hash function family for a given λ where the key of H is random, fixed, and publicly known.
Let there be a non-empty set of data entries s that will be updated into a new set  s . The proof δ of this activity is,
δ = activity ( s , s ) : Π i = 0 H ( s i ) · ( Π i = 0 H ( s i ) ) 1 H .
Definition 5
(Immutability). An activity proof of ( H , q ) is immutable if the following is less than or equal to ϵ ( λ ) .
P r ( s 1 , s 1 ) ? ( s 2 , s 2 ) activity ( s 1 , s 1 ) = ? activity ( s 2 , s 2 ) | s 1 , s 1 s 2 , s 2 A ( H , q 2 )

2.4. Hints

We frequently multiply high-bit polynomials with short challenge polynomials and check equality. Because the multiplication creates large errors that may propagate into higher bits, we use “hints”, a { 1 , 0 , 1 } polynomial vector that holds at most χ recovery bits. The way of creating and using hints is stated below.
hints ( χ , a R q n , b R q n ) ̲ :          use _ hints ( χ , a R q n , h R q n ) ̲ : h = a b R q n          if h > 1 h 1 > χ : if   h > 1 h 1 > χ : return                       return return   h          return b = a h R q n

2.5. Public Parameters

We use the following public parameters (Algorithm 1) throughout the remainder of the paper.
Algorithm 1 Public Parameter Generation
  • Assign C β N , L , p 1 , p 2 , χ , α , τ , τ 1 , τ 2 , τ 3 N such that
  •      L L N ⊳ Maximum number of inputs/outputs is 2 L because we only used one polynomial for carry commitments. When using l number of polynomials, this constraint should be L L N l .
  •     ⊳ for negligible soundness error
  •     log 2 N β + β 2 λ ,  
  •     ⊳ for smaller errors targeting different summations
  •      p 1 · 2 16 < 2 γ and p 2 · 2 8 < 2 γ
  •     ⊳ Norm 1 limit for hint polynomials is heuristically chosen according to p 1 and p 2 aiming to create hints within a reasonable time
  •      χ heuristic ( p 1 , p 2 ) s.t. hint ( · ) R q n 1 χ
  •     ⊳ for rejection sampling in range proofs
  •      0 < 2 α , 0 < β 2 τ + β τ 1 τ 2 γ ,
  •     ⊳ for rejection sampling in aggregate signatures
  •      0 < ( 2 L + 1 ) β τ τ 3 and 2 L τ 3 γ ,
  •     ⊳ for computational hiding of coin amounts
  •      ( m 3 ) N log 2 ( 2 τ ) 6 λ ,
  •      L α γ
  • Get H $ R q n × m s.t. Approx SIS n , m , q , N , γ , γ is hard.
  • C β N = [ x R q s . t . x = 1 , x 1 = β ]
  • return p p ( λ , L ) = ( n , m , q , N , C β N , L , p 1 , p 2 , χ , α , τ , τ 1 ,
  •          τ 2 , τ 3 , γ , γ , H )

2.6. Fiat–Shamir Signatures

We define a digital signature scheme based on Fiat–Shamir challenges similar to refs. [32,33,34,35,36] in Algorithm 2. This signature scheme is the Approx-SIS version of ref. [36] with (1) a varying key space to allow aggregate keys and (2) beginning zero polynomials to align with commitments.
SIG provides completeness and strong EUF-CMA (Existential Unforgeability under Chosen Message Attack) due to the security of ref. [36] and the hardness of Approx-SIS.
We define the security properties below.
Definition 6.
SIG is complete and strong EUF-CMA if
P r SIG . ver ( p p λ , p k , m , sig , c ) = ? 1 | ( k , p k ) = SIG . kgen ( p p λ , c ) sig = SIG . sign ( p p λ , k , m , c ) 1 ϵ ( λ )
Adv SIG , p p λ EUF , A : = P r Game SIG , p p λ EUF , A ( ) ϵ ( λ ) .
  • Game SIG , p p λ EUF , A : ̲
  • c A s t e p 1 ( p p λ ) ; if  c > 2 L : return ⊥
  • ( k , p k ) = SIG . kgen ( p p λ , c ) ; ( m , sig ) A s t e p 2 sign k ( p p λ , p k )
  • return ( m , sig ) Q SIG . ver ( p p λ , p k , m , sig , c )
  •  
  • Oracle sign k ( m , c ) : ̲ sig = SIG . sign ( p p λ , k , m , c )  
  • Q = Q { ( m , sig ) } ; return sig
Theorem 1.
SIG is complete and EUF-CMA when ref. [36] is complete and EUF-CMA, and solving Approx-SIS of ( n , m 3 , q , γ , γ , N ) is hard.
Algorithm 2 Digital Signatures
  1:
⊳ Here, the key spaces change according to c 2 L
  2:
⊳ Recall that τ 2 ( 2 L + 1 ) τ β and γ 2 L τ 3
  3:
SIG . kgen ( p p λ , c ) : ̲ k is the secret signing key
  4:
k $ [ c τ , c τ ] ( m 3 ) × N ; pk = highbits p 1 ( H [ 0 3 , r ] ) R q n
  5:
return ( k , pk )    
 
  6:
SIG . sign ( p p λ , k , m , c ) : ̲ if c > 2 L : return ⊥
  7:
pk = highbits p 1 ( H [ 0 3 , r ] ) R q n
  8:
r 0 $ [ c τ 3 , c τ 3 ] ( m 3 ) × N
  9:
y = highbits γ ( pk ) R q n
10:
x = hash ( pk , y , m ) C β N
11:
σ = r 0 + x k R m 3
12:
if  σ > ( c τ 3 c β τ ) : go to Step 8
13:
y = highbits γ ( H [ 0 3 , σ ] x up p 1 ( pk ) ) R q n
14:
h = hints ( χ , y , y ) ; if  h = : go to Step 8
15:
return ( σ , h , x )   
 
16:
SIG . ver ( p p λ , pk , m , σ , x , c ) : ̲
17:
if c > 2 L : return 0
18:
y = highbits γ ( H [ 0 3 , σ ] x up p 1 ( pk ) ) R q n
19:
y = hints ( χ , y , h ) ; if  y = : return 0
20:
return σ < γ x = ? hash ( pk , y , m )

3. LACT+ Protocol

A LACT+ transaction has input confidential coins, output confidential coins, and a header (signature, carry proof, and activity proof), as shown in Figure 1. The input confidential coins are in the blockchain’s set of unspent coins. During the aggregation, they will be removed from the unspent coin set, and output confidential coins will be added to the unspent coin set (see Figure 2) where coin ( s ) was removed). Therefore, an aggregated blockchain can be seen as a big transaction that contains all unspent coins. In this section, we explain confidential coins, carry proofs of the headers, and finally the complete aggregable transactions.

3.1. Confidential Coins

We begin by building confidential coin records where we can hide coin values but can also verify that the hidden coin amounts are in some range [ 0 , 2 L ) .
Let there be a confidential coin scheme COIN that supports the following functionalities.
  • COIN . gen ( p p ( λ , L ) , v ) : returns ( k , coin ) if v is in [ 0 , 2 L 1 ] ; otherwise returns ⊥. Here, k is a secret key, a.k.a., blinding key, and L is defined in p p ( λ , L ) .
  • COIN . open ( p p ( λ , L ) , v , k , coin ) : returns 1 if coin is generated for ( v [ 0 , 2 L ) , k ) ; otherwise, returns 0.
  • COIN . ver ( p p ( λ , L ) , coin ) : returns 1 if the hidden coin amount is in [ 0 , 2 L ) otherwise, returns 0.

Protocol Sketch

First, we sketch an interactive version of a 1-bit range proof. Let there be a value b which should be either 0 or 1. For some mask a [ α , α ] and random challenge x [ 1 , 0 , 1 ] , take z = b x + a if z [ α + 1 , α 1 ] . Otherwise, the process is repeated until a valid z is found. Then z ( z x ) = x a ( 2 b 1 ) + a 2 because x 2 b ( b 1 ) should be zero. We use this method to prove the range of a bit.
Let P be a prover and V be a verifier. V has a commitment u = com ( b , 0 , k ) , and P who knows k [ τ , τ ] wants to show that the bit b is either 1 or 0 without revealing it. The prover uses commitments to prove the range of b. First, P creates commitment t 1 = com ( b , a ( 2 b 1 ) , r 1 ) and sends it to V . After receiving a challenge x 1 from V , P replies with t 2 = com ( x a , a 2 , r 2 ) . Then, V sends the second challenge x 2 . After that, P computes z = ( b x + a ) and r = x 2 ( x 1 k + r 1 ) + r 2 . If z is in [ α + 1 , α 1 ] and r is in [ τ + τ 1 + τ 2 , τ τ 1 τ 2 ] , they statistically hide b , a , k , r 1 , and r 2 . Hence, P sends z and r to V . If z and r are not in the secure ranges, P rejects them and restarts the protocol. Finally, the verifier V checks that com ( x 1 z , z ( z x 2 ) , r ) = ? x 2 x 1 u + x 2 t 1 + t 2 . V accepts that b is either 0 or 1 if they are equal.
We use this technique to prove the range of the coin by repeating it for all bits. Furthermore, we increase the range of challenges into 2 2 λ so that P cannot cheat. The complete non-interactive protocol COIN is given in Algorithm 3, and a graphical overview is provided in Figure 3. Note that all LACT+ commitments have the form of com ( , , , ) , not com ( , , ) . Hence, the verifier will check com ( x 1 z , z ( z x 2 ) , 0 , r ) = ? x 2 x 1 u + x 2 t 1 + t 2 with a fixed 0 value. This extra value space is used for carry proofs which will be explained in the next section.
One-bit Range Proof Sketch (Interactive)
P V 2
a $ [ α , α ] ; r 1 $ [ τ 1 , τ 1 ]
t 1 = com ( b , a ( 2 b 1 ) , r 1 ) t 1
r 2 $ [ τ 2 , τ 2 ] x 1 x 1 $ [ 1 , 1 ]
t 2 = com ( x a , a 2 , r 2 ) t 2
z = ( b x + a ) [ α + 1 , α 1 ] x 2 x 2 $ [ 1 , 1 ]
r = x 2 ( x 1 k + r 1 ) + r 2 s . t .
r [ τ + τ 1 + τ 2 , τ τ 1 τ 2 ] z , r com ( x 1 z , z ( z x 2 ) , r ) = ?
x 2 x 1 u + x 2 t 1 + t 2
Algorithm 3 New Confidential Coins
  1:
⊳ Creates coin records for v coins
  2:
COIN . gen ( p p ( λ , L ) , v ) ̲ :
  3:
⊳ Short vector for the commitment
  4:
b = binary ( L , v ) s.t. v = i = 0 L 1 2 i b i
  5:
k $ [ τ , τ ] ( m 3 ) × N
  6:
s = [ b , 0 , 0 , k ] R q m
  7:
u = highbits p 1 ( H s ) R q n ⊳ Commitment
  8:
⊳ Get masking values for bits from Lazy Sampling
  9:
[ a i $ [ ( α ( 1 b i ) ) , ( α ( 1 b i ) ) ] N ] i = 0 L
10:
⊳ Short key vectors for range proof commitments
11:
r 1 $ [ τ 1 , τ 1 ] ( m 3 ) × N ; r 2 $ [ τ 2 , τ 2 ] ( m 3 ) × N
12:
s 1 = [ 0 , i = 0 L a i rot ( 2 b i 1 , i ) , 0 , r 1 ] R m
13:
t 1 = highbits p 2 ( H s 1 ) R q n
14:
x 1 = hash ( u , t 1 ) C β N
15:
s 2 = [ x 1 i = 0 L a i , i = 0 L a i a i , 0 , r 2 ] R m
16:
t 2 = highbits γ ( H s 2 ) R q n
17:
x 2 = hash ( u , t 1 , t 2 ) C β N
18:
[ z i = x 2 rot ( b i , i ) + a i ] i = 0 L R L
19:
r = x 2 ( x 1 k + r 1 ) + r 2 R m 3
20:
if  z > ( α 1 ) r > ( τ 2 β 2 τ β τ 1 ) :
21:
   go to Step 5
22:
⊳ Check norms
23:
z ^ = i = 0 L z i ( z i x 2 rot ( 1 , i ) ) R
24:
if  z ^ > γ : go to Step 5
25:
⊳ Create hints for t 2
26:
s = [ x 1 i = 0 L z i , z ^ , 0 , r ] R m
27:
t 2 = highbits γ ( H s x 2 ( x 1 up p 1 ( u ) + up p 2 ( t 1 ) ) ) R q n
28:
h = hints ( χ , t 2 , t 2 )
29:
if  h = : go to Step 5
30:
return k and coin = ( z , r , u , t 1 , h , x 2 )   
 
31:
⊳ Open coin records of v coins and key k
32:
COIN . open ( p p ( λ , L ) , v , k , coin ) : ̲
33:
( z , r , u , t 1 , h , x 2 ) = coin
34:
s = [ binary ( v ) , 0 , 0 , k ] R m
35:
return s ? α u = ? highbits p 1 ( H s ) R q n   
 
36:
⊳ Verify coin records
37:
COIN . ver ( p p ( λ , L ) , coin ) : ̲
38:
( z , r , u , t 1 , h , x 2 ) = coin
39:
x 1 = hash ( u , t 1 )
40:
z ^ = i = 0 L z i ( z i x 2 rot ( 1 , i ) ) R
41:
s = [ x 1 i = 0 L z i , z ^ , 0 , r ] R m
42:
⊳ Use hints to recompute t 2
43:
t 2 = highbits γ ( H s x 2 ( x 1 up p 1 ( u ) + up p 2 ( t 1 ) ) ) R q n
44:
t 2 = use _ hints ( χ , t 2 , h )
45:
if  t 2 = : return 0
46:
return x 2 = ? hash ( u , t 1 , t 2 ) s γ
We want COIN to be complete, hiding, binding, zero-knowledge, and knowledge sound. Here, we state the undefined security properties of COIN ; completeness and binding. Other properties, namely, hiding, zero-knowledge, and knowledge soundness, defined in Section 2.1 are valid for COIN as well when the statement L is
all  L  bits of  b = binary ( L , v )  are either 0 or 1 .
Definition 7
(Completeness).  COIN is complete if honestly generated proofs can be verified for the correct range, or the following is greater than or equal to 1 ϵ ( λ ) .
P r COIN . ver ( p p ( λ , L ) , coin ) | v s . [ 0 , 2 L 1 ] ( k , coin ) = COIN . gen ( p p ( λ , L ) , v )
Once a coin record has been published, no one, including the creator who knows the secret key, should be able to claim another coin value for the same coin record. Otherwise, after sending a transaction, owners can illegally generate coins. We capture this security property below.
Definition 8
(Binding).  COIN is binding if
P r ( v , k ) ? ( v , k ) COIN . open ( p p ( λ , L ) , v , k , coin ) COIN . open ( p p ( λ , L ) , v , k , coin ) | coin v , k v , k A ( p p ( λ , L ) ) ϵ ( λ )
Theorem 2.
COIN is complete, computationally binding, and computational knowledge sound, and zero-knowledge if approx-SIS of ( n , m , q , γ , γ , N ) is hard (see the security proof in Appendix A).

3.2. Logarithmic-Sized Carry Proofs

Binary commitments are smaller than full integer commitments. However, we cannot directly check summations of transactions’ in/outputs and chains’ total unspent coin amount when they are in binary forms. Therefore, LACT  ref. [2] uses static carries with maximum two inputs and two outputs and a static supply.
Unlike traditional blockchains, LACT maintains an unspent coin record (with a zero key) for the coinbase (coin supplier) where the coinbase holds future supply, and those coins do not belong to anyone until they are awarded. The idea is to maintain a constant coin amount on the blockchain all the time. For instance, the coinbase holds the maximum v base = S at the beginning and keeps reducing the amount v base = v base s ( t ) with each rewarded coin s ( t ) of transaction t. Therefore, the blockchain always has S coins. When the coin amount is constant, the following equations can be used to check the summation of individual transactions and the blockchain.
Let the maximum coin amount be in [ 0 , 2 L ) . For transaction t, let the inputs be c with coins [ v i ] i = 0 such that binary ( v i ) = [ b i , j ] j = 0 L and outputs be c with coins [ v i ] i = 0 such that binary ( v i ) = [ b i , j ] j = 0 L . Then, the input carries [ c j ] j = 0 L + 1 are computed as
0 , i = 1 | c | b i , 0 + c 0 ÷ 2 , , i = 1 | c | b i , L 2 + c L 2 ÷ 2 , 0 j = 0 L + 1
where c 0 and c L are zeros, and other c j s are either 0 or 1. Similarly, the output carries [ c j ] j = 0 L + 1  are
0 , i = 1 | c | b i , 0 + c 0 ÷ 2 , , i = 1 | c | b i , L 2 + c L 2 ÷ 2 , 0 j = 0 L + 1
such that c 0 and c L are zeros, and c j s are 0 or 1. Note that ÷ is the integer division and | · | is the size of a set/vector.
Then, these binary vectors satisfy Equation (1) if inputs coins are equal to output coins.
i = 1 | c | b i , j i = 1 | c | b i , j + ( c j ( t ) 2 c j + 1 ( t ) c j ( t ) + 2 c j + 1 ( t ) ) = ? 0 j = 0 L
Furthermore, due to the constant coin amount, Equation (2) can be used to verify that unspent coins ( ucoins ) are equal to the total supply S of headers ( headers ) binary ( S ) = [ S j ] j = 0 L .
i = 1 | ucoins | b i , j + t = 1 | headers | c j ( t ) 2 c j + 1 ( t ) c j ( t ) + 2 c j + 1 ( t ) = ? S j j = 0 L
Therefore, LACT headers contain carry
com ( [ c j ( t ) 2 c j + 1 ( t ) c j ( t ) + 2 c j + 1 ( t ) ] j = 0 L 1 , )
and range proofs of in/output carries (we call them carry proofs) when in/output size is 2. Note that when there is only one in/output, the carries are always zero, in which case no carry proofs are needed. These carries’ range proofs are similar to coins’ carry proofs even though a functional output of the carries is committed. However, a normal transaction has to be separated into multiple LACT transactions if there are more than two inputs or outputs. For example, a transaction of ( 2 3 ) can be separated into two transactions; ( 2 2 ) and ( 1 2 ) with two carry proofs.
We generalize this concept of static carry proofs for more than two input and output transactions at a logarithmic cost to reduce the size impact of carry proofs in LACT+.
Let there be a carry proof protocol, CARRY that commits and provides range proofs for maximum 2 L number of inputs or outputs.
  • CARRY . gen ( p p ( λ , L ) , [ v i ] i = 0 | in | , [ v i ] i = 0 | out | ) : returns ( k , carry ) if all v and v are in [ 0 , 2 L 1 ] ; otherwise returns ⊥. Here, k is the secret key of carry commitment, | in | 2 L and | out | 2 L . At this point, we do not check v = v , which will be performed in transaction creation. Here, | in | and | out | are the input and output sizes.
  • CARRY . ver ( p p ( λ , L ) , carry ) : returns one if the hidden carries are in [ 0 , 2 L ) and the carries are committed according to Equation (1); otherwise, it returns zero.

Protocol Sketch

Carry proofs contain a commitment and a range proof to show that each carry is in a proper range, which is [ 0 , 2 L ) for maximum 2 L 2 inputs and outputs. Let there be 2 L in number of inputs and 2 L out number of outputs. A LACT+ carry commitment is com ( c j ( t ) 2 c j + 1 ( t ) c j ( t ) + 2 c j + 1 ( t ) , 0 , 0 , k ) when c and c are input and output carries. Here, except for the 0th and ( L 1 ) th carries, the output carries [ c j ] j = 1 L 2 are in [ 0 , 2 L out ) , and other input carries [ c j ] j = 1 L 2 are in [ 0 , 2 L in ) . Hence, LACT+ creates range proofs for the following vectors
[ binary ( L in , c 1 ) , , binary ( L in , c L 2 ) ] R and [ binary ( L out , c 1 ) , , binary ( L out , c L 2 ) ] R .
We define the new carry proof protocol in Algorithm 4. Furthermore, we provide a graphical view of the carry proofs in Figure 4 using the same notation as Algorithm 4.
Algorithm 4 New Confidential Carry Proofs
  1:
| in | , | out |   ( 2 L ) are the number of in/outputs, including supplied coins and transaction fee.
  2:
CARRY . gen ( p p ( λ , L ) , [ v i ] i = 0 | in | , [ v i ] i = 0 | out | ) : ̲
  3:
if  | in | > 2 L | out | > 2 L :
  4:
        return ⊥
  5:
L in = log 2 ( ( 2 | in | 1 ) )
  6:
L out = log 2 ( ( 2 | out | 1 ) )
  7:
[ b i = binary ( v ( i ) ) ] i = 1 | in | , [ b i = binary ( v ( i ) ) ] i = 1 | out |
  8:
⊳ Carries when ÷ is the integer division
  9:
c 0 = 0 , [ c 0 , j + 1 = i = 1 | in | b i , j + c 0 , j ÷ 2 ] j = 0 L 1 , 0  
10:
c 1 = 0 , [ c 1 , j + 1 = i = 1 | out | b i , j + c 1 , j ÷ 2 ] j = 0 L 1 , 0
11:
⊳ Bits of input carries
12:
c 0 = [ binary L in ( c 0 , j ) ] j = 0 L + 1 R ( L + 1 ) × L
13:
⊳ Bits of output carries
14:
c 1 = [ binary L out ( c 1 , j ) ] j = 0 L + 1 R ( L + 1 ) × L
15:
⊳ Compute random masks for carries
16:
⊳ Lazy Sampling
17:
[ [ d 0 , i , l $ [ ( α ( 1 c 0 , i , l ) ) , ( α ( 1 c 0 , i , l ) ) ] N ] i = 1 L ] l = 0 L in
18:
Set d 0 , 0 = 0 and d 0 , L = 0
19:
[ [ d 1 , i , l $ [ ( α ( 1 c 1 , i , l ) ) , ( α ( 1 c 1 , i , l ) ) N ] i = 1 L ] l = 0 L out
20:
Set d 1 , 0 = 0 and d 1 , L = 0
21:
c ^ 0 = l = 0 L in j = 0 L d 0 , j , l rot ( 2 c 0 , j , l 1 , j L in + l ) R
22:
c ^ 1 = l = 0 L out j = 0 L d 1 , j rot ( 2 c 1 , j , l 1 , j L out + l ) R
23:
c ^ = [ ( c 1 , j c 0 , j ) 2 ( c 1 , j + 1 c 0 , j + 1 ) ] j = 0 L , 0 N L ] R
24:
t in = N j · ( L in 1 ) l
25:
t in = N ( j + 1 ) · ( L in 1 ) l 1
26:
d ^ 0 = l = 0 L in j = 0 L ( d 0 , j , l rot ( 2 l , t in ) 2 d 0 , j + 1 , l rot ( 2 l , t in ) )
27:
t out = N j · ( L out 1 ) l
28:
t out = N ( j + 1 ) · ( L out 1 ) l 1
29:
d ^ 1 = l = 0 L out j = 0 L ( d 1 , j , l rot ( 2 l , t out ) 2 d 1 , j + 1 , l rot ( 2 l , t out ) )
30:
⊳ Pick random masks
31:
k $ [ τ , τ ] ( m 3 ) × N
32:
r 1 $ [ τ 1 , τ 1 ] ( m 3 ) × N ; r 2 $ [ τ 2 , τ 2 ] ( m 3 ) × N
33:
⊳ Carry commitment
34:
u = highbits p 1 ( H [ c ^ , 0 , 0 , k ] ) R q n
35:
t 1 = highbits p 2 ( H [ 0 , c ^ 1 , c ^ 0 , r 1 ] ) R q n
36:
x 1 = hash ( u , t 1 ) C β N
37:
s 2 = [ x 1 ( d ^ 1 d ^ 0 ) , l = 0 L out j = 0 L d 1 , j , l 2 , l = 0 L in j = 0 L d 0 , j , l 2 , r 2 ]
 
38:
t 2 = highbits γ ( H s 2 ) R q n
39:
x 2 = hash ( u , t 1 , t 2 ) C β N
 
 
 
 
40:
z 0 = [ [ x 2 rot ( c 0 , j , l , j L in + l ) + d 0 , j , l ] j = 1 L ] l = 0 L in R L in × L
41:
z 1 = [ [ x 2 rot ( c 1 , j , l , j L out + l ) + d 1 , j , l ] j = 1 L ] l = 0 L in R L out × L
42:
if  z 0 > ( α 1 ) z 1 > ( α 1 ) :
43:
     go to Step 15
44:
r = x 2 ( x 1 k + r 1 ) + r 2 R m 3
45:
if  r > ( τ 2 β 2 τ β τ 1 ) :
46:
         go to Step 15
47:
z ^ 0 = x 1 l = 0 L in j = 0 L ( z 0 , j , l rot ( 2 l , t in )
48:
               2 z 0 , j + 1 , l rot ( 2 l , t in ) ) R
49:
z ^ 1 = x 1 l = 0 L out j = 0 L ( z 1 , j , l rot ( 2 l , t out )
50:
               2 z 1 , j + 1 , l rot ( 2 l , t out ) ) R
51:
z ^ 0 = l = 0 L in i = 0 L z 0 , i ( z 0 , i x 2 rot ( 1 , i L in + l ) ) R
52:
z ^ 1 = l = 0 L out i = 0 L z 1 , i ( z 1 , i x 2 rot ( 1 , i L out + l ) ) R
 
53:
s = [ z ^ 1 z ^ 0 , z ^ 1 , z ^ 0 , r ] R m
54:
if  s > γ : go to Step 15
55:
⊳ Compute hints for t 2
56:
t 2 = highbits γ ( H s x 2 ( x 1 up p 1 ( u ) + up p 2 ( t 1 ) ) ) R q n
57:
h = hints ( χ , t 2 , t 2 )
58:
if  h = : go to Step 15
59:
return carry = ( z 0 , z 1 , r , u , t 1 , h , x 2 )    
 
60:
CARRY . ver ( p p ( λ , L ) , | in | , | out | , carry ) : ̲
61:
( ) denotes variables that can be empty
62:
( z 0 ( ) , z 1 ( ) , r ( ) , u ( ) , t 1 ( ) , h ( ) , x 2 ( ) ) : = carry
63:
if  | in | > 2 L | out | > 2 L :
64:
        return ⊥
65:
L in = log 2 ( ( 2 | in | 1 ) )
66:
L out = log 2 ( ( 2 | out | 1 ) )
67:
t in = N j · ( L in 1 ) l
68:
t in = N ( j + 1 ) · ( L in 1 ) l 1
69:
t out = N j · ( L out 1 ) l
70:
t out = N ( j + 1 ) · ( L out 1 ) l 1
71:
if  z 0 > α z 1 > α :
72:
     return 0
73:
z ^ 0 = x 1 l = 0 L in j = 0 L ( z 0 , j , l rot ( 2 l , t in )
74:
               2 z 0 , j + 1 , l rot ( 2 l , t in ) ) R
75:
z ^ 1 = x 1 l = 0 L out j = 0 L ( z 1 , j , l rot ( 2 l , t out )
76:
               2 z 1 , j + 1 , l rot ( 2 l , t out ) ) R
77:
z ^ 0 = l = 0 L in i = 0 L z 0 , i ( z 0 , i x 2 rot ( 1 , i L in + l ) ) R
78:
z ^ 1 = l = 0 L out i = 0 L z 1 , i ( z 1 , i x 2 rot ( 1 , i L out + l ) ) R
 
79:
s = [ z ^ 1 z ^ 0 , z ^ 1 , z ^ 0 , r ] R m
80:
if  s > γ : return 0
81:
⊳ Recompute t 2 from hints
82:
t 2 = highbits γ ( H s x 2 ( x 1 up p 1 ( u ) + up p 2 ( t 1 ) ) ) R q n
83:
t 2 = use _ hints ( χ , t 2 , h )
84:
if  t 2 = : return 0
85:
return x 2 = ? hash ( u , t 1 , t 2 )
New carry proofs provide the following properties; completeness, knowledge soundness, and zero-knowledge argument. Zero-knowledge and knowledge soundness are defined for a statement L ,
all input and output carries are in  [ 0 ,   2 L in ) and [ 0 ,   2 L out )
according to Definitions 2 and 3.
Definition 9
(Completeness).  CARRY is complete if honestly generated proofs are always valid such that the following is greater than or equal to 1 ϵ ( λ ) .
P r CARRY . ver ( p p ( λ , L ) , | in | , | out | , c ) | v , v [ 0 , 2 L 1 ] s . t . | v | , | v | 2 L ( k , c ) = CARRY . gen ( p p ( λ , L ) , v , v )
Theorem 3.
CARRY is complete, zero-knowledge, and witness extractable if Approx-SIS of ( n , m , q , γ , γ , N ) is hard (see the security proof in Appendix B).

3.3. Aggregable Confidential Transactions with Activity Proofs

In this section, we describe LACT+ transactions, TX , with new confidential coins, carry proofs, and activity proofs.
A transaction converts a set of existing coin records (inputs) into new coins (outputs). First, users agree on the inputs and outputs. Then they create a carry proof to show the summation. Finally, they create the transaction by computing a signature to prove the ownership. Let [ b ] i = 0 , [ b ] i = 0 , c 0 , and c 1 be the binary inputs, binary outputs, input carries, and output carries accordingly. If the input coins are equal to output coins, they satisfy Equation (1) and a zero-coefficient vector is output. Therefore, the summed commitment p k  is,
com i = 0 b i = 0 b + ( c j ( t ) 2 c j + 1 ( t ) c j ( t ) + 2 c j + 1 ( t ) ) , 0 , 0 , i = 0 k i i = 0 k i + k r = com 0 , 0 , 0 , r = p k
when k , [ k ] i = 0 , and [ k ] i = 0 are the keys of the carry commitment, input coin commitments, and output coin commitments. Therefore, TX asks the users to use ( r , p k ) as the secret–public key pair and create a signature. First, the users picks a random r and computes y = com ( 0 , 0 , 0 , r ) . Then, users’ computers receive the challenge x = hash ( u , y ) by hashing p k and y, and compute σ = r x r . The signature is ( σ , x ) . If the input coins are equals to output coins, verifiers can recompute y : = com ( 0 , 0 , 0 , σ ) x × p k and check x = ? hash ( p k , y ) . When the challenge is large enough, users cannot cheat and create valid signatures if they illegally generate coins or steal coins.
LACT+ transactions contain activity proofs to enable complete aggregation. Activity proofs are immutable, or it is computationally impossible to find two different input and output sets for the same activity proof. Hence, preserving activity proofs is sufficient to provide immutability to the whole blockchain, including the removed spent coins.
The transaction generation is a multi-party protocol where each sender or receiver keeps their secret keys without sharing and computes a secure partial signature. At the end, those partial signatures are aggregated into a single signature used as the transaction’s signature. Therefore, the senders do not learn the secret keys of other inputs and outputs, and cannot take back the sent coins. We use “green color” to denote the secret computations of each individual.
Before aggregating a transaction into the chain, verifiers check whether the inputs are in the chain or not. If they are in the chain, verifiers check the summation, ownership, and activity of the transaction. When the transaction has valid proofs, the verifiers remove the inputs from the chain, add outputs into the unspent coin set, and preserve the header. The complete protocol of TX is stated in Algorithm 5 and an example of transaction aggregation is stated in Figure 2.
Algorithm 5 LACT+ Transactions and Chains
  1:
| in | , | out |   ( 2 L ) are the number of in/outputs.
  2:
⊳ owners do not share secret keys of inputs or outputs.
  3:
TX . gen ( p p ( λ , L ) , k , carry , [ k i , v i , coin i ] i = 1 | in | , [ k i , v i , coin i ] i = 1 | out | ) ̲ :
 
  4:
if  v v : return ⊥
  5:
⊳ Commitments cannot be repeated
  6:
if  coin . u coin . u coin . u coin . u
  7:
       coin coin ϕ : return 0
  8:
Δ activity ( [ coin i . u ] i = 1 | out | , [ coin i . u ] i = 1 | in | ) H
  9:
Each sender i [ 1 , | in | ] secretly computes:
10:
    r 3 , i $ [ τ 3 , τ 3 ] ( m 3 ) × N
11:
    y i = H [ 0 , 0 , 0 , r 3 , i ] R q n and share y i
12:
Each receiver  i [ 1 , | out | ]  secretly computes:
13:
    r 3 , i $ [ τ 3 , τ 3 ] ( m 3 ) × N
14:
    y i = H [ 0 , 0 , 0 , r 3 , i ] R q n and share y i
15:
⊳ All receivers compute public key pk R q n .
16:
pk = highbits p 1 ( carry . u + i = 1 | out | coin i . u i = 1 | in | coin i . u )
 
17:
y = highbits γ ( i = 1 | out | y i i = 1 | in | y i ) R q n
18:
x 0 = hash ( pk , y , Δ ) C β N ⊳ Signature challenge
19:
Each sender  i [ 1 , | in | ]  secretly computes:
20:
      σ i = r 3 , i + x 0 k i R ( m 3 )
21:
    if  σ i > ( τ 3 β τ ) : go to Step 9
22:
Each receiver  i [ 1 , | out | ]  secretly computes:
23:
     σ i = r 3 , i + x 0 k i R ( m 3 )
24:
    if  σ i > ( τ 3 β τ ) : go to Step 9
25:
⊳ All receivers compute the signature
26:
σ = x 0 ( k + i = 1 | out | σ i i = 1 | in | σ i ) R ( m 3 )
27:
if  σ > ( ( | out | + | in | ) τ 3 ( | out | + | in | + 1 ) β τ ) :
28:
      go to Step 9
29:
y = highbits γ ( H σ x 0 up p 1 ( pk ) ) R q n
30:
h = hints ( χ , y , y ) ⊳ Hints for y
31:
if  h = : go to Step 9
32:
header = ( pk , h , σ , x 0 , carry , Δ )
33:
return tx = ( header , [ coin i ] i = 1 | in | , [ coin i ] i = 1 | out | )    
 
34:
⊳ A chain is an aggregated CT with multiple headers
35:
TX . aggregate ( p p ( λ , L ) , chain , tx ) : ̲
36:
( header , in , out ) ) : = tx
37:
( headers , S , ucoins ) : = chain
38:
if  ¬ TX . ver ( p p ( λ , L ) , tx ) : return ⊥
39:
⊳ Spending coins should be in the chain
40:
if  tx . in ucoins : return ⊥
41:
⊳ Remove spending coins from the chain
42:
ucoins = ( ucoins tx . in ) tx . out
43:
⊳ Add proofs to the transaction table
44:
headers = headers ( | tx . in | , | tx . out | , tx . header )
45:
⊳ Commitments cannot be repeated
46:
if  ucoins . u ucoins . u : return ⊥
47:
return chain = ( headers , S , ucoins ) )    
 
48:
TX . header _ ver ( p p ( λ , L ) , | in | , | out | , header ) ̲ :
49:
( pk , h , σ , x 0 , carry , Δ ) : = header
50:
⊳ Recompute y from hints
51:
y = highbits γ ( H σ x 0 up p 1 ( pk ) ) R q n
52:
y = use _ hints ( χ , y , h )
53:
if  y = : return 0
54:
return x 0 = ? hash ( pk , y , Δ )
55:
           CARRY . ver ( p p ( λ , L ) , | in | , | out | , carry )    
 
56:
TX . ver ( p p ( λ , L ) , tx ) : ̲
57:
( header , [ coin i ] i = 1 | in | , [ coin i ] i = 1 | out | ) ) : = tx
58:
( pk , h , σ , x 0 , carry , Δ ) : = header
59:
⊳ Commitments cannot be repeated
60:
if  coin . u coin . u coin . u coin . u :
61:
       coin coin ϕ : return 0
62:
⊳ Check activity
63:
if  Δ = activity ( [ coin i . u ] i = 1 | out | , [ coin i . u ] i = 1 | in | ) H : return 0
 
64:
if  [ ¬ COIN . ver ( p p ( λ , L ) , coin i ) ] i = 1 | in | : return 0
65:
if  [ ¬ COIN . ver ( p p ( λ , L ) , coin i ) ] i = 1 | out | : return 0
66:
if  ¬ TX . header _ ver ( p p ( λ , L ) , | in | , | out | , header ) :
67:
          return 0
68:
return highbits γ p 1 ( pk ) = highbits γ ( carry . u
69:
              + i = 1 | out | coin i . u i = 1 | in | coin i . u ) R q n    
 
70:
TX . chain _ ver ( p p ( λ , L ) , chain ) : ̲
71:
( headers , S , ucoins ) : = chain
72:
pk = u = 0 n R q n ; s = [ bin ( S ) , 0 ( m 1 ) ] R q m
73:
⊳ Commitments cannot be repeated
74:
if  ucoins . u ucoins . u : return 0
75:
for all ( coin i ) ucoins :
76:
     if  ¬ COIN . ver ( p p ( λ , L ) , coin i ) : return 0
77:
      u = u + coin i . u R q n
78:
for all  ( | in | , | out | , h i ) headers :
79:
     if  ¬ TX . header _ ver ( p p ( λ , L ) , | in | , | out | , h ) : d return 0
80:
      pk = pk + h . carry i . pk R q n
81:
      u = u + h . carry i . u R q n
82:
return highbits γ p 1 ( pk ) = ? highbits γ p 1 ( u H s )
83:
Π Δ headers Δ = ? Π c ucoins hash 0 ( c . u ) H
TX is expected to have the following security properties: completeness, zero-knowledge, knowledge soundness, theft resistance, and immutability. We reuse zero-knowledge and knowledge soundness from Definitions 2 and 3 when the statements of L are:
all coins are in  [ 0 ,   2 L ) and total unspent coins are equal to total supplied coins
Definition 10
(Completeness).  TX is complete if the honestly generated transactions are always valid, and aggregating a valid transaction into a valid chain always produces a correct chain with the unspent coins of that transaction. Let G be an arbitrary chain generator.
P r arbitrary _ tx ( ) arbitrary _ chain ( ) 1 ϵ ( λ ) .
  • arbitrary _ tx ( ) : ̲
  • For any [ v i ] i = 1 | in | [ 0 , 2 L 1 ] and [ v i ] i = 1 | out | [ 0 , 2 L 1 ]
  •      such that i = 1 | in | [ v i ] = i = 1 | out | [ v i ] [ 0 , 2 L 1 ] :
  •       [ ( k i , coin i ) = COIN . gen ( p p ( λ , L ) , v i ) ] i = 1 | in |
  •       [ ( k i , coin i ) = COIN . gen ( p p ( λ , L ) , v i ) ] i = 1 | out |
  • tx = TX . gen ( p p ( λ , L ) , [ k i , coin i ] i = 1 | in | , [ k i , coin i ] i = 1 | out | )
  • return tx . in = ? [ coin ] i = 1 | in | tx . out = ? [ coin ] i = 1 | out |
  •         TX . ver ( p p ( λ , L ) , tx )
  • arbitrary _ chain ( ) : ̲
  • Get any chain such that
  •       TX . chain _ ver ( p p ( λ , L ) . chain ) = 1 and T = | headers |
  • for  i [ 0 , t ] :
  •       tx i $ G ( p p ( λ , L ) ) s.t. CTx . ver ( p p ( λ , L ) , tx i ) = 1
  •       chain = TX . aggregate ( p p ( λ , L ) , chain , tx )
  •      if  chain = : continue
  •      if  headers T + i tx . carry
  •            tx i . out chain . ucoins : return 0
  • return TX . chain _ ver ( p p ( λ , L ) , chain ) | headers | = ? T + t
Even after aggregation, TX ensures that unspent coins cannot be spent without their secret keys. We consider strong theft resistance where the adversary has control over everything except an honest user’s secret key. Here, the adversarial algorithm generates a chain (an aggregated CT). In the first step, the algorithm sends some coins to the honest user, where the user locks those coins with a new key. Then, the algorithm tries to spend those coins without obtaining the new secret key. In other words, the network is set to have only one honest user, simulating a real-world decentralized network where everyone can be malicious except the honest user.
Definition 11
(Theft Resistance).  TX is theft resistant if
Adv TX , p p ( λ , L ) TR , A = P r Game TX , p p ( λ , L ) TR , A = ? 1 ϵ ( λ ) .
  • Game TX , p p ( λ , L ) TR , A : ̲   chain A s t e p 1 ( p p ( λ , L ) )
  • if  TX . chain _ ver ( p p ( λ , L ) , chain ) : return ⊥
  • T = | chain . headers |
  • ⊳ Receive coin tx from A s.t. A does not know the key of coin .
  • chain = TX . aggregate ( p p ( λ , L ) , chain , tx )
  • chain A s t e p 2 ( p p ( λ , L ) , chain )
  • ⊳ Check whether the coin has been spent or not
  • return TX . chain _ ver ( p p ( λ , L ) , chain )
  •      coin chain . ucoins
  •      [ chain . headers i ] i = 0 T + 1 = ? [ chain . headers ] i = 0 T + 1
Informally, blockchains’ immutability states that generating two different input and output sets for the same consensus data should be computationally infeasible. Because we build TX for a generic consensus mechanism, we capture the immutability such that finding two different input and output sets for the same header(s) is computationally difficult. Therefore, preserving headers is sufficient to provide immutability to the whole blockchain, including removed spent coin records.
Definition 12
(Immutability).  TX ensures immutability if
Adv TX , p p ( λ , L ) IM , A = P r Game TX , p p ( λ , L ) IM , A = ? 1 ϵ ( λ ) .
  • Game TX , p p ( λ , L ) IM , A : ̲   ( tx , tx ) A ( p p ( λ , L ) )
  • return TX . ver ( p p ( λ , L ) , tx ) TX . ver ( p p ( λ , L ) , tx )
  • ( tx . in . com , tx . out . com ) ? ( tx . in . com , tx . out . com )
  •           tx . header . Δ = ? tx . header . Δ
Theorem 4.
TX is complete, computationally theft-resistant, zero-knowledge, and immutable if Approx-SISs of ( n , m , q , γ , γ , N ) and ( n , m 3 , q , γ , γ , N ) are hard (see the security proofs in Appendix C).

4. Implementation

We implement a C library ref. [25] for LACT+ aiming to achieve 128-bit security. Therefore, a root-Hermite factor δ = 1.004 was used for lattices implementations allowing a gap for future attacks ref. [37]. A prime-order multiplicative group H with at least multiplicative 2 384 elements was used for membership proofs. The prime order of H is q 2 such that ( q 2 1 ) / 2 > 2 3 λ is also prime ( q 2 = 3a2c6ad1f4ef4084fbf76e7c6201b32850c57c408a6e0c4a6cda6c290c61e6dadd4e6b7312dd3aa6bd610a917c1d42f03). The concrete parameters used for tests are defined in Table 2. According to the parameters, a coin record is 29.9 KB (a commitment and a range proof), and a public key is 5760 Bytes.
We use two multiplications: number theoretic transform (NTT) for regular polynomials and an easy multiplication when one of the polynomials is a rot ( , ) (see below). The C library uses 64-bit integers except for the NTT, which uses 128-bit integers. In NTT multiplication, we convert polynomials to NTT space using Cooley–Tukey butterflies ref. [39], point-wise multiply them using Montgomery point-wise multiplications ref. [40], and then convert them back using inverse-transform from Gentleman–Sande butterflies ref. [41].
Recall that rot ( v i , i ) is a polynomial where coefficient i is v i , and all other coefficients are zero. Therefore, a multiplication of a rot ( v i , i ) is computed as follows: convert coefficients in [ N i , N ) into their negative values, rotate all coefficients by i, and multiply all coefficients by v i . Because this is faster than NTT multiplication, we use this easy multiplication whenever possible, e.g., most of the short-norm vectors in CARRY .
We chose bits’ masking keys from [ α , α ] such that some functional polynomials like Step 29 in COIN and Step 53 in CARRY can be larger than γ . However, there is a high probability that they will be in the accepted range due to centrally reduced numbers. Therefore, we perform norm checks during the generation of COIN and CARRY to ensure completeness.
All the benchmarks were configured as follows: The maximum coin amount and the initial coinbase value are 2 64 1 . Here, we use “aggregated size” to denote the database size, which is slightly larger than theoretical sizes due to indexing and identifiers. “Deleted size” means the exact size of deleted coin records as explained in Section 3.1. Therefore, “unaggregated size” is computed as the summation of the aggregated and deleted sizes. The verification times are measured on an i7-1065G7 CPU at 1.30GHz. Furthermore, [ x : y ] denotes that the number of inputs and outputs are randomly chosen from [ 1 , x ] and [ 1 , y ] .
Efficiency of New Carry Proofs. First, we run benchmarks to get the sizes of new carry proofs and LACT carry proofs. Recall that LACT creates multiple LACT transactions if the numbers of input coins and out coins are larger than two. Therefore, the size impact of carry proofs to the total blockchain is proportional to the number of transactions, whereas in LACT+, this impact is now logarithmic. We simulate carry proof benchmarks to see this size and verification time impact for normal transactions where the input size can be larger than two. Figure 5 and Figure 6 show the accumulated sizes and total verification times for carry proof(s) of LACT and LACT+. From the graphs, we conclude that new LACT+ carry proofs are more efficient than LACT carry proofs. Therefore, the whole system is more efficient than prior post-quantum CT schemes, from unaggregated ones to aggregated ones like LACT, in spite of its other added benefits such as fully trustless verifiable immutability.
Impact of Aggregation. The main efficiency mechanism of LACT+ is transaction aggregation. The impact of the transaction aggregation changes according to input/output rates because more unspent outputs lead to larger blockchains. We ran benchmarks for different input/output rates, and we show the results in Figure 7. From the graph, we see that even if the output rate is higher than the input rate, aggregation achieves significant reductions in size. Verification times for these benchmarks are shown in Figure 8.
A Theoretical Comparison with MatRiCT+ Esgin et al. proposed ref. [22], an efficient lattice-based Ring CT protocol that uses the Chinese Remainder Theorem (CRT) packing, e.g., packing all L number of z into a single polynomial. Even without CRT packing, LACT+ is more efficient than MatRiCT+ as illustrated in Figure 9.

5. Conclusions

Aggregable confidential transactions are more private and scalable than typical transactions. However, the scalability of previous aggregable transactions does not provide trustless verification at the consensus level because real-world transactions should be immutable. LACT+ post-quantum aggregable confidential transactions solve this problem by adding aggregable activity proofs. Equally importantly, LACT+ is more efficient and faster than existing post-quantum aggregable transactions due to our use of approximate SIS and logarithmic carry proofs. LACT+ is the first practical post-quantum aggregable confidential transaction protocol that provides consensus-level aggregation and fully trustless verification.

Author Contributions

Conceptualization, J.A.; Writing-original draft, J.A.; Writing—review, editing, X.B. and M.M.; Supervision, X.B. and M.M. All authors have read and agreed to the published version of the manuscript.

Funding

This research received no external funding.

Data Availability Statement

Not applicable.

Conflicts of Interest

The authors declare no conflict of interest.

Appendix A. Security Proofs of Confidential Coins

  • Binding. We claim COIN is binding because finding two openings ( v , k ) ( v , k ) for the same coin record means the adversary finds a solution to the Approx-SIS problem such that
    s = [ binary ( v ) , k , 0 m 2 ] [ binary ( v ) , k , 0 m 2 ] 0 m s γ and highbits γ ( H s ) = 0 n R q n .
  • Knowledge Soundness. Let there be a p.p.t. algorithm that breaks the knowledge soundness such that the extractor E outputs b of number not in [ 0 , 2 L ) for a valid proof. According to the verification in Step 44, the algorithm finds s for [ z i = x 2 rot ( b i , i ) + a i ] i = 0 L 1 R L such that b i is not 0 or 1, but
    highbits γ ( H s ) ? highbits γ ( x 2 ( x 1 u + t 1 ) + t 2 ) R q n .
Because b i is not 0 or 1, the following is true,
highbits γ ( x 2 2 [ H [ 0 , i = 0 L ( rot ( b i ( b 1 1 ) , i ) ) , 0 m 2 h 0 m ] ) = 0 n R q n .
Here, h  is a solution to the Approx-SIS problem. Therefore, we claim range proofs are knowledge sound.
  • Zero-Knowledge Argument of Range Proofs.  z i statistically hides b i because z i = b i x 2 + a i [ ( α 1 ) , ( α 1 ) ] when the range of a i is [ α , α ] . We claim the computational hiding for commitments ( u , t 1 , t 2 ) of COIN due to dropped bits of Approx-SIS and sufficient randomness of k , r 1 , r 2 (see ref. [26]). If there is a p.p.t. algorithm that breaks the zero-knowledge argument by successfully distinguishing the generated proofs over the simulated proofs, then the algorithm can be used to break the hiding property of the commitments; in other words, solving the Approx-SIS problem. Therefore, we claim that the range proofs satisfy the zero-knowledge argument.
Finally, we prove that Theorem 2 is true because COIN is complete (Figure 3), binding, knowledge-sound, and zero-knowledge.

Appendix B. Security Proofs of Carry Proofs

  • Knowledge Soundness If there is an algorithm that breaks the knowledge soundness of CARRY then it creates
    highbits γ x 2 2 H 0 , l = 0 L | out | i = 0 L ( rot ( c 1 , i ( c 1 , i , l 1 ) , i L | out | + l ) ) l = 0 L | in | i = 0 L ( rot ( c 0 , i , l ( c 0 , i 1 ) , i L | in | + l ) ) , 0 m 3 h 0 m = 0 n
    for invalid binary vectors of carries; c 0 and c 1 which are not 0 nor 1 (see Step 22).
Here, h is a solution to Approx-SIS problem. Therefore, we conclude that CARRY is knowledge sound.
  • Zero-Knowledge Argument. Due to the rejection sampling, z 0 and z 1 statistically hide bits of both input carries and output carries. Furthermore, commitments u , t 1 and t 2 hide their short vectors due to the Approx-SIS problem. Therefore, we claim CARRY holds the zero-knowledge argument property.
Finally, we conclude Theorem 3 is accurate due to the above proofs. Or CARRY is complete (Figure 4), computationally knowledge sound, and holds the zero-knowledge argument property.

Appendix C. Security Proofs of Aggregable CT

  • Theft Resistance. If a p.p.t. algorithm wins the game of theft resistance, then the algorithm creates a transaction with a valid signature unknowing the secret key. In other words, the algorithm breaks EUF-CMA of SIG defined in Section 2.6, knowledge soundness of COIN , or knowledge soundness of CARRY . Therefore, if COIN , CARRY , and SIG are secure, then TX is theft resistant.
  • Zero-Knowledge and Knowledge Soundness. Suppose a p.p.t. algorithm creates a chain with more or less unspent coins than the supplied coins. In that case, the algorithm either breaks COIN ’s knowledge soundness, CARRY ’s knowledge soundness, or forges a signature for a public key with non-zero beginning polynomials. Therefore, we conclude that TX is knowledge soundness when COIN , CARRY , and SIG are secure. We directly claim the zero-knowledge of TX because COIN , CARRY , and SIG are zero-knowledge.
  • Immutability.  TX ’ immutability states that no p.p.t algorithm can find two different valid transactions with the same membership proof but with different in/out commitment sets. If an algorithm wins the game of immutability, then the algorithm solves the group collision resistance problem (GCR). Therefore, if GCR is computationally hard, TX is computationally immutable.
Therefore, we claim Theorem 4 is true or TX is complete, computationally theft-resistant, zero-coin generating, and immutable.

References

  1. Zhang, H.; Zhang, F.; Wei, B.; Du, Y. Implementing confidential transactions with lattice techniques. IET Inf. Secur. 2019, 14, 30–38. [Google Scholar] [CrossRef]
  2. Alupotha, J.; Boyen, X.; Mckague, M. Aggregable Confidential Transactions for Efficient Quantum-Safe Cryptocurrencies. IEEE Access 2022, 10, 17722–17747. [Google Scholar] [CrossRef]
  3. Androulaki, E.; Karame, G.O.; Roeschlin, M.; Scherer, T.; Capkun, S. Evaluating User Privacy in Bitcoin. In Proceedings of the Financial Cryptography and Data Security, Okinawa, Japan, 1–5 April 2013; Sadeghi, A.R., Ed.; Springer: Berlin/Heidelberg, Germany, 2013; pp. 34–51. [Google Scholar]
  4. Spagnuolo, M.; Maggi, F.; Zanero, S. BitIodine: Extracting Intelligence from the Bitcoin Network. In Proceedings of the Financial Cryptography and Data Security, Okinawa, Japan, 1–5 April 2013; Christin, N., Safavi-Naini, R., Eds.; Springer: Berlin/Heidelberg, Germany, 2014; pp. 457–468. [Google Scholar]
  5. Fleder, M.; Kester, M.S.; Pillai, S. Bitcoin transaction graph analysis. arXiv 2015, arXiv:1502.01657. [Google Scholar]
  6. Reid, F.; Harrigan, M. An Analysis of Anonymity in the Bitcoin System. In Proceedings of the 2011 IEEE Third International Conference on Privacy, Security, Risk and Trust and 2011 IEEE Third International Conference on Social Computing, Boston, MA, USA, 9–11 October 2011; pp. 1318–1326. [Google Scholar] [CrossRef]
  7. Herrera-Joancomartí, J. Research and Challenges on Bitcoin Anonymity. In Data Privacy Management, Autonomous Spontaneous Security, and Security Assurance; Garcia-Alfaro, J., Herrera-Joancomartí, J., Lupu, E., Posegga, J., Aldini, A., Martinelli, F., Suri, N., Eds.; Springer International Publishing: Cham, Switzerland, 2015; pp. 3–16. [Google Scholar]
  8. Khalilov, M.C.K.; Levi, A. A survey on anonymity and privacy in bitcoin-like digital cash systems. IEEE Commun. Surv. Tutor. 2018, 20, 2543–2585. [Google Scholar] [CrossRef]
  9. Morris, L. Anonymity Analysis of Cryptocurrencies. Master’s Thesis, Rochester Institute of Technology, Rochester, NY, USA, 2015. Available online: https://scholarworks.rit.edu/theses/8616/ (accessed on 10 January 2023).
  10. Jedusor, T.E. Mimblewimble. 2016. Available online: https://docs.beam.mw/Mimblewimble.pdf (accessed on 10 January 2023).
  11. Poelstra, A. Mimblewimble. 2016. Available online: https://download.wpsoftware.net/bitcoin/wizardry/mimblewimble.pdf (accessed on 10 January 2023).
  12. Poelstra, A.; Back, A.; Friedenbach, M.; Maxwell, G.; Wuille, P. Confidential assets. In Proceedings of the International Conference on Financial Cryptography and Data Security, Nieuwpoort, Curaçao, 26 February–2 March 2018; Springer: Berlin/Heidelberg, Germany, 2018; pp. 43–63. [Google Scholar]
  13. Fuchsbauer, G.; Orrù, M.; Seurin, Y. Aggregate Cash Systems: A Cryptographic Investigation of Mimblewimble. In Proceedings of the Advances in Cryptology—EUROCRYPT 2019, Darmstadt, Germany, 19–23 May 2019; Ishai, Y., Rijmen, V., Eds.; Springer: Cham, Switzerland, 2019; pp. 657–689. [Google Scholar]
  14. Alupotha, J.; Boyen, X.; Foo, E. Compact Multi-Party Confidential Transactions. In Proceedings of the Cryptology and Network Security, Vienna, Austria, 14–16 December 2020; Krenn, S., Shulman, H., Vaudenay, S., Eds.; Springer: Cham, Switzerland, 2020; pp. 430–452. [Google Scholar]
  15. IBM-Research. IBM’s Roadmap for Scaling Quantum Technology. Available online: https://research.ibm.com/blog/ibm-quantum-roadmap (accessed on 21 March 2022).
  16. Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008. Available online: https://bitcoin.org/bitcoin.pdf (accessed on 10 January 2023).
  17. Wood, G. Ethereum: A Secure Decentralised Generalised Transaction Ledger; Ethereum project yellow paper; Ethereum: Zug, Switzerland, 2014; Volume 151, pp. 1–32. [Google Scholar]
  18. Noether, S.; Mackenzie, A.; the Monero Research Lab. Ring confidential transactions. Ledger 2016, 1, 1–18. [Google Scholar] [CrossRef]
  19. Sun, S.F.; Au, M.H.; Liu, J.K.; Yuen, T.H. RingCT 2.0: A Compact Accumulator-Based (Linkable Ring Signature) Protocol for Blockchain Cryptocurrency Monero. In Proceedings of the Computer Security—ESORICS 2017, Oslo, Norway, 11–15 September 2017; Foley, S.N., Gollmann, D., Snekkenes, E., Eds.; Springer: Cham, Switzerland, 2017; pp. 456–474. [Google Scholar]
  20. Esgin, M.F.; Zhao, R.K.; Steinfeld, R.; Liu, J.K.; Liu, D. MatRiCT: Efficient, scalable and post-quantum blockchain confidential transactions protocol. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, London, UK, 11–15 November 2019; pp. 567–584. [Google Scholar]
  21. Alberto Torres, W.; Kuchta, V.; Steinfeld, R.; Sakzad, A.; Liu, J.K.; Cheng, J. Lattice RingCT V2.0 with Multiple Input and Multiple Output Wallets. In Proceedings of the Information Security and Privacy, Prague, Czech Republic, 23–25 February 2019; Jang-Jaccard, J., Guo, F., Eds.; Springer: Cham, Switzerland, 2019; pp. 156–175. [Google Scholar]
  22. Esgin, M.F.; Steinfeld, R.; Zhao, R.K. MatRiCT+: More Efficient Post-Quantum Private Blockchain Payments. Cryptol. ePrint Arch. 2021, 545, 1–21. [Google Scholar]
  23. Grin tech.org. Minimal Implementation of the MimbleWimble Protocol. Available online: https://github.com/mimblewimble/grin (accessed on 27 January 2021).
  24. Scalable Confidential Cryptocurrency—MimbleWimble Implementation. Available online: https://www.beam.mw/ (accessed on 27 January 2021).
  25. Alupotha, J. LACT+: Post-Quantum Aggregable Confidential Transactions. 2022. Available online: https://github.com/jaymine/LACTv2 (accessed on 11 January 2023).
  26. Chen, Y.; Genise, N.; Mukherjee, P. Approximate trapdoors for lattices and smaller hash-and-sign signatures. In Proceedings of the International Conference on the Theory and Application of Cryptology and Information Security, Kobe, Japan, 8–12 December 2019; Springer: Berlin/Heidelberg, Germany, 2019; pp. 3–32. [Google Scholar]
  27. Regev, O. On lattices, learning with errors, random linear codes, and cryptography. J. ACM 2009, 56, 34. [Google Scholar] [CrossRef]
  28. Ajtai, M. Generating hard instances of lattice problems. In Proceedings of the Twenty-Eighth Annual ACM Symposium on Theory of Computing, Philadelphia, PA, USA, 22–24 May 1996; ACM: New York, NY, USA, 1996; pp. 99–108. [Google Scholar]
  29. Alupotha, J.; Boyen, X. Origami Store: UC-Secure Foldable Datachains for The Quantum Era. IEEE Access 2021, 9, 81454–81484. [Google Scholar] [CrossRef]
  30. Noether, S.; Noether, S. Monero Is Not That Mysterious. Technical Report. 2014. Available online: https://web.getmonero.org/ru/resources/research-lab/pubs/MRL-0003.pdf (accessed on 11 January 2023).
  31. Maxwell, G. Confidential Transactions. 2015. Available online: https://people.xiph.org/greg/confidential_values.txt (accessed on 11 January 2023).
  32. Fiat, A.; Shamir, A. How To Prove Yourself: Practical Solutions to Identification and Signature Problems. In Proceedings of the Advances in Cryptology—CRYPTO’ 86, Santa Barbara, CA, USA, 1 January 1987; Odlyzko, A.M., Ed.; Springer: Berlin/Heidelberg, Germany, 1987; pp. 186–194. [Google Scholar]
  33. Pointcheval, D.; Stern, J. Security arguments for digital signatures and blind signatures. J. Cryptol. 2000, 13, 361–396. [Google Scholar] [CrossRef]
  34. Abdalla, M.; An, J.H.; Bellare, M.; Namprempre, C. From Identification to Signatures via the Fiat-Shamir Transform: Minimizing Assumptions for Security and Forward-Security. In Proceedings of the Advances in Cryptology—EUROCRYPT 2002, Amsterdam, The Netherlands, 28 April–2 May 2002; Knudsen, L.R., Ed.; Springer: Berlin/Heidelberg, Germany, 2002; pp. 418–433. [Google Scholar]
  35. Lyubashevsky, V. Lattice-Based Identification Schemes Secure Under Active Attacks. In Proceedings of the Public Key Cryptography—PKC 2008, Barcelona, Spain, 9–12 March 2008; Cramer, R., Ed.; Springer: Berlin/Heidelberg, Germany, 2008; pp. 162–179. [Google Scholar]
  36. Lyubashevsky, V. Fiat-Shamir with Aborts: Applications to Lattice and Factoring-Based Signatures. In Proceedings of the Advances in Cryptology—ASIACRYPT 2009, Tokyo, Japan, 6–10 December 2009; Matsui, M., Ed.; Springer: Berlin/Heidelberg, Germany, 2009; pp. 598–616. [Google Scholar]
  37. Albrecht, M.R. LWE Estimator. Available online: https://lwe-estimator.readthedocs.io/en/latest/readme_link.html (accessed on 22 October 2021).
  38. Gleen, M.L. Device for and Method of One-Way Cryptographic Hashing. U.S. Patent 6829355, 12 July 2004. [Google Scholar]
  39. Gauss, C.F. Nachlass: Theoria interpolationis methodo nova tractata. Carl Friedrich Gauss Werke 1866, 3, 265–327. [Google Scholar]
  40. Montgomery, P.L. Modular multiplication without trial division. Math. Comput. 1985, 44, 519–521. [Google Scholar] [CrossRef]
  41. Gentleman, W.M.; Sande, G. Fast Fourier transforms: For fun and profit. In Proceedings of the Fall Joint Computer Conference, San Francisco, CA, USA, 7–10 November 1966; pp. 563–578. [Google Scholar]
Figure 1. LACT+ transaction structure.
Figure 1. LACT+ transaction structure.
Cryptography 07 00024 g001
Figure 2. Transaction aggregation.
Figure 2. Transaction aggregation.
Cryptography 07 00024 g002
Figure 3. A graphical overview of confidential coins (Algorithm 3).
Figure 3. A graphical overview of confidential coins (Algorithm 3).
Cryptography 07 00024 g003
Figure 4. Graphical overview of carry proofs (Algorithm 4).
Figure 4. Graphical overview of carry proofs (Algorithm 4).
Cryptography 07 00024 g004
Figure 5. Carry proof sizes.
Figure 5. Carry proof sizes.
Cryptography 07 00024 g005
Figure 6. Carry proof verification times.
Figure 6. Carry proof verification times.
Cryptography 07 00024 g006
Figure 7. Aggregated sizes and unaggregated sizes vs. transactions.
Figure 7. Aggregated sizes and unaggregated sizes vs. transactions.
Cryptography 07 00024 g007
Figure 8. Verification times vs. transactions for different input and output rates.
Figure 8. Verification times vs. transactions for different input and output rates.
Cryptography 07 00024 g008
Figure 9. LACT+ and MatRiCT+: For MatRiCT, Coins ( cn ) are 4.48 KB, public keys are 3.4 KB, and ( 2 2 ) proofs are 47 KB at 1/11 anonymity.
Figure 9. LACT+ and MatRiCT+: For MatRiCT, Coins ( cn ) are 4.48 KB, public keys are 3.4 KB, and ( 2 2 ) proofs are 47 KB at 1/11 anonymity.
Cryptography 07 00024 g009
Table 1. Comparison of Confidential Transactions.
Table 1. Comparison of Confidential Transactions.
ImplementationPost
Quantum
SecurityAggregableImmutable
Headers
Ring CT  ref. [30]DLP-
Maxwell’s CT  ref. [31]DLP-
Mimblewimble  ref. [10]DLP
Ring CT v2  ref. [19]DLP-
Fuchsbauer et al.  ref. [13]DLP
Lattice Ring CT  ref. [21]SIS-
MATRiCT  ref. [20]MSIS-
Zhang et al.  ref. [1]SIS
MATRiCT+  ref. [22]MSIS/LWE-
LACT  ref. [2]SIS/MSIS
Ours (LACT+)Approx-SIS
Table 2. Concrete Parameters and Variables.
Table 2. Concrete Parameters and Variables.
ParameterValueDescription
( n , m ) (6, 4)Approx-SIS hard
N256Polynomial Size
q 2 44 2 14 + 1 q = 1 ( mod 2 N )
L , 2 L 64, 15Ranges
γ 2 36 Short-Vector Norm
γ 2 36 Error Norm
β 60 log 2 N β + β 256
log ( p 1 ) , log ( p 2 ) 17, 29 < log ( γ ) , < log ( γ )
α ( + log 2 ( | L | / 2 ) ) 2 9 to 2 11 maximum 16 in/outputs
τ , τ 1 , τ 2 2 4 1 , 2 7 1 , 2 28 1 < γ
τ 3 2 16 < 2 L γ
χ 60 · 1 Norm of Hints
| x | 48 bytesSHAKE256 ref. [38]
| Δ | 49 bytesActivity Proofs
highbits p 1 ( · ) 5.7 KBPacked High-bits
highbits p 2 ( · ) 3.1 KBPacked High-bits
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

MDPI and ACS Style

Alupotha, J.; Boyen, X.; McKague, M. LACT+: Practical Post-Quantum Scalable Confidential Transactions. Cryptography 2023, 7, 24. https://doi.org/10.3390/cryptography7020024

AMA Style

Alupotha J, Boyen X, McKague M. LACT+: Practical Post-Quantum Scalable Confidential Transactions. Cryptography. 2023; 7(2):24. https://doi.org/10.3390/cryptography7020024

Chicago/Turabian Style

Alupotha, Jayamine, Xavier Boyen, and Matthew McKague. 2023. "LACT+: Practical Post-Quantum Scalable Confidential Transactions" Cryptography 7, no. 2: 24. https://doi.org/10.3390/cryptography7020024

Article Metrics

Back to TopTop