DiFastBit: Transaction Differentiation Scheme to Avoid Double-Spending for Fast Bitcoin Payments

Abstract

Bitcoin is a payment system that generates a decentralized digital currency without ensuring temporal constraints in its transactions; therefore, it is vulnerable to double-spending attacks. Karame has proposed a formalization for a successful double-spending attack based on meeting three requirements. This focuses on fast payment scenarios where the product is delivered immediately after the payment is announced in the mempool, without waiting for transaction confirmation. This scenario is key in Bitcoin to increase the probability of a successful double-spending attack. Different approaches have been proposed to mitigate these attacks by addressing one or more of Karame’s three requirements. These include the following: flooding every transaction without restrictions, introducing listeners/observers, avoiding isolation by blocking incoming connections, penalizing malicious users by revealing their identity, and using machine learning and bio-inspired techniques. However, to our knowledge, no proposal deterministically avoids double-spending attacks in fast payment scenarios. In this paper, we introduce DiFastBit: a distributed transaction differentiation scheme that shields Bitcoin from double-spending attacks in fast payment scenarios. To achieve this, we modeled Bitcoin from a distributed perspective of events and processes, reformulated Karame’s requirements based on Lamport’s happened-before relation (HBR), and introduced a new theorem that consolidates the reformulated requirements and establishes the necessary conditions for a successful attack on fast Bitcoin payments. Finally, we introduce the specifications for DiFastBit, formally prove its correctness, and analyze DiFastBit’s confirmation time.

1. Introduction

Bitcoin is a payment system introduced in 2009 by Satoshi Nakamoto [1] that creates a decentralized digital currency and operates on a distributed network of nodes. Its communication is asynchronous, exchanging blocks and transactions in their messages without ensuring temporal constraints. As a result, Bitcoin is a non-deterministic payment system, and transaction verification is a slow process that can take from a few minutes to as long as 72 h [2]. This delay is generally acceptable for scenarios without temporal restrictions, such as Internet sales. However, in fast payment scenarios, such as withdrawing money from ATMs [3], shopping in self-service stores [4], and food delivery service apps [5], Bitcoin is exposed to double-spending attacks because transactions in the mempool cannot be trusted due to the distributed nature of the system [6].

Karame has formalized the requirements for a successful double-spending attack by meeting three conditions [7], and based on these requirements, several strategies have been proposed to prevent or detect the attack. Karame proposes flooding the transaction in the network without restriction, even if the same currency is detected to be spent twice, thus increasing the probability of detecting a double-spending attack [7]. Another strategy introduces observers and listeners to detect attacks; the more listeners there are in the network, the higher the probability of detection [8]. In addition, to avoid isolation, it is suggested to connect to random nodes, reject connections, and not forward transactions while a transaction is processed [9]. Other approaches propose revealing the private keys of malicious users through new types of transactions using Bitcoin’s scripting language [10]. Recently, innovative methods have been proposed, such as the use of artificial immune systems [11], advanced machine learning techniques such as graph neural networks (GNNs) [12], and the modification of SHA-256 to SHA512 [13].

However, to our knowledge, there is no proposal that deterministically avoids double-spending attacks on fast Bitcoin payments. This remains an open challenge due to the distributed nature of the system. In this paper, we introduce DiFastBit: the first scheme capable of shielding Bitcoin, avoiding double-spending attacks for fast payments based on the requirements proposed by Karame. To achieve this, we follow these methodological steps:

• Modeling of Karame’s requirements for double-spending attacks in fast payment scenarios.
• Reformulation of Karame’s requirements using Lamport’s HBR.
• DiFastBit specification and formal proof of its correctness.

The results of this methodology show that it is possible to enable the immediate delivery of products or services without double-spending attacks, according to the modeling and reformulation of Karame’s requirements. By reformulating these requirements from a distributed perspective based on Lamport’s HBR, we establish that they are necessary for a successful double-spending attack on fast Bitcoin payments. To counter these reformulated requirements, we propose a transaction differentiation scheme and a merchant layer to handle fast-payment transactions, extending the original Bitcoin payment system. Finally, we prove that the asynchronous verification layer can process fast-payment transactions, ensuring the reliable immediate delivery of any product or service without falling victim to double-spending attacks.

The rest of the paper is organized as follows: Section 2 presents an overview of the fundamental concepts of Bitcoin, such as double-spending for fast Bitcoin payments, Karame’s model, and Lamport’s HBR. Section 3 provides an overview of related work, with a particular focus on strategies to prevent or detect double-spending attacks. Section 4 reformulates Karame’s requirements based on Lamport’s HBR, and Appendix A presents the proof that Karame’s reformulated requirements are necessary for a successful double-spending attack. Section 5 introduces DiFastBit: a transaction differentiation scheme to avoid double-spending on fast Bitcoin payments, and Section 6 compares the Bitcoin confirmation time with the DiFastBit confirmation time. Section 7 discusses our findings and future work, and finally, Section 8 concludes the paper.

2. Background

In this section, we provide an overview of Bitcoin, explaining the transactional confirmation process and decentralization. We then analyze the double-spending attack, an issue for digital currencies, and describe how a malicious user can attempt to spend the same coin twice. In addition, we outline Karame’s model and the conditions necessary for a successful double-spending attack. Finally, we introduce Lamport’s HBR, essential for understanding causal interactions in distributed systems.

2.1. Bitcoin Overview

Bitcoin is the result of years of research in distributed systems and cryptography, leading to a decentralized payment system. In this system, peers verify and propagate transactions that transfer value between users, eliminating the need for trusted third parties [14].

In Bitcoin, the amount of coins that a user receives during a transaction is represented by unspent transaction outputs (UTXOs), which are signed data structures that reference previous transactions. Basically, an input is an unspent output from a previous transaction, and a user’s balance is the sum of all their UTXOs, which they can access and spend using their digital signature [15].

To propagate a transaction on the Bitcoin network, a user must connect through a node and generate a pair of keys: one public and one private. The private key is generated using a secure random seed, and the public key is generated by performing an elliptic curve multiplication on the private key. Both keys are stored in a wallet and are associated with an address derived from the digest of the public key. This address is used to receive Bitcoin transactions, while the private key is used to sign and authorize them [16].

Each time a node receives a transaction, it verifies that it is correct, i.e., that there are enough Bitcoins to perform the transaction (the output does not exceed the input), that the UTXO is spent once (there is no double-spending), and that the digital signature is authentic. Once the transaction is verified, the node stores it in a memory space called the mempool and propagates it to its neighbors [17]. In the mempool, transactions wait to be added to a block. The time it takes for a transaction to be added to a block and confirmed on the blockchain can vary depending on the fees paid by the user. For example, higher fees generally result in faster transaction confirmation times of approximately 10 min, while lower fees can result in delays of up to 72 h [18,19].

2.2. Overview of Double-Spending Attack on Fast Bitcoin Payments

The double-spending attack is a digital currency problem that arises from the replicable data structure and occurs when a malicious user, such as Alice, attempts to purchase two products with the same coins [20]. To do this, Alice creates two conflicting transactions, ($Tr\left(B\right)$) and ($Tr\left(A\right)$), where $Tr\left(B\right)$ is the “honest’’ transaction that attempts to pay the merchant, Bob, and $Tr\left(A\right)$ is the “dishonest’’ transaction that reverses the funds from the "honest" transaction or pays for another product.

Figure 1 shows a double-spending attack, where a malicious user exploits the distributed nature of Bitcoin, propagating two conflicting transactions and splitting the network into two parts. The red nodes verify $Tr\left(A\right)$, while the blue nodes verify $Tr\left(B\right)$. Bitcoin states to the nodes receiving both transactions validate the one that arrives first and rejects any transaction that spends the same UTXO [21]. The figure shows this node’s outline in green. The reject process allows Bob to be isolated, and as a result, the network has no clear consensus on which transaction is valid, allowing Alice to spend the same coin twice [22]. Bitcoin solves the isolation problem through consensus, as all nodes in the network confirm one of the two transactions. However, the confirmation time is a slow and non-deterministic process, and resolving conflicting transactions can take several hours, making it uncertain which of the two transactions will be confirmed.

2.3. Karame’s Model

Karame’s model involves two actors: a malicious user named Alice and a seller named Bob, connected to the Bitcoin network. Alice wants to buy a product from Bob without spending her coins by performing a double-spending attack, where she spends the same coin twice. It is assumed that Alice can control several nodes in the network but does not have access to Bob’s nodes, and that the other nodes are honest. Additionally, Alice lacks sufficient computational power to create a block, which means that once a transaction is part of a block, it cannot be changed [6]. To successfully perform a double-spending attack [7], Karame suggests the following conditions:

Requirement for Successful Double-Spending

• Requirement  1: $Tr\left(B\right)$ is added to Bob’s mempool. If $Tr\left(B\right)$ is not added to Bob’s mempool, then there is no product delivery because there is no evidence that Alice wants to pay Bob.
• Requirement  2: $Tr\left(A\right)$ is confirmed on the blockchain. If transaction $Tr\left(B\right)$ is confirmed before transaction $Tr\left(A\right)$, Alice will not be able to get her coins back and Bob will receive payment for the product.
• Requirement  3: Bob’s product delivery time is less than Alice’s misbehavior detection time. Bob needs to be in a fast-payment scenario to ensure the product is delivered before blockchain confirmation.

2.4. Definition of Lamport’s Happened-Before Relation

The causal relation proposed by Lamport is denoted by “→’’ and is called the happened-before relation [23]. It is defined as follows:

Definition 1 

(Happened-Before Relation). The relation “→’’ on the set of events of a process in a system satisfies the following three conditions:

1. 

If a and b are events belonging to the same process and a occurred before b, then $a\to b$.

2. 

If a is the sending of a message by one process and b is the reception of the same message by another process, then $a\to b$.

3. 

If $a\to b$ and $b\to c$, then $a\to c$.

When two events are unrelated, Lamport defines a pair of concurrent events as follows:

Definition 2 

(Concurrent Events). Two events a and b are considered concurrent, denoted as $a\Vert b$ if there is no causal relation between them. According to Lamport, this means that it cannot be affirmed that a happened before b (denoted as $a\to b$), nor that b happened before a (denoted as $b\to a$). The mathematical expression for this is:

$$a\left|\right|bif\neg (a\to b\vee b\to a)$$

(1)

3. Related Work

This section delves into proposals addressing double-spending attacks in fast payments, highlighting how each method probabilistically detects, prevents or combines both types of solutions.

Table 1. Comparative analysis of double-ppending prevention and detection methods.

Author	Method	Features	Advantages	Disadvantages
Mathias Herrmann 2012 [21]	Transaction border analysis	Detection: Implementation and detection of attacks through transaction border analysis	Provides practical insights into attack methods and detection mechanisms	Limited to specific scenarios and probabilistic detection in certain configurations
Ghassan Karame et al. 2012 [6]	Network flooding and observers	Prevention: Flooding transactions in the network Detection: Use of listeners and observers	Provides a lightweight solution that enhances detection of double-spending attacks in fast payments	Used observers to detect the attack in a probabilistic manner, network flooding can overload the network
Tobias Bamert et al. 2013 [8]	Random node connection	Prevention: Connecting to random nodes, rejecting connections and not forwarding transactions	Focuses on practical use cases of Bitcoin in everyday transactions	The prevention methods are probabilistic and limited to small fast payments.
Ghassan Karame et al. 2015 [7]	Network flooding and observers	Detection: Techniques and accountability measures for double-spending	Details the necessary conditions for a successful double-spending attack	Detection is probabilistic depending on observers, could overload the network
John Podolanko et al. 2017 [9]	Hybrid peer alert system	Detection: Enhanced observers and hybrid peer alert system for fast-payment transactions	Detects double-spend attacks within 22 s on average	Requires balancing the number of observers and detection is probabilistic
Cristina Pérez-Solà et al. 2017 [10]	Bitcoin script key revelation	Prevention: Private key revealed using the Bitcoin scripting language to prevent double-spending	Uses Bitcoin’s scripting language to reveal private key and prevent double spending attacks	The probabilistic detection depends on observers to prevent attacks
Zhengjun Liu et al. 2017 [11]	Artificial immune systems	Detection: Artificial immune systems for detecting double-spending in fast Bitcoin payments	Innovative approach inspired by biological systems rate improves significantly with memory detectors	Require extensive testing in multiple scenarios increase the memory to improve probabilistic detection.
Changhoon Kang et al. 2023 [12]	Graph neural networks	Detection: Observer node strategy, graph neural networks (GNNs), to detect double-spending attacks	Uses advanced machine learning techniques for detection	Requires high computation needs to adjust the number of observers to increase the probabilistic detection.
Hasan Hashim et al. 2023 [13]	SHA-512 ECDSA algorithms	Prevention: Algorithms to prevent double-spending attacks using SHA-512 and ECDSA	Provides a strong theoretical foundation for prevention and enhanced security compared to SHA-256	Higher execution time and probabilistic difficult to generate transaction signatures.
Our Work 2024	Transaction differentiation	Avoiding: DiFastBit avoids double-spending in fast Bitcoin payments using transaction differentiation.	Provides models that abstract the problem and provide a theoretical solution deterministic for the attack.	The implementation may overload the network when checking fast payments in nodes.

provides a summary of these strategies, detailing the methods, advantages, and disadvantages presented by various authors over the years. Furthermore, we identify a research gap, as no study focuses on a deterministic solution to double-spending attacks on fast Bitcoin payments according to Karame’s requirements.

Mathias Herrmann (2012) [21] analyzed the vulnerability of Bitcoin to double-spending attacks in fast-payment scenarios and proposed that attacks succeed in such situations. The study evaluated the probability of success of these attacks and explored different attacker and victim configurations. The contribution of this work is the proposal of a detection mechanism that leverages border transactions—nodes at the boundary of conflicting transactions—to alert users of double-spending attacks. This method improves detection by monitoring transaction conflicts and providing alerts within a ten-second window. Herrmann also suggests security parameters to mitigate risks, highlighting the probabilistic nature of these attacks and offering practical insights into their prevention.

Ghassan Karame et al. (2012 and 2015) [6,7] have presented two studies on the problem of double-spending on fast Bitcoin payments. In the first study, entitled “Two Bitcoin at the Price of One? Double-Spending Attacks on Fast Payments in Bitcoin’’, the authors show that double-spending attacks are feasible and can be executed on current versions of Bitcoin. They propose a lightweight countermeasure that allows the detection of these attacks without requiring significant modifications to Bitcoin’s implementation. Experimental results show the feasibility and ease of performing double-spending attacks. The second study, “Misbehavior in Bitcoin: A Study of Double-Spending and Accountability’’, analyzes the security of fast Bitcoin payments, where the time between the exchange of currency and products is short. The article focuses on the requirements necessary for a successful double-spending attack. The authors suggest propagating transactions without restriction to alert nodes of potential double-spending attacks. Experimental results show both the feasibility of these attacks and the effectiveness of the proposed countermeasures.

Tobias Bamert et al. (2013) [8] implemented and evaluated a system that enables fast payments with Bitcoin, overcoming the limitation of long transaction confirmation times. The authors suggest that the merchant should connect to a random sample of nodes in the Bitcoin network to avoid relying on a single node. In addition, they suggest not accepting incoming connections to prevent attackers from sending fraudulent transactions directly to the merchant, and implementing a listening period to monitor transactions and use return chaining to ensure that any refund is valid for the original transaction. The authors implement their proposal in a vending machine that accepts Bitcoin payments. A transaction is valid if it reaches a propagation threshold in the network in less than 10 s. Experimentation shows that the probability of detecting double-spending attempts improves significantly.

John Podolanko et al. (2017) [9] address the vulnerability of Bitcoin to double-spending attacks in fast payment scenarios, such as fast food restaurants and vending machines. The proposal implements enhanced observers (ENHOBS) that inspect all received transactions. Once a double-spending attack is detected, an alert message is sent to the victim. The ENHOBS requires minimal modifications to the Bitcoin clients to accept and process alerts. Experiments run within the Shadow simulation framework introduced double-spending attacks into the simulated network and measured the detection time. The results show that the ENHOBS can alert vendors to a double-spending attack in an average of 22 s. Implementing ENHOBS in 2% of the network significantly improves detecting and responding to double-spending attacks.

Cristina Pérez-Solà et al. (2017) [10] address the issue of zero-confirmation Bitcoin transactions, which allow fast payments but are vulnerable to double-spending attacks. The authors propose a mechanism to prevent double-spending in these transactions by exploiting the flexibility of Bitcoin’s scripting language and a known vulnerability in the elliptic curve digital signature algorithm (ECDSA). The signature scheme is probabilistic, allowing multiple valid signatures with the same private key for the same message. If k identical values are used in the signatures of two messages, attackers can derive the signer’s private key. The method proposes a new script called “fixed-r pay-to-pubkey’’ (FR-P2PK), which adds a condition to spend an output: the signature must be made with a specific r value. If two different signatures made with the same k are detected, the private key can be derived, allowing any observer to create a third transaction to penalize the attacker.

Zhengjun Liu et al. (2017) [11] address the issue of double-spending on fast Bitcoin payments from a bio-inspired perspective. They propose an artificial immune-based attack detection model, which includes Bitcoin nodes equipped with a detection module and a traditional node. Antigens, specific characteristics extracted from transactions, are used to generate initial detectors. These detectors undergo an evolutionary process: immature detectors that do not match the self-antigens evolve into mature detectors. If a mature detector identifies a double-spending attack, it evolves into a memory detector and transmits a “vaccine’’ to other nodes to alert. Simulations run with real Bitcoin data show that the proposed model can rapidly detect double-spending attacks, significantly enhancing security in fast payments.

Changhoon Kang et al. (2023) [12] address the detection of double-spending attacks on fast Bitcoin payments using a GNN. Since Bitcoin transactions use UTXOs as inputs and generate new UTXOs at specific addresses, double-spending occurs when a UTXO is used more than once in different transactions. The authors create virtual Bitcoin networks with a structure similar to the real network, fixing the number of nodes at 14,000. The model utilizes two GNN layers, ReLU and dropout. Cross-entropy loss is used to train the model, and three popular GNN algorithms are employed: GCN, GraphSAGE, and GAT. The detection accuracy of the model was at least 95% with 100 observer nodes. However, the model could not be fully trained because there was not enough information to predict the state of the whole network.

Hasan Hashim et al. (2023) [13] address the challenge of double-spending attacks in zero-confirmation transactions within Bitcoin. The authors present an approach that generates a cryptographic identity using elliptic curve cryptography, combined with SHA-512, to enhance transaction security. This method significantly increases the difficulty of double-spending attempts by using SHA-512, which produces a 512-bit hash, much larger than the 256-bit hash. The experiments and simulations show that SHA-512 offers superior performance in countering double-spending attempts, effectively mitigating these risks. In addition, the authors suggest that integrating SHA-512 into the ECDSA scheme not only enhances security but also provides a more robust method for protecting zero-confirmation transactions. The results show that SHA-512 can effectively prevent double-spending attacks, and the authors suggest areas for future research to further enhance transaction security in the Bitcoin network.

Joseph Poon et al. [24] and Decker et al. [25] introduce the use of smart contracts to conduct transactions off the main Bitcoin blockchain via payment channels. Based on this, the Lightning Network was developed, an infrastructure that facilitates fast transactions and enhances Bitcoin’s transactional throughput. Although the Lightning Network increases throughput, it also presents specific risks, such as the possibility that one of the users might remove the payment channel during a transaction. For this reason, the Lightning Network is recommended for small transactions, such as paying for coffee or fast food, and not for purchasing high-value items. In Section 7.4 of the paper, we focus on the differences between the Lightning Network and DiFastBit, concluding that although DiFastBit solves the double-spending problem, its distinctive transaction management positions it as a viable alternative for fast payments. We also discuss differences that may complement future work in this area.

Summary

Several approaches have been proposed to mitigate double-spending attacks on fast Bitcoin payments. However, as shown in the Table 1, there is a gap in the current research as these approaches focus on probabilistic prevention or detection of the attack but not on complete prevention. This paper presents DiFastBit, the first scheme to deterministically shield Bitcoin against double-spending attacks in fast payment scenarios. This scheme is based on Karame’s reformulated requirements and breaks these requirements, effectively avoiding these attacks in the Bitcoin network.

4. Modeling Karame’s Requirements Based on Lamport’s HBR

The requirements proposed by Karame for a successful double-spending attack are based on the propagation time of malicious and honest transactions. According to Karame, the difference in propagation time gives an advantage to the malicious transaction, allowing it to reach more nodes and increasing its probability of being added to the blockchain faster. To understand this, suppose Alice is a malicious user attempting a double-spending attack by exploiting propagation time. Alice’s goal is to obtain a product from Bob without spending her coins. Thus, she propagates $Tr\left(B\right)$ to Bob to pay for the product, while simultaneously propagating $Tr\left(A\right)$ to as many nodes as possible to counteract $Tr\left(B\right)$. However, in a decentralized system such as Bitcoin, ensuring a successful double-spending attack based on propagation time is not precise, as communication between nodes is asynchronous, and propagation can often experience delays or may not reach all nodes.

Based on this premise, in this section, we model Bitcoin in a distributed environment of processes and events. We then propose a reformulation of Karame’s requirements using Lamport’s HBR.

4.1. Bitcoin Model as Distributed Environment of Processes and Events

To understand the decentralized logic of Bitcoin and the challenge of double-spending in fast Bitcoin payments, we modeled Bitcoin as a distributed environment, obtaining additional information about the system’s behavior. This model provides a detailed view of transactional propagation and node communication, allowing one to observe the effects of asynchronous communications and evaluating Karame’s requirements.

We model Bitcoin in three different sets: A set of processes $Nodes$, a set of messages M, and a set of events E.

4.1.1. Processes

The processes are a set of nodes that execute the consensus algorithm, validate transactions, and ensure the integrity of the blockchain. The independent operation of each node is key, as it allows the system to remain robust in the face of failures of individual nodes.

Consider that each node $n\in Nodes$ is defined as an independent process that participates in the maintenance and operation of the Bitcoin blockchain. This is formally defined as follows:

Definition 3. 

Let $Nodes$ be the set of all processes in the Bitcoin network, where each process n is defined by a identifier and a state. The state ${\mathcal{S}}_n$ of a node n includes its current view of the blockchain, and pending transactions. Thus, a node n can be defined as the tuple:

$$n=(i{d}_n,{\mathcal{S}}_n)$$

(2)

where $i{d}_n$ is the identifier of the node.

4.1.2. Messages

The Bitcoin protocol uses a variety of message types to ensure communication and operation within its network. These include initial handshake messages, which establish connections between nodes; inventory (inv) messages, which inform other nodes of known blocks and transactions; payload messages, which contain the actual data of transactions or blocks; get data messages, which request specific transactions or blocks; block messages, which contain block information; and transaction messages, which transmit transaction data [26]. For this model, we focus on blocks and transactions, which are the usage messages for a double-spending attack.

• Transactions represent the fundamental mechanism through which value is transferred between participants in the network. They modify the state ${\mathcal{S}}_n$ of each node that validates and accepts the transaction. Transactions consist of several elements:

  Definition 4. 

  Txid is the unique identifier of the transaction. ${\mathit{Vin}}_{\mathit{Tr}\left(X\right)-1}$ represents the inputs, which are references to outputs of previous transactions that are being spent by this transaction. ${\mathit{Vo}}_x$ lists the outputs, where each output specifies an amount of Bitcoins and a recipient address to which these Bitcoins are being transferred.

  $$Tr\left(X\right)=\{Txid,Vi{n}_{T_{x-1}},V{o}_x\}$$

  (3)
• Blocks in the Bitcoin network are data structures that store a set of transactions, ensuring the integrity of the blockchain. Below is a formal definition:

  Definition 5. 

  A block, denoted as BC, is a set of transactions that have been validated and linked to the blockchain. It is defined as:

  $$BC=\left\{Tr\right(X),Tr(Y),Tr(Z),\dots \}$$

  (4)

  where each $Tr$ represents a transaction included in the block.
  The block in Bitcoin contains additional information such as the block header, timestamp, nonce, and the previous block hash. However, for the purposes of our double-spending model, we are only relevant to the transactions contained in the block.

4.1.3. Events

In the Bitcoin network, events represent actions that occur at a time interval and are associated with processes in the set $n\in Nodes$. Each event e is part of the set E, which is divided into internal and external events, denoted $E_{internal}$ and $E_{external}$.

Internal events are performed by nodes and affect their state without affecting other nodes in the network. Specific internal events include adding a transaction to the mempool, rejecting a transaction, and delivering a product. Each of these events is described in detail below.

• Add transaction to mempool: This event is released when a transaction is temporarily stored in the mempool, awaiting confirmation to be added to the blockchain.

  $$Add(n,MP\leftarrow Tr(X\left)\right)$$

  (5)
• Rejecting a transaction: A transaction is rejected by the node if it fails the validation process due to issues such as double-spending, where the same digital currency is spent twice.

  $$Reject\left(Tr\right(X\left)\right)$$

  (6)
• Delivery product: This event represents the delivery of an item from Bob to Alice after the successful receipt of the transaction $Tr\left(B\right)$, by Karame’s model.

  $$d(Alice,P)$$

  (7)

External events have a significant impact on the network because they affect the view of multiple nodes and are essential for keeping the network consistent and ensuring data propagation. Each of these events is described in detail below.

• Sent $Tr\left(X\right)$: Represents the action of a node sending a transaction or message to another node in the network.

  $$s(n,Tr(X\left)\right)$$

  (8)
• Received $Tr\left(X\right)$: Occurs when a node receives a transaction or message that modifies its local state.

  $$r(n,Tr(X\left)\right)$$

  (9)
• Sent $BC$: Represents a node broadcasting a newly validated block to other nodes, ensuring the block’s acceptance and integration into the blockchain.

  $$s(n,BC)$$

  (10)
• Received $BC$: Occurs when a node receives a block from another node, critical for maintaining the continuity and integrity of the blockchain across the network.

  $$r(n,BC)$$

  (11)

This abstraction is fundamental for analyzing Bitcoin from a distributed perspective and is crucial for addressing the challenge of double-spending attacks in fast payments. This model provides a detailed view of transaction propagation, node communication, and internal/external events, allowing us to observe the effects of asynchronous communication. For instance, formalizing nodes as tuples enables us to analyze their individual and collective behavior within the network as they exchange messages. The formal definition of messages, focusing on transactions and blocks, helps us quickly understand double-spending attacks. In addition, splitting events into internal and external shows the nodes’ ability to make individual decisions in a permissionless distributed environment.

Finally, the definitions made in this section serve as a basis for understanding, reformulating, and developing the scheme to avoid double-spending on fast Bitcoin payments proposed in this paper. In the next section, we use these definitions to reformulate Karame’s requirements, allowing us to identify new scenarios for successful double-spending attacks.

4.2. Reformulation of Karame’s Requirements

Based on the Bitcoin model outlined above, this section focuses on the reformulation of Karame’s requirements for a successful double-spending attack in a distributed environment. To achieve this, we utilize Lamport’s HBR causality, which deletes the physical time and simplifies the events of the Bitcoin asynchronous network. This approach clarifies the temporal events of double-spending attacks and improves understanding of the mechanisms involved on fast Bitcoin payments.

In the model proposed by Karame, four entities are introduced: Alice, a Helper Node, Bob, and the other Bitcoin network nodes. Each entity is modeled as a process with a specific state, denoted by $n=({\mathrm{id}}_n,{\mathcal{S}}_n)$. Figure 2 illustrates this notation, where each vertical line represents the current state of the process and displays the identifiers for each entity at the top.

4.2.1. Karame’s First Requirement Reformulated

According to Karame, to meet the first requirement, Alice propagates transaction $Tr\left(B\right)$ directly to Bob while simultaneously using a Helper Node to propagate transaction $Tr\left(A\right)$ faster and reverse transaction $Tr\left(B\right)$. However, this is not is the only scenario for satisfying Requirement 1. Based on our model, there are two possible scenarios:

• First scenario (Figure 2): In this scenario, the events $Add(Bob,MP\leftarrow Tr(B\left)\right)$ and $r(Nodes,Tr(A\left)\right)$ are concurrent. This implies that while $Tr\left(B\right)$ is being added to Bob’s mempool, $Tr\left(A\right)$ is received by the nodes simultaneously. The concurrency of these events helps the confirmation of $Tr\left(A\right)$ on the blockchain.
• Second scenario (Figure 3): In this scenario, the event $Add(Bob,MP\leftarrow Tr(B\left)\right)$ causally precedes the event $r(Nodes,Tr(A\left)\right)$. This means that transaction $Tr\left(B\right)$ is added to Bob’s mempool first, followed by the reception of $Tr\left(B\right)$ by the nodes, and then $Tr\left(A\right)$ is received by the nodes. The sequence of events in this scenario allows the confirmation of $Tr\left(A\right)$ despite its propagation disadvantage.

The notation in the figures has been simplified from $E(n,Tr(X\left)\right)$ to $E\left(Tr\right(X\left)\right)$. This change was made because the identification process is explicitly shown at the top of each figure.

The difference between Karame’s requirement 1 and the reformulation proposed in this paper lies in the variability of the propagation of $Tr\left(A\right)$ and $Tr\left(B\right)$, given the distributed nature of Bitcoin. In both scenarios, Alice satisfies requirement 1, which is the direct propagation of $Tr\left(B\right)$ to Bob’s node. However, the propagation process may vary depending on the connections between Alice’s Helper Node and Bob’s node. For example, if Alice’s Helper Nodes are segregated during the propagation process, $Tr\left(B\right)$ could reach the set of $Nodes$ first, which would ensure an advantage in propagation and, according to Karame, a higher probability of confirmation of $Tr\left(B\right)$. The reformulation shows that without giving $Tr\left(A\right)$ the advantage, the scenario satisfies Karame’s requirement 1, and successful double-spending is probable. Based on this alternative scenario, we reformulate requirement 1 as follows:

Lemma 1. 

Karame’s first requirement based on Lamport’s HBR: Given two events $r(Nodes,Tr(A\left)\right)$ and $Add(Bob,MP\leftarrow Tr(B\left)\right)$, where $r(Nodes,Tr(A\left)\right)$ is the reception of transaction $Tr\left(A\right)$ by the nodes’ processes, and $Add(Bob,MP\leftarrow Tr(B\left)\right)$ is the addition of the transaction $Tr\left(B\right)$ to Bob’s mempool. Thus, Karame’s first requirement is satisfied if:

$$\exists Tr\left(B\right)\in MP\Rightarrow \left\{\begin{array}{c}Add(Bob,MP\leftarrow Tr(B\left)\right)\Vert r(Nodes,Tr(A\left)\right)\hfill \\ Add(Bob,MP\leftarrow Tr(B\left)\right)\to r(Nodes,Tr(A\left)\right)\hfill \end{array}\right.$$

(12)

where $MP$ is the mempool of Bob.

4.2.2. Karame’s Second Requirement Reformulated

Karame’s second requirement states that the probability of transaction $Tr\left(A\right)$ being included in the blockchain must be greater than transaction $Tr\left(B\right)$. To enhance the probability of $Tr\left(A\right)$, Karame suggests two strategies: first, use Helper Nodes to propagate $Tr\left(A\right)$ across all possible nodes in the network; secondly, Alice should initiate the propagation of $Tr\left(A\right)$ to $Tr\left(B\right)$. Karame’s analysis primarily focuses on scenarios where $Tr\left(A\right)$ holds an advantage over $Tr\left(B\right)$. However, even in cases where $Tr\left(B\right)$ precedes $Tr\left(A\right)$ in the nodes, the second requirement remains feasible. Thus, there are two other possible scenarios based on our model:

3.

Third scenario (Figure 2): This scenario is proposed by Karame, where the transaction $Tr\left(A\right)$ should have an advantage in propagation to increase its probability of being included in the blockchain. This means that $r(Nodes,Tr(A\left)\right)$ causally precedes $r(Nodes,Tr(B\left)\right)$.

4.

Fourth scenario (Figure 3): In this scenario, the confirmation of transaction $Tr\left(A\right)$ is completed, despite $Tr\left(B\right)$ propagating faster among the nodes. This is possible due to the probabilistic nature of Bitcoin. The sequence of events is as follows: $r(Nodes,Tr(A\left)\right)$ causally preceding $s\left(Tr\right(A)\in BC)$, meaning that the transaction $Tr\left(A\right)$ is confirmed without regard to the events that occurred earlier.

The difference between the scenario proposed by Karame and the one identified with the reformulation depends on the order in which the nodes receive the transactions $Tr\left(A\right)$ and $Tr\left(B\right)$. Due to the probabilistic nature of Bitcoin’s confirmation process, there is a chance for a double-spending attack to succeed regardless of the order. In both scenarios, transaction $Tr\left(A\right)$ can be added to the blockchain, enabling the double-spending attack to succeed. We have reformulated this requirement to account for both scenarios:

Lemma 2. 

Karame’s second requirement based on Lamport’s HBR: Consider the following three events: $r(Nodes,Tr(A\left)\right)$ is the reception of transaction $Tr\left(A\right)$ by the nodes; $r(Nodes,Tr(B\left)\right)$ is the reception of transaction $Tr\left(B\right)$ by the nodes; and $s\left(Tr\right(A)\in BC)$ is the propagation of the block containing Alice’s malicious transaction $Tr\left(A\right)$. Karame’s second requirement is satisfied if:

$$\exists Tr\left(A\right)\in BC\Rightarrow \left\{\begin{array}{c}r(Nodes,Tr(A\left)\right)\to r(Nodes,Tr(B\left)\right)\hfill \\ r(Nodes,Tr(A\left)\right)\to s\left(Tr\right(A)\in BC)\hfill \end{array}\right.$$

(13)

where $BC$ represents the block that belongs to the blockchain.

4.3. Karame’s Third Requirement Reformulated

To meet Karame’s third requirement, Bob must receive fast Bitcoin payments, which means he does not await transaction confirmation to deliver the product. According to Karame’s model, the delivery time is shorter than the confirmation time of $Tr\left(A\right)$. We determine that transaction confirmation and product delivery must occur concurrently to meet the requirements. Thus, another possible scenario based on our model satisfies requirement 3:

5.

Fifth scenario (Figure 2): According to Karame, to meet the third requirement, Bob must accept fast Bitcoin payments, and the product delivery time must be shorter than the confirmation time of $Tr\left(A\right)$. The sequence of events is that $d(Alice,P)$ causally precedes $Add(BC\leftarrow Tr(A\left)\right)$.

6.

Sixth scenario (Figure 3): In this scenario, the confirmation of transaction $Tr\left(A\right)$ and the product delivery occur concurrently. This implies that Bob delivers the product at the same time the malicious transaction is confirmed, i.e., $d(Alice,P)$ and $Add(BC\leftarrow Tr(A\left)\right)$ occur concurrently.

The difference between Karame’s requirement 3 and the reformulation is that a causal order is established between the delivery of the product $d(Alice,P)$ and the confirmation of the transaction on the blockchain $Add(BC\leftarrow Tr(A\left)\right)$. However, for the double-spending attack to be successful, it can also be achieved if the delivery of the product is concurrent with the confirmation of $Tr\left(A\right)$, since the event can occur on any of the nodes and Alice would have the propagation advantage to obtain the product. We have reformulated requirement 3 as follows:

Lemma 3. 

Karame’s third requirement based on Lamport’s HBR: Consider the pair of events: $d(Alice,P)$, which represents the delivery of the product by Bob, and $Add(BC\leftarrow Tr(A\left)\right)$, which is the addition of the block containing Alice’s malicious transaction $Tr\left(A\right)$ to the blockchain. Karame’s third requirement is met under the following conditions:

$$\exists d(Alice,P)\in E_b\Rightarrow \left\{\begin{array}{c}d(Alice,P)\to Add(BC\leftarrow Tr(A\left)\right)\hfill \\ d(Alice,P)\Vert Add(BC\leftarrow Tr(A\left)\right)\hfill \end{array}\right.$$

(14)

where P represents the product.

In brief, Karame’s reformulated requirements introduce new scenarios for successful double-spending on fast Bitcoin payments. For example, in requirement 1, by propagating transaction $Tr\left(B\right)$ directly to Bob, Alice can either give $Tr\left(A\right)$ an advantage to or establish a causal relation between the events of receiving $Tr\left(B\right)$ in Bob’s mempool and receiving $Tr\left(A\right)$ in the $Nodes$. Both scenarios satisfy the requirement equally well—see Scenario 2. In requirement 2, although $Tr\left(A\right)$ has a lower probability of being added to the blockchain than $Tr\left(B\right)$, there is a scenario where $Tr\left(A\right)$ can succeed due to the probabilistic nature of Bitcoin—see Scenario 4. Finally, in requirement 3, there does not need to be causal precedence between the delivery of the product and the confirmation of $Tr\left(A\right)$ in the blockchain; these two events can be concurrent, and the attack’s success is probable—see Scenario 6.

These new scenarios extend Karame’s work, emphasizing the sequence of events shown in Figure 2 and Figure 3. In addition, each identified scenario is formalized and added to the requirements through new lemmas. Below, we propose a theorem that captures the lemmas defining the requirements necessary for a successful double-spending attack on fast Bitcoin payments.

Necessary Conditions for Double-Spending Attack Based on Lamport’s HBR

By reformulating Karame’s requirements using Lamport’s HBR, we eliminate the need for a global view and reveal new scenarios where double-spending attacks can be successful. In this theorem, we encapsulate the lemmas that reformulate Karame’s requirements. Using this theorem, we designed DiFastBit to avoid double-spending attacks on fast Bitcoin payments. The reformulated requirements are formally proven in Appendix A and satisfy the requirements in Karame’s original work.

The detailed findings and their implications are thoroughly outlined in Theorem 1 as follows:

Theorem 1. 

If the Lemmas 1–3 are satisfied, then there exists a successful double-spending attack on a fast Bitcoin payment. Specified as follows:

$$\begin{array}{c}\hfill \exists Tr\left(B\right)\in MP\wedge \exists d(Alice,P)\in E_b\wedge \exists Tr\left(A\right)\in BC\Rightarrow \mathrm{DSS}\end{array}$$

(15)

Summary

This section abstracts the Bitcoin environment and creates a model of processes and events that depict the double-spending problem on fast Bitcoin payments. This model is based on Lamport’s HBR causality and is illustrated in Figure 2 and Figure 3. We define the processes, transactions, and blocks, representing only the structures necessary for this attack. Our results include scenarios not considered in Karame’s original work, such as Scenarios 2, 4 and 6, but which have the probability of being successfully executed. Finally, we formalize the reformulated requirements into three lemmas and demonstrate in Appendix A that these requirements are necessary for a successful double-spending attack. In addition, we consolidate these lemmas in Theorem 1 and, based on our proofs, assert that breaking any of these lemmas avoids a double-spending attack proposed by a malicious user.

Based on these results, the following section introduces DiFastBit, a scheme specifically designed to break the reformulated requirements of Karame’s model, avoiding double-spending on fast Bitcoin payments.

5. DiFastBit: Transaction Differentiation Scheme to Avoid Double-Spending for Fast Bitcoin Payments

To avoid the double-spending attack on fast Bitcoin payments, we propose the DiFastBit scheme, which creates a P2P merchant layer capable of differentiating fast-payment transactions. The DiFastBit confirms transactions in an asynchronous system such as Bitcoin, adding a merchants’ mempool of fast-payment transactions and assuming the HBR of events between the Bitcoin network and merchants. Modifications to the Bitcoin protocol include:

• An algorithm that modifies Bitcoin transactions to fast-payment transactions.
• An algorithm for adding fast-payment transactions to the mempool.

Additionally, we perform a fast-payment transaction verification process and the elimination of fast-payment transactions of merchants’ mempool on the merchant layer.

This section is organized as follows: The threat model is outlined in Section 5.1, followed by the secure fast payment framework in Section 5.2. The formal DiFastBit events and structure are presented in Section 5.3. The initialization of the DiFastBit scheme algorithms is outlined in Section 5.4. Finally, the correctness proof of the proposed algorithm is presented in Section 5.5.

5.1. Threat Model

The threat model for a double-spending attack in the context of fast Bitcoin payments is based on Karame’s reformulated requirements, which show greater depth in the successful attack scenarios, as shown in Figure 2 and Figure 3. The goal of the section is to describe the entities, events involved, and the assumptions we make in this scenario. In addition, we clarify that our contribution addresses the scenarios of the reformulated requirements to avoid double-spending.

The threat model identifies several entities: Alice, the malicious user attempting to execute a double-spending attack; Bob, the merchant who receives fast Bitcoin payments; the Helper Node, which assists Alice in propagating malicious transactions; and the other Bitcoin nodes, which validate and propagate transactions and blocks. The critical assets in this context include Bitcoin transactions ($Tr$), which represent the transfer of value within the network; the mempool, the temporary storage for unconfirmed transactions; and the blocks, which contain the confirmed transactions.

The model makes several assumptions. First, we assume that communication between nodes is asynchronous, which can cause delays in transaction propagation. In addition, the distributed environment implies that the nodes are a set of geographically dispersed processes. Regarding transaction confirmation, although the Bitcoin process generally requires waiting for a depth of six blocks to consider a transaction confirmed, in this model, we assume that a transaction is confirmed when it belongs to a block.

For the attack, we consider two scenarios: In the first scenario, Alice sends $Tr\left(B\right)$ to Bob while causally sending $Tr\left(A\right)$ to the network using a Helper Node to increase the probability that $Tr\left(A\right)$ reaches more nodes and gets confirmed first. In the second scenario, $Tr\left(B\right)$ and $Tr\left(A\right)$ propagate concurrently, taking advantage of the network’s asynchrony, with the possibility that $Tr\left(A\right)$ gets confirmed first. The threat details include Alice’s strategy for exploiting a double-spending attack to obtain a product without using her coins. This model considers the propagation, confirmation, and successful execution of the double-spending attack by Alice.

Our contribution is to propose a scheme capable of avoiding the double-spending attack based on the differentiation of transactions, increasing the reliability of this type of payment. In the following section, we introduce the DiFastBit framework, which aims to secure the new merchant layer and delineate the events needed to process fast payments effectively, mitigating this specific threat model.

5.2. Implementation Framework for Secure Fast-Payment Transactions

This section details how to implement the DiFastBit layer to handle fast-payment transactions in Bitcoin. This setup includes an initialization phase, which describes how to implement the merchant layer and the requirements to belong to this set of nodes. Then, a verification phase is addressed, where the consensus rules of the merchant nodes are defined to choose a delegate node to perform the verification process. In addition, this phase sets restrictions on fast-payment transactions to enhance the security of this layer. Next, the fee mechanisms are defined, establishing how the merchant layer obtains additional profit by verifying this type of transaction and creating a business model.

5.2.1. Initialization

To initialize the merchants’ layer, we need at least two nodes to generate a multi-signature wallet [27]. These nodes are disjoint, meaning they are unrelated nodes. The multi-signature wallet establishes a trust fund to support fast-payment transactions. To add new nodes, at least 51% of the consensus nodes must be reached, consistent with the Bitcoin consensus mechanism; this percentage may vary depending on the number of nodes in the layer. The nodes create an additional mempool called the merchants’ mempool, where fast-payment transactions wait for confirmation on the blockchain. The method is as follows:

• At least two nodes configure a multi-signature address for the trust fund that supports fast payments.
• The nodes deposit the coins into the trust fund.
• The merchants’ mempool is enabled.
• New nodes are added by 51% consensus of the layer.

5.2.2. Verification Process

The fast payment verification process introduced by DiFastBit is performed by a delegate, a node selected every 2016 blocks, consistent with Bitcoin’s difficulty adjustment. Delegates are selected using a pseudorandom function that prioritizes nodes holding the highest number of coins in the trust fund [28]. The verification process for a fast transaction is the same as that for a traditional transaction; however, since the mempool is a shared memory space, the delegate is the only one to add transactions to the merchants’ mempool. Research by Meni Rosenfeld shows that a traditional transaction takes approximately 3 s to propagate and add to the nodes’ mempool [29]. Since fast-payment transactions are processed by a subset of Bitcoin nodes, their processing time should be shorter. If a delegate node misbehaves, other nodes unlock their coins from the trust fund to cover any losses. Unlocking trust funds for misbehavior requires transaction proof and consensus from different merchants.

5.2.3. Fee Mechanism

Bitcoin transactions require a fee to be included in the blockchain, and this fee can vary depending on network demand [30,31]. The merchants’ layer employs a fee difference payment mechanism to incentivize merchant nodes to become delegates.

To implement this fee difference mechanism, the following steps are taken:

• The fee mechanism aims to capitalize on the high demand for Bitcoin transactions by allowing merchants to pay lower fees when processing transactions on the blockchain.
• The delegates reduce the fee and send the transactions to the Bitcoin nodes generating profit. These transactions will eventually be confirmed on the blockchain.
• The DiFastBit scheme in the merchant layer ensures consistency between fast-payment transactions by locking the UTXO that is marked as a fast-payment transaction.
• When a fast-payment transaction belongs to the merchants’ mempool, it is equivalent to a traditional transaction receiving six confirmations on the Bitcoin blockchain. This allows merchants to spend the balance of that transaction without waiting for confirmation from the blockchain, as the consistency of fast-payment transactions is maintained by the merchant nodes until they are confirmed on the blockchain.
• Finally, delegates cannot leave pending transactions at the end of the epoch, and other merchant nodes audit the behavior of the delegate node.

The implementation of the DiFastBit layer for fast Bitcoin transactions includes three phases: initialization, verification, and fee mechanism. During initialization, a multi-signature wallet and a trust fund are set up with trusted nodes to support fast transactions. In the verification phase, delegate nodes selected at random validate transactions, enhancing security and reducing processing time by checking for misbehavior. The fee mechanism capitalizes on the high demand for Bitcoin transactions, enabling merchants to earn profits while ensuring quick and consistent transaction confirmation. This framework enhances the security of fast transactions by preventing misbehavior by merchants. This section is designed to validate the effectiveness of DiFastBit under the assumption that the merchant layer is secure. We acknowledge the existence of studies focused only on the security of secondary layers, as mentioned in [32]. Therefore, we have designed DiFastBit with the flexibility to incorporate these methods into future research. Our main goal is to optimize Bitcoin to enable fast payments free from double-spending.

5.3. DiFastBit Events and Fast-Payment Transaction Structure

The DiFastBit formalization specifies the new events introduced in the scheme for fast-payment transactions in the Bitcoin network. The specification covers the merchant process, creation of fast-payment transactions, management of the merchants’ mempool, and the structure of fast-payment transactions.

• Merchants ($N_m$) are a set of processes that belong to the Bitcoin nodes.

  $$N_m\subseteq Nodes$$

  (16)
• A fast-payment transaction is a modified structure to differentiate it from traditional transactions. The modification is shown below:

  $$FTr\left(X\right)\leftarrow Tr\left(X\right)\cup C_f$$

  (17)
• An update to the merchants’ mempool is an internal event that modifies the memory space to include fast-payment transactions. This update event is denoted as:

  $$M{P}_m\leftarrow M{P}_m\cup \left\{FTr\left(X\right)\right\}$$

  (18)
• Querying the merchants’ mempool is an external event that checks whether a fast-payment transaction is part of the merchants’ mempool. It is denoted as:

  $$q(FTr\left(X\right)\in M{P}_m)$$

  (19)
• In the merchant process, an internal event removes fast-payment transactions from the merchants’ mempool after they are added to the blockchain. This event is denoted as:

  $$Delete\_M{P}_m\left(NB\right)$$

  (20)
• The structure of a fast-payment transaction is similar to a traditional transaction, but it includes an additional identifier to differentiate it. We define the structure as follows.

  Definition 6. 

  $Txid$ is the transaction identifier, $Vi{n}_{Tr\left(X\right)-1}$ is the input from the previous transaction, $V{o}_x$ is the address to which funds are transferred, and $C_f$ is an identifier which differentiates fast-payment transactions from traditional transactions.

  $$FTr\left(X\right)=\{Txid,Vi{n}_{Tr\left(X\right)-1},V{o}_x,C_f\}$$

  (21)

These events and the new structure extend the Bitcoin model from the Section 4.1. In the next section, we detail how DiFastBit integrates the framework, differentiates fast payments, the new merchant layer, and processes events to avoid the threat model.

5.4. DiFastBit Working

This section describes the DiFastBit processes for handling fast-payment transactions in Bitcoin. This implementation is split into four steps: creating a fast-payment transaction, verification by merchant nodes, verification by Bitcoin nodes, and the removal of transactions after confirmation. The steps are described through algorithms to ensure a clear understanding of each process.

5.4.1. Creating a Fast-Payment Transaction

To initiate a fast payment with DiFastBit, a user inserts an identifier that differentiates the fast-payment transaction. This identifier modifies the traditional transaction structure by utilizing the flexibility of transaction types [33]. The modification is programmed using the Algorithm 1, which is inspired by the flexibility of the script language [34], Colored Coins [35], and Ordinals [36].

Algorithm 1 Create Transaction Fast-Payment

1: ▹$Tr\left(X\right)$: Transaction. 2: ▹$FTr\left(X\right)$: Fast-Payment Transaction. 3: ▹N: Nodes. 4: procedure Create_transaction_FP($Tr\left(X\right)$) 5:     $FTr\left(X\right)\leftarrow Tr\left(X\right)\cup C_f$ 6:     $Sen{d}_{N_m}\left(FTr\left(X\right)\right)$ 7: end procedure

5.4.2. Verification by Merchant Nodes

The verification process begins when the user propagates the fast-payment transaction on the Bitcoin network. Merchants receive the transaction and initiate the verification process, which is coordinated by the delegate [37]. This verification process is similar to a traditional transaction: the delegate verifies the authenticity of the digital signature and that the UTXOs are available to spend in the chain state. However, Algorithm 2 is added, which verifies that the transaction is not attempting to spend the same UTXO within the merchants’ mempool. If the verification process is true, the delegate adds the transaction to the merchants’ mempool and propagates the fast-payment transaction to the rest of the nodes for confirmation. If the verification process is false, meaning the UTXO is already in the merchants’ mempool, the fast-payment transaction is rejected immediately.

Algorithm 2 Merchant Nodes Algorithm

1: ▹$FTr\left(X\right)$: Transaction fast-payment. 2: ▹$Vi{n}_{Tr\left(X\right)}$: Output no spent UTXO. 3: ▹$Txid$: Transaction identifier (Hash). 4: ▹$M{P}_m$: Mempool of Merchant. 5: procedure ReceiveNm($FTr\left(X\right)$) 6:     if $(Vi{n}_{Tr\left(X\right)}\in M{P}_m)$ and $(Txid\notin M{P}_m)$ then 7:         $Reject\left(FTr\right(X\left)\right)$ 8:     else 9:         $M{P}_m\leftarrow M{P}_m\cup \left\{FTr\left(X\right)\right\}$ 10:       $Sen{d}_{N_m}\left(FTr\left(X\right)\right)$ 11:     end if 12: end procedure

5.4.3. Verification by Bitcoin Nodes

The verification process for fast Bitcoin payments by nodes that do not belong to the merchant layer involves querying the merchants’ mempool to check if the transaction is already stored in that mempool or needs to be inserted for the first time, as shown in Algorithm 3. If the transaction is already in the merchants’ mempool, the traditional Bitcoin node performs its verification and adds it to its local mempool. If the transaction is not in the merchants’ mempool but is not rejected, it indicates that the merchants have not yet seen this transaction and it is being verified. In this case, the traditional node must wait for the transaction to be accepted or rejected by the merchants. Finally, if the transaction is denied, the traditional node will reject it.

Algorithm 3 Nodes Algorithm

1: ▹$FTr\left(X\right)$: Transaction fast-payment. 2: ▹$Txid$: Transaction identifier (Hash). 3: ▹$M{P}_m$: Mempool of Merchant. 4: procedure ReceiveN($FTr\left(X\right)$) 5:     if $(Txid\in M{P}_m)$ then 6:         Bitcoin($FTr\left(X\right)$) 7:     else 8:         $Reject\left(FTr\right(X\left)\right)$ 9:     end if 10: end procedure

5.4.4. Removal of Confirmed Transactions

Once a fast-payment transaction is added to the blockchain, the delegate executes a function represented by Algorithm 4 to remove it from the merchants’ mempool. This function removes all transactions associated with the new block from the merchant mempool, ensuring that the same transaction is not processed twice. This ensures that the transaction is removed from the network and that the Bitcoin nodes mempool remains consistent with the merchants mempool.

Algorithm 4 Delete from Database

1: ▹$NB=\{FT{r}_i,i=1,2,3,\dots ,n\}$: Set of transaction that will be stored in the blockchain. 2: ▹$M{P}_m$: Merchants Mempool. 3: procedure Delete_$M{P}_m$($NB$) 4:     $M{P}_m\leftarrow M{P}_m$\$NB$ 5: end procedure

Based on the introduced algorithm, the threat model, the implementation framework, and the formal specification, the next section provides the correctness proof of DiFastBit. This proof demonstrates how our proposed differentiated verification of fast-payment transactions breaks Karame’s reformulated requirements and successfully avoids the threat of double-spend attacks on fast Bitcoin payments.

5.5. DiFastBit’s Correctness Proof

In this section, we use the threat model and Karame’s reformulated requirements to present two cases that evaluate the effectiveness of DiFastBit against double-spending attacks. The cases highlight conditions under which fast-payment transactions can be rejected or validated at the merchant layer, demonstrating the robustness of our scheme and emphasizing the importance of the algorithms and the framework to keep Bitcoin free from this threat. Finally, we use a proof by contradiction to show that DiFastBit effectively avoids double-spending attacks.

5.5.1. Case 1: Transaction $FTr\left(B\right)$ in Merchants’ Mempool

In this case, we assume that Alice creates two fast-payment transactions, $FTr\left(B\right)$ and $FTr\left(A\right)$, and propagates them through the Bitcoin network, as shown in Figure 4. The $FTr\left(B\right)$ is received by Bob and immediately propagated to the merchant layer, where it is added to the merchants’ mempool (blue dot) before the $FTr\left(A\right)$. When the merchants receive the $FTr\left(A\right)$, they use Algorithm 2 to verify its validity. If they find that the $FTr\left(B\right)$ already exists in their mempool and that both transactions spend the same UTXO, $FTr\left(A\right)$ is rejected (red dot).

If the $FTr\left(A\right)$ is first propagated to a traditional non-merchant layer Bitcoin node, the nodes use Algorithm 3 to verify if this transaction is valid within the merchant layer. In this case, the transaction is rejected because the nodes inform the traditional node that there is already a transaction spending the same UTXO. Finally, when the fast-payment transaction is added to the blockchain, Algorithm 4 removes it from the merchants’ mempool.

This scenario is simplified with the following event:

$$\exists FTr\left(B\right)\in M{P}_m$$

(22)

5.5.2. Case 2: Transaction $FTr\left(B\right)$ Not in Merchants’ Mempool

Similar to the previous case, we assume two conflicting transactions, $FTr\left(B\right)$ and $FTr\left(A\right)$. However, in this scenario, the $FTr\left(A\right)$ is added to the merchants’ mempool before the transaction $FTr\left(B\right)$. As shown in Figure 5, the $FTr\left(A\right)$ follows the confirmation process within the Bitcoin network, while $FTr\left(B\right)$ is rejected (red dot). The merchant layer immediately informs Bob that $FTr\left(B\right)$ is an invalid transaction because the UTXO is used twice, and Bob does not deliver the product to Alice. This scenario is simplified with the following event:

$$\nexists FTr\left(B\right)\in M{P}_m$$

(23)

5.5.3. DiFastBit Correctness Proof

In this section, we present the correctness proof of the DiFastBit scheme through proof by contradiction. To do this, we use the two cases presented above to show that DiFastBit avoids double-spending attacks. Each case involves a different sequence of events, and we show that in both scenarios the scheme maintains consistency and security while avoiding double-spending.

Correctness Proof Case 1. 

We assume for proof by contradiction that $\exists FTr\left(B\right)\in M{P}_m$, and this is only true when the following chain of events exists in DiFastBit.

$$\begin{array}{cc}\hfill & s(Alice,FTr(B\left)\right)\to r(Bob,FTr(B\left)\right)\to s(Bob,FTr(B\left)\right)\hfill \\ \hfill & \to r(Merchants,FTr\left(B\right))\to Add(M{P}_m\leftarrow FTr\left(B\right))\hfill \end{array}$$

(24)

Recall that Lemma 2 is the inclusion of transaction $Tr\left(A\right)$ in Blockchain, and for this to happen, there are two sub-cases; $Tr\left(A\right)\to Tr\left(B\right)$ or $Tr\left(A\right)\to S\left(Tr\right(A)\in BC)$ in the nodes’ processes. Explicitly in Bitcoin, the order of reception of $Tr\left(A\right)$ in the nodes’ processes does not matter. Because, in either of the two sub-cases, there is a probability that $Tr\left(A\right)$ belongs to the Blockchain. However, DiFastBit inserts a strict partial order that limits the sub-cases of Lemma 2 to just one chain of events:

$$\begin{array}{cc}\hfill & s(HelperN,FTr(A\left)\right)\to r(Merchant,FTr(A\left)\right)\hfill \\ \hfill & \to Add(M{P}_m\leftarrow FTr\left(A\right))\to s(Merchant,FTr\left(A\right))\hfill \\ \hfill & \to r(Nodes,FTr(A\left)\right)\to s\left(FTr\right(A)\in BC)\hfill \end{array}$$

(25)

This chain of events can be seen in Figure 5. Note that, the event $Add(M{P}_m\leftarrow FTr\left(A\right))$ implies $\nexists FTr\left(B\right)\in M{P}_m$ as that Algorithm 2, line 7, reject the transaction $FTr\left(B\right)$, which leads to a contradiction of the initial condition. Therefore, if condition initial is true, Lemma 2 is broken. The proof results are as follows:

$$\begin{array}{c}\hfill \exists FTr\left(B\right)\in M{P}_m\Rightarrow \nexists Add(M{P}_m\leftarrow FTr\left(A\right))\end{array}$$

(26)

☐

Correctness Proof Case 2. 

We assume for proof by contradiction that $\nexists FTr\left(B\right)\in M{P}_m$, and when this happens, the following chain of events exists in DiFastBit.

$$\begin{array}{cc}\hfill & s(Alice,FTr(B\left)\right)\to r(Bob,FTr(B\left)\right)\to s(Bob,FTr(B\left)\right)\hfill \\ \hfill & \to r(Merchants,FTr(B\left)\right)\to Reject\left(FTr\right(B\left)\right)\hfill \end{array}$$

(27)

Lemma 3 is satisfied when Bob receives the transaction $Tr\left(B\right)$ sent by Alice, inserts it in the mempool, and without waiting for confirmation, he delivers the product. Concurrently, Alice propagates the transaction $Tr\left(A\right)$ that spends the same UTXO as $Tr\left(B\right)$ and inserts it into the blockchain. Product delivery is a significant event in Lemma 3, as it is a cyber-physical event that Bob cannot reverse. However, DiFastBit adds a verification process for product delivery, where the transaction $FTr\left(B\right)$ sent by Alice follows the chain of events below:

$$\begin{array}{cc}\hfill & r(Bob,FTr(B\left)\right)\to s(Bob,FTr(B\left)\right)\hfill \\ \hfill & \to q(FTr\left(B\right)\in M{P}_m)\to r\left(True\right)\hfill \\ \hfill & \to Add(MP\leftarrow FTr(B\left)\right)\to d(Alice,P)\hfill \end{array}$$

(28)

Unlike the traditional Bitcoin protocol, nodes with the proposed scheme consult merchants before adding fast-payment transactions to the local mempool. This verification is performed in Algorithm 3, line 5, and can be seen in Figure 4.

The proof result is as follows, the event $Add(MP\to FTr(B\left)\right)$ implies $\exists FTr\left(B\right)\in M{P}_m$, which leads to a contradiction of the initial condition. Therefore, if the initial condition is true, Lemma 3 breaks, as shown below.

$$\begin{array}{c}\hfill \nexists FTr\left(B\right)\in M{P}_m\Rightarrow \nexists Add(MP\to FTr\left(B\right))\end{array}$$

(29)

☐

Summary

We designed DiFastBit based on the premise of our demonstration in Appendix A, which proves that breaking any of the three requirements during a double-spending attack will cause the attack to fail. To achieve this, a merchant layer extends the Bitcoin network by adding a mempool specifically for fast-payment transactions. This merchant layer defines a set of new events and processes within the Bitcoin abstraction. In addition, we created a framework that introduces the initialization process of the merchant layer, an additional verification mechanism for fast-payment transactions, and an incentive mechanism based on transaction fees. We designed DiFastBit and established the threat model, proposing attack scenarios against it.Finally, we performed a correctness proof based on this model and theoretically showed that DiFastBit can deterministically avoid double-spending attacks. In the next section, we simulate the confirmation time of DiFastBit and compare it to the confirmation times of the Bitcoin mainnet.

6. Analysis of Confirmation Time on Fast Transaction in DiFastBit vs. Traditional Transaction on Bitcoin

In this section, we aim to evaluate the reduction in confirmation time achieved by the merchant layer and compare it to traditional Bitcoin confirmation times. To achieve this, we analyzed the propagation time of 100 transactions across 18,900 Bitcoin nodes, and the confirmation time from block 854,758 to 854,858 to use as a baseline. We then modeled the time introduced by the propagation of fast-payment transactions to the merchant delegated, the time taken to verify the transactions, and the time required to add a transaction to the merchants’ mempool. Next, we simulated Bitcoin by adding the merchant layer and observed the confirmation time of a fast-payment transaction in this layer. Finally, we compared the confirmation time of Bitcoin blockchain, the propagation time of transactions, and the DiFastBit confirmation time.

6.1. Propagation Time and Confirmation Time in Bitcoin Network

In this section, we present data on transaction propagation time and block confirmation time within the Bitcoin network. According to Karame’s model, a fast-payment merchant processes the delivery of products once a transaction has propagated through the network, without waiting for block confirmation. This method assumes that a transaction’s visibility in the network will lead to its eventual confirmation; however, it has a high risk of double-spending. We consider transaction propagation time as the lower bound of our comparison. On the other hand, waiting for blockchain confirmation, which has a high time delay, significantly reduces the risk of double-spending. We consider confirmation time as the upper bound of our comparison.

6.1.1. Lower Bound Analysis: Transaction Propagation Time

To obtain the propagation time data, we used the Bitnodes tool [38] and tracked the propagation time of 100 transactions. Based on a random sample of nodes, we found that transaction propagation time can range from 4000 ms to 7000 ms, with a mean of 5456 ms and a standard deviation of ±503 ms, as shown in Figure 6. This measurement depends on network load and provides an average observation of delay in the Bitcoin mainnet environment. It is also consistent with the results presented in previous measurements by researchers such as Ahamad et al. [39] and Meni Rosenfeld et al. [29].

6.1.2. Upper Bound Analysis: Blockchain Confirmation Time

To obtain the confirmation time data, we used the mempool.space API [40]. The horizontal axis represents the number of blocks, while the vertical axis shows the confirmation time in minutes. We collected data from 100 blocks. The blue dots connected by lines shown in Figure 7 represent the individual confirmation times for each block. The red dashed line indicates the average confirmation time, approximately 9.24 min, while the light red shaded area represents the standard deviation of ±8.59 min, highlighting the variability in confirmation times. By tracking the timestamps of these blocks, we observed that although the average confirmation time is relatively constant, there is considerable variability, with confirmation times that are significantly faster or slower.

6.2. Analysis of Confirmation Time in the Merchant Layer

In this section, we model the time required by the merchant layer to secure a fast-payment transaction without the risk of double-spending. This process is based on the topology shown in Figure 8, where the network includes traditional Bitcoin nodes, a merchant delegated node, and merchant nodes. The confirmation process in the merchant layer involves three steps: the propagation of the fast transaction to the delegated, verification by the delegated, and propagation to the merchant nodes.

6.2.1. Propagation Time to the Delegated

The propagation time of a fast-payment transaction to the delegate depends on several parameters. The first parameter is the number of hops a transaction takes to reach the delegate, represented as $Hop{s}_{N_D}$. This parameter varies depending on the initial position of the transaction in the network and the specific path it takes. Also included is the latency parameter, which represents the delay in transmission at each step. Based on these factors, we can calculate the propagation time of a fast transaction to the delegated as follows:

$$T_{Delegated}=Hop{s}_{N_D}\times Latency$$

(30)

6.2.2. Delegated Verification Time for Fast Transactions

The verification time for a fast-payment transaction by the delegated node depends on transaction complexity and the computational processing per unit time of the delegated node. We assume the difficulty of verifying the fast transaction constant, as the delegated node only handles this transaction type. In addition, we assume that the delegated node’s computational capacity remains constant during verification. To measure the verification time for a fast-payment transaction, we use the following equation:

$$T_{Process}={\displaystyle \frac{FastTransaction}{DelegatedCapacity}}$$

(31)

6.2.3. Propagation Time to Merchant Nodes

The propagation time of fast-payment transactions to merchant nodes is determined by the number of hops required a transaction to fully flow through all nodes. This propagation process is similar to that of Bitcoin and involves both traditional Bitcoin nodes and merchant nodes. The propagation time is represented by the following equation:

$$T_{Merchants}=Hop{s}_{N_m}\times Latency$$

(32)

6.2.4. Total Confirmation Time in DiFastBit

Based on the topology shown in Figure 8 and the equations introduced above, we calculate the total confirmation time for fast-payment transactions in the DiFastBit system. This calculation includes the propagation time for the transaction to reach the delegated node, the processing time required by the delegated node to verify the transaction, and the propagation time for the transaction to propagate among the merchant nodes.

The total confirmation time ($T_{Total}$) is the sum of these parameters and is specified using the following equation:

$$T_{Total}=T_{Delegated}+T_{Process}+T_{Merchants}$$

(33)

If we simplify the equation by treating the verification process time as a constant, given that fast transactions have invariant verification complexity, the equation becomes:

$$T_{Total}=Hop{s}_{N_D}+Hop{s}_{N_m}\times Latency+Constant$$

(34)

This simplified equation provides a better representation of the total merchant layer confirmation time in a star topology. In the next section, we use the outlined parameters to simulate the confirmation time for the merchant layer and compare it to the upper and lower bounds discussed above.

6.3. Simulation of Merchant Layer Confirmation Time

The experiments were run on a computer with an Intel Core i7 4.80 GHz processor and 16 GB of RAM. We used Python 3 and the networkx library version 3.3 for the simulations. We simulated 18,900 Bitcoin nodes modeled with a Watts–Strogatz graph [41]. We added a layer of merchants with 1890 nodes according to the topology shown in Figure 8, representing 10% of the total Bitcoin nodes. A communication latency of 255 ms was established between the nodes [40], and each node achieved at most four connections to the network [18]. The transaction processing parameter used was 5 $\mathsf{\mu }$s, the estimated time for verifying a traditional transaction on the above computer.

In the experiment, we randomly selected a node outside the merchant layer and propagated a fast-payment transaction. This transaction began its broadcast process in the graph until it reached the merchant nodes. During this process, we observed the number of hops necessary to reach the merchant layer, which ranged between 22 and 30 hops. Once the merchant nodes were reached, according to Algorithm 2, the merchants initiated their propagation process on the merchant layer, and a delegated node verified the transaction to confirm that the merchant’s mempool had no inconsistencies. We performed 100 iterations of fast transactions to measure the confirmation time of DiFastBit. In Figure 9, the confirmation times for the merchants have an average of 9.4 s with a standard deviation of 622 ms. Additionally, we observed that the times vary depending on the initial propagation location in the graph and that it is possible to achieve confirmation times of up to 7 s.

Finally, we compared DiFastBit’s confirmation times to Bitcoin’s transaction propagation times and Bitcoin’s confirmation times, as shown in Figure 10.

We observe that the confirmation times of DiFastBit, represented by the red line, remain in the order of seconds, in contrast to Bitcoin’s confirmation times, represented by the blue line, which exceed several minutes. The green line shows the propagation time of Bitcoin transactions, which is the time it takes for merchants to see the transaction and deliver the product. Although this propagation time is shorter than DiFastBit’s confirmation time, accepting a transaction without confirmation is vulnerable to double-spending attacks, as proposed in Karame’s model.

Summary

This section compares the confirmation time reduction achieved by DiFastBit’s merchant layer against traditional Bitcoin confirmation times. For this comparison, the confirmation time of 100 transactions distributed across 18,900 Bitcoin nodes was analyzed, along with the average confirmation time between blocks 854,758 and 854,858. We modeled the confirmation time of the merchant layer to confirm a fast-payment transaction without the risk of double-spending. We then simulated the Bitcoin network and a set of merchants coordinated by a delegate responsible for verification.

The simulation showed that the average confirmation time for DiFastBit is 9.4 s, with a standard deviation of 622 ms. When comparing these results with the propagation and confirmation times of Bitcoin’s mainnet, it was found that DiFastBit times are significantly shorter, to the order of seconds.

In conclusion, adding a merchant layer to handle fast-payment transactions in Bitcoin solves the double-spending problem in these scenarios, offering faster confirmations than the traditional Bitcoin system. Although this merchant layer may cause an overhead in the propagation of transactions, it aligns with the trade-off between security and scalability in permissionless blockchains.

7. Discussion

In this section, we discuss the implications of our model of Bitcoin as a distributed environment of events and processes and analyze how this approach helps to understand the complexity of Bitcoin as a payment system. We then discuss the practical implications of Karame’s reformulated requirements, mentioning how these new scenarios help improve protection against this type of attack. We then compare DiFastBit to state-of-the-art proposals, highlighting that it is the first work to provide a deterministic solution. Finally, we mention the future work that can be derived from our results.

7.1. Impact of the Bitcoin Model as a Distributed Environment for Processes and Events

Bitcoin operates in a complex distributed environment that is difficult to understand due to the large number of messages propagated through the network and the geographic distribution of its nodes. The abstraction introduced in this work simplifies this complexity by focusing on formalizing events and defining messages and processes. In addition, the propagation behavior of these messages is illustrated in diagrams, making it easier to analyze each double-spending case. Our results describe the system behavior to understand double-spending and provide an abstraction of the structures required to avoid such attacks.

7.2. Practical Implications of Karame’s Reformulated Requirements

The reformulation of Karame’s requirements introduces new scenarios for the execution of double-spending attacks in fast payments. In the first requirement, the concurrency of events between the receipt of $Tr\left(B\right)$ in Bob’s mempool and the receipt of $Tr\left(A\right)$ by the nodes shows that it is not necessary to establish a propagation advantage for the attack to be successful. In the second requirement, despite the propagation advantage of $Tr\left(B\right)$, $Tr\left(A\right)$ can still succeed due to the probabilistic nature of Bitcoin. In the third requirement, product delivery and transaction confirmation can occur concurrently, increasing the probability of a successful attack.

These new scenarios extend Karame’s work by emphasizing the sequence of events in the presented diagrams. In addition, previous works lack the same level of detailed modeling, leaving gaps in the analysis of double-spending attacks. The new scenarios presented have several implications for Bitcoin transaction security, including the need to analyze vulnerabilities in asynchronous networks, model and simulate malicious attack scenarios, and configure nodes to improve security.

7.3. Discussion on DiFastBit

The fundamental difference between DiFastBit and existing methods is that the latter relies on probabilistic detection or prevention of double-spending attacks, while DiFastBit provides a deterministic approach. This scheme enhances the security of fast-payment transactions by introducing a merchant layer and an additional verification process. DiFastBit is the first theoretical proposal that extends Karame’s work, its practical implementation requires consideration of several factors. Our results demonstrate the possibility of secure fast payments and future work to improve DiFastBit or develop alternative strategies based on breaking the reformulated requirements for a successful double-spending attack.

7.4. Differences between DiFastBit and Lightning Network

In this section, we discuss the differences between DiFastBit and the Lightning Network, considering aspects such as transaction type, layer, security model, and approach. The aim of this comparison is to show that DiFastBit addresses the threat of double-spending attacks in Bitcoin, while the Lightning Network focuses on transaction scalability without directly addressing double-spending attacks. In addition, we show that the transaction differentiation in DiFastBit could be a viable solution for fast payments in Bitcoin. These differences are key for future research, which could focus on improving DiFastBit and considering its possible extension to both Bitcoin and the Lightning Network.

7.4.1. Transaction Type and Layer

The Lightning Network works as a second layer on Bitcoin, creating trusted payment channels through transaction scripts. Once these channels are established, coins are transferred off-chain, enabling continuous operations between users. This setup makes the Lightning Network act as an off-chain layer-two solution.

On the other hand, DiFastBit differentiates transactions by inserting data, similar to systems such as Ordinals or Runes. This differentiation allows a set of merchants to treat transactions without locking them out, making DiFastBit act as an on-chain layer-two solution.

7.4.2. Security Model

The Lightning Network’s security model is based on locking transactions on the blockchain, which requires the cooperation of multiple participants. However, the Lightning Network is vulnerable to double-spending during the process of opening and closing channels, and it is recommended that users do not lock large amounts of money.

DiFastBit, on the other hand, is based on the security of Bitcoin and uses a merchants’ mempool to manage transactions. This mempool is guarded by a set of nodes that have a direct interest in receiving such payments and is supported by a trust fund that protects against misbehavior.

7.4.3. Approach

The Lightning Network is designed to handle a large amounts of small transactions, making it an ideal solution for micropayments due to its low fees. This approach leverages the scalability of transactional throughput to enable fast and frequent payments at minimal fees.

On the other hand, DiFastBit addresses the challenge of double-spending in fast-payment transactions, an issue for Bitcoin’s fast payment scenarios. Unlike the Lightning Network, DiFastBit focuses on maintaining transaction integrity, ensuring that each transaction is unique and secure regardless of the transaction amount.

We conclude that both approaches are designed to address different challenges in Bitcoin. While the Lightning Network improves Bitcoin’s transactional throughput, DiFastBit focuses on avoiding double-spending attacks based on Karame’s model. However, we have observed that the Lightning Network can be vulnerable to double-spending attacks, while DiFastBit could be an effective solution for fast payments in Bitcoin. Future research could focus on merging these two types of solutions to create a hybrid approach that addresses both the double-spending problem and Bitcoin’s scalability issue.

7.5. Future Work

The future work explores the development of DiFastBit in an environment network to evaluate its effectiveness in practical scenarios. In addition, it analyzes the scheme for confirmation time and resource usage in different types of attacks. Likewise, it involves modeling the fee mechanism to balance transaction security and operational costs for merchants and analyzing the economic impact of this mechanism on the Bitcoin ecosystem. In particular, one goal is to generalize DiFastBit to integrate with interoperable multi-chain protocols, facilitating fast payments across multiple chains. It is also necessary to identify the necessary and sufficient conditions to fully characterize the double-spending attack, including the fast payment scenario.

8. Conclusions

DiFastBit is introduced; a distributed transaction differentiation scheme for fast Bitcoin payments that avoids deterministic double-spending attacks. We reformulated Karame’s double-spending requirements from a distributed perspective based on Lamport’s HBR model to achieve double-spending-free fast-payment transactions. DiFastBit modifies two variables in the Bitcoin environment: transactions and nodes. Fast-payment transactions are differentiated from regular transactions to give them special attention. An asynchronous verification layer is added for fast payments, performed by a new role of nodes called merchants. Thanks to the asynchronous verification layer and the distributed transaction differentiation strategy introduced, DiFastBit is able to process double-spending-free fast-payment transactions, ensuring reliable immediate delivery of any product or service. Formal proof for this strong assertion was included. Furthermore, the use of Lamport’s HBR model in the reformulation of Karame’s double-spending requirements highlights the importance of considering distributed perspectives when designing secure systems. This may have implications beyond the Bitcoin network, as it provides a framework for addressing security issues in other distributed systems. Overall, the introduction of DiFastBit represents a significant step forward in the development of fast and secure payment systems in the Bitcoin network, and demonstrates the potential of transaction differentiation schemes for enhancing the security and efficiency of distributed systems.