# A Secure Incentive Scheme for Vehicular Delay Tolerant Networks Using Cryptocurrency

Authors: Youngho Park; Chul Sur; Kyung-Hyune Rhee
Journal: Security and Communication Networks
 (2018)

---

## 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.


---

## Body

## 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 S to the display located at D. Another application is to forward messages to the Internet through the gateway server located at D when Internet connection is not possible atS.Figure 1
An example of store-carry-forwarding scenario in VANETs.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 Section2, 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.


## 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 Section2, 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. Table1 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.Table 1
Some remarkable cryptocurrencies based on blockchain.
project launched anonymity remarks ref. Bitcoin 2009 pseudonymous (i) first blockchain-based cryptocurrency(ii) uses proof-of-work timestamping [20]  Namecoin 2011 censorship registance (i) first altcoin that implemented Satoshi’s BitDNS idea(ii) key-value pair registration and transfer [21]  Litecoin 2011 pseudonymous (i) technical detail is similar to Bitcoin(ii) aims to process a block every 2.5 minutes, rather than Bitcoin’s 10 minutes(iii) uses scrypt in its proof-of-work algorithm [22]  Monero 2014 pseudonymous,unlinkable (i) implemented based on the CryptoNote protocol(ii) uses ring confidential transactions technique [23]  Ethereum 2015 pseudonymous (i) provides Turing-complete virtual machine, Ethereum Virtual Machine (EVM)(ii) distributed computing platform featuring smart contract functionality(iii) Ether is a cryptocurrency generated by the Ethereum platform [24] Zcash 2016 strong anonymity,shielded transactions (i) decentralized cryptocurrency that provides strong privacy protections(ii) transactions can be controlled by a zero-knowledge proof called zk-SNARKs [25]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 calledminers. After validating the transactions pended for a given time period, miners collect the transactions into a single unit calledblock. The new block accepted by the miners according to a consensus protocol is then added to the Bitcoin public ledger calledblockchain.


### 2.2. Transaction

Bitcoin transaction is the record implying that transfers the value of coins from a sender to a recipient as shown in Figure2. 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.Figure 2
Overview of Bitcoin transaction structure and spending.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_CHECKSIGTo 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 scriptscriptPubKey: 2 <PubKey A>  <PubKey B>  <PubKey C> 3 OP_CHECKMULTISIGcan 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>, orscriptSig: 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 useCHECKLOCKTIMEVERIFY 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. Figure3 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.Figure 3
Blockchain structure in the Bitcoin system.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 thatHash(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.


## 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 calledminers. After validating the transactions pended for a given time period, miners collect the transactions into a single unit calledblock. The new block accepted by the miners according to a consensus protocol is then added to the Bitcoin public ledger calledblockchain.


## 2.2. Transaction

Bitcoin transaction is the record implying that transfers the value of coins from a sender to a recipient as shown in Figure2. 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.Figure 2
Overview of Bitcoin transaction structure and spending.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_CHECKSIGTo 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 scriptscriptPubKey: 2 <PubKey A>  <PubKey B>  <PubKey C> 3 OP_CHECKMULTISIGcan 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>, orscriptSig: 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 useCHECKLOCKTIMEVERIFY 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. Figure3 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.Figure 3
Blockchain structure in the Bitcoin system.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 thatHash(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 Figure4 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.Figure 4
System architecture for Bitcoin-based incentives for VDTNs.(i)
Service manager (SM) controls roadside units and authorizes vehicles participating in message dissemination service on VDTNs. SM issues certified public keys to the authorized roadside units and vehicles for authenticated vehicular communications and Bitcoin incentive transactions. The public key of SM for certified key generation is known to other entities in the system. (ii)
Vehicles participating in the system are equipped with OBUs embedding LTE/5G mobile communication for Internet connection, 802.11p for V2I and V2V communications [28] and navigation system with digital map. For handling Bitcoin transactions, Bitcoin client module is also installed in the vehicle. (iii)
Roadside units are under the control of SM and have 802.11p wireless link for communicating with vehicles passing by them, but not all roadside units have end-to-end or direct communication among them, so it is made in an opportunistic way with the help of moving vehicles.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. Table2 describes the notations used in the proposed system.Table 2
Notations and descriptions.
notation description x , X master secret and public key pair of SM  b s k i , b p k i private and public key pair of entityi  C i certified public key of entityi  T X Bitcoin transaction  T X . i n input of the transactionTX  T X . o u t output of the transactionTX  S i g s k , M signature for a messageM under a private key sk  V r f p k , σ verification for a signatureσ under a public key pk  ρ : G → Z q a mapping function  t s timestamp


### 3.2. Certified Bitcoin Public Key

For providing Bitcoin-based incentives, we assume that each roadside serverRSi and each vehicle vi participated in message dissemination service on VDTNs has certified Bitcoin public key [18] issued by the SM. That is, RSi and vi have their Bitcoin private and public key pair bskSi,bpkSi and bskvi,bpkvi, respectively. More specifically, let p,q,G,P∈G be the public parameters where p and q are two large prime numbers, G is an additive group with the order q consisting of all points on an elliptic curve E(Fp), and P is a base point of G. We can choose the parameters in accordance with secp256k1 ECDSA curve specification used in Bitcoin.Letx,X be the secret and public key pair of SM where x∈Zq and X=x·P. Certified public keys for each entity Ui authorized by SM are generated as follows:(1)
Ui chooses a random ki∈Zq and computes Ki=ki·P, then requests its certified public key by sending Ki to SM.(2)
Assuming that the legitimacy ofUi was validated, SM chooses a random ri∈Zq, computes Ci=Ki+ri·P and yi′=ri+ρ(Ci)·x (mod q) where ρ is a function encoding an element of G as a positive integer. Then SM provides Ci,y′ to Ui.(3)
Ui computes yi=yi′+ki (mod q), Yi=yi·P and checks if Yi=?Ci+ρ(Ci)·X. If it holds, Ui sets bski←yi,bpki←Yi as its ECDSA key pair and Ci as certified public key.WhenUi’s certified public key Ci is given, we can derive the public key Yi from Ci by using SM’s public key X as Yi=Ci+ρ(Ci)·X so as to verify the signature generated under yi. 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 Ci is only used in authentication between a vehicle and a raodside server, and then the public key Yi derived from Ci 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 serverRSs wants to send a message M to a destination point RSd by means of store-carry-forward with the help of a vehicle vi. When RSs requests vi to deliver a message to the destination point RSd, the incentive transaction TX of RSs is published to the Bitcoin network under the condition that the output of TX can be redeemed by vi if vi completes the message forwarding to RSd by using MultiSig transaction. However, if vi does not forward the message to the destination, RSs is likely to lose its coins without taking advantage of message delivery service from vi because the RSs’s input of TX is treated as spent in the Bitcoin system once TX is published. To cope with this situation, we put time-locked condition together with MultiSig so as for RSs to withdraw the coins from TX if vi 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 serverRSs broadcasts a request message including the identity of the destination point RSd and the location information locd to ask for a volunteer vehicle which will help carrying a message to RSd.(2)
A vehiclevi, which will pass by RSd’s location and be willing to help message forwarding, responds to RSs by giving σ=Sig(bskvi,RSdlocd) with its certified public key Cvi.(3)
RSs verifies the signature σ as Vrf(bpkvi,σ) by deriving vi’s public key bpkvi from Cvi as described in Section 3.2. If the signature is valid, RSs prepares a Bitcoin transaction TX1 and composes a message bundle msg1:=MtsSigbskRSs,Mts,CRSs,TX1. Figure 5 shows the transactions for transferring Bitcoin as incentives. TX1.in specifies unspent coins retrieved from RSs’s UTXO pool and it includes RSs’s signature for the transaction. The amount of coins given to vi as incentives is recorded in TX1.out and the redemption condition for TX1.out is written by using locking script consisting of 2-of-2 MultiSig for vi and time-lock constraint for RSd. Implementation details of the locking and unlocking scripts are presented in the next sections. RSs publishes the TX1 to the Bitcoin network and provides msg1 to vi. Note, at this phase, that TX1 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 receivingmsg1, vi derives RSs’s public key from CRSs and verifies RSs’s signature. Then, vi stores and carries the message bundle to the destination point RSd. In addition, vi checks the validity of TX1 through the Bitcoin network and partially prepares a transaction TX2 to redeem the coins specified in TX1.out while moving to the destination. At this phase, vi fills in all other forms of TX2 except MultiSig unlocking script for TX2.in.(5)
Ifvi is an honest volunteer vehicle, vi will faithfully store, carry, and forward the message bundle. Hence, when vi arrives at the destination location and recognizes RSd, vi composes the message msg2:=MtsSigbskRSs,Mts,CRSs,TX2 and sends to RSd.(6)
RSd parses the msg2 and verifies the signature of Sig(bskRSs,Mts) by using CRSs, then accepts the message M if the signature is valid. Then, as a witness to the effort of message delivery of vi, RSd generates a partial signature for TX2 to unlock 2-of-2 MultiSig script which is needed for vi to spend the coins specified in the previous transaction TX1.out. RSd provides TX2,SigbskRSd,TX2,CRSd to vi.(7)
vi derives RSd’s public key from CRSd and verifies the signature. If it holds, vi completes 2-of-2 MultiSig unlocking script by adding vi signature for TX2 and finally publish TX2 to the Bitcoin network to transfer the incentive given by TX1 to vi’s another Bitcoin account.Figure 5
Transactions to give incentive or withdraw.If all the above steps are correctly processed, the transactionsTX1 and TX2 will be validated over the Bitcoin network and successfully appended to the blockchain, then vi can gain Bitcoin incentives as a reward for its contribution to message delivery on VDTNs. In other words, vi will not be rewarded if it ceases from forwarding the message even though TX1 is published to the Bitcoin network in step 3 because vi alone cannot fulfill 2-of-2 MultiSig locking script. Therefore, when RSs finds that TX1 is not redeemed by vi after the time-lock expired, RSs withdraws the coins by publishing the transaction TX2′ as regarding that vi 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 serverRSs in our incentive scheme, we make use of MultiSig script and time-lock script in the Bitcoin transactions. Hence, when the source server RSs publishes the transaction TX1, RSs can specify the proper recipient for TX1.out (i.e., vi for incentive or RSs 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 TX1.out can be spent after the specified time has elapsed starting from the TX1 publishing time. For example, RSs can specify one day amount of time in <time-lock> if RSs allows for vi to deliver the message within a day so that RSs does not withdraw the coins for the day.Algorithm 1:Locking script of TX1.out for giving incentives.
scriptPubKey:OP_IF 2 < bpkvi > < bpkRSd > 2 OP_CHECKMULTISIG OP_ELSE < time-lock > OP_CHECKSEQUENCEVERIFY OP_DROP < bpkRSs > OP_CHECKSIGVERIFY OP_ENDIFOnceRSs published the TX1 to the Bitcoin network for providing incentives to vi, the redemption condition for vi to spend the coins of TX1.out is constrained under 2-of-2 MultiSig script fulfilled by both vi’s and destination point RSd’s signatures. Hence, if vi correctly delivers the message requested by RSs to the destination point RSd and receives a partial signature for TX2 from RSd, vi can spend the coins of TX1 by completing the unlocking script of TX2.in as shown in Algorithm 2.Algorithm 2:Unlocking script in TX2.in for vi to redeem the incentive.
scriptSig:OP_0 < Sigvi >  < SigRSd > TRUEThe 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 Figure6, and the combined script is executed from left to right in sequence by every Bitcoin validating node.Figure 6
Combining unlocking script and locking script to evaluate a transaction script.By combining those scripts ofTX2.in and TX1.out, 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  <Sigvi>  <SigRSd> 2 <bpkvi><bpkRSd>  2OP_CHECKMULTISIGFigure7 shows the stack-based script execution to validate vi’s redemption condition by using MultiSig operation.Figure 7
Script execution for validatingvi’s redemption condition.On the other hand, in order to withdraw the coins ofTX1 after the time-lock expired, RSs publishes the transaction TX2′ containing the unlocking script as shown in Algorithm 3.Algorithm 3:Unlocking script in TX2′.in for RSs to withdraw the coins.
scriptSig:< SigRSs > FALSELike the preceding, by puttingFALSE at the end of unlocking script, the execution path of ELSE clause is selected, but this execution is only used after the amount of <time-lock> has elapsed from the creation of TX1. If so, RSd’s script would be evaluated in the script execution stack as the following form:< S i g R S s >   < b p k R S s >  OP_CHECKSIGVERIFYFigure8 shows the stack-based script execution to validate RSs’s redemption condition by using time-lock restriction.Figure 8
Script execution for validatingRSs’s redemption condition.


## 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 Figure4 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.Figure 4
System architecture for Bitcoin-based incentives for VDTNs.(i)
Service manager (SM) controls roadside units and authorizes vehicles participating in message dissemination service on VDTNs. SM issues certified public keys to the authorized roadside units and vehicles for authenticated vehicular communications and Bitcoin incentive transactions. The public key of SM for certified key generation is known to other entities in the system. (ii)
Vehicles participating in the system are equipped with OBUs embedding LTE/5G mobile communication for Internet connection, 802.11p for V2I and V2V communications [28] and navigation system with digital map. For handling Bitcoin transactions, Bitcoin client module is also installed in the vehicle. (iii)
Roadside units are under the control of SM and have 802.11p wireless link for communicating with vehicles passing by them, but not all roadside units have end-to-end or direct communication among them, so it is made in an opportunistic way with the help of moving vehicles.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. Table2 describes the notations used in the proposed system.Table 2
Notations and descriptions.
notation description x , X master secret and public key pair of SM  b s k i , b p k i private and public key pair of entityi  C i certified public key of entityi  T X Bitcoin transaction  T X . i n input of the transactionTX  T X . o u t output of the transactionTX  S i g s k , M signature for a messageM under a private key sk  V r f p k , σ verification for a signatureσ under a public key pk  ρ : G → Z q a mapping function  t s timestamp


## 3.2. Certified Bitcoin Public Key

For providing Bitcoin-based incentives, we assume that each roadside serverRSi and each vehicle vi participated in message dissemination service on VDTNs has certified Bitcoin public key [18] issued by the SM. That is, RSi and vi have their Bitcoin private and public key pair bskSi,bpkSi and bskvi,bpkvi, respectively. More specifically, let p,q,G,P∈G be the public parameters where p and q are two large prime numbers, G is an additive group with the order q consisting of all points on an elliptic curve E(Fp), and P is a base point of G. We can choose the parameters in accordance with secp256k1 ECDSA curve specification used in Bitcoin.Letx,X be the secret and public key pair of SM where x∈Zq and X=x·P. Certified public keys for each entity Ui authorized by SM are generated as follows:(1)
Ui chooses a random ki∈Zq and computes Ki=ki·P, then requests its certified public key by sending Ki to SM.(2)
Assuming that the legitimacy ofUi was validated, SM chooses a random ri∈Zq, computes Ci=Ki+ri·P and yi′=ri+ρ(Ci)·x (mod q) where ρ is a function encoding an element of G as a positive integer. Then SM provides Ci,y′ to Ui.(3)
Ui computes yi=yi′+ki (mod q), Yi=yi·P and checks if Yi=?Ci+ρ(Ci)·X. If it holds, Ui sets bski←yi,bpki←Yi as its ECDSA key pair and Ci as certified public key.WhenUi’s certified public key Ci is given, we can derive the public key Yi from Ci by using SM’s public key X as Yi=Ci+ρ(Ci)·X so as to verify the signature generated under yi. 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 Ci is only used in authentication between a vehicle and a raodside server, and then the public key Yi derived from Ci 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 serverRSs wants to send a message M to a destination point RSd by means of store-carry-forward with the help of a vehicle vi. When RSs requests vi to deliver a message to the destination point RSd, the incentive transaction TX of RSs is published to the Bitcoin network under the condition that the output of TX can be redeemed by vi if vi completes the message forwarding to RSd by using MultiSig transaction. However, if vi does not forward the message to the destination, RSs is likely to lose its coins without taking advantage of message delivery service from vi because the RSs’s input of TX is treated as spent in the Bitcoin system once TX is published. To cope with this situation, we put time-locked condition together with MultiSig so as for RSs to withdraw the coins from TX if vi 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 serverRSs broadcasts a request message including the identity of the destination point RSd and the location information locd to ask for a volunteer vehicle which will help carrying a message to RSd.(2)
A vehiclevi, which will pass by RSd’s location and be willing to help message forwarding, responds to RSs by giving σ=Sig(bskvi,RSdlocd) with its certified public key Cvi.(3)
RSs verifies the signature σ as Vrf(bpkvi,σ) by deriving vi’s public key bpkvi from Cvi as described in Section 3.2. If the signature is valid, RSs prepares a Bitcoin transaction TX1 and composes a message bundle msg1:=MtsSigbskRSs,Mts,CRSs,TX1. Figure 5 shows the transactions for transferring Bitcoin as incentives. TX1.in specifies unspent coins retrieved from RSs’s UTXO pool and it includes RSs’s signature for the transaction. The amount of coins given to vi as incentives is recorded in TX1.out and the redemption condition for TX1.out is written by using locking script consisting of 2-of-2 MultiSig for vi and time-lock constraint for RSd. Implementation details of the locking and unlocking scripts are presented in the next sections. RSs publishes the TX1 to the Bitcoin network and provides msg1 to vi. Note, at this phase, that TX1 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 receivingmsg1, vi derives RSs’s public key from CRSs and verifies RSs’s signature. Then, vi stores and carries the message bundle to the destination point RSd. In addition, vi checks the validity of TX1 through the Bitcoin network and partially prepares a transaction TX2 to redeem the coins specified in TX1.out while moving to the destination. At this phase, vi fills in all other forms of TX2 except MultiSig unlocking script for TX2.in.(5)
Ifvi is an honest volunteer vehicle, vi will faithfully store, carry, and forward the message bundle. Hence, when vi arrives at the destination location and recognizes RSd, vi composes the message msg2:=MtsSigbskRSs,Mts,CRSs,TX2 and sends to RSd.(6)
RSd parses the msg2 and verifies the signature of Sig(bskRSs,Mts) by using CRSs, then accepts the message M if the signature is valid. Then, as a witness to the effort of message delivery of vi, RSd generates a partial signature for TX2 to unlock 2-of-2 MultiSig script which is needed for vi to spend the coins specified in the previous transaction TX1.out. RSd provides TX2,SigbskRSd,TX2,CRSd to vi.(7)
vi derives RSd’s public key from CRSd and verifies the signature. If it holds, vi completes 2-of-2 MultiSig unlocking script by adding vi signature for TX2 and finally publish TX2 to the Bitcoin network to transfer the incentive given by TX1 to vi’s another Bitcoin account.Figure 5
Transactions to give incentive or withdraw.If all the above steps are correctly processed, the transactionsTX1 and TX2 will be validated over the Bitcoin network and successfully appended to the blockchain, then vi can gain Bitcoin incentives as a reward for its contribution to message delivery on VDTNs. In other words, vi will not be rewarded if it ceases from forwarding the message even though TX1 is published to the Bitcoin network in step 3 because vi alone cannot fulfill 2-of-2 MultiSig locking script. Therefore, when RSs finds that TX1 is not redeemed by vi after the time-lock expired, RSs withdraws the coins by publishing the transaction TX2′ as regarding that vi 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 serverRSs in our incentive scheme, we make use of MultiSig script and time-lock script in the Bitcoin transactions. Hence, when the source server RSs publishes the transaction TX1, RSs can specify the proper recipient for TX1.out (i.e., vi for incentive or RSs 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 TX1.out can be spent after the specified time has elapsed starting from the TX1 publishing time. For example, RSs can specify one day amount of time in <time-lock> if RSs allows for vi to deliver the message within a day so that RSs does not withdraw the coins for the day.Algorithm 1:Locking script of TX1.out for giving incentives.
scriptPubKey:OP_IF 2 < bpkvi > < bpkRSd > 2 OP_CHECKMULTISIG OP_ELSE < time-lock > OP_CHECKSEQUENCEVERIFY OP_DROP < bpkRSs > OP_CHECKSIGVERIFY OP_ENDIFOnceRSs published the TX1 to the Bitcoin network for providing incentives to vi, the redemption condition for vi to spend the coins of TX1.out is constrained under 2-of-2 MultiSig script fulfilled by both vi’s and destination point RSd’s signatures. Hence, if vi correctly delivers the message requested by RSs to the destination point RSd and receives a partial signature for TX2 from RSd, vi can spend the coins of TX1 by completing the unlocking script of TX2.in as shown in Algorithm 2.Algorithm 2:Unlocking script in TX2.in for vi to redeem the incentive.
scriptSig:OP_0 < Sigvi >  < SigRSd > TRUEThe 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 Figure6, and the combined script is executed from left to right in sequence by every Bitcoin validating node.Figure 6
Combining unlocking script and locking script to evaluate a transaction script.By combining those scripts ofTX2.in and TX1.out, 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  <Sigvi>  <SigRSd> 2 <bpkvi><bpkRSd>  2OP_CHECKMULTISIGFigure7 shows the stack-based script execution to validate vi’s redemption condition by using MultiSig operation.Figure 7
Script execution for validatingvi’s redemption condition.On the other hand, in order to withdraw the coins ofTX1 after the time-lock expired, RSs publishes the transaction TX2′ containing the unlocking script as shown in Algorithm 3.Algorithm 3:Unlocking script in TX2′.in for RSs to withdraw the coins.
scriptSig:< SigRSs > FALSELike the preceding, by puttingFALSE at the end of unlocking script, the execution path of ELSE clause is selected, but this execution is only used after the amount of <time-lock> has elapsed from the creation of TX1. If so, RSd’s script would be evaluated in the script execution stack as the following form:< S i g R S s >   < b p k R S s >  OP_CHECKSIGVERIFYFigure8 shows the stack-based script execution to validate RSs’s redemption condition by using time-lock restriction.Figure 8
Script execution for validatingRSs’s redemption condition.


## 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 transactionTX1 which conceptually transfers coins from the source server RSs’s Bitcoin account (TX1.in) to the forwarding vehicle vi’s account (TX1.out). Since the TX1.out for vi is locked by 2-of-2 MultiSig script when RSs publishes TX1 to the Bitcoin network, the coin amount specified in TX1.out is ineffective for vi to redeem it by TX2.in at this moment unless the destination point RSd confirms the message receiving by giving its signature for TX2 to unlock 2-of-2 MultiSig combined with vi’s signature. vi cannot but complete message forwarding to RSd in order to redeem the incentive. Therefore, the source server RSs does not need to worry about dine and dash of vi, and vi also can be rewarded for its contribution to message delivery if vi honestly follows the protocol run.Moreover, as considering the problematic situation wherevi ceases delivering the message to the destination once RSs published TX1 incentive transaction, RSs is allowed to make the transaction TX2′ to withdraw the coins from TX1 by putting time-locked script. When RSs finds that TX1 is not redeemed by vi after the time-lock expired, it is regarded that vi did not follow the protocol and could not redeem the incentive, so RSs withdraws the coins. Such time-lock condition also provides another feature that RSs cannot withdraw the coins earlier than the time-lock. As an example for 12-hour time-lock, vi can acquire the coins of TX1 if vi arrives at the destination point within 12 hours while RSs 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 vehiclev and each roadside unit RS are authenticated by using certified Bitcoin public keys (Cv and CRS, 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. Table3 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.Table 3
Comparison of the characteristics of the proposed system with the previous systems.
Lee et al. [3] Zhu et al. [15] Lu et al. [16] proposed network service simple broadcast dtn dtn vdtn  trust model centralized authority centralized virtual bank (VB) centralized (VB) distributed (blockchain)  fault tolerance weak weak weak strong  fairness escrow held by the authority escrow held by the VB escrow held by the VB multisig and timelock script on a blockchain  incentive means virtual coin, application dependent virtual coin, application dependent reputation, virtual coin, application dependent Bitcoin, worldwide  payment contract signed receipt by a receiver layered credits by sender, forwarder, receiver in sequence layered credits Bitcoin transaction script  rewarding exchange receipt to virtual cash through the authority credit clearance through the VB credit clearance through the VB Bitcoin payment  identity certificate certificate certificate Bitcoin public key (address)  anonymity low n/a n/a mediumThe 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 Table4. 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.Table 4
Comparison of the incentive procedures to perform virtual coin rewarding.
VANET VB / Blockchain sender forwarder receiver Zhu et al. & Lu et al. (1) generate a base layer credit (2) check the validity of the base layer credit(3) generate and add its endorsed layer credit (4) check the validity of the layered credits(5) generate and add its endorsed layer credit(6) send and request clearance of the credits to VB (7) check the validity of the all layered credits(8) check sender’s balance(9) record amount of coin in forwarder’s account  proposed (1) publish incentive transaction to blockchain network(7) publish withdraw transaction to blockchain network (4) query the validity of the incentive transaction to Bitcoin network(7) publish redemption transaction to blockchain network (6) sign forwarder’s redemption transaction (2), (8) validate the incoming transaction(5) respond to the transaction query(3), (9) add the transaction to a blockchainOn 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.


## 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 transactionTX1 which conceptually transfers coins from the source server RSs’s Bitcoin account (TX1.in) to the forwarding vehicle vi’s account (TX1.out). Since the TX1.out for vi is locked by 2-of-2 MultiSig script when RSs publishes TX1 to the Bitcoin network, the coin amount specified in TX1.out is ineffective for vi to redeem it by TX2.in at this moment unless the destination point RSd confirms the message receiving by giving its signature for TX2 to unlock 2-of-2 MultiSig combined with vi’s signature. vi cannot but complete message forwarding to RSd in order to redeem the incentive. Therefore, the source server RSs does not need to worry about dine and dash of vi, and vi also can be rewarded for its contribution to message delivery if vi honestly follows the protocol run.Moreover, as considering the problematic situation wherevi ceases delivering the message to the destination once RSs published TX1 incentive transaction, RSs is allowed to make the transaction TX2′ to withdraw the coins from TX1 by putting time-locked script. When RSs finds that TX1 is not redeemed by vi after the time-lock expired, it is regarded that vi did not follow the protocol and could not redeem the incentive, so RSs withdraws the coins. Such time-lock condition also provides another feature that RSs cannot withdraw the coins earlier than the time-lock. As an example for 12-hour time-lock, vi can acquire the coins of TX1 if vi arrives at the destination point within 12 hours while RSs 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 vehiclev and each roadside unit RS are authenticated by using certified Bitcoin public keys (Cv and CRS, 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.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 transactionTX1 which conceptually transfers coins from the source server RSs’s Bitcoin account (TX1.in) to the forwarding vehicle vi’s account (TX1.out). Since the TX1.out for vi is locked by 2-of-2 MultiSig script when RSs publishes TX1 to the Bitcoin network, the coin amount specified in TX1.out is ineffective for vi to redeem it by TX2.in at this moment unless the destination point RSd confirms the message receiving by giving its signature for TX2 to unlock 2-of-2 MultiSig combined with vi’s signature. vi cannot but complete message forwarding to RSd in order to redeem the incentive. Therefore, the source server RSs does not need to worry about dine and dash of vi, and vi also can be rewarded for its contribution to message delivery if vi honestly follows the protocol run.Moreover, as considering the problematic situation wherevi ceases delivering the message to the destination once RSs published TX1 incentive transaction, RSs is allowed to make the transaction TX2′ to withdraw the coins from TX1 by putting time-locked script. When RSs finds that TX1 is not redeemed by vi after the time-lock expired, it is regarded that vi did not follow the protocol and could not redeem the incentive, so RSs withdraws the coins. Such time-lock condition also provides another feature that RSs cannot withdraw the coins earlier than the time-lock. As an example for 12-hour time-lock, vi can acquire the coins of TX1 if vi arrives at the destination point within 12 hours while RSs 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 vehiclev and each roadside unit RS are authenticated by using certified Bitcoin public keys (Cv and CRS, 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. Table3 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.Table 3
Comparison of the characteristics of the proposed system with the previous systems.
Lee et al. [3] Zhu et al. [15] Lu et al. [16] proposed network service simple broadcast dtn dtn vdtn  trust model centralized authority centralized virtual bank (VB) centralized (VB) distributed (blockchain)  fault tolerance weak weak weak strong  fairness escrow held by the authority escrow held by the VB escrow held by the VB multisig and timelock script on a blockchain  incentive means virtual coin, application dependent virtual coin, application dependent reputation, virtual coin, application dependent Bitcoin, worldwide  payment contract signed receipt by a receiver layered credits by sender, forwarder, receiver in sequence layered credits Bitcoin transaction script  rewarding exchange receipt to virtual cash through the authority credit clearance through the VB credit clearance through the VB Bitcoin payment  identity certificate certificate certificate Bitcoin public key (address)  anonymity low n/a n/a mediumThe 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 Table4. 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.Table 4
Comparison of the incentive procedures to perform virtual coin rewarding.
VANET VB / Blockchain sender forwarder receiver Zhu et al. & Lu et al. (1) generate a base layer credit (2) check the validity of the base layer credit(3) generate and add its endorsed layer credit (4) check the validity of the layered credits(5) generate and add its endorsed layer credit(6) send and request clearance of the credits to VB (7) check the validity of the all layered credits(8) check sender’s balance(9) record amount of coin in forwarder’s account  proposed (1) publish incentive transaction to blockchain network(7) publish withdraw transaction to blockchain network (4) query the validity of the incentive transaction to Bitcoin network(7) publish redemption transaction to blockchain network (6) sign forwarder’s redemption transaction (2), (8) validate the incoming transaction(5) respond to the transaction query(3), (9) add the transaction to a blockchainOn 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.



---

*Source: 5932183-2018-07-08.xml*