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

Abstract

Current research on cryptocurrency dual-offline payment systems has garnered significant attention from both academia and industry, owing to its potential payment feasibility and application scalability in extreme environments and network-constrained scenarios. However, existing dual-offline payment schemes exhibit technical limitations in privacy preservation, failing to adequately safeguard sensitive data such as payment amounts and participant identities. To address this, this paper proposes a privacy-preserving dual-offline payment method utilizing a cryptographic challenge-response mechanism. 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. The method adopts the payment credential generation and credential verification mechanism, combined with elliptic curve cryptography (ECC), to construct the verification protocol. These components enable dual-offline functionality while concealing sensitive information, including counterparty identities and wallet balances. 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. The research provides an innovative technical solution for cryptocurrency dual-offline payment, advancing both theoretical foundations and practical applications in the field.

1. Introduction

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. Compared to traditional currencies, cryptocurrencies demonstrate significant advantages in reducing transaction costs, enhancing payment efficiency, and optimizing market responsiveness. However, current cryptocurrency payments remain heavily dependent on online networks, severely limiting their application in network-constrained scenarios. The online payment paradigm fails to meet user needs in connectivity-restricted environments, whereas dual-offline payment technology—enabling payment without network access—holds substantial application value for regions with poor or nonexistent network coverage.

Dual-offline payment technology aims to overcome network limitations by enabling fund transfers without network [3]. Taking China’s digital RMB (e-CNY) as an example [4,5], it leverages near-field communication (NFC) technology and hardware wallets with embedded security chips [6,7] to ensure uninterrupted payment processes during network instability or complete disconnection. This innovation simultaneously enhances transactional convenience and security while effectively addressing the limitations of online payments. It significantly improves payment system usability and flexibility [8,9], while reducing network dependency [10,11,12]. Existing dual-offline payment models typically employ local payment recording during offline phases [13], perform security verification after network restoration, and execute deductions post-verification. However, this paradigm exhibits critical privacy preservation deficiencies. Sensitive data involved in the payment process, including identity characteristics, account status, and fund flows, lack robust cryptographic authentication mechanisms. This vulnerability facilitates cybersecurity threats such as differential privacy attacks [14], thereby creating user privacy leakage risks.

Zero-knowledge proof (ZKP) constitutes a cryptographic technique enabling one party (the prover) to convince another party (the verifier) of a statement’s validity without disclosing any underlying information content. Characterized by its dual capability to simultaneously authenticate data and rigorously preserve privacy [15,16], this property demonstrates that significant potential in privacy-preserving systems and identity authentication domains. Consequently, the construction of security models that harmonize payment efficiency with privacy protection through innovative integrations of cryptographic techniques, particularly the combined use of zero-knowledge proofs and elliptic curve cryptography, has emerged as a critical research focus in dual-offline payment systems [17,18].

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, this approach focuses specifically on concealing sensitive payment data through cryptographic commitments and challenge-response logic. To solve the privacy protection problem in offline scenarios, this 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.

The method systematically solves the privacy protection problem in offline payment by building a closed-loop security system. Regarding privacy protection, it effectively avoids the risk of leaking sensitive information such as the payer’s wallet balance. From a security perspective, it combines the anti-double-spend mechanism with the cryptographic communication protocol to resist security threats, such as replay attacks and data tampering. Theoretical analysis and simulation verification show that, compared with the traditional scheme, this method achieves significant improvement in privacy protection strength, security attack resistance, and comprehensive threat mitigation across multiple attack scenarios. Thereby constructing a technically feasible and security-assured solution for cryptocurrency double-offline payments, yielding significant theoretical and practical significance for advancing cryptocurrency applications and technological innovation.

The proposed dual-offline payment method features the following innovations:

(1)

An innovative payment-credential-based, non-interactive, zero-knowledge proof (NIZKP) verification mechanism is constructed. By designing an end-to-end payment credential generation and verification framework integrated with NIZKP algorithms, this approach achieves dual objectives of payment validity verification and privacy preservation without exposing sensitive information of transacting parties, effectively addressing the critical privacy leakage challenge in offline payment scenarios.

(2)

A novel zero-sum verification protocol is designed to enable privacy-preserving authentication of payment data authenticity. Employing innovative verification logic, this mechanism validates credential authenticity without disclosing sensitive information such as the identity of the payer and the payment amount, thereby mitigating risks of fraudulent payment and data tampering while enhancing trust assurance in dual-offline payment systems.

These two innovations synergistically establish a comprehensive technical framework for cryptocurrency dual-offline payments, achieving integrated solutions for privacy preservation, data security, and payment reliability.

The following sections of this paper systematically carry out research on cryptocurrency dual-offline payment technology: Section 2 focuses on related works; systematically analyzes the technical limitations of existing dual-offline payment schemes, such as blockchain, cryptographic protocols, and NFC technology; and builds the theoretical basis for comparison. Section 3 proposes the dual-offline payment method, detailing the design based on zero-knowledge proofs and elliptic curve cryptography, including the payment credential generation mechanism, zero-sum verification protocol, and end-to-end interaction logic. Section 4 conducts theoretical analysis, constructing a threat model covering tampering attacks, double-spending attacks, and privacy leakage, with security robustness verified through cryptographic proofs. Section 5 performs a multi-dimensional performance evaluation, quantifying time cost and memory usage through 100 simulated payments, and comparing technical advantages with existing schemes using visual charts. Section 6 summarizes the research value, clarifies the scheme’s role in cryptocurrency innovation, and identifies future directions, such as continuous offline payment optimization. The paper follows the structure of “problem formulation, design, validation, evaluation, and conclusion”, presenting a complete research cycle from innovation to application.

2. Related Works

Currently, multiple approaches exist for implementing offline payments, with core technologies spanning blockchain, cryptographic protocols, NFC, CBDC-oriented designs, and mobile security frameworks. However, existing schemes suffer from limitations such as inadequate privacy protection, high computational complexity, and poor dual-offline compatibility. This section systematically reviews recent advances in key technical directions (including Pedersen commitments, ECC-based privacy protection, and efficient ZKP systems) and analyzes their gaps relative to dual-offline payment requirements.

2.1. Blockchain-Based Offline Payment

Blockchain-based offline payment schemes leverage decentralization and tamper resistance to ensure transaction validity. Ivanov [19] proposed a secure and efficient mobile terminal system for offline payments using blockchain technology, which achieves transaction traceability but suffers from high latency due to on-chain consensus. Jie Wanqing et al. [20] identified vulnerabilities in offline blockchain payments and developed a high-performance vulnerability detection framework, yet failed to address privacy leakage caused by blockchain’s transparency.

Recent blockchain-based schemes have integrated cryptographic commitments to enhance privacy. Fang et al. [21] proposed PROMISE, a Pedersen commitment-based transaction-hiding scheme that combines Pedersen’s additive homomorphism with ZKP to realize amount hiding and confidential verification. However, PROMISE relies on on-chain consensus for settlement, making it incompatible with dual-offline scenarios where real-time network support is unavailable. This method abandons blockchain dependence and adopts a lightweight ECC+ZKP fusion mechanism, enabling offline-compatible privacy protection without sacrificing efficiency.

2.2. Cryptographic Protocol-Based Schemes

Cryptographic protocols for offline payments primarily include blind signatures, Pedersen commitments, and zero-knowledge proofs, focusing on anonymity and privacy protection.

Ivanov et al. [22] proposed secure offline e-payment schemes using untraceable blind signatures (BS), which sever the link between e-money and its owner. Sadiku et al. [23] introduced an RSA-based BS system to ensure payment anonymity, but these schemes only achieve transaction anonymity and fail to hide specific payment amounts. Additionally, their high computational complexity and reliance on strong mathematical assumptions hinder deployment on resource-constrained offline devices.

Pedersen commitments have emerged as a core tool for transaction privacy due to their concealment and additive homomorphism. Feng et al. [24] proposed a secure multi-party computing protocol that combines Pedersen commitment and Schnorr signature, which can combine signatures of different transaction information under anonymous conditions. However, the scheme requires interactive signature generation, which is incompatible with dual-offline scenarios lacking real-time communication. Fang et al. [21] further optimized Pedersen commitment integration for blockchains, but their reliance on on-chain consensus limits offline applicability.

The proposed method implicitly inherits Pedersen commitment’s homomorphism through the zero-sum verification protocol. By embedding commitment logic into the zero-sum equation $(R^{\prime }=P_c+P_r-P_i)$, this realizes offline-compatible amount verification without additional computational overhead or network dependence—addressing the core limitations of existing Pedersen commitment-based schemes.

Recent ZKP research has focused on reducing computational complexity for resource-constrained devices. Xie et al. [25] proposed Orion, a ZKP scheme with linear prover time ($\left(O\right(N\left)\right)$ complexity), which improves efficiency compared to traditional zk-SNARKs. Nevertheless, Orion still relies on arithmetic circuit constructions, leading to higher overhead than this $\left(O\right(1\left)\right)$ constant-time design. This method abandons general-purpose ZKP circuits and adopts a signature-based challenge-response mechanism, reducing computational complexity to constant time—critical for offline hardware with limited resources.

2.3. ECC-Based Privacy Protection

Elliptic curve cryptography is widely used in lightweight security schemes due to its high security-to-overhead ratio, making it suitable for resource-constrained offline devices. Recent studies have applied ECC to privacy-preserving authentication and payment systems.

Huang [26] proposed an ECC-based three-factor authentication scheme for wireless sensor networks, combining biometrics, smart cards, and passwords to enhance security. However, this scheme focuses on device authentication and lacks protection for payment amounts or balances. Fariss et al. [27] developed a lightweight ECC-based mutual authentication protocol for IoT-WSNs, which resists cloning and insider attacks but fails to support zero-sum verification and anti-double-spending mechanisms required for offline payments.

This method leverages ECC’s unique advantages to address privacy and security gaps in offline payments: (1) Using ECC scalar multiplication $(y\times H)$ to encrypt sensitive data (e.g.,$(V_i,V_c)$), ensuring attackers cannot derive amounts from public parameters $(P_i,P_c)$ due to Elliptic Curve Discrete Logarithm Problem (ECDLP) hardness; (2) combining ECC with decoy factors $(R_i,R_c,R_r)$ to realize multi-layered privacy protection, addressing the privacy gap in ECC-based offline schemes [26,27]; (3) designing a zero-sum verification protocol based on ECC’s commutative and associative laws, ensuring transaction validity without revealing sensitive information.

2.4. NFC/CBDC-Oriented Offline Payment

NFC technology enables efficient near-field communication for offline payments. Sun et al. [28] proposed an efficient and secure NFC mobile payment scheme, while Jayasinghe et al. [29] proposed an offline contactless mobile payment protocol based on EMV tokenization, which implements end-to-end encryption between terminals and security components by introducing offline transaction token. However, these schemes rely on hardware security chips for security, failing to adequately satisfy privacy requirements—attackers can exploit hardware vulnerabilities to leak payment data. Additionally, NFC-based schemes lack robust anti-double-spending mechanisms, limiting their applicability to dual-offline scenarios.

CBDC-focused offline solutions prioritize compliance and operational resilience. Chu et al. [30] reviewed CBDC offline security and proposed a TEE-based enhancement, yet TEE security depends on hardware safeguards, making it vulnerable to software attacks. Hong et al. [31] developed a solution for the offline double-spending issue of digital currencies based on the one-time signature power delegation technique, which achieves the one-time feature of digital currencies to avoid double spending when users are offline, but the scheme lacks consideration for payment amount privacy.

2.5. Mobile Security-Related Offline Payment

Focusing on the security and flexibility aspects of dual-offline payments, Yang Bo et al. [32] proposed an efficient anonymous dual-offline payment scheme for mobile platforms using Trusted Execution Environment (TEE) and Secure Element (SE) technologies. Yang Bo et al. [33] further developed DOPS (Dual-Offline Payment Scheme), a feasible solution for peer-to-peer mobile e-wallets. This approach relies solely on SE to establish a secure mobile architecture while preventing double-spending, forgery, relay attacks, and similar threats. Yang et al. [34] introduced DOT-M to address mobile users’ requirements for central bank cryptocurrency offline payments, delivering both security and efficiency. Although these existing schemes demonstrate progress in security and flexibility, they suffer from high computational complexity and inadequate privacy protection.

Pure software-based approaches such as code obfuscation or white-box cryptography [35] are vulnerable to low-level OS and hardware attacks. Host Card Emulation (HCE) technology [36] enables efficient mobile payments when combined with NFC, but its security relies on banking backend systems or SE-emulating local applications—failing to meet dual-offline privacy requirements.

The exploration of cryptographic offline payments traces back to Chaum’s blind signature work [37], which laid the foundation for untraceable e-cash. Camenisch et al. [38] advanced this line of research with compact e-cash schemes, and Luo et al. [39] proposed a multi-denomination e-cash system for offline payments. However, these methods exhibit impractical computational complexity and inadequate double-spending prevention, limiting real-world deployment.

This method solves the following problems through three innovations: (1) A lightweight ECC+ZKP fusion mechanism that hides balances without network dependence; (2) A non-interactive zero-sum verification protocol that inherits Pedersen commitment homomorphism for offline validity proof; (3) $\left(O\right(1\left)\right)$ constant-time complexity, ensuring compatibility with resource-constrained offline devices. These design choices enable this scheme to simultaneously meet dual-offline payment requirements for privacy, security, and efficiency.

3. Offline Payment Methods

3.1. The Proposed System

The proposed cryptocurrency double-offline payment system comprises two core components: payment hub and security-hardened devices, as shown in Figure 1. The payment hub is the ledger core of the system, which undertakes secure hardware registration, issues asset credential issuance, and executes final transaction settlement. Both the payer and the payee utilize the security-hardened devices, which serve as secure payment carriers in the offline environment, and the payer and the payee use them to realize cryptocurrency payment functions.

The system operates through three sequential phases:

(1)

Pre-deposit Phase: Under online conditions, the payment hub transfers a specified amount to security-hardened Device A, generating an asset credential. Simultaneously, the payment hub deducts amount N from the account balance, while Device A’s balance increases by N.

(2)

Dual-Offline Payment Phase: The payer’s Device A constructs payment data (including payment credential, change credential, and digital signature) and transmits it to the payee’s security-hardened Device B. Upon successful offline verification, Device B accepts and records the payment, marking the transaction as locally settled.This phase adopts a “Bluetooth pairing binding + UUID uniqueness verification” dual mechanism to ensure one-to-one transaction execution: ① 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. ② 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.

(3)

Settlement Phase: When the payee’s device reconnects, it submits the payment proof to the payment hub. The hub verifies the proof’s uniqueness and validity, confirms absence of double-spending, executes fund settlement, and updates the distributed ledger.

This study focuses on the dual-offline payment component of the aforementioned system. This study proposes a zero-knowledge proof based cryptocurrency dual-offline payment scheme to address privacy preservation in offline payments. By integrating ZKP techniques with elliptic curve cryptography, the proposed method realizes cryptographic protection of sensitive information (e.g., payer’s wallet balance) in the process of payment capability verification, thereby establishing a privacy-preserving yet auditable solution for dual-offline payment scenarios.

3.2. Cryptocurrency Dual-Offline Payment Method Design

3.2.1. Pre-Conditions

The core of the proposed method is a signature-based challenge-response protocol designed to verify payment validity without data exposure. 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. Specifically, the protocol utilizes Elliptic Curve Cryptography to construct a commitment to the transaction amount. The payer proves ownership of the funds and satisfaction of the zero-sum equation ($V_i=V_c+V_r$) by generating a valid digital signature over the hashed transaction data. This process ensures that the verifier (payee) is convinced of the transaction’s validity, yet computationally cannot extract the underlying values ($V_i$, $V_c$, $V_r$) or the private key, thereby achieving privacy preservation in offline scenarios.

The security of the protocol relies on the ECDLP. It is assumed that given points G and $(P=k\times G)$ on the curve secp256k1, it is computationally infeasible to derive the scalar k (the private key or blinded amount). Consequently, even if an attacker intercepts the commitment P or the signature, they cannot reverse the operation to reveal the user’s wallet balance or transaction amount, thus ensuring the method’s confidentiality.

The generation of initial points G and H adheres to the principle of “standard generator + hash-to-curve” to ensure security and backdoor-free properties: ① G adopts the standard generator of the secp256k1 curve, complying with the NIST SP 800-186 standard [40] (specific coordinates of the secp256k1 standard generator G are $x=79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798$, $y=483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8$. These parameters are consistent with the secp256k1 curve definition in the cryptographic standards, ensuring the security of the base point.)  ② H is generated through the hash-to-curve algorithm: Selecting common “nothing-up-my-sleeve” parameters (adopting the SHA256 hash function recommended by NIST P-256, which is a recommended elliptic curve in NIST SP 800-186 [40] with SHA256 specified as its preferred hash function for hash-to-curve operations), mapping a random seed in the curve field to obtain an independent generator linearly irrelevant to G.

The NIZKP adopted in this scheme satisfies three core formal properties, with its key definitions as follows: ① Language L: The set of all valid transaction statements that satisfy “the input credential amount $V_i\ge$ the received amount $V_r$” and “the zero-sum equation $V_i=V_c+V_r$ holds”; ② Instance x: Specific data of a single transaction (including public parameters such as uuid, $P_i$, $P_c$, $P_r$); ③ Witness w: Private key-related data ($R_i$, $K_s$) and the original balance $V_i$ of the payer (neither is disclosed to the public).

Mathematical Principle:

(1)

Exchange and union laws for addition and scalar multiplication of elliptic curves, for any scalar k, j, satisfy

$$(k+j)\times H=k\times H+j\times H,$$

(1)

where H is a point on the elliptic curve.

(2)

Hash operation: $SH A256\left(abc\right)$ refers to the use of a SHA256 algorithm for the hash calculation of abc, $(A\mid B\mid C)$, where the symbol “∣” means that A, B, and C are spliced together.

This study stipulates that the payment credential ownership verification mechanism operates under the following principle: ownership of payment outputs is cryptographically bound to possession of the corresponding ECC private key. Specifically, the private key holder can prove ownership without explicitly signing payment data, enabling verification through zero-knowledge proofs. This design preserves payment authenticity while eliminating sensitive information exposure, thereby establishing a foundational privacy-preserving framework. The symbols used in this method and their meanings are shown

Table 1. Symbols and their meanings.

Symbol	Description
$G,H$	A random point on an elliptic curve is obtained by randomly generating a private key and obtaining its corresponding public key.
$K\times H$	The result of scalar multiplication of the private key K with the point H is used as the public key.
$V_i$	The amount in the payer’s input credentials.
$V_c$	The amount in the payer’s change credentials.
$V_r$	The amount the recipient needs to receive.
$R_i,R_c,R_r$	Large, random numbers (decoy factors), used to hide payment information.
$P_i$	The payer’s input credentials with the expression $R_i\times G+V_i\times H$
$P_c$	The payer’s change credentials with the expression $R_c\times G+V_c\times H$
$P_r$	The payee’s receipt credentials with the expression $R_r\times G+V_r\times H$
$R_s$	Random numbers associated with $R_c$ and $R_i$, $R_s=R_c-R_i$
$R^{\prime }$	Credentials zero-sum results, $R^{\prime }=P_c+P_r-P_i=(R_r+R_s)\times G$
$K_s,K_r$	The large number, the random number (Nonce) required by the paying parties to generate a signature.
$K_s\times G,K_r\times G$	Based on random numbers and random points for signatures.
E	The hash value required to sign the payment data, computed by SHA256 ($uuid\Vert P_c\Vert P_i\Vert (K_s+R_s)\times G$)
$S_s$	Signature of the payer, $S_s=(K_s+E\times R_s)\times G$
$S_r$	Signature of the payee, $S_r=(K_r+E\times R_r)\times G$
$S^{\prime }$	Total payment signature, $S^{\prime }=S_r+S_s$
$K^{\prime }$	Points corresponding to the sum of the two Nonces, $K^{\prime }=K_s\times G+K_r\times G$

.

3.2.2. Zero-Sum Verification Schematic Design

In a dual-offline payment, this paper designs the zero-sum equation that the amount of the payer’s input credentials should be equal to the sum of the amount of the change amount and the amount of the payee’s receipt, mathematically represented as follows:

$$V_c+V_r-V_i=0.$$

(2)

The zero-sum equation holds only if the payer’s input credential has a sufficient amount ($V_i$) and the sum of the payer’s input amount, the offline payment change amount, and the payee’s receipt amount are equal. This proves that the payer has sufficient funds and honors the promised amount, demonstrating that the amount in each successful dual-offline payment is valid; otherwise, the equation cannot hold. With the zero-sum equation being valid, this study ensures privacy protection of the payment amount by introducing a “decoy factor” to the payment information, implemented through an additional ECC curve. This approach achieves privacy protection for payment amount information, expressed in the equation as follows:

$$\begin{array}{cc}\hfill R_c\times G+V_c\times H+R_r\times G+V_r\times H-R_i\times G-V_i\times H& =\hfill \\ \hfill R_c\times G+R_r\times G-R_i\times G+(V_c+V_r-V_i)\times H& =\hfill \\ \hfill (R_c+R_r-R_i)\times G+0.\end{array}$$

(3)

To prevent negative amount attacks (where a malicious user crafts a negative change amount to inflate the payment value), this scheme integrates a hardware-level range constraint. Since the calculation of $V_c=V_i-V_r$ is performed within the Secure Element (SE) of the payer’s device, the hardware logic strictly enforces two conditions before generating the commitments: (1) Positivity: $V_r>0$ and $V_c\ge 0$ are verified at the register level; (2) Boundness: If $V_r>V_i$, the SE will trigger a “Balance Insufficient” exception and terminate the signing process. This design leverages the tamper-resistant nature of the SE to ensure that any commitment $P_c$ or $P_r$ produced by the device inherently satisfies the range requirements, eliminating the need for computationally expensive cryptographic range proofs such as Bulletproofs. Complementing this hardware-enforced range control, the above equation is designed to enable the payee (verifier) to cryptographically confirm the value of $(R_c+R_r-R_i)\times G$ during dual-offline payment without revealing counterparty payment information. This demonstrates that the proposed approach achieves authentic and valid payments while preserving complete confidentiality of transaction amounts, thereby ensuring rigorous privacy protection for all payment data. The above equation is designed to enable the payee (verifier) to cryptographically confirm the value of “$(R_c+R_r-R_i)\times G$” during dual-offline payment without revealing counterparty payment information. This demonstrates that this approach achieves authentic and valid payments while preserving complete confidentiality of transaction amounts, thereby ensuring rigorous privacy protection for all payment data.

3.2.3. Methodological Process

This study designs a NIZKP-based double-offline payment method that conceals “$(R_r+R_s)\times G$” within the payer’s source credential, change credential, and the payee’s receiving credential through zero-sum amount computation. The protocol executes as follows: both parties sign the payment separately, the payer countersigns the complete payment package, and the payee verifies all signatures to validate payment legitimacy. If payment verification succeeds, the payment information, including payment amount ($V_r$), receipt credential ($P_r$), and decoy factor ($R_r$), are stored locally. Upon successful verification, the source credential is deleted, and the change credential becomes the new source credential. Transaction atomicity is guaranteed by a three-level “snapshot-update-rollback” mechanism: ① At the initialization of the transaction, an encrypted snapshot of the device state (including credentials, balance, and private key-related parameters) is created; ② after successful verification, the state is atomically updated (delete $P_i$ and activate $P_c$), and the snapshot is automatically invalidated; ③ 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. The flowchart of this non-interactive, zero-knowledge, proof-based, dual-offline payment method is shown in Figure 2.

(1)

Generation of payer and payee payment. The steps for generating payer payment information are as follows: First, the payer generates the transaction unique identifier $UUID$, constructs the input credential $P_i=R_i\times G+V_i\times H$, and the payer decoy factor $R_i$. Subsequently, the payer preemptively executes change operation in advance (before sending the payment information to the payee), partitioning the input credential’s blinding factor as follows:

$$R_s=R_c-R_i.$$

(4)

Calculate the change voucher as follows:

$$P_c=(R_s+R_i)\times G+V_c\times H.$$

(5)

After that, generate a random number $K_s$ (payer Nonce), then compute intermediate elliptic curve point $K_s\times G$. 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. Specifically, E is computed as follows:

$$E=\mathrm{SHA}256\left(\mathrm{uuid}\Vert P_c\Vert P_i\Vert (K_s+R_s)\times G\right).$$

(6)

Based on formulation of E, the payer’s signature calculated as follows:

$$S_s=(K_s+E\times R_s)\times G.$$

(7)

Finally, the UUID, change credential Pc, input credential Pi, payer Nonce, and payer signature Ss are packaged and sent to the payee. Payer payment information is generated as shown in Figure 2.

The workflow for generating the payee’s payment information in Algorithm 1 is as follows:

First, the payee can generate the payee Nonce, the payee decoy factors $R_r$, and the receipt credential $P_r$ at the beginning of the payment.

After that, the payee signature $S_r$ is computed based on E after receiving the relevant information sent by the payer.

Algorithm 1 Offline payment generation.

Require: V: transaction amount,                   ▹ Constraint: V > 0      R: secret scalar,      N: number of transactions,     $Balance$: payer’s wallet balance ▹ Constraint: $Balance\ge V$ (sufficient funds check)      If Balance < V, return “Error: Insufficient Funds” Ensure:  $\{\mathrm{uuid},P_c,P_i,K_{\mathrm{srg}},S_s\}$ for each transaction  1: Initialize EC curve $(G,H)$, compute $P_i\leftarrow H\times V+G\times R$  2: for $i=1$ to N do  3:     $\mathrm{uuid}\leftarrow \mathrm{GenerateUUID}\left(\right)$  4:     $\mathrm{V}erify(V_r>0)and(V_r\le V_i);if not satisfied,return“Error:InvalidPaymentAmoun{t}^{”}$  5:     $V_i\leftarrow V$, $V_s\leftarrow \mathrm{constant}$, $V_c\leftarrow V_i-V_s$  6:     $R_i\leftarrow R$, $R_s\leftarrow \mathrm{RandomScalar}\left(\right)$, $R_c\leftarrow R_i+R_s$  7:     $P_c\leftarrow H\times V_c+G\times R_c$  8:     $K_s\leftarrow \mathrm{RandomScalar}\left(\right)$, $K_{\mathrm{srg}}\leftarrow G\times (R_s+K_s)$  9:     $E\leftarrow \mathrm{SHA}256(\mathrm{uuid}\Vert P_c\Vert P_i\Vert K_{\mathrm{srg}})$           ▹ Fiat-Shamir transformation  10:     $S_s\leftarrow G\times (K_s+E\times R_s)$  11:     Record timing: ec, keyGen, hash, sign  12:     Store $\{\mathrm{uuid},P_c,P_i,K_{\mathrm{srg}},S_s\}$  13: end for

Implementation Note: To effectively achieve privacy protection for both payment parties’ payment information, the system must ensure the payee cannot access the payer’s payment details. This requires cryptographic protection of the payer’s $R_c$ and $R_i$ parameters, while guaranteeing exclusive ownership of input credential and change credential remains with the payer (see Section 3.2.1: Pre-Conditions). The designed method prevents the payee from obtaining ownership of input credential and change credential while permitting payment validity verification. The core design establishes the relation equation:

$$R_s=R_c-R_i.$$

(8)

and distributes the decoy factor across three variables: $R_c$ and $R_i$ are embedded in credentials, while $R_s$ is transmitted to the verifier. Consequently, the expanded form of the payer’s change credential becomes

$$P_c=(R_s+R_i)\times G+V_c\times H.$$

(9)

(2)

Verification of the payment. By verifying the signature equations of the payer and payee, the uniqueness and non-tamperability of each signed information are cryptographically enforced. The payer’s signature is defined as:

$$S_s=(K_s+E\times R_s)\times G.$$

(10)

The payee’s signature is defined as follows:

$$S_r=(K_r+E\times R_r)\times G.$$

(11)

The total payment signature is defined as follows:

$$\begin{array}{cc}\hfill S^{\prime }& =S_r+S_s=(K_s+K_r)\times G+E\times (R_r+R_s)\times G\hfill \end{array}$$

(12)

$$\begin{array}{cc}\hfill K^{\prime }& =K_s\times G+K_r\times G=(K_s+K_r)\times G.\hfill \end{array}$$

(13)

The value of credentials zero-sum results $R^{\prime }$ is calculated as follows:

$$\begin{array}{cc}\hfill R^{\prime }& =P_c+P_r-P_i\hfill \\ \hfill & =R_c\times G+V_c\times H+R_r\times G+V_r\times H-R_i\times G-V_i\times H\hfill \\ \hfill & =R_c\times G+R_r\times G-R_i\times G+(V_c+V_r-V_i)\times H\hfill \\ \hfill & =(R_c+R_r-R_i)\times G+0\hfill \\ \hfill & =(R_s+R_r)\times G+0\hfill \end{array}$$

(14)

And the total payment signature $S^{\prime }$ is calculated as follows:

$$\begin{array}{cc}\hfill S^{\prime }& =K^{\prime }+E\times R^{\prime }\hfill \end{array}$$

(15)

$$\begin{array}{cc}\hfill S^{\prime }& =S_r+S_s=(K_s+K_r)\times G+E\times (R_r+R_s)\times G\hfill \end{array}$$

(16)

If both equations yield equivalent values, this cryptographically demonstrates payment validity without disclosing transaction amounts. This process ensures that payment is tamper resistant and sufficient funds can be confidentially verified. The verification process is shown in Algorithm 2. The complete algorithm and formal proof procedure are illustrated in Figure 2.

Algorithm 2 Offline payment verification.

Require:  Payer’s params: $\mathrm{uuid},P_c,P_i,K_{\mathrm{srg}},S_s$, ($K_s\times G$), G, H      Payee’s params: $P_r$, $S_r$, ($K_r\times G$) Ensure: Accept/Reject for each transaction  1: for each transaction do  2:       $E\leftarrow \mathrm{SHA}256(\mathrm{uuid}\Vert P_c\Vert P_i\Vert K_{\mathrm{srg}})$  3:       $K^{\prime }\leftarrow K_s\times G+K_r\times G$  4:       $R^{\prime }\leftarrow P_c+P_r-P_i$  5:       $S^{\prime }\leftarrow K^{\prime }+E\times R^{\prime }$  6:       $S{v}^{\prime }\leftarrow S_r+S_s$  7:       Check: $S^{\prime }\stackrel{?}{=}S{v}^{\prime }$  8:       if Check holds (equal) then  9:             return Accept             ▹ Transaction is valid  10:     else  11:          return Reject    ▹ Transaction is invalid (signature mismatch)  12:     end if  13:     Record timing: verify  14: end for

Finally, if the validation passes, the payer deletes the input credential and reclassifies the change credential ($P_c$) as the new input credential, and the payee records the payment information locally marking successful offline payment. If the validation fails, the payer rolls back the change and other operations to restore the original state.

4. Methodological Theoretical Analysis

This section conducts an in-depth security analysis of the proposed method. Addressing the aforementioned threat model, this study systematically examines potential vulnerabilities and attack vectors, explicitly defining both adversarial methodologies and the corresponding defense strategies.

4.1. Adversarial Model and Security Assumptions

Given the unique characteristics of a dual-offline payment scenario (lack of real-time network support and reliance on local secure hardware for credential storage), this study first defines a formal adversarial model, which provides clear boundaries and foundational assumptions for the subsequent security proofs.

4.1.1. Model Environment and Participant Assumptions

1.

Environment and Interaction Assumptions: The payment parties (Payer P and Receiver R) complete the offline interaction via secure cryptographic hardware. Payment credentials ($P_i,P_c,P_r$, etc.) are stored locally and transferred offline. Upon re-establishing a network connection, the credentials are batch-uploaded to the Payment Center ($PC$) for final settlement, with no additional real-time data interaction involved.

2.

Participant Behavior Assumptions: Honest participants strictly adhere to the protocol, avoiding proactive leakage or tampering of private keys ($R_i,K_s$) or hidden balance information. The Malicious Participant (Adversary A) is a third-party interceptor, possessing the capability of data interception, tampering, and forgery in the offline environment. However, A cannot bypass the physical security of the secure hardware to extract private keys or original balance data.

3.

Cryptographic Hardness Assumptions: The security relies on the computational intractability of the ECDLP on the secp256k1 curve. Hash functions (e.g., SHA−256) satisfy collision resistance and pre-image resistance. 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.

It is important to note the limitations of SHA256 when instantiated in the ROM, as the ROM is an idealized cryptographic model: 1. Ideal vs. Real-World Gap: The ROM assumes SHA256 behaves as a “perfect random function,” but practical implementations may have side-channel vulnerabilities (e.g., timing discrepancies during hash computation on different inputs), which could leak partial information about the input. 2. Future Security Risks: While SHA256 is currently collision-resistant and pre-image-resistant, advancements in quantum computing or cryptographic analysis may undermine these properties in the long term. 3. Fixed Output Length: The 256-bit output length of SHA256 may become insufficient as computational power grows, though this risk is negligible for the current security parameter $\lambda =256$.

These limitations do not invalidate the scheme’s security: side-channel vulnerabilities are mitigated by the SE’s hardware-isolated execution environment (Section 4.1.1), and SHA256 can be replaced with post-quantum hash functions (e.g., SHA-3, XMSS) without modifying the protocol’s core framework.

4.

Malicious payer’s double-spending attack scenario: A malicious payer (Adversary A) exploits the lack of real-time verification in the offline environment to reuse the same input credential $P_i$, forge supporting proofs (e.g., generate fake $R_s$, $R_c$), and initiate payments to multiple payees. The attacker attempts to complete multiple local verifications before settlement to achieve “repeated spending of the same fund”. The core attack path is Offline reuse of $P_i$ → Generate multiple sets of proofs → Complete local verification with different payees → Batch upload for settlement to conceal double-spending.

5.

Secure Element (SE) Formal Assumptions: The scheme’s security relies on three formal properties of the SE integrated in hardened devices, which are consistent with industrial security standards:

➀

Tamper-Resistance: The SE’s hardware isolation prevents adversaries from extracting or modifying sensitive data stored inside (including private keys $R_i,K_s$, credentials $P_i,P_c$, and transaction state). Formally, for any sensitive data $d\in \mathrm{SE}\text{-}\mathrm{Storage}$, $Pr\left[\mathcal{A}\mathrm{extracts}/\mathrm{modifies}d\right]\le \mathrm{negl}\left(\lambda \right)$.

➁

Computational Integrity: All cryptographic operations executed within the SE (elliptic curve scalar multiplication, signature generation, zero-sum equation verification, atomic state update) are correct and unalterable. Formally, for any SE-executed function f and input x, the output $f_{\mathrm{SE}}\left(x\right)$ is identical to the ideal function output $f_{\mathrm{ideal}}\left(x\right)$, and $Pr\left[\mathcal{A}\mathrm{tampers}\mathrm{with}{f}_{\mathrm{SE}}\left(x\right)\right]\le \mathrm{negl}\left(\lambda \right)$.

➂

Secure I/O: The communication channel between the SE and the device’s main processor is authenticated and encrypted. Formally, adversaries cannot intercept or forge data transmitted between the SE and the main processor.

The effectiveness of computational privacy in this scheme relies on three core prerequisites: ① Curve selection: Adopting the secp256k1 secure elliptic curve, whose order n satisfies collision resistance and discrete logarithm hardness; ② No side-channel attacks: Relying on hardened devices resistant to timing attacks and power analysis attacks to ensure no information leakage during signature and credential generation; ③ Secure generation of point H: Generating an independent generator H through the hash-to-curve algorithm to ensure non-knowledge of the discrete logarithm between G and H. These three prerequisites collectively form the foundation of privacy protection, and none can be omitted.

4.1.2. Attacker Capabilities and Security Targets

This study defines attacker A as possessing capabilities including data interception (${\mathcal{C}}_{\mathrm{Intercept}}$), tampering and forgery (${\mathcal{C}}_{\mathrm{Forge}}$), replay attacks (${\mathcal{C}}_{\mathrm{Replay}}$), and limited computation (${\mathcal{C}}_{\mathrm{Limit}}$). The core attack goals are categorized into Privacy Theft (Type I) and Transaction Tampering (Type II). Here, $\lambda$ denotes the security parameter (set to 256 in this work, corresponding to the key length of the secp256k1 curve), and $\mathrm{negl}\left(\lambda \right)$ represents a negligible probability (i.e., $\mathrm{negl}\left(\lambda \right)\le 2^{-\lambda }$).

• Type I: Privacy Theft Attack (${\mathcal{T}}_{\mathbf{Privacy}}$) Formal Goal: A attempts to derive the Payer’s hidden balance or transaction amounts ($V_i,V_c,V_r$) from the intercepted public data (Pub). Security Requirement (Balance Privacy): The probability of A’s success ${\mathrm{Adv}}_A^{\mathrm{Privacy}}\left(\lambda \right)$ must be negligible, formally ${\mathrm{Adv}}_A^{\mathrm{Privacy}}\left(\lambda \right)\le \mathrm{negl}\left(\lambda \right)$.
• Type II: Transaction Tampering Attack (${\mathcal{T}}_{\mathbf{Integrity}}$) Formal Goal: A attempts to bypass the zero-sum verification and signature check through tampering or forgery, to achieve illegal profit (e.g., increasing $V_r$ or double spending). Security Requirement (Transaction Integrity): The probability of A’s successful forgery passing verification ${\mathrm{Adv}}_A^{\mathrm{Integrity}}\left(\lambda \right)$ must be negligible, formally ${\mathrm{Adv}}_A^{\mathrm{Integrity}}\left(\lambda \right)\le \mathrm{negl}\left(\lambda \right)$.

4.1.3. Security Goals

The security goals of the proposed method are to ensure the following:

1.

Balance Privacy: Resistance against Type ${\mathcal{T}}_{\mathrm{Privacy}}$ attacks, preventing the derivation of sensitive balance information from public data.

2.

Transaction Integrity: Resistance against Type ${\mathcal{T}}_{\mathrm{Integrity}}$ attacks, ensuring that any malicious tampering or forgery is detected during the offline verification or the final settlement.

4.2. Security Analysis and Proof

4.2.1. Formal Zero-Knowledge Proof: Simulator Construction and Transcription Indistinguishability

To formally prove the zero-knowledge property of the proposed NIZKP, we construct a polynomial-time simulator $\mathcal{S}$ that generates a simulated transcript indistinguishable from the real protocol execution, satisfying the definition of computational zero-knowledge.

Simulator Setup

-

Input: Security parameter $\lambda =256$, secp256k1 curve parameters ($G,H$), environment $\mathcal{Z}$’s input (transaction context, adversary $\mathcal{A}$’s attack queries).

-

Output: Simulated transcript ${\mathrm{Trans}}_{\mathcal{S}}=({\mathrm{uuid}}^s,P_c^s,P_i^s,K_{srg}^s,E^s,S_s^s,{\mathrm{verify}}^s)$, where superscript s denotes simulated values.

Simulation Process

• Simulate Public Parameters: $\mathcal{S}$ generates random scalars $R_i^s,R_c^s,V_i^s,V_c^s\in {\mathbb{Z}}_q$ (q is the order of secp256k1), and computes simulated credentials:

  $$\begin{array}{cc}\hfill P_i^s& =R_i^s\times G+V_i^s\times H,\hfill \end{array}$$

  (17)

  $$\begin{array}{cc}\hfill P_c^s& =R_c^s\times G+V_c^s\times H.\hfill \end{array}$$

  (18)
  These simulated credentials follow the same distribution as real credentials (due to the uniform randomness of scalars and ECDLP hardness).
• Simulate Challenge Value $E^s$: Leveraging the ROM property of SHA256, $\mathcal{S}$ records the input to the hash function (${\mathrm{uuid}}^s\parallel P_c^s\parallel P_i^s\parallel K_{srg}^s$ ) and returns a uniformly random 256-bit string as $E^s$. This aligns with the ROM’s ideal randomness assumption, making $E^s$ indistinguishable from the real challenge value E (generated via SHA256 in the protocol).
• Simulate Signature $S_s^s$: $\mathcal{S}$ generates a random scalar $K_s^s\in {\mathbb{Z}}_q$, computes $R_s^s=R_c^s-R_i^s$, and simulates the payer’s signature:

  $$S_s^s=(K_s^s+E^s\times R_s^s)\times G.$$

  (19)
  Since $E^s$ and $K_s^s$ are random, $S_s^s$ is computationally indistinguishable from real signatures (which use private key $K_s$).
• Simulate Verification Result: $\mathcal{S}$ sets ${\mathrm{verify}}^s=\mathrm{True}$, which is consistent with the real protocol’s 100% success rate in valid transactions.

Transcription Indistinguishability

For any polynomial-time environment $\mathcal{Z}$, the advantage of distinguishing between the real transcript ${\mathrm{Trans}}_{\mathcal{P}}$ (from the protocol $\mathcal{P}$) and the simulated transcript ${\mathrm{Trans}}_{\mathcal{S}}$ is negligible:

$$|Pr[\mathcal{Z}\left({\mathrm{Trans}}_{\mathcal{P}}\right)=1]-Pr[\mathcal{Z}\left({\mathrm{Trans}}_{\mathcal{S}}\right)=1]|\le \mathrm{negl}\left(\lambda \right).$$

This holds because

-

The challenge values E (real) and $E^s$ (simulated) are both uniformly random (ROM assumption for SHA256).

-

All elliptic curve points ($P_i,P_c,S_s$ ) in both transcripts follow the same distribution (group properties of secp256k1), and ECDLP hardness prevents $\mathcal{A}$ from distinguishing simulated scalars from real ones.

-

The verification result is identical in both transcripts, providing no distinguishing information.

Thus, the proposed NIZKP satisfies computational zero-knowledge via the simulator $\mathcal{S}$.

4.2.2. Security Analysis

This section details the defense mechanisms of this scheme against the two core attack targets defined in Section 4.1.

The Fiat–Shamir transformation converts an interactive Sigma protocol into a non-interactive proof. Its core logic is compute the challenge value E by hashing the public transaction parameters (uuid, $P_c$, $P_i$, $K_{srg}$), replacing the random challenge in interactive verification. Under the ROM model, the randomness of the hash function ensures that attackers cannot infer the witness w from E, and a simulator can be constructed to generate transcripts indistinguishable from real interactions, thereby preserving zero-knowledge; meanwhile, this transformation guarantees knowledge extractability—if an attacker can generate a valid proof, there exists an extractor that obtains the witness w by replaying hash queries, verifying the reliability of the scheme.

(1)

Analysis of Transaction Tampering (Against Type ${\mathcal{T}}_{\mathrm{Integrity}}$ Attacks). An attacker may intercept the payment data during the payment process and try to modify the payment amount $V_r$, credentials $P_i$ and $P_c$, or other key information. To counter such attacks, this method employs elliptic curve cryptography to enforce data integrity, with correctness guaranteed by the SE’s computational integrity assumption (Section 4.1.1 (5)(②)).

The protocol computes a cryptographic digest E derived from the payment data hash. The $K_{\mathrm{srg}}$ is calculated as follows:

$$K_{\mathrm{srg}}=(K_s+R_s)\times G$$

(20)

Any tampering with the payment data inevitably alters the cryptographic digest value, enabling detection by the receiving party. Moreover, since $K_s$ and $R_s$ are stored in the SE (tamper-resistant assumption, Section 4.1.1 (5)(①)), the attacker cannot forge valid $K_{\mathrm{srg}}$ or E—this eliminates the possibility of tampered data passing verification.

This scheme adopts a Schnorr-like linear signature structure, whose additive linear property is naturally compatible with the zero-sum verification protocol. In the verification process, tampering attempts are identified by validating whether the following equation aligns with the expected signature:

$$S^{\prime }=K^{\prime }+E\times R^{\prime }$$

(21)

This process constitutes a robust defense mechanism against payment-data-tampering attacks, with security anchored in the SE’s tamper-resistance and computational integrity assumptions.

(2)

Defense Against Double-Spending Attacks. The anti-double-spending mechanism of this scheme is realized through the design of “atomic certificate lifecycle management + security hardware isolation”, with validity formally guaranteed by the SE’s core assumptions (Section 4.1.1 (5)):

① Atomic lifecycle management: When the payer generates payment data (lines 5–9 of Algorithm 1), the change credential $P_c$ is pre-generated synchronously, and an atomic “snapshot-update-rollback” operation is executed; after successful transaction verification, the original input credential $P_i$ is immediately marked as invalid, and only $P_c$ is valid for subsequent payments; if verification fails, the system atomically rolls back to the pre-transaction state, and $P_i$ remains uniquely valid. This mechanism logically eliminates the possibility of $P_i$ being reused for multiple offline payments, directly blocking the attacker’s core path of “reusing $P_i$ to initiate double-spending”. The atomicity of this operation is guaranteed by the SE’s computational integrity assumption (Section 4.1.1 (5)(②)), which prevents adversaries from disrupting the state update process.

② Secure hardware isolation: Core credentials $P_i$, $P_c$, and private key-related data ($R_i$, $K_s$) are all stored inside a side-channel attack-resistant Secure Element (SE). By the SE’s tamper-resistance assumption (Section 4.1.1 (5)(①)), external parties cannot extract or copy these sensitive data—this physically prevents the attacker from forging proofs by copying $P_i$, as required for the double-spending attack. Additionally, the SE’s secure I/O assumption (Section 4.1.1 (5)(③)) ensures that the state update commands (mark $P_i$ as invalid) are not intercepted or forged.

Formally, the probability of a successful double-spending attack is bounded by the SE’s security: ${\mathrm{Adv}}_{\mathcal{A}}^{\mathrm{DS}}\left(\lambda \right)\le Pr\left[\mathrm{SE}\mathrm{assumptions}\mathrm{are}\mathrm{violated}\right]+\mathrm{negl}\left(\lambda \right)\le \mathrm{negl}\left(\lambda \right)$, proving the mechanism’s effectiveness.

(3)

Proof of Balance Privacy and Anonymity (Against Type ${\mathcal{T}}_{\mathrm{Privacy}}$ Attacks). The attacker attempts to obtain the identity information or other sensitive information of both parties in the payment. This scheme’s privacy protection relies on multi-layered cryptographic mechanisms and the SE’s security assumptions (Section 4.1.1 (5)):

First, elliptic curve points are used as pseudonymous identity proxies instead of explicit personal data, and payment amounts are encrypted via ECC scalar multiplication enhanced with blinding factors. The computational infeasibility of ECDLP ensures that attackers cannot derive $V_i,V_c,V_r$ from public credentials $P_i,P_c,P_r$.

Second, the SE’s tamper-resistance assumption (Section 4.1.1 (5)(①)) guarantees that private keys $R_i,K_s$ and blinding factors $R_s,R_c$ are not leaked—this eliminates the risk of attackers using leaked private data to decrypt sensitive information. The SE’s computational integrity assumption (Section 4.1.1 (5)(②)) ensures that the encryption and signature operations are executed correctly, with no information leaked via side channels (e.g., power analysis).

The protocol further integrates zero-knowledge proofs to guarantee participant anonymity, enabling verifiable payment validation without information disclosure by allowing a prover to demonstrate statement correctness without revealing underlying data. Specifically, non-interactive zero-knowledge proofs generate a challenge value E, which facilitates the construction of aggregated signatures $S^{\prime }$ as follows:

$$\begin{array}{cc}\hfill S^{\prime }& =S_r+S_s\hfill \end{array}$$

(22)

$$\begin{array}{cc}\hfill S_s& =(K_s+E\times R_s)\times G\hfill \end{array}$$

(23)

$$\begin{array}{cc}\hfill S_r& =(K_r+E\times R_r)\times G\hfill \end{array}$$

(24)

Thus, proving the validity of the payment without revealing the payment amount. The challenge value E is derived from hashed concatenation of the payment UUID, credentials $P_c$, $P_i$, and nonces. In the communication, only the necessary payment data is transmitted, reducing the exposure of sensitive information.

Formally, the privacy protection requirement is satisfied: ${\mathrm{Adv}}_{\mathcal{A}}^{\mathrm{Privacy}}\left(\lambda \right)\le Pr[\mathrm{ECDLP}$$\mathrm{is}\mathrm{solved}]+Pr[\mathrm{SE}\mathrm{tamper}\text{-}\mathrm{resistance}\mathrm{is}\mathrm{violated}]+\mathrm{negl}(\lambda )\le \mathrm{negl}(\lambda )$.

5. Methodological Evaluation

5.1. Comparison with Existing Methods

This research addresses dual-offline payment scenarios by systematically identifying three core security requirements: data integrity and authenticity guarantee [41], anti-double-spending [41] mechanism construction, and user privacy protection [42,43]. The proposed method is comprehensively compared with existing dual-offline payment solutions against these security criteria, with detailed comparative results presented in

Table 2. Comparison of realized functions with existing methods.

Implementation Functions	Data Integrity and Authenticity	Anti-DS Mechanism	Privacy Protection
Blockchain-based system [19,20]	✓	✓
Utilizing BS Cryptography Protocol [22,23]	✓	✓
TEE+SE [32,33,34]		✓
Utilizing NFC technology [28,29]
CBDC Payment Program [30]	✓
Electronic cash [39]	✓
Proposed scheme	✓		✓
Proposed scheme (with secure element)	✓	✓	✓
Evaluation Criteria Definitions:
Data integrity and authenticity: Focuses on whether cryptographic mechanisms (digital signatures/hash functions) are employed to detect data tampering during transmission/storage. Anti-Double Spending (Anti-DS) Mechanism: Focuses on whether the scheme prevents the same payment credential from being spent multiple times, with effectiveness specifically evaluated in offline scenarios. Privacy protection: Focuses on whether sensitive information such as payment amount and identities of transaction parties is concealed from unauthorized parties.

Symbol ✓ indicates the scheme satisfies the corresponding criterion based on above definitions.

.

As evidenced in Table 2, existing dual-offline payment solutions exhibit significant functional deficiencies compared to the proposed methodology, which delivers a more comprehensive security framework. The approach not only satisfies core security requirements of dual-offline payments but also provides users with the practical flexibility essential for real-world scenarios. Specifically, the other conventional methods demonstrate critical limitations: secure communication channels remain unimplemented in competing systems, severely restricting their applicability, trusted execution environment and secure element solutions [32,33,34] fail to meet fundamental security standards required for robust offline payments, NFC-based protocols [28,29] lack adequate mechanisms to ensure data integrity and authenticity during offline operations while exhibiting inherent vulnerabilities in double-spending prevention, and CBDC-focused frameworks  [30] and electronic cash and multi-denomination systems [39] fundamentally lack payer privacy protection. In contrast, the dual-offline payment method fulfills all aforementioned functional requirements while demonstrating superior performance in both security robustness and privacy preservation metrics.

5.2. Experimental Environment Configuration

The dual-offline payment scheme implemented in this paper operates between two payment devices via offline accounts and enables end-to-end transaction processing through a payment credential generation and verification mechanism. Experimental evaluations were conducted in two independent environments: a software prototype platform and a practical hardware wallet platform.

Software Prototype Environment: The testing platform utilized a laptop equipped with an Intel(R) Core(TM) i5-1035G1 quad-core processor operating at a base frequency of 1.19 GHz, paired with 8 GB of RAM, running the Microsoft Windows 11 operating system (version 22631.4317) on an Inspiron 5493 hardware base. The core scheme was implemented in JavaScript, leveraging the elliptic library (version 6.5.4) to perform all requisite elliptic curve cryptographic operations based on the secp256k1 curve. Cryptographically secure random number generation for critical parameters such as private keys and nonces was ensured through the crypto.getRandomValues() Web API. This software-based implementation served as the foundational reference model, allowing for controlled performance profiling and verification of the protocol’s logical correctness in a standard computing setting.

Hardware Wallet Environment: To comprehensively evaluate the practical feasibility and real-world performance of the scheme, the system was ported and exhaustively evaluated on a hardware wallet device. This device is architected around a dedicated Secure Element (SE), which provides a tamper-resistant environment and hardware acceleration specifically optimized for secp256k1 operations, forming the cornerstone for secure offline key management and transaction signing. The hardware platform is characterized by its constrained resources, featuring 16 MB of Flash memory for persistent storage of application code and payment credentials, and 8 MB of RAM to support runtime operations. For the essential peer-to-peer data exchange required in dual-offline payments, the device incorporates an integrated Bluetooth module. Beyond computational specifications, it embodies a high-assurance security posture through multiple integrated active physical protection mechanisms. These include real-time monitoring sensors for voltage, temperature, and ambient light; robust tamper detection that triggers upon case-opening attempts; and inherent cryptographic design resistances to sophisticated side-channel attacks, such as Differential Power Analysis and Simple Power Analysis. Performance metrics, most notably the total end-to-end payment processing latency, were systematically collected over 100 consecutive transaction cycles in this environment, and a detailed analysis of these results is presented in Section 5.3.

5.3. Assessment of the Dual-Offline Payment Methodology

(1)

Offline account performance

The experiments employ JavaScript to support the offline payment protocol and simulate dual-offline payments between two accounts. Performance metrics focused on computational efficiency during payment generation and verification under varying operational conditions, including time consumption and memory footprint. For payment generation, the system initiates by creating a unique payment $UUID$, then computes input credentials $P_i$ and change credentials $P_c$ through the dot-multiplication operation on elliptic curves based on initial parameters and decoy factors. Additional operations include cryptographic key-pair generation, challenge value E, and signatures $S_s$.

Across 100 simulated dual-offline payments, all transactions succeeded with an average generation latency of 29.13 ms. This time consumption mainly concentrates on elliptic curve operation and encryption operation, indicating high computational efficiency in offline environments and rapid response to the user’s payment request. Regarding verification performance, the critical security process involves recalculating challenge value E, validating signature integrity, and executing zero-sum verification. The experimental results show that an average verification latency is 25.09 ms, confirming the algorithm’s real-time efficacy in authenticating payment legitimacy while protecting counterparty interests. Performance trends are visualized in the line chart presented in Figure 3.

To further validate the applicability of this dual-offline payment protocol in a real physical security environment, we deployed the described offline payment solution within a hardware wallet device for implementation and evaluation. This hardware wallet, specifically designed for offline key management and transaction signing, represents the form factor of a payment terminal. On this hardware platform, we simulated and executed 100 complete dual-offline payment processes, matching the scale of the software environment. Experimental results demonstrate that all transactions were executed securely and stably, achieving a 100% success rate. The key performance metric—the generation time and verification time of the payment process—are illustrated in Figure 4, showing their trend and average value. Under this hardware implementation, the average generation time was 129.7 ms, and the average verification time was 64.1 ms, with these two core operations together constituting the complete offline payment processing. This data holds significant practical importance, demonstrating that porting the core cryptographic operations of this protocol to dedicated secure hardware is both fully feasible and highly efficient. The average payment time falls within the realm of instantaneous response at the user interaction level, ensuring a seamless payment experience. More importantly, operating within a hardware security environment completely isolates sensitive information such as private keys from potential internet-based intrusions. This physically enhances the payment process’s resilience against attacks and malicious theft, achieving a balance between security and efficiency. In summary, the successful implementation and performance metrics on hardware wallets demonstrate that the offline payment protocol proposed in this paper not only operates efficiently in software environments but can also be securely realized in dedicated hardware devices. This provides a robust practical foundation for truly secure and reliable dual-offline payment solutions.

This paper evaluates multiple stages within the payment generation in this study: elliptic curve operations (ec), key generation (keyGen), hash computation (hash), and signature generation (sign). Building upon the total payment generation and verification latency metrics, we further analyze stage-specific time consumption and performance stability across these phases. Through 100 simulated dual-offline payment trials, the mean duration per stage was calculated, with stage stability quantified using the standard deviation formula:

$$\sigma =\sqrt{{\displaystyle \frac{1}{N}}{\sum }_{i=1}^N{(x_i-\mu )}^2}$$

(25)

where $x_i$ is a single measurement, $\mu$ is the mean value, and N is the total number of measurements, the standard deviation of the time spent in each stage of the calculation scale. Analysis results are visualized in Figure 5 and tabulated in

Table 3. Distribution of time spent in each stage of payment generation.

Phase	Average Time Consumption	Standard Deviation
Elliptic curve operations	7.61 ms	1.11 ms
Key generation	11.89 ms	1.33 ms
Hash computation	0.20 ms	0.53 ms
Signature generation	10.10 ms	1.24 ms

. The elliptic curve operation involves elliptic curve dot multiplication, addition, and other operations. The analysis shows that the average time consumed is $7.61\mathrm{ms}$, with low standard deviation ($\sigma =1.11$), indicating stable operation time. Key generation encompasses cryptographically secure random number generation (crypto.randomBytes) and elliptic curve point multiplication (G.mul), which is the most time-consuming phase at $11.89\mathrm{ms}$ mean duration. Hash computation demonstrated high efficiency with $0.2\mathrm{ms}$ average latency and near-zero standard deviation ($\sigma \approx 0$), confirming the optimized performance of the SHA-256 implementation. Signature generation exhibited $10.10\mathrm{ms}$ mean latency due to its dependency on elliptic curve cryptography, aligning with keyGen’s computational profile. Key generation and signature generation account for 88.7% of the total generation time, consistent with the theoretical time complexity of ECC key generation and signature. The minimal standard deviations across all stages (Table 3) confirm consistent performance characteristics throughout repeated executions.

Memory efficiency is also an important metric in offline payment protocols. This experiment simulated the memory usage changes during 100 dual-offline payment. The experimental results demonstrate relatively low memory consumption at $0.635$ $\mathrm{MB}$, with minimal fluctuation range of ± $0.002$ $\mathrm{MB}$ (0.6330 $\mathrm{MB}$ to 0.6350 $\mathrm{MB}$). Crucially, memory utilization remained consistently stable despite increasing transaction duration and volume, as shown in Figure 6.

(2)

Security Evaluation

In terms of data integrity protection, the payment process utilizes elliptic curve cryptography and SHA256 hash algorithm to generate a digest value E and signature $S_s$. Since any tampering with the payment data would alter both E and $S_s$—detectable during verification—this method effectively identifies unauthorized modifications, thereby ensuring end-to-end payment data integrity. Payment validity is confirmed through equivalence verification between $S^{\prime }$ and $S{v}^{\prime }$. The verification algorithm designed based on the algorithmic principle has two scenarios of verification results, as shown in Figure 7 and Figure 8, respectively.

Experimental evaluation demonstrated 100 successful validation across offline payments between paired accounts, confirming unaltered data transmission and robust integrity protection—empirically validating the method efficacy for dual-offline payments as quantified in

Table 4. Offline account performance.

	Proposed Scheme	Proposed Scheme with SE	TEE-Based Blockchain Offline Payment [20]	DOPS [33]
Avg. Gen. Time	29.13 ms	129.7 ms	32 ms	80 ms 1
Avg. Ver. Time	25.09 ms	64.1 ms	16.7 ms	-

¹ Minimum total transaction time 112 ms (including communication), core generation time 80 ms.

.

Regarding privacy protection, user identities are represented as elliptic curve points, while all sensitive information (including payment amounts) undergoes elliptic curve encryption supplemented with blinding factors for multi-layered security. In addition, even when payment data is intercepted, the computational infeasibility of elliptic curve discrete logarithm problems prevents decryption of sensitive information, thereby achieving computational privacy guarantees and ensuring comprehensive payment security.

5.4. Cryptographic Cost Comparison (O(1) Complexity)

This scheme utilizes a fixed, small number of Elliptic Curve Point Multiplications (ECPMs) and Point Additions for credential generation and verification. This approach provides significant performance benefits over general-purpose zero-knowledge proofs:

• This Scheme (ECC+ZKP Principles): The computational complexity for both payment generation and verification is constant time, $O\left(1\right)$, as the number of ECPMs is fixed, irrespective of the magnitude of the transaction amount or the number of prior transactions.
• Generic ZKP Systems (e.g., zk-SNARKs): Proof generation typically exhibits complexity ranging from $O(NlogN)$ to $O\left(N\right)$ (where N is the number of gates in the underlying arithmetic circuit), making them significantly heavier for resource-constrained offline devices, especially when N is large [25].

This $O\left(1\right)$ constant time complexity is a key advantage for resource-constrained dual-offline scenarios, providing a superior performance-to-privacy tradeoff compared to full-fledged ZKP constructions.

5.5. Analytical Interpretation of Simulation Results

The experimental data reveals two distinct performance profiles for the protocol. In the software-only implementation, the average payment generation latency is $29.13$ ms and verification latency is $25.09$ ms. These low and stable latency figures, even when simulating large numbers of payments (up to 100 in this test) and varying transaction amounts, are a direct consequence of the protocol’s $O\left(1\right)$ computational complexity. The core operations (Elliptic Curve Point Multiplications and Additions) are fixed in number regardless of the input values (transaction amounts $V_i$, $V_c$, $V_r$), resulting in a flat latency profile and assuring high efficiency and scalability.

For the hardware-based implementation incorporating a Secure Element (SE), the average payment generation time rises to $129.7$ ms and the average verification time to $64.1$ ms. This increase in latency is attributed to the inherent constraints of secure hardware, including limited processing power, communication overhead between the main processor and the SE, and the execution of robust side-channel attack countermeasures (e.g., against Differential Power Analysis). Despite the higher absolute times compared to the software implementation, the performance remains within the realm of real-time interaction for end-users. More critically, this implementation achieves a fundamental security enhancement by physically isolating sensitive cryptographic material and operations within a tamper-resistant environment, thus providing a balanced trade-off between security assurance and practical performance for deployment in hardened payment terminals.

6. Conclusions and Future Work

This paper proposes a cryptocurrency dual-offline payment method utilizing cryptographic commitments and zero-knowledge principles to specifically address privacy protection problems in offline payment scenarios. The method achieves cryptographic protection of sensitive information (e.g., the payer’s wallet balance) during identity verification, a process in which payment capability is demonstrated through a specialized cryptographic challenge-response protocol that establishes a solution that balances reliability with privacy. By implementing a payment credential generation and verification mechanism integrated with elliptic curve cryptography authentication protocols, the method ensures transaction validity through cryptographic signatures while concealing counterparty identities and transaction amounts. Furthermore, this paper systematically characterizes the threat model for dual-offline payment system and empirically validate the method’s satisfies fundamental security requirements of real-world offline payment scenarios, including guaranteed data integrity and authenticity, effective double-spending resistance mechanism, and robust user privacy protection.

Through theoretical analysis and comparison, the method proposed in this paper significantly outperforms existing schemes in both security and privacy, fully meeting the security requirements of offline payment. However, this study primarily focuses on the atomic model of a single, isolated dual-offline transaction. The protocol’s application reveals several inherent limitations that warrant further research:

• Adversarial testing and extended experimental comparison: Future work will conduct comprehensive adversarial testing, including simulating advanced attacks such as differential power analysis (against SE), malicious SE tampering, and transaction replay attacks under extreme offline conditions. We will also extend experimental comparisons to more state-of-the-art dual-offline payment schemes (e.g., zk-SNARKs-based solutions), evaluating performance (latency, memory usage) and security robustness across diverse hardware environments (low-power IoT devices, edge computing nodes) and network constraints.
• Continuous Offline Transactions: The current design does not efficiently support repeated or chained offline spending, where a single payer makes multiple successive transactions before reconnecting to the network. Extending the method to handle continuous transactions requires sophisticated mechanisms for state management and privacy-preserving balance updates without online consensus.
• Advanced Scenario Complexity: Further research is needed on complex scenarios, such as multi-hop payments (transferring funds through multiple intermediate offline devices), and detailed analyses of malicious behavior by the payer or payee during the final settlement reconciliation.

Addressing these limitations, particularly the challenge of continuous offline transactions, will be the central focus of next phase of work. These improvements aim to construct a comprehensive and practical solution suitable for high-frequency, complex offline payment environments.