Abstract
One remarkable feature of vehicular ad hoc networks is characterized by an opportunistic communications by means of store-carry-forward message relaying which requires the cooperation of vehicles on the networks. However, we cannot be sure that all vehicles willingly contribute their computing resources to the networks for message forwarding with no rewards for their efforts in real-world scenarios. In addition, unfortunately, there may exist some selfish and greedy node which may not help others but tend to take their own gain. To cope with this challenge, incentive mechanisms are generally considered as the promising solution. In this paper, we design a Bitcoin-based secure and reliable incentive scheme for cooperative vehicular delay tolerant networking services. Bitcoin is the well-known worldwide cryptocurrency and digital payment system whose implementation relies on cryptographic techniques, which makes it possible to develop a practical credit-based incentive scheme on the vehicular networks at a low cost. We also implement Bitcoin transaction scripts to handle our proposed incentive scheme.
1. Introduction
It is trend of modern vehicles to equip GPS-based navigation system with digital map and on-board unit (OBU) devices which allow vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications. Due to the advances of modern car technologies incorporating with wireless communication, vehicular communications have been an active research area over the last decade. In particular, we have also witnessed 5G connected vehicular communications test-bed in South Korea recently. As a result, up to date, a variety of vehicular ad hoc network (VANET) applications have been researched to provide not only comfortable transportation services but also location-based infotainment services on the road. Another attractive vehicular network architecture is vehicular delay tolerant networks (VDTNs), focusing on the opportunistic connectivity among vehicles and road side units, in which vehicles contribute to a message relaying service by utilizing store-carry-forward paradigm [1, 2]. As shown in Figure 1, some information collected at a source location (S) can be stored, carried, and then forwarded to a destination location (D) by a vehicle passing through the roads. An example of such opportunistic networking applications is to deliver some location-aware information such as gas and parking around to the display located at . Another application is to forward messages to the Internet through the gateway server located at when Internet connection is not possible at S.
However, because VANETs and VDTNs are autonomous and self-organized networks with the cooperation among vehicles, we cannot always expect that all vehicles voluntarily contribute their computing resources to the network. Moreover, some selfish vehicles would not help message relaying service for others while they enjoy the services provided by the network. One solution to this challenge is to provide incentives to stimulate vehicles to voluntarily participate in the networks by rewarding for their contribution with an actual money or credit. For example, when a sender asks a vehicle for help, the sender gives some incentive to the vehicle so that the vehicle is willing to store, carry, and forward sender’s message to a destination.
Although, on the one hand, an incentive looks like an attractive approach to selfish behavior, another concern is how the sender can be convinced whether the message is actually delivered to the destination or not [3, 4]. If a source location server first gives credits to a vehicle, a malicious vehicle will not faithfully store-carry-forward the message to the specified destination after receiving the credit. The source location server may be concerned about such malicious behavior of a vehicle so-called dine and dash, such situation is unfair to the source location server. Therefore, it is also a critical challenge how to resolve such unfairness issue of incentive scheme on autonomous vehicular networks.
1.1. Related Work
While vehicular communications have received a great deal of attentions, the researches on secure vehicular communications have also widely carried out, and most of them are focusing on anonymous authentication schemes implemented by digital signature combined with pseudonyms of vehicles so as to guarantee nonrepudiation and anonymity of the communication activities simultaneously [5–12]. However, ordinary digital signature itself cannot deal with the fairness problem. To resolve the fairness problem in store-carry-forward message delivery, Lin et al. proposed a location-release signature [4] in which the credit signed by a source location server becomes valid if the credit reaches to a specific destination location server. However, they did not present how to actual incentives are rewarded to the vehicles.
Incentive schemes for cooperative VANET or VDTN environments can be categorized into reputation-based scheme and credit-based scheme. In reputation-based schemes, network nodes evaluate trust relationship with each other and vote on neighboring node’s activity of message forwarding so that uncooperative nodes of bad reputation are excluded from the networks [13, 14]. Li et al. proposed an announcement scheme for VANETs based on a reputation system which allows for vehicles to evaluate message reliability [13]. In their scheme, the reliability of a message is evaluated by the reputation of the vehicle which generates the message, and the reputation score is collected, updated, and certified by a trusted third party.
Credit-based schemes employ some form of virtual currency for regulating message forwarding among different nodes and rewarding nodes for their helps [15–17]. When a source node needs help of other nodes for message forwarding, the source node should pay a certain amount of virtual coins to the helper nodes. To incentivize nodes for DTNs, Zhu et al. proposed a secure multilayer credit-based incentive scheme, named SMART [15], which provides nodes with virtual coins to charge for and reward the provision of data forwarding. They also briefly discussed several security issues in DTNs and countermeasures; however, they did not consider fairness issue. With regard to fairness issues in VDTNs, Lu et al. proposed a secure and practical incentive protocol Pi, which is a hybrid model combining reputation and credit, using verifiably encrypted signature technique.
However, those schemes additionally require implementing an application-dependent reputation management system or a virtual coin management system on VANETs. Furthermore, the existing incentive schemes entirely rely on a central trusted third party to assign some virtual coins to each node and to keep track of issued virtual coins in the system.
1.2. Contribution
In this paper, we present a secure credit-based incentive scheme for cooperative VDTNs integrating with a blockchain-based cryptocurrency system. Bitcoin is the most famous and practical cryptocurrency, whose implementation relies on cryptographic techniques and a distributed electronic payment system in which no trusted third party is required. By taking advantage of the Bitcoin system or Bitcoin overlay network, we can design a secure message delivery service and credit-based incentive scheme for VDTNs at a low cost.
As compared to the existing credit-based scheme, we do not need to be concerned about the reliability of virtual coin rewards on VDTNs. Instead, reliable virtual coin exchange transactions are shifted to the Bitcoin system. Moreover, we do not need to implement public key and pseudonym management system such as vehicular-PKI to authenticate vehicles participating in store-carry-forward communications because the private and public key pair of Bitcoin account owned by the vehicle/user can be used for vehicular communications on VDTNs as well as handling Bitcoin transactions rewarded as incentives. That is, the Bitcoin public key can be viewed as vehicle’s pseudonym.
However, ordinary Bitcoin public keys are not sufficient to incorporate trustworthiness from real-world entities into the system, but vehicular networking is a cyberphysical system implemented in real world. We present authenticated vehicular communication using certified Bitcoin public key technique [18] to validate the legitimacy of the entity taking part in the system. Even though a trusted authority is involved in the proposed system for issuing certified public keys, we can more efficiently implement authentication system than the existing vehicular-PKI.
In our preliminary version of this work [19], we presented how Bitcoin can be used as incentive in VANET but did not show implementation details. In this paper, we show that how the fairness issues of incentive scheme on VDTNs can be resolved by handling Bitcoin transactions which transfer coins to a volunteer vehicle as incentives and implement Bitcoin locking and unlocking scripts to control the redemption conditions to spend the coins specified in the incentive transactions.
The rest of this paper is organized as follows: we first shortly introduce the technical concept of the Bitcoin needed to understand our proposed system in Section 2, then we design the proposed Bitcoin-based secure incentive system on VDTNs in Section 3. We discuss the security features of the proposed system in Section 4 and finally conclude this paper in Section 5.
2. Background
Cryptocurrency is a digital asset to support a medium of exchange based on cryptography to secure its transactions and to verify the transfer of assets. As opposed to centralized electronic cash and banking systems, cryptocurrencies are maintained by decentralized control through a blockchain functioning as a distributed ledger. Since the first implementation of decentralized cryptocurrency, Bitcoin, numerous alternative coins (altcoins) have been created. Table 1 summarizes some remarkable cryptocurrencies and their technological characteristics. Due to the cost effectiveness in validating transactions and the security of immutable ledgers on a distributed blockchain, the concept of blockchain is evolving to a platform beyond the cryptocurrency to develop decentralized applications and collaborative organizations to remove the need for a trusted third party.
In the followings, to understand blockchain-based cryptocurrency system, we briefly give a general overview of the Bitcoin on which our proposed incentive scheme is built.
2.1. Bitcoin System
Bitcoin is the first cryptocurrency which is a new form of a decentralized electronic cash system introduced by Satoshi Nakamoto [26]. Unlike traditional currency systems relying on a central authority such as a bank, Bitcoin is based on Peer-to-Peer (P2P) network and distributed consensus protocol without a trusted third party. In Bitcoin system, each user has a private and public key pair to sign the transactions for coin transfers, and the address to uniquely identify a user is represented by a cryptographic hash of the public key for the respective user. The address is associated with user’s account and the private key is used to sign transactions for spending coins.
Bitcoin payments are processed by generating transactions which transfer the values of coins from one user’s account to another. Transactions are composed by senders and distributed to the Bitcoin P2P network, then the validity of the transactions is verified by Bitcoin network nodes called miners. After validating the transactions pended for a given time period, miners collect the transactions into a single unit called block. The new block accepted by the miners according to a consensus protocol is then added to the Bitcoin public ledger called blockchain.
2.2. Transaction
Bitcoin transaction is the record implying that transfers the value of coins from a sender to a recipient as shown in Figure 2. A transaction (TX) has a unique identifier and consists of a set of inputs and outputs which are key components of the transaction. Each input specifies unspent coins, belonging to a particular user, of the previous transaction identified by its hash code. Each output represents the amount transferred to the specified address of a recipient. To authorize spending the coins in the transaction input, the user should present his/her signature for the transaction and corresponding public key. Bitcoin uses ECDSA as a digital signature scheme.
Unlike traditional bank services in which transactions are verified and maintained by a central bank, transaction verification in Bitcoin system is distributed to P2P network nodes and only the valid transactions are recorded in the distributed ledger by means of a blockchain.
The concept of processing Bitcoin transactions, which spends outputs of previous transactions, is to manage transaction chain which transfers coin ownership from a sender to a recipient [27]. Therefore, sending some Bitcoin is creating an unspent transaction output (UTXO) locked to a specific public key owner, and a new transaction can consume one or more UTXOs as transaction inputs.
2.3. Script
Each UTXO has to be bound to a specific user eligible for spending the coins in it. Bitcoin system introduces a scripting language to describe the essential conditions (encumbrances) to claim the coins. That is, each transaction output can contain a locking script which defines the conditions that must be met to spend the coins associated with the UTXO. One dominant script supported by today’s Bitcoin system is Pay-to-Public-Key-Hash (P2PKH) which encumbers the output with a public key hash known as address. An output locked by a P2PKH script can be unlocked by the user who can present a public key and a signature generated by the corresponding private key. A P2PKH transaction output would have the following script of form (we omit detailed operation of each script command):
scriptPubKey: OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
To authorize spending the output, the corresponding input specifies an unlocking script of the form:
scriptSig: <Signature> <PubKey>.
Another interesting transaction to us is MultiSig transaction which requires multiple signatures to unlock the encumbrance. MultiSig transaction outputs are usually denoted as M-of-N, where N is the total number of public keys and M is the minimum number of signatures required for redeeming the transaction output. For example, 2-of-3 MultiSig transaction of the following script
scriptPubKey: 2 <PubKey A> <PubKey B> <PubKey C> 3 OP_CHECKMULTISIG
can be redeemable by including any combination of two signatures of the private keys corresponding to the three listed public keys as follows:
scriptSig: OP_0 <Signature A> <Signature C>, or
scriptSig: OP_0 <Signature B> <Signature C>
2.4. Time-Locked Transaction
Bitcoin supports both transaction-level and script-level time-lock features which restrict the spending of outputs of the time-locked transactions by a certain time in the future. The functions of time-locks are useful for postdating transactions and withholding redemption of funds to a date in the future. We are interested in script-level time-locks.
There are two types of time-locks in the Bitcoin system: one is absolute time-lock and the other is relative time-lock. Absolute time-lock transactions use CHECKLOCKTIMEVERIFY opcode to specify a fixed date in the future when the output of the transaction can be spent, and relative time-lock transactions use CHECKSEQUENCEVERIFY opcode to establish amount of time far from the transaction publishing time.
2.5. Blockchain
Blockchain is a linked-list type data structure which maintains entire transaction history in terms of blocks. Figure 3 shows the blockchain structure used in the Bitcoin. When a transaction is generated and distributed to the Bitcoin network, some node called miner in the network collects and verifies the pending transactions for a given time period to form a new block. Each block header contains the hash value pointing to the previous block and root of Merkle hash tree constructed from the transactions specified in the block. Once a block grouping some transactions is added to the blockchain, it means that a majority of miners verified the legitimacy of the transactions and validated the block through a probabilistic distributed consensus protocol with a Proof-of-Work (PoW) implemented by a complex cryptographic puzzle.
In order to agree on a common order of transactions and to ensure consistent state of the blockchain in a distributed system, Bitcoin is employing the PoW by varying a nonce value in the block until the hash value becomes lower or equal to the given difficulty target value, i.e., finding a random nonce such that Hash(header, nonce) ≤ target. Bitcoin uses SHA-256 cryptographic hash function, and it is computationally difficult to find a desired hash value. If a majority of miners verify a block by solving a computationally hard PoW puzzle, then the new block is broadcasted to the network and successfully added to the blockchain. Other nodes in the Bitcoin network can easily verify the block by recalculating the hash value for the nonce given in the block header and comparing with target value. By making use of the PoW-based consensus protocol, Bitcoin system makes it hard to abnormally manipulate blockchain. Therefore, the blockchain can be viewed as a distributed immutable ledger.
3. Proposed System
In this section, we describe the proposed system architecture to design a Bitcoin-based secure and reliable incentive scheme for VDTNs. Anonymity of the vehicles participating in the communication is guaranteed by the use of Bitcoin public keys, and the vehicles are stimulated to help message store-carry-forward from one location to another location by paying them Bitcoin as incentives. Moreover, the fairness to a source location server is guaranteed by exploiting the 2-of-2 MultiSig transaction, in which the signature of the destination server is required as well as vehicle’s, so that the forwarding vehicle can be allowed to spend the coins given as incentives once the vehicle actually arrives at the destination point.
3.1. System Model
Opportunistic networking applications on VDTNs can be characterized by store-carry-forward communications with the help of moving vehicles in the circumstance where a direct communication link is not always possible between source to destination. To design a Bitcoin-based incentive scheme, we consider the information dissemination service scenario as shown in Figure 4 where a vehicle helps forwarding some messages received from the source server to the destination point that displays the information such as commercial ad for the source server location.
We assume that the owners/users of both roadside servers and vehicles have their Bitcoin accounts to give and receive Bitcoin as incentives. When a source server asks for a vehicle to transfer a message bundle to a certain destination point, the source server publishes a Bitcoin transaction to the Bitcoin network for paying incentives to the vehicle. The source server’s Bitcoin transaction is locked under the condition that the coins can be spent by the vehicle which forwards the message bundle to the destination roadside point. Therefore, if the vehicle faithfully transfers the message bundle and receives a confirmation from the destination point, the vehicle can spend the coins.
For such a scenario, in this paper, we focus on how to design Bitcoin-based secure incentive scheme for VDTNs by taking the following security goals into account.(i)Fairness: actual incentives must be rewarded to the volunteer vehicles only if the vehicle completes to transfer a message bundle to the destination point, which is fair to the source server to prevent a sort of dine and dash.(ii)Authorization: in cyberphysical vehicular networks, only the entities authorized by SM must be able to take part in the vehicular communications for preventing illegal entities from misusing the system.(iii)Anonymity of vehicles: the identity of the vehicle participating in store-carry-forwarding should be hidden during vehicular communications and incentive protocol run for privacy preservation.
The proposed system achieves the security goals by leveraging the functionalities of Bitcoin transactions and adopts certified Bitcoin public key technique to authorize vehicles in the system. Table 2 describes the notations used in the proposed system.
3.2. Certified Bitcoin Public Key
For providing Bitcoin-based incentives, we assume that each roadside server and each vehicle participated in message dissemination service on VDTNs has certified Bitcoin public key [18] issued by the SM. That is, and have their Bitcoin private and public key pair and , respectively. More specifically, let be the public parameters where and are two large prime numbers, is an additive group with the order consisting of all points on an elliptic curve , and is a base point of . We can choose the parameters in accordance with secp256k1 ECDSA curve specification used in Bitcoin.
Let be the secret and public key pair of SM where and . Certified public keys for each entity authorized by SM are generated as follows:(1) chooses a random and computes , then requests its certified public key by sending to SM.(2)Assuming that the legitimacy of was validated, SM chooses a random , computes and (mod ) where is a function encoding an element of as a positive integer. Then SM provides to .(3) computes (mod ), and checks if . If it holds, sets as its ECDSA key pair and as certified public key.
When ’s certified public key is given, we can derive the public key from by using SM’s public key as so as to verify the signature generated under . In [18], the certified public key itself is encoded in the Bitcoin transaction output in the form of scriptPubKey script to designate the recipient. On the other hand, in our proposed system, the certified public key is only used in authentication between a vehicle and a raodside server, and then the public key derived from is encoded in the Bitcoin transaction rewarded as incentives.
3.3. Bitcoin-Based Incentive
In this section, we describe Bitcoin-based incentive scheme to reward a vehicle for the effort of message forwarding. Suppose that a source roadside server wants to send a message to a destination point by means of store-carry-forward with the help of a vehicle . When requests to deliver a message to the destination point , the incentive transaction of is published to the Bitcoin network under the condition that the output of can be redeemed by if completes the message forwarding to by using MultiSig transaction. However, if does not forward the message to the destination, is likely to lose its coins without taking advantage of message delivery service from because the ’s input of is treated as spent in the Bitcoin system once is published. To cope with this situation, we put time-locked condition together with MultiSig so as for to withdraw the coins from if does not forward the message nor redeem the output before the time-lock expires.
The details of the proposed scheme are described in the following:(1)A source roadside server broadcasts a request message including the identity of the destination point and the location information to ask for a volunteer vehicle which will help carrying a message to .(2)A vehicle , which will pass by ’s location and be willing to help message forwarding, responds to by giving with its certified public key .(3) verifies the signature as by deriving ’s public key from as described in Section 3.2. If the signature is valid, prepares a Bitcoin transaction and composes a message bundle . Figure 5 shows the transactions for transferring Bitcoin as incentives. specifies unspent coins retrieved from ’s UTXO pool and it includes ’s signature for the transaction. The amount of coins given to as incentives is recorded in and the redemption condition for is written by using locking script consisting of 2-of-2 MultiSig for and time-lock constraint for . Implementation details of the locking and unlocking scripts are presented in the next sections. publishes the to the Bitcoin network and provides to . Note, at this phase, that does not mean a prompt coin transfer but functions as a deposit which will be spent by someone who satisfies the unlocking condition.(4)Upon receiving , derives ’s public key from and verifies ’s signature. Then, stores and carries the message bundle to the destination point . In addition, checks the validity of through the Bitcoin network and partially prepares a transaction to redeem the coins specified in while moving to the destination. At this phase, fills in all other forms of except MultiSig unlocking script for .(5)If is an honest volunteer vehicle, will faithfully store, carry, and forward the message bundle. Hence, when arrives at the destination location and recognizes , composes the message and sends to .(6) parses the and verifies the signature of by using , then accepts the message if the signature is valid. Then, as a witness to the effort of message delivery of , generates a partial signature for to unlock 2-of-2 MultiSig script which is needed for to spend the coins specified in the previous transaction . provides to .(7) derives ’s public key from and verifies the signature. If it holds, completes 2-of-2 MultiSig unlocking script by adding signature for and finally publish to the Bitcoin network to transfer the incentive given by to ’s another Bitcoin account.
If all the above steps are correctly processed, the transactions and will be validated over the Bitcoin network and successfully appended to the blockchain, then can gain Bitcoin incentives as a reward for its contribution to message delivery on VDTNs. In other words, will not be rewarded if it ceases from forwarding the message even though is published to the Bitcoin network in step 3 because alone cannot fulfill 2-of-2 MultiSig locking script. Therefore, when finds that is not redeemed by after the time-lock expired, withdraws the coins by publishing the transaction as regarding that did not forward the message faithfully.
3.4. Implementing Transaction Scripts
Validating a Bitcoin transaction relies on two types of scripts, a locking script and an unlocking script. For guaranteeing the fairness to the source server in our incentive scheme, we make use of MultiSig script and time-lock script in the Bitcoin transactions. Hence, when the source server publishes the transaction , can specify the proper recipient for (i.e., for incentive or for withdraw) by using MultiSig and time-lock script as shown in Algorithm 1. In our implementation, we consider relative time-lock which implies that can be spent after the specified time has elapsed starting from the publishing time. For example, can specify one day amount of time in if allows for to deliver the message within a day so that does not withdraw the coins for the day.
| ||||||||||||
Once published the to the Bitcoin network for providing incentives to , the redemption condition for to spend the coins of is constrained under 2-of-2 MultiSig script fulfilled by both ’s and destination point ’s signatures. Hence, if correctly delivers the message requested by to the destination point and receives a partial signature for from , can spend the coins of by completing the unlocking script of as shown in Algorithm 2.
| ||
The Bitcoin transaction script is a stack-based execution language which uses a stack data structure to store input parameters and a return value of each operation. To execute an operation, the arguments for the operation are first pushed onto a stack and its calculation is performed by reading these arguments directly from the stack. The unlocking script contained in the output and the locking script in the referenced input are combined as shown in Figure 6, and the combined script is executed from left to right in sequence by every Bitcoin validating node.
By combining those scripts of and , the execution path of the first IF clause is selected by putting TRUE, then it would be evaluated in the script execution stack as the following form:
OP_0 2 2OP_CHECKMULTISIG
Figure 7 shows the stack-based script execution to validate ’s redemption condition by using MultiSig operation.
On the other hand, in order to withdraw the coins of after the time-lock expired, publishes the transaction containing the unlocking script as shown in Algorithm 3.
| ||
Like the preceding, by putting FALSE at the end of unlocking script, the execution path of ELSE clause is selected, but this execution is only used after the amount of has elapsed from the creation of . If so, ’s script would be evaluated in the script execution stack as the following form:
OP_CHECKSIGVERIFY
Figure 8 shows the stack-based script execution to validate ’s redemption condition by using time-lock restriction.
4. Discussion
4.1. Security of the Proposed System
As presented so far, our incentive scheme for VDTNs is designed by making use of Bitcoin system which is a cryptographically secure and practical decentralized virtual currency system. In this section, we discuss the security properties of the proposed system in terms of fairness, authorization, and anonymity of vehicular communications.
4.1.1. Fairness
When we design an incentive scheme based on virtual currency for VDTN environments in this paper, one of the important issues is fairness to the source server because a malicious vehicle might not follow the protocol run if the source server provides incentives first.
In the proposed system, providing incentives to a vehicle contributed to message forwarding is processed by the Bitcoin transaction which conceptually transfers coins from the source server ’s Bitcoin account () to the forwarding vehicle ’s account (). Since the for is locked by 2-of-2 MultiSig script when publishes to the Bitcoin network, the coin amount specified in is ineffective for to redeem it by at this moment unless the destination point confirms the message receiving by giving its signature for to unlock 2-of-2 MultiSig combined with ’s signature. cannot but complete message forwarding to in order to redeem the incentive. Therefore, the source server does not need to worry about dine and dash of , and also can be rewarded for its contribution to message delivery if honestly follows the protocol run.
Moreover, as considering the problematic situation where ceases delivering the message to the destination once published incentive transaction, is allowed to make the transaction to withdraw the coins from by putting time-locked script. When finds that is not redeemed by after the time-lock expired, it is regarded that did not follow the protocol and could not redeem the incentive, so withdraws the coins. Such time-lock condition also provides another feature that cannot withdraw the coins earlier than the time-lock. As an example for 12-hour time-lock, can acquire the coins of if arrives at the destination point within 12 hours while cannot withdraw the coins, which guarantees kind of fairness to the vehicle.
4.1.2. Authorization
To deploy a practical VDTNs application of good quality of service in the real-world scenarios, it is needed to allow only authenticated users to take part in the system. We consider using Bitcoin public key cryptography based on ECDSA for our VDTN scenario instead of adopting vehicular-PKI for authenticated vehicular communications. However, ordinary Bitcoin public keys are not sufficient to incorporate trustworthiness from real-world entities into the system. Hence, in the proposed system, each vehicle and each roadside unit are authenticated by using certified Bitcoin public keys ( and , respectively) issued by SM based on the technique of [18].
When a vehicle and a roadside unit communicate to forward a message and give incentives, they exchange their certified public keys, then the corresponding Bitcoin public keys are derived from SM’s public key. Because the exchanged message and Bitcoin transactions include signatures verified under the derived public keys, any other entities unauthorized by SM cannot join the system.
4.1.3. Anonymity of Vehicles
For secure vehicular communications, another security aspect is anonymity of vehicles which voluntarily take part in message store-carry-forwarding communications on VDTNs. The only thing required to the vehicles in the system is their valid Bitcoin public key to uniquely identify the vehicle and handle Bitcoin transactions for incentives. Those public keys used in vehicle to roadside unit communications can be viewed as vehicle’s pseudonyms and do not contain any identity information of the vehicle even though the proposed scheme employs certified public keys.
When we say privacy preservation, we should consider not only anonymity of user identity but also unlinkability. However, the proposed system does not fully satisfy unlinkability requirement because we just assumed that each vehicle has a single public key, so that any outside observer can decide any two messages or two transactions originated from the same user by tracing the fixed same public key of the user.
One simple solution to this challenge is for a vehicle to generate multiple Bitcoin public keys and use a different public key whenever a message forwarding and incentive protocol is performed on VDTNs. However, in this case, it is required to securely maintain lots of private keys as many as the number of public keys. Another flexible solution is to use a one-time public key technique such as CryptoNote in which an ephemeral key pair for each protocol run can be computed from a fixed long-term key pair[29]. Hence, the proposed scheme can be modified by using one-time public key technique to enhance the anonymity of vehicular communications and incentive transactions.
4.2. Comparison
To highlight the novelty of the proposed Bitcoin-based incentive system for VTDNs, we evaluate and qualitatively compare our system with previous systems. Table 3 summarizes the different characteristics of the proposed system as compared with Lee et al.’s [3], Zhu et al.’s [15], and Lu et al.’s [16], respectively.
The key difference of the proposed system results from the use of Bitcoin which is a decentralized cryptocurrency and a worldwide payment system whose transactions are verified by means of a blockchain, while each previous system implements its own application-dependent virtual coin relying on a centralized trusted authority or a bank to guarantee the validity of payment transactions. Hence, for the previous system, we cannot help but depend on the central authority to enjoy reliable payment service. However, it is widely believed that the distributed structure of blockchain network performs better robustness under the single point of failure, so the proposed system can provide strong fault tolerance.
In addition, the previous systems make use of public key certificate to identify the entities participating in the network service and to verify the layered credits, but they do not focus on the anonymity of users. On the other hand, in our system, the Bitcoin public key used in a payment contract as the form of Bitcoin transaction script can be viewed as a pseudonym and we can generate multiple keys or adopt one-time public key technique to enhance the anonymity to some degree.
We also compare the incentive procedures of the proposed system to reward a node for message forwarding and briefly shows the processes assigned to each entity relating to incentive scheme in Table 4. In the previous systems of [15, 16], the incentive for message forwarding is endorsed by means of the layered credits which are sequentially generated by message sender, forwarder, and receiver during the message delivery phase. To securely handle incentive scheme, forwarder and receiver must check the validity of the given credit by themselves and add their own credit layers in sequence. Then, the VB verifies the collected credits and records amount of virtual coin in forwarder’s account if the credits are valid.
On the other hand, in our system, the incentive is handled by means of Bitcoin transactions to pay the coin from the sender to the forwarder. Those Bitcoin transactions are validated by Bitcoin network in a distributed manner and added to a blockchain which serves as immutable distributed ledgers. The message forwarder just queries the validity of sender’s payment transaction to Bitcoin network, instead of verifying sender’s payment transaction by forwarder itself. Message sender can control that the payment would be redeemed by the honest forwarder which delivers the message to the receiver by putting MultiSig locking script to the payment transaction which must be resolved by both forwarder’s and receiver’s signatures.
As compared to the previous system, the processes of validating incentive transactions to reliably pay the coins from the sender to the forwarder as an incentive are not burdened to VANET but shifted to Bitcoin network. The required processes for the sender and the forwarder are just to publish Bitcoin transactions which will be validated through a blockchain network. Therefore, we can develop a practical credit-based incentive scheme on VANETs at a low cost by removing the necessary of implementing application-dependent virtual coin system but by taking advantage of the functionalities of the existing cryptocurrency system.
5. Conclusion
In this paper, we proposed a secure incentive scheme incorporating with Bitcoin for VDTNs to stimulate vehicles positively cooperating with other nodes and to reward their efforts. Based on the security features of the Bitcoin system, the incentives for volunteer vehicles are rewarded by means of Bitcoins which can be worldwide used as virtual cash, and the fairness to the source server is guaranteed by using MultiSig transaction so that a message relaying vehicle can redeem the coins of incentive transactions only if the vehicle correctly completes the message relaying to a destination. To achieve the fairness goal, we also implemented transaction scripts to deal with reliable incentive rewarding based on locking and unlocking scripts consisting of 2-of-2 MultiSig and time-lock condition. Especially, as compared to the previous systems, the proposed incentive scheme can be developed at a low cost because we do not need to implement our own virtual currency system on VDTNs.
Data Availability
No data were used to support this study.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work was supported by Institute for Information & Communications Technology Promotion (IITP) grant funded by the Korea Government (MSIT) (2017-0-00156, The Development of a Secure Framework and Evaluation Method for Blockchain).