A Cryptocurrency Dual-Offline Payment Method for Payment Capacity Privacy Protection

Round 1

Reviewer 1 Report (Previous Reviewer 2)

Comments and Suggestions for Authors

The comments in the previous review report have been adequately addressed in the revised manuscript. However, there are still a couple of really important issues, which are:

1. 1. References [23], [26], and [32] are not peer-reviewed, please kindly use a peer-reviewed alternatives.
   2. Some references are published in non-indexed places such as [3] and [25], which reduces the credibility of the paper.

Comments on the Quality of English Language

1. Line 314: “This demonstrates our …” should be “This demonstrates that our …”
2. Better not to use first person tone (e.g., we, our ... etc.) in academic writing, it will be much better if you use passive tone instead.
3. Line 565: “method’s efficacy for …” should be “method efficacy for …”
4. Still several sentences throughout the manuscript are too long such as the sentences in lines 9-12, 263-267, 608-611 … etc.

Author Response

Response

Comment 1: The comments in the previous review report have been adequately addressed in the revised manuscript. However, there are still a couple of really important issues, which are:

• References [23], [26], and [32] are not peer-reviewed, please kindly use a peer-reviewed alternatives.
• Some references are published in non-indexed places such as [3] and [25], which reduces the credibility of the paper.

Response 1: Thank you for pointing this out. Regarding the crucial issue with the references, we sincerely appreciate your guidance in enhancing the academic rigor of our manuscript. We have fully addressed your concerns and have accordingly revised the reference list.

"[[26]Feng, Liu, et al. "A secure multi-party computation protocol combines Pederson commitment with Schnorr signature for blockchain." 2020 IEEE 20th international conference on Communication Technology (ICCT). IEEE, 2020.

[25]Allam A M. Privacy-Preserving NFC-Based Authentication Protocol for Mobile Payment System[J]. KSII Transactions on Internet & Information Systems, 2023, 17(5).]"

 

Response on the Quality of English Language

Comment 1: Line 314: “This demonstrates our …” should be “This demonstrates that our …”

Response 1: Thank you for pointing this out. We agree with this comment. Therefore, we have revised the sentence by adding the word “that” to correct the grammar.

"[This demonstrates that our...]"

 

Comment 2: Better not to use first person tone (e.g., we, our ... etc.) in academic writing, it will be much better if you use passive tone instead.

Response 2: Thank you for pointing this out. We fully agree and have systematically revised the entire text to eliminate first-person pronouns (“we”、“our”、“us”) and replaced them with passive voice or other impersonal constructions.

 

Comment 3: Line 565: “method’s efficacy for …” should be “method efficacy for …”

Response 3:Thank you for pointing this out.The text has been corrected as suggested.

"[method efficacy for...]"

 

Comment 4: Still several sentences throughout the manuscript are too long such as the sentences in lines 9-12, 263-267, 608-611 … etc.

Response 4:Thank you for pointing this out. We have thoroughly reviewed the entire manuscript and have systematically broken down overly long sentences to improve readability and clarity. The key strategy was to separate multiple ideas into distinct sentences and use clearer transitional words.

"[The method employs zero-knowledge proof technology to cryptographically protect sensitive information, such as the payer’s wallet balance, during identity verification and payment authorization. This provides a technical solution that balances verification reliability with privacy protection in dual-offline transactions.

This study clarifies that the method shares the fundamental zero-knowledge property of verifying truth without revealing secrets. However, its implementation differs from generic ZKP arithmetic circuits like zk-SNARKs. Specifically, it is realized as a specific cryptographic commitment scheme.]"

 

Author Response File: Author Response.pdf

Reviewer 2 Report (New Reviewer)

Comments and Suggestions for Authors

The formal properties of an NIZKP (completeness, soundness, zero-knowledge) require a definition of the language, the instance, and the witness, as well as a structured argument (or a reference to a known construct) demonstrating the simulability of the transcription. However, in the manuscript, the "proof" coincides with an aggregation of equations on elliptic points and the use of the Fiat–Shamir transformation to derive a challenge E (lines 336–340), without ever formally demonstrating the zero-knowledge entailed by a discussion of the requirements of the Random Oracle Model implied by Fiat–Shamir.

The expressions adopted for the signatures Ss and Sr are of the type “(K + E R)×G”, that is, they are elliptic points (lines 359–365; Table 1), i.e. formally attributable to a Schnorri/linear structure; nevertheless, ECDSA is invoked as one of the mechanisms employed (“application of … ECDSA”, p. lines 440–442), a statement that is technically irreconcilable with the equations presented, since ECDSA does not have an additive linear form in this way and produces pairs (r,s) on scalars with different relations. It follows that the existential unforgeability argument included among the assumptions (lines 399–403) is not well anchored to the framework defined in the text, thus risking the entire argument regarding resistance to tampering and counterfeiting being based on an improper reference.

The statement that the equation “holds only if … the input credential has a sufficient quantity (Vc)” (lines 303–305) cannot represent the original availability Vi and guarantee sufficiency in the accounting sense, since Vc is subsequently defined as the quantity of change (Table 1).

Furthermore, derivation (3) introduces masking factors Rc, Rr, Ri and concludes with (Rc + Rr − Ri)×G + 0 (lines 309–316), which is then rewritten as (Rs + Rr)×G (lines 364–365) using Rs = Rc − Ri without discussing the verifiability of the range constraint (e.g. Vr > 0 and Vr ≤ Vi) and the exclusion of negative or non-canonical values ​​in a modular context.

In the threat model, the adversary is defined as a third-party interceptor, and the possibility of extracting secrets from the hardware is explicitly excluded (lines 393–398). A similar treatment is missing for the most critical case for offline payments, in which the malicious payer deliberately attempts to respend before settlement.

In Section 4.2 the claim that double spending would be prevented because for each payment, new random numbers Rs and Rc are generated, making the credentials globally unique (lines 450–452), is insufficient because the uniqueness of a commitment does not equate to the uniqueness of the value spent if the same input credential can be reused with different proofs.

There is no detailed description of the reliable mechanism for ensuring atomicity on an offline device, how state duplication is prevented at the application or storage level (selective rollbacks, snapshotting, anti-rollback protection), and how payment concurrency is managed (even if only in the form of repeated attempts).

The conclusion that the computational impossibility of ECDLP would lead to information-theoretic privacy guarantees (lines 569–572) is confusing because a computationally private protocol might require more stringent parameters and assumptions (e.g., group selection, no side channels, correct H generation) and therefore cannot be presented as information-theoretic without a specific proof to that effect.

Regarding the generation of the initial points G and H, which would be obtained by generating a private key uniformly at random and computing its corresponding public key (lines 279–283), there are problems. If H is not an independent generator and the non-knowledge of the discrete log between G and H is not ensured, the entire commitment construction (which implicitly recalls Pedersen) may lose fundamental properties. It is therefore necessary to clarify how H is obtained in a secure and standard way (e.g., hash-to-curve), assuming a common parameter "nothing up my sleeve," and to describe solutions to avoid the case of a privileged entity choosing H with a trap door.

The fact that the proposed system was implemented in JavaScript with the elliptic library and measured on a Windows laptop (lines 498–501) represents a context that does not respect the typical constraints of hardened devices and a secure element, which makes it difficult to infer realistic performance for the claimed use.

The 100 transactions measurements characterized by a 100% successful validation (lines 517–524, 563–566) lack adversarial tests, replicable experimental comparisons with baselines, and an adequate statistical analysis.

Table 2 misses the criteria and references for each check.

Author Response

Response

Comment1: The formal properties of an NIZKP (completeness, soundness, zero-knowledge) require a definition of the language, the instance, and the witness, as well as a structured argument (or a reference to a known construct) demonstrating the simulability of the transcription. However, in the manuscript, the "proof" coincides with an aggregation of equations on elliptic points and the use of the Fiat–Shamir transformation to derive a challenge E (lines 336–340), without ever formally demonstrating the zero-knowledge entailed by a discussion of the requirements of the Random Oracle Model implied by Fiat–Shamir.

Response1:  Thank you for pointing out the lack of NIZKP’s formal properties, unproven zero-knowledge, and ROM requirements. We have made systematic revisions: added a paragraph in Section 3.2.1 to clarify NIZKP’s three formal properties (language L: valid transactions satisfying (V_i \geq V_r\) and \(V_i = V_c + V_r\); instance x: public transaction parameters; witness w: payer’s private key-related data and \(V_i\), kept confidential); supplemented the ROM declaration, confirming SHA256 meets uniform random output and input independence; and added a section in Section 4.2 explaining that the Fiat-Shamir transformation uses SHA256 to compute E, with ROM ensuring zero-knowledge (indistinguishable transcripts via simulation) and knowledge extractability, fully establishing the logical connection and enhancing the scheme’s cryptographic rigor.

 

Comment2: The expressions adopted for the signatures Ss and Sr are of the type “(K + E R)×G”, that is, they are elliptic points (lines 359–365; Table 1), i.e. formally attributable to a Schnorri/linear structure; nevertheless, ECDSA is invoked as one of the mechanisms employed (“application of … ECDSA”, p. lines 440–442), a statement that is technically irreconcilable with the equations presented, since ECDSA does not have an additive linear form in this way and produces pairs (r,s) on scalars with different relations. It follows that the existential unforgeability argument included among the assumptions (lines 399–403) is not well anchored to the framework defined in the text, thus risking the entire argument regarding resistance to tampering and counterfeiting being based on an improper reference.

Response2: We sincerely thank the reviewer for pointing out this technical inconsistency. We apologize for the improper use of the term "ECDSA." As the reviewer correctly noted, our scheme relies on a linear signature structure to support homomorphic verification and zero-sum auditing, which is fundamentally different from the standard ECDSA (which produces scalar pairs and lacks additive linearity).

“[This scheme adopts a Schnorr-like linear signature structure, whose additive linear property is naturally compatible with the zero-sum verification protocol.

The Fiat–Shamir transformation in this scheme is implemented using the SHA256 hash function. Here, we assume that SHA256 satisfies the core properties of the Random Oracle Model (ROM)—its output is uniformly random and independent of the input—laying the foundation for the zero-knowledge property and knowledge extractability of NIZKP.]”

 

Comment3: The statement that the equation “holds only if … the input credential has a sufficient quantity (Vc)” (lines 303–305) cannot represent the original availability Vi and guarantee sufficiency in the accounting sense, since Vc is subsequently defined as the quantity of change (Table 1).

Response3: Thank the reviewers for their keen observation. There is a sign misuse at Line 303. We mistakenly wrote the change amount (Vc) into the input amount (Vi). We have corrected this clerical error.

 

Comment4: Furthermore, derivation (3) introduces masking factors Rc, Rr, Ri and concludes with (Rc + Rr − Ri)×G + 0 (lines 309–316), which is then rewritten as (Rs + Rr)×G (lines 364–365) using Rs = Rc − Ri without discussing the verifiability of the range constraint (e.g. Vr > 0 and Vr ≤ Vi) and the exclusion of negative or non-canonical values ​​in a modular context.

Response4: Thank you for pointing this out. We acknowledge that the original manuscript does not fully explain how the system can prevent negative value attacks in an offline environment. In section 3.2.2, we added a detailed discussion on the scope constraint mechanism. In our dual offline architecture, before generating commitments and signatures, the scope check (Vr>0 and Vi ≥ Vr) is enforced by the internal logic of the security element .

 

Comment5: In the threat model, the adversary is defined as a third-party interceptor, and the possibility of extracting secrets from the hardware is explicitly excluded (lines 393–398). A similar treatment is missing for the most critical case for offline payments, in which the malicious payer deliberately attempts to respend before settlement.

Response5: Thank you for pointing this out. We have supplemented the corresponding attack scenario and improved the defense logic as follows:In Section 4.1.1 (Model Environment and Participant Assumptions), we added a dedicated "malicious payer’s double-spending attack scenario" as the 4th participant behavior assumption. This scenario clarifies the attacker’s core path: exploiting offline real-time verification absence to reuse the same input credential \(P_i\), forge supporting proofs (e.g., fake \(R_s\), \(R_c\)), complete local verification with multiple payees, and batch upload for settlement to conceal double-spending.

 

Comment6: In Section 4.2 the claim that double spending would be prevented because for each payment, new random numbers Rs and Rc are generated, making the credentials globally unique (lines 450–452), is insufficient because the uniqueness of a commitment does not equate to the uniqueness of the value spent if the same input credential can be reused with different proofs.

Response6:  we appreciate your comment on the insufficient argumentation for double-spending prevention and over-reliance on random numbers. We have thoroughly revised the relevant content to address these issues:We replaced the original "Defense Against Double-Spending Attacks" paragraph in Section 4.2 with a new argumentation framework centered on "atomic credential lifecycle management + secure hardware isolation". Specifically: (1) Atomic lifecycle management ensures that the input credential \(P_i\) is immediately marked invalid after a successful transaction (only the change credential \(P_c\) remains valid), and the system atomically rolls back to the pre-transaction state if verification fails, logically eliminating \(P_i\) reuse. (2) Secure hardware isolation stores core credentials (\(P_i\), \(P_c\)) and private key-related data (\(R_i\), \(K_s\)) in the SE, preventing extraction or copying and physically blocking \(P_i\) forgery.

 

Comment7: There is no detailed description of the reliable mechanism for ensuring atomicity on an offline device, how state duplication is prevented at the application or storage level (selective rollbacks, snapshotting, anti-rollback protection), and how payment concurrency is managed (even if only in the form of repeated attempts).

Response7:  Thank you for pointing out the lack of detailed mechanisms for atomicity and payment concurrency management. We have supplemented the corresponding mechanisms in key sections, ensuring completeness and feasibility:

Offline transaction atomicity: Added a three-level "snapshot-update-rollback" mechanism in Section 3.2.3 (Methodological Process). It creates an encrypted device state snapshot at transaction initialization, atomically updates the state (delete \(P_i\), activate \(P_c\)) after successful verification, and triggers hardware-level rollback if the transaction is interrupted, eliminating intermediate states.

Payment concurrency management: Added a "Bluetooth pairing binding + UUID uniqueness verification" dual mechanism after the "Dual-Offline Payment Phase" in Section 3.1. The payee’s SE generates a unique 6-digit pairing code to establish an exclusive 1-to-1 communication link, and each transaction is assigned a globally unique UUID (stored in a local blacklist after execution) to reject repeated requests. This eliminates concurrency conflicts from both communication and logic perspectives.

“[Transaction atomicity is guaranteed by a three-level "snapshot-update-rollback" mechanism: (1) At the initialization of the transaction, an encrypted snapshot of the device state (including credentials, balance, and private key-related parameters) is created; (2) After successful verification, the state is atomically updated (delete \(P_i\) and activate \(P_c\)), and the snapshot is automatically invalidated; (3) If verification fails or is interrupted (e.g., power outage, communication disconnection), a hardware-level rollback instruction is triggered to restore the pre-transaction state, eliminating intermediate states of "partial success". This mechanism operates entirely locally on the offline device without network dependence.

This phase adopts a "Bluetooth pairing binding + UUID uniqueness verification" dual mechanism to ensure one-to-one transaction execution: (1)Secure Bluetooth pairing prerequisite: Prior to data transmission, the payee’s Device B generates a unique 6-digit pairing code via its Secure Element (SE) (non-extractable and only displayed locally). The payer inputs the code to complete pairing, establishing an exclusive encrypted communication link that prevents the payer from connecting to multiple payees or receiving concurrent payment requests. (2) Transaction UUID uniqueness constraint: Each transaction is assigned a globally unique UUID during initialization. After transaction completion, the UUID is stored in the local blacklist of both devices; any repeated request with the same UUID (e.g., due to accidental reconnection) is immediately rejected. This dual mechanism eliminates concurrency risks from both communication links and transaction logic.]”

 

Comment8: The conclusion that the computational impossibility of ECDLP would lead to information-theoretic privacy guarantees (lines 569–572) is confusing because a computationally private protocol might require more stringent parameters and assumptions (e.g., group selection, no side channels, correct H generation) and therefore cannot be presented as information-theoretic without a specific proof to that effect.

Response8: We acknowledge that the term 'information theory privacy' is improperly used. In the revised version, we have corrected it to 'computational privacy', and reviewed the qualitative description of privacy intensity in the full text to ensure that it conforms to the cryptographic terminology specification.

 

Comment9: Regarding the generation of the initial points G and H, which would be obtained by generating a private key uniformly at random and computing its corresponding public key (lines 279–283), there are problems. If H is not an independent generator and the non-knowledge of the discrete log between G and H is not ensured, the entire commitment construction (which implicitly recalls Pedersen) may lose fundamental properties. It is therefore necessary to clarify how H is obtained in a secure and standard way (e.g., hash-to-curve), assuming a common parameter "nothing up my sleeve," and to describe solutions to avoid the case of a privileged entity choosing H with a trap door.

Response9: In order to eliminate the potential trap risk, we defined the generation process of base points in Section 3.2.1 of the revised draft. We use the standard 'Hash to Curve' method to generate mutually independent base points G and H, ensuring that there is no known discrete logarithmic relationship between them, thus strictly ensuring the binding promised by Pedersen.

 

Comment10: The fact that the proposed system was implemented in JavaScript with the elliptic library and measured on a Windows laptop (lines 498–501) represents a context that does not respect the typical constraints of hardened devices and a secure element, which makes it difficult to infer realistic performance for the claimed use.

Response10: Thank you for your comment. To address this, we have significantly expanded our experimental evaluation to include deployment and testing on a dedicated hardware wallet platform. The details of this hardware environment have been added to Section 5.2 (Experimental Environment Configuration) of the revised manuscript. The hardware wallet is equipped with a Secure Element (SE) that provides accelerated cryptographic operations for the secp256k1 elliptic curve, which is fundamental to our protocol. Its key specifications are: 16 MB of Flash memory for program and credential storage, 8 MB of RAM for runtime operations, and integrated Bluetooth for device-to-device communication in offline scenarios. Furthermore, the device incorporates multiple active hardware security protection mechanisms, including voltage, temperature, and light sensors, tamper detection, and resistance to Differential Power Analysis (DPA) and Simple Power Analysis (SPA), ensuring a high level of physical security. We conducted a dedicated performance evaluation on this hardware platform, simulating 100 complete dual-offline payment processes (matching the scale of our software tests). All transactions were executed successfully and stably, with a 100% success rate. The key performance metrics—the payment generation time and payment verification time—are illustrated in Figure 4, showing their trends and average values. The hardware implementation achieved an average generation time of 129.7 ms and an average verification time of 64.1 ms, with these two core operations together constituting the complete offline payment processing. The minor fluctuations observed confirm the stable performance of our protocol within the constraints of resource-limited secure hardware. These results demonstrate that our protocol's cryptographic operations are not only efficient in a software prototype but are fully deployable and performant in a realistic, hardened hardware context. The total time for generation and verification falls within the realm of instantaneous response at the user interaction level, ensuring a seamless payment experience while leveraging the superior key isolation and attack resilience of a dedicated security device. These additions strengthen the practical relevance of our work and directly support our claim of providing a viable dual-offline payment solution for real-world secure hardware.

 

Comment11: The 100 transactions measurements characterized by a 100% successful validation (lines 517–524, 563–566) lack adversarial tests, replicable experimental comparisons with baselines, and an adequate statistical analysis.

Response11: Thank you for your comment on benchmark testing. We conducted comparative analysis with two representative schemes, with data derived from their official experimental results:(1) TEE-based scheme (Jie et al., 2024)：Avg. payment generation time 32 ms, single-transaction verification time ~16.7 ms (derived from 3-transaction verification time of 50 ms). (2) SE-based DOPS (Yang et al., 2023)：Minimum total transaction time 112 ms (including communication), core generation time ~80 ms. All benchmark data are directly cited from the referenced papers, verifying our scheme’s better balance between security and efficiency.

 

Comment12: Table 2 misses the criteria and references for each check.

Response12: We appreciate your valuable comment on Table 2. To address the lack of judgment criteria and reference basis, we have thoroughly revised the table as follows: we added a "Judgment Criteria" column to standardize the evaluation benchmark, we appended a table note explaining that the symbol "✓" indicates the scheme meets the corresponding judgment criteria, which are established based on the consensus of mainstream research in the field of dual-offline payments, avoiding ambiguity in comparative analysis.

 

 

Author Response File: Author Response.pdf

Round 2

Reviewer 2 Report (New Reviewer)

Comments and Suggestions for Authors

Some minor issues remain:

Comment 1: An explicit simulator construction and a formal sketch of transcription indistinguishability are still missing. The SHA256 assumption satisfies the ROM. It would be better to add a discussion regarding the related limitations.

Comment 4: The security analysis remains informal at the protocol level, and the dependency on the SE is not explicitly formalized within the security model.

Comment 11: I suggest adding that adversarial testing and experimental comparison will be the subject of future developments in the research conducted.

Author Response

Response

Comment 1: An explicit simulator construction and a formal sketch of transcription indistinguishability are still missing. The SHA256 assumption satisfies the ROM. It would be better to add a discussion regarding the related limitations.

Response1: Thank you for your valuable comment regarding the formalization of the zero-knowledge property. We have thoroughly revised the manuscript to address the missing explicit simulator construction, formal sketch of transcription indistinguishability, and discussion on SHA256’s limitations in the Random Oracle Model (ROM). Specifically, we added a new subsection 4.2.1 titled “Formal Zero-Knowledge Proof: Simulator Construction and Transcription Indistinguishability” in Section 4.2, where we constructed a polynomial-time simulator S that generates a simulated transcript indistinguishable from real protocol execution. The simulator setup, step-by-step simulation process (including simulating public parameters, challenge value E^s, signature S_s^s, and verification result), and formal proof of transcription indistinguishability are detailed, demonstrating that the advantage of any polynomial-time environment in distinguishing the simulated transcript from the real one is negligible.

Additionally, we supplemented the discussion on SHA256’s limitations in the “Cryptographic Hardness Assumptions” part of Section 4.1.1, clarifying the gap between the ideal ROM and real-world implementations (e.g., potential side-channel vulnerabilities, future quantum security risks, and fixed output length constraints), while explaining that these limitations are mitigated by the Secure Element’s hardware isolation and the protocol’s compatibility with post-quantum hash functions. These revisions further consolidate the cryptographic rigor of the proposed NIZKP mechanism, fully addressing your concerns.

 

Comment 4: The security analysis remains informal at the protocol level, and the dependency on the SE is not explicitly formalized within the security model.

Response4: We sincerely appreciate your insightful comment pointing out the informality of the protocol-level security analysis and the lack of explicit formalization of Secure Element (SE) dependency in the security model. To address this, we have made targeted revisions to strengthen the formality and rigor of the security framework.

First, we formally integrated the SE’s role into the security model by adding a dedicated “Secure Element (SE) Formal Assumptions” item in Section 4.1.1 (Model Environment and Participant Assumptions), which clearly defines three core properties of the SE—tamper-resistance, computational integrity, and secure I/O—with formal probability-based descriptions consistent with industrial security standards.

Second, we upgraded the protocol-level security analysis in Section 4.2 (Security Analysis and Proof) from descriptive to formalized derivation: for each defense mechanism (against transaction tampering, double-spending, and privacy theft attacks), we explicitly bind the effectiveness to the SE’s formal assumptions, providing rigorous logical derivations to show how the SE’s tamper-resistance prevents sensitive data leakage, computational integrity guarantees the correctness of cryptographic operations, and secure I/O ensures untampered communication between the SE and the main processor. These revisions explicitly formalize the SE’s dependency within the security model and enhance the formality of the security analysis, making the scheme’s security guarantees more solid and traceable.

 

Comment 11: I suggest adding that adversarial testing and experimental comparison will be the subject of future developments in the research conducted.

Response11: Dear Reviewer, we appreciate your suggestion on adversarial testing and experimental comparisons. We have added this as a key direction in the "Future Work" section (Section 6), planning to conduct comprehensive adversarial testing (e.g., differential power analysis, replay attacks) and extend comparisons with state-of-the-art schemes to validate practical robustness. Thank you for your constructive feedback.

 

Author Response File: Author Response.pdf

This manuscript is a resubmission of an earlier submission. The following is a list of the peer review reports and author responses from that submission.

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

Overall, this is a good paper. I have the following comments.

1. Missing quantitative results in the abstract - what are the actual performance metrics?
2. The review omits significant work on offline electronic cash systems from the cryptography literature (Chaum's blind signatures, compact e-cash schemes). 
3. The Experimental Environment description is fine, but you might add implementation details: which JS library is used for ECC, how randomness is generated, and whether the implementation is constant-time or purely functional (since timing can be affected by this). 
4. What is the actual zero-knowledge property being achieved? The protocol uses signatures, not standard ZKP.
   Where is the Fiat-Shamir transformation explicitly shown?
   What statement is being proven? "I know Rs such that..." - this needs formal specification.
5. You repeatedly introduce the terms Elliptic Curve Cryptography (ECC) and zero-knowledge proofs (ZKPs) throughout the manuscript, suggesting the use of AI tools. Please disclose how you used AI tools in your work.

Author Response

Comment 1: Missing quantitative results in the abstract - what are the actual performance metrics?

Response 1: Thank you for pointing this out. We agree with this comment. Therefore, we have revised the abstract to include the key quantitative performance metrics obtained from our experiments. The updated text can be found in the Abstract section, on page 1, lines 16-19 of the revised manuscript.

"[Theoretical analysis and experimental verification on 100 simulated transactions show that this method achieves an average payment generation latency of 29.13 ms and verification latency of 25.09 ms, significantly outperforming existing technology in privacy protection, computational efficiency, and security robustness.]"

 

Comment 2: The review omits significant work on offline electronic cash systems from the cryptography literature (Chaum's blind signatures, compact e-cash schemes).  

Response 2: Thank you for pointing this out. We agree with this comment. While our original manuscript did discuss recent e-cash schemes (e.g., [35], [36], [37]), we have now revised Section 2 to explicitly include and discuss the seminal contributions of Chaum's blind signatures and subsequent compact e-cash schemes. This provides a more complete academic context and allows for a clearer comparison between the properties of classical, general-purpose e-cash and our lightweight, scenario-specific design. The changes can be found in Section 2, on page 4, within the paragraph discussing electronic cash schemes.

"[The revised paragraph now begins by acknowledging Chaum's foundational work and compact e-cash, then proceeds to discuss recent schemes, and concludes with a strengthened comparative analysis that highlights the design trade-offs our method makes for the dual-offline payment scenario.]"

 

Comment 3: The Experimental Environment description is fine, but you might add implementation details: which JS library is used for ECC, how randomness is generated, and whether the implementation is constant-time or purely functional (since timing can be affected by this).

Response 3: Thank you for pointing this out. We agree with this comment. Therefore, we have expanded the "Experimental Environment" section to include the specified implementation details. These changes can be found in Section 5.2, on page 14, in a new paragraph titled "Implementation Details".

"[Implementation Details: The prototype was implemented in JavaScript. Elliptic curve operations (secp256k1) were performed using the elliptic library (v6.5.4). All random values (e.g., private keys, nonces) were generated using the cryptographically secure crypto.getRandomValues() Web API. The implementation relied on the underlying library's algorithms.]"

 

Comment 4: What is the actual zero-knowledge property being achieved? The protocol uses signatures, not standard ZKP. Where is the Fiat-Shamir transformation explicitly shown? What statement is being proven? "I know Rs such that..." - this needs formal specification.

Response 4: Thank you for pointing this out. We agree that clarification is needed regarding the protocol's construction. Therefore, we have added a formal clarification at the beginning of the methodology section to precisely define the protocol's nature and the zero-knowledge properties it achieves. This clarification can be found in Section 3.2, on page 6, in a newly added introductory paragraph. After that,we have now explicitly indicated the application of the Fiat-Shamir transformation in both the methodological description and Algorithm 1. The transformation is implemented in the computation of the challenge value E, where the hash function SHA256 acts as the random oracle, replacing an interactive verifier's challenge. The changes can be found in Section 3.2.3, on page 9, in the paragraph describing the generation of E, and in Algorithm 1, line 8, with an added comment.

"[The core of our proposed method is an interactive authentication protocol that leverages digital signatures and commitment schemes to achieve zero-knowledge properties, rather than being a generic zero-knowledge proof for arbitrary NP statements. Specifically, in our protocol, the payer proves to the payee that they possess a valid, authorized payment credential and that the transaction satisfies the zero-sum equation ($V_i = V_c + V_r$), without revealing the actual values of $V_i$, $V_c$, $V_r$ or the payer's secret key. This is achieved by working with cryptographic commitments ($P_i$, $P_c$, $P_r$) and demonstrating knowledge of the underlying secrets in a way that does not leak them during the signature-based challenge-response process. We have added the sentence: 'The payment information hash value E is then derived by applying the Fiat-Shamir transformation, where the interactive challenge is replaced by a hash function over the transcript. ' and annotated the corresponding step in Algorithm 1 with '▷ Fiat-Shamir transformation'.]"

 

Comment 5: You repeatedly introduce the terms Elliptic Curve Cryptography (ECC) and zero-knowledge proofs (ZKPs) throughout the manuscript, suggesting the use of AI tools. Please disclose how you used AI tools in your work.

Response 5: Thank you for pointing this out. We hereby confirm that no AI-powered text generation tools were used to create, draft, or generate any substantive content, technical descriptions, or ideas in this manuscript.

Author Response File: Author Response.docx

Reviewer 2 Report

Comments and Suggestions for Authors

1. The phrase in the title “with privacy protection” is so broad and should be quantified with a way that reflects the core contribution of the manuscript.
2. The abstract should highlight the key results of the study.
3. The introduction section contains many redundancy (e.g., privacy leakage, balancing verification … etc.). Also, it provides details of the provided approach that should appear in the methodology not in the introduction (e.g., credential phrasing, zero-sum equation … etc.). Moreover, the connection to the related study should be deepened, strengthened, and critically analyzed in the introduction.
4. The manuscript does not clearly answer the research question with an adequate depth, for example, no formal/simulation privacy proof, no comparison with ZKP models, no quantitative analysis of the security, no formal adversarial model, the provided comparison is so superficial (no cryptographic comparison, no performance metrics comparison, no benchmarking … etc.)
5. The literature review (section 2 in the manuscript) is neither sufficient nor recent, it mainly ignores recent related studies such as the recent studies in ZKP, Pedersen commitment model to which the provided approach is so similar to it, however, it is completely ignored in the manuscript, recent studies in ZK payment methods, ECC commitment … etc. Additionally, this section is basically descriptive rather than analytic. Hence, this section needs a lot of improvement.
6. The methodology is embedded inside the “Results” section, please kindly separate it into a separate section that should come before the results section for a clear structure of the manuscript.
7. 2 is not actually a flowchart, please kindly correct the caption to refer to correct type.
8. The provided ZKP should be fully assessed against ZKP cryptographic standards, since there are many requirements that have never been satisfied by the provided approach, since the provided ZKP is a kind of signature-based challenge-response approach not a ZKP, and it does not satisfy completeness, soundness, and above all zero-knowledge. Additionally, no adversarial model provided, no explicit proof for the information leak, no hardness assumption provided … etc. These are actually very critical points that must be provided since the methodology is far from being complete. Moreover, Algorithms 1 and 2 are incomplete, there is fundamental information that should be provided in them such as how the algorithms handle errors, the boundary conditions of each of them, in addition to the many steps in them are not listed. The paper actually relies on already known cryptographic constructs. Moreover, the paper fails to demonstrate a sound scientific contribution.
9. The “Credentials zero-sum results” in Table 1 does not guarantee zero knowledge, does not prevent some adversarial manipulation, it assumes the commitment homomorphism without proof, does not take into consideration the case when the values of the input variables are malicious … etc.
10. The results provided in the manuscript are not sufficient, for example, there should be experiments to test the security robustness of the provided approach (attack scenarios, tamper resistance, credential forging … etc.), the behavior of the provided approach for large number of payments, no formal privacy metric adopted and compared to related work … etc. Additionally, the comparative analysis provided is far from being complete, comparative analysis mainly ignores many recent baselines in this direction, and it is mostly qualitative. Moreover, it does not provide any kind of cryptographic cost comparison. Overall, the results provided are too limited for a proper scientific claim. Moreover, most of the writeup in the result section is descriptive rather than analytic.
11. The limitations of the provided approach are numerous (e.g., repeated offline spending, multi-hop offline payments, detailed discussion of malicious payer/payee, network reconnection complexities … etc.), however, minor mentioning of them are provided with minimal discussion.
12. There is a major concern for the reproducibility of the methodology and results listed in the manuscript. Mainly because of the incomplete description of the cryptographic steps, missing assumptions related to the adversarial model and trust assumptions, missing information for the measurement environment (e.g., CPU architecture, memory, operating system), many missing assumptions in the results section … etc.
13. The list of references used ignores or weakly covers several of the important topics in the paper. Additionally, some of the references used are old for certain topics given that there are a lot of recent references that can be adopted. For example, ZKP, ECC-based confidential transactions, the threat models for dual offline-payment … etc. Hence, there should be more recent references to cover such topics.
14. More than 30% of references are dated before 2020, which can be considered a bit old given the vast number of recent studies in such area. Additionally, more than 17% of references are dated before 2015, which can be considered as old. Please kindly consider using recent alternatives.
15. Some references in the reference list are not peer-reviewed such as [20], [27], [33], [35] … etc.
16. Some references in the reference list are not related / weakly related to the context of the manuscript such as [4], [7], [9], [11], [12], [13], [16], [17], [18], [19], and [33].
17. Some references in the reference list are unindexed/unranked such as [20], [24], [25], [27], [33], [35], and [36].
18. Some references in the reference list miss the complete referencing information such as [20], [27], and [33].

Comments on the Quality of English Language

1. Several sentences throughout the manuscript are too long such as the sentences in lines 24-27, 60-63, 217-219 … etc.
2. There are many grammatical/spelling mistakes and typos throughout the manuscript (the manuscript needs a full proofreading) such as:
   1. Line 8: “method for cryptocurrencies, aims to solve” should be “method for cryptocurrencies that aims to solve”
   2. Line 41: “It significantly improving payment system” should be “It significantly improves payment system”
   3. Line 113: “VolgaPay [20]proposed” should be “VolgaPay [20] proposed”, this typo is repeated in several locations in the manuscript such as lines 122, 123 … etc.
   4. Line 169: “during internet outages” should be “during Internet outages”
   5. Line 177: “authentication , our approach” should be “authentication, our approach”
   6. Lines 395, 296: “in offline environment” should be either “in offline environments” or “in an offline environment”
   7. Caption of Fig. 3: “100 dual-offline payment” should be “100 dual-offline payments”
   8. Line 453, 454: “during identity verification a payment capability by zero-knowledge proof technology” the sentence is not grammatically correct.
   9. Line 492: “Secure Elemen” should be “Secure Element”
   10. Line 492: “Trusted Execution Environmen” should be “Trusted Execution Environment”
   11. Please kindly use “Section” instead of “Chapter” in the last paragraph in the introduction.
   12. Line 449: “6. Conclude” should be “6. Conclusion”

                  … etc.

Author Response

Comment 1: The phrase in the title “with privacy protection” is so broad and should be quantified with a way that reflects the core contribution of the manuscript.

Response 1: Thank you for pointing this out. We agree that the original phrasing was too generic and did not sufficiently highlight the specific technical contribution of our work. To directly address this, we have revised the title to explicitly state the core cryptographic techniques that form the foundation of our privacy-preserving mechanism.

"[The title has been updated as follows in the revised manuscript: Revised Title: A Cryptocurrency Dual-Offline Payment Method for Payment Capacity Privacy Protection]"

 

Comment 2: The abstract should highlight the key results of the study.

Response 2: Thank you for pointing this out. We agree with this comment. Therefore, we have revised the abstract to include the key results obtained from our experiments. The updated text can be found in the Abstract section, on page 1, lines 16-19 of the revised manuscript.

"[Theoretical analysis and experimental verification on 100 simulated transactions show that this method achieves an average payment generation latency of 29.13 ms and verification latency of 25.09 ms, significantly outperforming existing technology in privacy protection, computational efficiency, and security robustness.]"

 

Comment 3: The introduction section contains many redundancy (e.g., privacy leakage, balancing verification … etc.). Also, it provides details of the provided approach that should appear in the methodology not in the introduction (e.g., credential phrasing, zero-sum equation … etc.). Moreover, the connection to the related study should be deepened, strengthened, and critically analyzed in the introduction.

Response 3: Thank you for pointing this out. We have streamlined the text by removing repetitive discussions concerning privacy leakage risks and the trade-offs in verification balancing, ensuring a more concise presentation of the problem statement. The updated text can be found in the Introduction section, on page 2 of the revised manuscript.

"[This paper proposes an innovative dual-offline payment method based on a specialized signature verification protocol with zero-knowledge properties. Unlike generic Zero-Knowledge Proof systems, our approach focuses specifically on concealing sensitive payment data through cryptographic commitments and challenge-response logic. To solve the privacy protection problem in offline scenarios, our method constructs a payment credential mechanism with dedicated generation and verification processes. The core of this mechanism is the novel combination of Elliptic Curve Cryptography and Zero-Knowledge Proof technology.]"

 

Comment 4: The manuscript does not clearly answer the research question with an adequate depth, for example, no formal/simulation privacy proof, no comparison with ZKP models, no quantitative analysis of the security, no formal adversarial model, the provided comparison is so superficial (no cryptographic comparison, no performance metrics comparison, no benchmarking … etc.)

Response 4: Thank you for pointing this out. We acknowledge that the initial manuscript lacked a formal definition of the threat environment. To address this, we have added a dedicated " Adversarial Model and Security Assumptions " subsection (Section 4.1) in the revised manuscript. In this section, we formally define the capabilities of potential attackers, including their ability to intercept offline communication channels and attempt differential privacy attacks. “[In the revised manuscript, Section 4.1 "Adversarial Model and Security Assumptions" has been added to define the attacker's capabilities and the security boundaries of the system.]”

 

Comment 5: The literature review (section 2 in the manuscript) is neither sufficient nor recent, it mainly ignores recent related studies such as the recent studies in ZKP, Pedersen commitment model to which the provided approach is so similar to it, however, it is completely ignored in the manuscript, recent studies in ZK payment methods, ECC commitment … etc. Additionally, this section is basically descriptive rather than analytic. Hence, this section needs a lot of improvement.

Response 5: Thank you for pointing this out We fully agree that the original section lacked sufficient coverage of recent studies and was overly descriptive. To address this, we have comprehensively revised Section 2 "Related Work" by supplementing cutting-edge research on ZKP, Pedersen commitment models, ECC commitments, and ZK payment methods, and transformed the section from descriptive to analytic by emphasizing critical comparisons with our work.

“[Fang Z, Yu J, Huang G, et al. PROMISE: A Pedersen Commitment-Based Transaction Hiding Scheme for Blockchain System[C]//Blockchain and Web3 Technology Innovation and Application Exchange Conference. Singapore: Springer Nature Singapore, 2025: 177-188.

Yu G. Simple Schnorr signature with Pedersen commitment as key[J]. Cryptology ePrint Archive, 2020.

Huang W. ECC-based three-factor authentication and key agreement scheme for wireless sensor networks[J]. Scientific Reports, 2024, 14(1): 1787.

Fariss M, El Gafif H, Toumanari A. A lightweight ECC-based three-factor mutual authentication and key agreement protocol for WSNs in IoT[J]. International Journal of Advanced Computer Science and Applications, 2022, 13(6).]”

 

Comment 6: The methodology is embedded inside the “Results” section, please kindly separate it into a separate section that should come before the results section for a clear structure of the manuscript.

Response 6: Thank you for pointing this out. We have reorganized the paper to ensure a logical flow. The new structure presents the system design, algorithmic details, and security protocols in Section 3, followed by the Theoretical Analysis in Section 4, and finally the Performance Evaluation in Section 5. “[The manuscript structure has been adjusted: Section 3 now exclusively details the Methodology, completely separated from the Evaluation results in Section 5.]”

 

Comment 7: 2 is not actually a flowchart, please kindly correct the caption to refer to correct type.

Response 7: Thank you for pointing this out. The caption has been corrected as suggested.

"[In the revised manuscript, it now reads: Figure 2. Protocol steps and cryptographic equations for the dual-offline payment.]"

 

Comment 8: The provided ZKP should be fully assessed against ZKP cryptographic standards, since there are many requirements that have never been satisfied by the provided approach, since the provided ZKP is a kind of signature-based challenge-response approach not a ZKP, and it does not satisfy completeness, soundness, and above all zero-knowledge. Additionally, no adversarial model provided, no explicit proof for the information leak, no hardness assumption provided … etc. These are actually very critical points that must be provided since the methodology is far from being complete. Moreover, Algorithms 1 and 2 are incomplete, there is fundamental information that should be provided in them such as how the algorithms handle errors, the boundary conditions of each of them, in addition to the many steps in them are not listed. The paper actually relies on already known cryptographic constructs. Moreover, the paper fails to demonstrate a sound scientific contribution.

Response 8: Thank you for pointing this out. We wish to clarify that our method utilizes ZKP principles (specifically non-interactive zero-knowledge proofs based on Sigma protocols) integrated with ECC to achieve privacy preservation, rather than a generic zk-SNARK construction. We have revised the text to be precise about this distinction. To address the completeness of the algorithms, we have revised Algorithm 1 and Algorithm 2. We added explicit steps for error handling (e.g., invalid signature formats) and boundary conditions (e.g., checking for negative balances) to ensure the system is robust against malformed inputs. We also explicitly stated the hardness assumption (ECDLP) that underpins the non-leakage of the private key and transaction amount. “[Algorithms 1 and 2 have been refined to include input validation, boundary checks, and error handling mechanisms. The text now explicitly frames the method as an ECC-based protocol utilizing ZKP properties for balance hiding.]”

 

Comment 9: The “Credentials zero-sum results” in Table 1 does not guarantee zero knowledge, does not prevent some adversarial manipulation, it assumes the commitment homomorphism without proof, does not take into consideration the case when the values of the input variables are malicious … etc.

Response 9: Thank you for pointing this out. In the revised manuscript, we have clarified the mathematical basis for the zero-sum verification. The validity of the zero-sum result relies on the homomorphic properties of Elliptic Curve Cryptography (specifically the commutative and associative laws of point addition). We demonstrated that because P=r×G+v×H, the sum of commitments equals the commitment of the sum ( ∑P=∑r×G+∑v×H ). Regarding malicious inputs: if an adversary manipulates the input values such that the amounts do not balance, the homomorphic relationship breaks, and the signature verification (S’=Sv’​) will fail.

 

Comment 10: The results provided in the manuscript are not sufficient, for example, there should be experiments to test the security robustness of the provided approach (attack scenarios, tamper resistance, credential forging … etc.), the behavior of the provided approach for large number of payments, no formal privacy metric adopted and compared to related work … etc. Additionally, the comparative analysis provided is far from being complete, comparative analysis mainly ignores many recent baselines in this direction, and it is mostly qualitative. Moreover, it does not provide any kind of cryptographic cost comparison. Overall, the results provided are too limited for a proper scientific claim. Moreover, most of the writeup in the result section is descriptive rather than analytic.

Response 10: Thank you for pointing this out. We acknowledge that the previous evaluation was primarily descriptive and lacked sufficient theoretical grounding and quantitative analysis. To strengthen the scientific claims, we have significantly expanded the theoretical analysis and interpretation of results in the revised manuscript. Specifically, we introduced a formal adversarial model in Section 4.1 and provided corresponding security proofs in Section 4.2 to rigorously demonstrate robustness against tampering and privacy attacks based on the ECDLP hardness assumption. Furthermore, to address the lack of cryptographic cost comparison, we added Section 5.4, which theoretically quantifies our method's O(1) complexity advantage over generic ZKP systems. We also added Section 5.5 to analytically interpret the simulation data, explaining the stability of latency under high transaction volumes. "[In the revised manuscript, we have added Section 4.1 "Adversarial Model and Security Assumptions" and Section 4.2 to formalize the security proofs. Additionally, Section 5.4 "Cryptographic Cost Comparison" and Section 5.5 "Analytical Interpretation of Simulation Results" have been included to provide the requested quantitative and analytical evaluation.]"

 

Comment 11: The limitations of the provided approach are numerous (e.g., repeated offline spending, multi-hop offline payments, detailed discussion of malicious payer/payee, network reconnection complexities … etc.), however, minor mentioning of them are provided with minimal discussion.

Response 11: Thank you for pointing this out. We acknowledge that the initial discussion of limitations, particularly concerning complex application scenarios, was minimal. To provide a more candid and systematic evaluation of our method's current boundaries, we have significantly expanded the discussion in the Conclusion and Future Work (Section 6). This section now explicitly differentiates the current model (focused on a single, atomic transaction) from advanced challenges such as repeated offline spending, multi-hop payments, and the detailed analysis of malicious behavior during settlement reconciliation. We emphasize that developing robust solutions for these complex, continuous scenarios is the central focus of our next research phase, demonstrating our full awareness of the steps required for a practical, comprehensive system. [In the revised manuscript, Section 6 "Conclusion and Future Work" has been expanded to explicitly list and discuss limitations, including Continuous Offline Transactions, Advanced Scenario Complexity, and the need for detailed analysis of malicious payer/payee behavior.]

 

Comment 12: There is a major concern for the reproducibility of the methodology and results listed in the manuscript. Mainly because of the incomplete description of the cryptographic steps, missing assumptions related to the adversarial model and trust assumptions, missing information for the measurement environment (e.g., CPU architecture, memory, operating system), many missing assumptions in the results section … etc.

Response 12: Thank you for pointing this out. We agree with this comment. Therefore, we have expanded the "Experimental Environment" section to include the specified implementation details. These changes can be found in Section 5.2, on page 12, in a new paragraph titled "Implementation Details".

"[Implementation Details: The prototype was implemented in JavaScript. Elliptic curve operations (secp256k1) were performed using the elliptic library (v6.5.4). All random values (e.g., private keys, nonces) were generated using the cryptographically secure crypto.getRandomValues() Web API. The implementation relied on the underlying library's algorithms.]"

 

 

Comment 13: The list of references used ignores or weakly covers several of the important topics in the paper. Additionally, some of the references used are old for certain topics given that there are a lot of recent references that can be adopted. For example, ZKP, ECC-based confidential transactions, the threat models for dual offline-payment … etc. Hence, there should be more recent references to cover such topics.

Response 13: We acknowledge that our initial reference list did not adequately reflect the latest advancements in key areas such as Zero-Knowledge Proofs (ZKP), ECC-based confidential transactions, and threat models for dual-offline payments. To address this, we have thoroughly revised the bibliography to include recent, high-quality sources (primarily from 2020 to 2025) that specifically cover these topics.

 

Comment 14: More than 30% of references are dated before 2020, which can be considered a bit old given the vast number of recent studies in such area. Additionally, more than 17% of references are dated before 2015, which can be considered as old. Please kindly consider using recent alternatives.

Response 14: We agree with the observation that a high percentage of older references diminishes the perceived timeliness of the manuscript. We have carefully reviewed the entire reference list and replaced or removed several outdated citations to ensure the manuscript reflects the vast number of recent studies in this rapidly evolving field.  This revision has significantly reduced the proportion of pre-2020 references, ensuring the list is dominated by publications from 2020 onwards.

 

Comment 15: 20.Some references in the reference list are not peer-reviewed such as [20], [27], [33], [35] … etc.

Response 15: Thank you for pointing this out. We have carefully reviewed the reference list and removed all non-peer-reviewed sources mentioned, including [20], [27], [33], and [35]. These have been replaced with appropriate, peer-reviewed journal or conference papers that support the respective points in the manuscript. The overall quality and relevance of the reference list have been significantly improved as a result of this revision.

"[Ivanov, N., Yan, Q. (2021). System-Wide Security for Offline Payment Terminals. In: Garcia-Alfaro, J., Li, S., Poovendran, R., Debar, H., Yung, M. (eds) Security and Privacy in Communication Networks. SecureComm 2021. Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, vol 399. Springer, Cham. https://doi.org/10.1007/978-3-030-90022-9_6.

Bernardo M, Calandra F, Esposito A, et al. On the Operational Resilience of CBDC: Threats and Prospects of Formal Validation for Offline Payments[J]. arXiv preprint arXiv:2508.08064, 2025.

Alpirez Bock E, Brzuska C, Fischlin M, et al. Security reductions for white-box key-storage in mobile payments[C]//International Conference on the Theory and Application of Cryptology and Information Security. Cham: Springer International Publishing, 2020: 221-252.]"

 

Comment 16: Some references in the reference list are not related / weakly related to the context of the manuscript such as [4], [7], [9], [11], [12], [13], [16], [17], [18], [19], and [33].

Response 16: Thank you for pointing this out. We agree that some quotations are too broad. In order to ensure that the manuscript is fully supported by highly relevant literature, we conducted a thorough review to ensure that the remaining references are only used to support statements directly related to dual offline payment and security model.

 

Comment 17: Some references in the reference list are unindexed/unranked such as [20], [24], [25], [27], [33], [35], and [36].

Response 17: Thank you for pointing this out. We have conducted a comprehensive review of the reference list and replaced or removed all unindexed citation sources ([20], [24], [25], [27], [33], [35], [36]) with peer-reviewed literature from authoritative journals/conferences. This revision ensures the manuscript is now supported by reliable and authoritative references.

"[Ivanov, N., Yan, Q. (2021). System-Wide Security for Offline Payment Terminals. In: Garcia-Alfaro, J., Li, S., Poovendran, R., Debar, H., Yung, M. (eds) Security and Privacy in Communication Networks. SecureComm 2021. Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, vol 399. Springer, Cham. https://doi.org/10.1007/978-3-030-90022-9_6.

Sadiku P O, Oladele O T, Balogun G B, et al. Development of an Offline Payment System Using Cryptographic Digital Time Signature[J]. 2025.

Sun Q, Zhou Y, Tang T. Mobile Payment Innovations in China: China UnionPay’s Practice and Experience[M]//Business Innovation with New ICT in the Asia-Pacific: Case Studies. Singapore: Springer Nature Singapore, 2020: 257-279.

Bernardo M, Calandra F, Esposito A, et al. On the Operational Resilience of CBDC: Threats and Prospects of Formal Validation for Offline Payments[J]. arXiv preprint arXiv:2508.08064, 2025.

Alpirez Bock E, Brzuska C, Fischlin M, et al. Security reductions for white-box key-storage in mobile payments[C]//International Conference on the Theory and Application of Cryptology and Information Security. Cham: Springer International Publishing, 2020: 221-252.]"

 

Comment 18: Some references in the reference list miss the complete referencing information such as [20], [27], and [33].

Response 18: Thank you for pointing this out. We have thoroughly checked and corrected the entire reference list. Specifically, the missing information for references [20], [27], and [33] has been supplemented to meet the standard bibliographic format. Additionally, we have performed a global check to ensure that all other references now contain complete and accurate information.

"[Ivanov, N., Yan, Q. (2021). System-Wide Security for Offline Payment Terminals. In: Garcia-Alfaro, J., Li, S., Poovendran, R., Debar, H., Yung, M. (eds) Security and Privacy in Communication Networks. SecureComm 2021. Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, vol 399. Springer, Cham. https://doi.org/10.1007/978-3-030-90022-9_6.

Bernardo M, Calandra F, Esposito A, et al. On the Operational Resilience of CBDC: Threats and Prospects of Formal Validation for Offline Payments[J]. arXiv preprint arXiv:2508.08064, 2025.

Alpirez Bock E, Brzuska C, Fischlin M, et al. Security reductions for white-box key-storage in mobile payments[C]//International Conference on the Theory and Application of Cryptology and Information Security. Cham: Springer International Publishing, 2020: 221-252.]"

Response on the Quality of English Language

Comment 1: Several sentences throughout the manuscript are too long such as the sentences in lines 24-27, 60-63, 217-219 … etc.

Response 1: Thank you for pointing this out. We have revised all overly long sentences throughout the manuscript to improve clarity and readability. Key revisions include the sentences on lines 24-27 and 60-63.

"[In recent years, the deep integration of blockchain and financial technologies has propelled cryptocurrencies from conceptual exploration to a critical component of the global financial system [1]. Concurrently, central banks worldwide have successively launched their Central Bank Digital Currency (CBDC) initiatives [2], further validating this trend. And, to solve the privacy protection problem in offline scenarios, our method constructs a payment credential mechanism with dedicated generation and verification processes. The core of this mechanism is the novel combination of elliptic curve cryptography (ECC) and zero-knowledge proof technology.]"

 

Comment 2: There are many grammatical/spelling mistakes and typos throughout the manuscript (the manuscript needs a full proofreading) such as:

• Line 8: “method for cryptocurrencies, aims to solve” should be “method for cryptocurrencies that aims to solve”
• Line 41: “It significantly improving payment system” should be “It significantly improves payment system”
• Line 113: “VolgaPay [20]proposed” should be “VolgaPay [20] proposed”, this typo is repeated in several locations in the manuscript such as lines 122, 123 …
• Line 169: “during internet outages” should be “during Internet outages”
• Line 177: “authentication , our approach” should be “authentication, our approach”
• Lines 395, 296: “in offline environment” should be either “in offline environments” or “in an offline environment”
• Caption of Fig. 3: “100 dual-offline payment” should be “100 dual-offline payments”
• Line 453, 454: “during identity verification a payment capability by zero-knowledge proof technology” the sentence is not grammatically correct.
• Line 492: “Secure Elemen” should be “Secure Element”
• Line 492: “Trusted Execution Environmen” should be “Trusted Execution Environment”
• Please kindly use “Section” instead of “Chapter” in the last paragraph in the introduction.
• Line 449: “ Conclude” should be “6. Conclusion”

Response 1: Thank you for pointing this out. All listed grammatical and spelling errors (items (1) through (12)) have been corrected in the revised manuscript, with changes highlighted in red at their corresponding locations in the original text.

Author Response File: Author Response.docx