cryptography

: A “ conﬁdential monetary value ” carries information about the real monetary value but does not disclose it. Post-quantum private blockchains with conﬁdential monetary values—large-sized blockchains with large veriﬁcation 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 conﬁdential monetary blockchains, LACT+ ( Lattice-based Aggregable Conﬁdential Transactions ), which is more scalable than previous post-quantum conﬁdential blockchains, i.e., many input/output transactions with logarithmic sized complexity.


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

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 • 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 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 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  [1,[10][11][12][13][14]. In the previous equation, if participants do not generate coins illegally, they can create digital signatures for pk using the aggregated secret key ∑ * i=0 k i − ∑ * i=0 k i . Hence a signature of pk 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 = ∑ 63 i=0 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.

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 Cryptography 2023, 7, 24 5 of 24 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. 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

Preliminary
An integer ring is Z/qZ = Z q which has integers in [− q−1 2 , . A polynomial is denoted with an upper arrow, e.g., a that is in R or 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 pp (λ) . We only use the following norms: the infinity norm a = max([|a i |] N−1 i=0 ) and the level 1 norm a 1 = ∑ N−1 i=0 |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 = ∑ L i=0 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] N j=0,j =i . 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) = vs. · 2 p . We use these functions for polynomial vectors in an elementwise 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,

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(pp λ ), and D 0 be the simulated distribution created by a simulator S(pp λ , T ) with a trapdoor T of public parameter pp λ . For any A, P's outputs are hiding if 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, 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(pp λ , L, T ) with a trapdoor T of public parameter pp λ for L, and D 1 be the real output distribution of protocol P(pp λ ) for statements L. For any p.p.t. A, P's outputs are zero-knowledge if 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(pp λ , L, Π) verifies whether hidden values of Π satisfies L or not. P is simulated witness extractable if Technically, these extractors do not exist outside the simulated world because public parameters are securely generated to avoid unintentional trapdoors.

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,

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, Definition 5 (Immutability). An activity proof of (H, q ) is immutable if the following is less than or equal to (λ).

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.

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 ≤ Nl.
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
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.

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.

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.
Here, k is a secret key, a.k.a., blinding key, and L is defined in pp (λ,L) .
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 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(2b − 1), r 1 ) and sends it to V. After receiving a challenge x 1 from V, P replies with t 2 = com(xa, a 2 , r 2 ). Then, V sends the second challenge x 2 . After that, P computes z = (bx + a) and , 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( 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. [−τ+τ 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)  Creates coin records for v coins 2: COIN.gen(pp (λ,L) , v): 3: Short vector for the commitment 4: Get masking values for bits from Lazy Sampling Short key vectors for range proof commitments 11: 21: go to Step 5 22: Check norms 23 Step 5 25: Create hints for t 2 26:  Verify coin records 37: COIN.ver(pp (λ,L) , coin) : Use hints to recompute t 2 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 − (λ).
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.
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).

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 where c 0 and c L are zeros, and other c j s are either 0 or 1. Similarly, the output carries 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. (1) if inputs coins are equal to output coins.

Then, these binary vectors satisfy Equation
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) = Therefore, LACT headers contain carry 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.

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 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. |in|, |out| (≤ 2 L ) are the number of in/outputs, including supplied coins and transaction fee.

Definition 9 (Completeness)
. CARRY is complete if honestly generated proofs are always valid such that the following is greater than or equal to 1 − (λ).
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).

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.
, 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 pk is, , 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, pk) 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 pk and y, and compute σ = r − xr. The signature is (σ, x). If the input coins are equals to output coins, verifiers can recompute y := com(0, 0, 0, σ) − x × pk and check x ? =hash(pk, 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.

14:
y i = H[ 0, 0, 0, r 3,i ] ∈ R n q and share y i 15: All receivers compute public key pk ∈ R n q .

24:
if σ i > (τ 3 − βτ): go to Step 9 25: All receivers compute the signature 26: 27: if σ > ((|out| + |in|)τ 3 − (|out| + |in| + 1)βτ): 28: go to Step 9 29: y = highbits γ ( H σ − x 0 up p 1 ( pk)) ∈ R n q 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, 68: return highbits γ −p1 ( pk) = highbits γ (carry. u 69: 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. 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. 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.

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 = 3a2c6ad1f4ef4084fbf76e7c6201b32850c57c408 a6e0c4a6cda6c290c61e6dadd4e6b7312dd3aa6bd610a917c1d42f03). 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 arot(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. Figures 5 and 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.

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.

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 n q . 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 ] L −1 i=0 ∈ 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 n q . Because b i is not 0 or 1, the following is true, 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 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.