Privacy-Protected Deletable Blockchain

A deletable blockchain has been proposed recently to change the immutability of the traditional blockchain. However, the users’ identities and transaction contents are all public in the scheme, and the public data may reveal the users’ privacy. In order to protect the privacy of the users, we propose a privacy-protected deletable blockchain based on the proof-of-space consensus mechanism, which does not rely on complex cryptographic tools or any trusted party. In order to satisfy full transparency and accountability in an anonymous environment, we use a traceable ring signature or a Pedersen commitment scheme to disclose the users’ real identities or the real transaction contents respectively according to different deletion reasons. During the deletion process, we propose a linkable multi-signature scheme, which allows multiple users to generate a valid signature by using their one-time addresses as pseudonyms to protect their identity privacy. Moreover, the proposed multi-signature scheme can link two sub-signatures if they are generated by the same malicious user. Finally, we simulate the generation and deletion process of a block under the proof-of-space consensus mechanism and give the time of generating and deleting a block. The experimental results prove the efficiency and feasibility of our proposed scheme.


I. INTRODUCTION
In decentralized information technology, blockchain is a breakthrough innovation which was initially invented as the foundation for Bitcoin [1] (the first decentralized cryptocurrency which is released in 2009). A distributed database containing a continuously growing list of ordered records is the basic concept of blockchain. The decentralized nature of blockchain is supported by the consensus mechanism. There are different types of consensus mechanism including the proof-of-work(PoW) [2], [3] which is based on the computing power invested by miners, while the proof-ofstake(PoS) [4] is based on the stake held by miners and the proof-of-space(PoSpace) [5] is based on the storage capacity invested by miners.
In the traditional blockchain, the transparent transaction data will leak the users' privacy. The malicious attacker can track the flow of transactions to reveal the real identities of the users through data mining. Ignoring those privacy issues will result in impaired users' benefits. Many solutions have been proposed recently aimed at preserving the privacy of blockchain. Non-interactive zero-knowledge proof [6], ring The associate editor coordinating the review of this manuscript and approving it for publication was Fan Zhang. signature [7], and mixing services [8] are three kinds of popular methods for protecting privacy in blockchain.
One of the core features of blockchain is immutability, which means that once the block is generated, the data put on the block cannot be changed anymore. The immutability leads to a problem that once the block is generated, the block data cannot be altered or deleted even for dangerous or useless data. However, in the present deletable blockchain scheme, the users' identities and transaction contents are all public, and the users' privacy will be leaked during the deletion process. To mitigate this problem, it is necessary to propose a privacy-protected deletable blockchain system.

A. RALATED WORK
The deleted or redacted block will bring the changed hash link. Most of the present redactable schemes utilize a hash mechanism called chameleon hash [9] to keep the same hash link relationship between the neighboring blocks. The first approach which uses the chameleon hash is proposed by Ateniese et al. In their proposed scheme [10], when the altered or edited block brings the changed hash link, they use the chameleon hash to calculate the collision. However, the chameleon hash demands that only the reckoner who has the trapdoor can calculate the collision and this requires a trusted party in the blockchain system. Thus, many researchers proposed an improved redactable blockchain by sharing the trapdoor key to different users.
Kondapally et al. [11] decentralize the trapdoor through a non-linear method of secret sharing, then they reconstruct the trapdoor key through the multi-party computation(MPC) technology, which ensures the modification of a block does not depend on one user but depend on multiple ones, the edit authority is given to more parties. What's more, they propose a new idea to use a second trapdoor key to edit a block without the agreement of the block's generator. Nevertheless, this scheme needs to create a short term key for each block, and a key authority should be constructed to manage these keys.
However, all of the proposed schemes solve this problem on the block level. Recently, Derler et al. [12] proposed a finegrained and transaction-level redactable blockchain. In their scheme, a new policy-based chameleon hash was proposed, the new hash allows anyone who possesses sufficient privileges to satisfy the policy can then find arbitrary collisions for a given hash value. However, this solution is limited in the permissioned setting. In the permissionless setting, when the trapdoor key is shared with different users and the collision is calculated through a multi-party computation policy, this solution will suffer from scalability issues.
Instead of using the chameleon hash, Ren [13] recently proposed a deletable blockchain which is based on the proofof-space consensus mechanism and a threshold ring signature scheme. However, all of the block data is public in this deletable proposal and it may leak the users' real identities and the transaction contents during the deletion process. The research on proposing a privacy-protected deletable blockchain is very important and challenging.

B. OUR CONTRIBUTIONS
Inspired by the recent work, this paper proposes a privacyprotected deletable blockchain scheme based on the proofof-space consensus mechanism [5]. We use an anonymous protocol to conceal the transaction contents and the addresses of both parties in one transaction. Then we categorize the reasons for the transaction which applies for a deletion request. In order to satisfy full transparency and accountability in an anonymous environment, we use a traceable ring signature or a Pedersen commitment scheme to disclose the users' real identities or the real transaction contents respectively according to different privacy protection requirements.
During the process of deleting a block, we propose a linkable digital multi-signature scheme which allows the users to generate a signature by using their one-time addresses. The proposed multi-signature scheme can link two subsignatures if they are generated by the same malicious user. The users who come to an agreement on a deletion request generate a multi-signature jointly and the rest of the users in the blockchain accept the deletion operation if the multisignature is valid. Specifically, we provide formal security analysis, and our proposed scheme has the following features: • Only the transaction sender has the right to propose a deletion request due to the anonymous environment. The sender can choose to reveal the real transaction contents or his real identity as the deletion evidence.
• The identities of the transaction sender and the receiver are still concealed if the transaction sender chooses to disclose the real transaction contents.
• The real transaction contents and the identity of the transaction receiver are still private if the transaction sender chooses to reveal his real identity.
Finally, we execute several experiments to simulate the mining process and give the time of generating and deleting a block. The experimental results show that the average deletion time of a block is about twice the generation time, which proves the efficiency and feasibility of our proposed scheme.

II. PRELIMINARIES
In this section, we introduce some security protocols and basic definitions, including Ring confidential transaction(Ring CT) protocol [14], traceable ring signature [15] and ''proof-of-space'' [5] consensus mechanism. Finally, we introduce a complexity assumption that will be used to prove security of the proposed signature scheme in Section 3.

A. RING CT PROTOCOL
The Ring CT protocol is an anonymous protocol used in Monero which contains three algorithms, multilayered linkable spontaneous anonymous group signature(MLSAG), stealth address and Petersen commitment. These algorithms are used in our blockchain to conceal the origin and destination addresses of a transaction and the transaction contents. The details can be seen in the Cryptonote protocol [16] and the Ring CT protocol [14].
MLSAG. Let pk N * M be a public key which presents a set of ring members. On input pk N * M , a secret key sk M and a message m ∈ {0, 1} * , it outputs a signature σ .
Stealth address. On input the receiver's real public key (pk A , pk B ) and a random number r, it outputs a one-time public address P.
Petersen commitment. On input the real transaction contents d and random data a, it outputs a commitment C.

B. TRACEABLE RING SIGNATURES
A traceable ring signature can reveal the identity of the real signer in a particular situation without any trusted party. A tag L = (issue, pk N ) is included in the traceable ring signature, where issue refers to an identity of some social issue and pk N is the public key set of the ring members. We donate the public key set as pk N = {pk 1 , . . . , pk n }. A traceable ring signature scheme contains the following four algorithms: Gen. On input a security parameter k ∈ N , it outputs a public/secret-key pair (pk, sk).
Sign. On input a message m ∈ {0, 1} * , a tag L = (issue, pk N ), and a secret key sk i , where i ∈ N , it outputs a signature σ .  Verify. On input a signature σ , a message m ∈ {0, 1} * , and a tag L = (issue, pk N ), it outputs one of the following strings: ''accept'' or ''reject''.
Trace. On input two message/signature pairs (m, σ ), (m , σ ) and a tag L = (issue, pk N ), it outputs the real signer's public key pk if the two signatures are generated by the same person, where pk ∈ pk N .

C. PROOF-OF-SPACE CONSENSUS MECHANISM
Spacemint [5] (proof-of-space) is a new type of consensus mechanism which is based on the storage capacity. It uses the disk space invested by the miners rather than the computing power to mine blocks. The size of the disk space is larger, the probability of successful mining is higher, vice versa.
The proof-of-space consensus mechanism is based on the fact to construct a structure map in a certain time. We first introduce the certification process of the proof-of-space. As shown in Figure 1, let G = (V , E) be a directed acyclic structure graph, where V = {v 1 , . . . , v N } is a node set, N is the number of the nodes, and E is a set of the directed edges. To further describe the relationship between each node and highlight the structure of the graph, the tag value is set for each node as follows: In equation (1), i represents the index number of a node, µ is a configurable random number, (l p 1 , l p 2 , . . . , l p t ) represents the forward nodes which direct to the current nodes as well as the label values of their parent nodes. In this way, each node and its parent node are linked by the tag value, and thus a directed acyclic graph based on the tag values is formed.
As shown in Figure 1, it takes a certain space to store the above structure diagram. It is easier for a user to store and recover the structure diagram if the storage space invested by the user is larger. In the case of insufficient space, space is reused to store related data, data is stored and deleted repeatedly, and time is exchanged for space. Therefore, when the time is limited, the miners with different spatial sizes have different storage capacities to store the graph with the same structure, and this results in the competition based on the storage capacity. The proof-of-space consensus mechanism was built under such a model. The structure of the blockchain which is based on the proof-of-space of consensus mechanism is shown in Figure 2. Each block i is divided into three sub-blocks: a proof subblock ϕ i , a signature sub-block σ i and a transaction subblock τ i .

• Proof sub-block
The proof sub-block ϕ i consists of the miner's signature ζ ϕ on the (i−1)th proof sub-block ϕ i−1 , a proof including the miner's public key pk and the current block's index i.
• Signature sub-block The signature sub-block σ i consists of the miner's signature ζ τ on the ith transaction sub-block τ i , the miner's signature ζ σ on the (i − 1)th transaction sub-block σ i−1 , and the current block's index i.

• Transaction sub-block
The transaction sub-block τ i consists of a list of transactions and the current block's index i.

D. COMPLEXITY ASSUMPTION
This section introduces the elliptic curve discrete logarithm problem (ECDLP) and its complexity assumption. Definition 1 (ECDLP): Let (P, Q) ∈ G q be a random instance, where Q = aP and a ∈ R Z * q . It is hard to compute a from P and Q through any polynomial-time bounded algorithm. Assume a polynomial time-bounded algorithm B can solve the ECDLP, then the probability can be defined as Adv ECDLP

III. THE PROPOSED LINKABLE DIGITAL MULTI-SIGNATURE
In this section, a new linkable digital multi-signature (LDMS) is proposed, which allows the users to delete data jointly by generating a multi-signature with their one-time addresses. The proposed LDMS scheme will be used in the following deletable blockchain.

A. THE PROPOSED LDMS SCHEME
Let {ID 1 , ID 2 , . . . , ID n } be the set of the signers and ID 1 be the signature collector who computes the final multisignature by collecting all the individual signatures from the entire group signers. The following polynomial timebounded algorithms describe the proposed LDMS scheme.
• Setup: Assume that H i (i = 0, 1, 2):{0, 1} * → {0, 1} k represent three distinct and secure one-way hash functions. Let F q be a prime filed over a k-bit prime q, and E/F q be the elliptic curve points on F q . Let G q be an additive elliptic curve group which is a subset of E/F q , and P be a generator of G q . The game publishes the system's parameter Each signer ID i chooses a number k i ∈ R Z * q as his real private key and computes K i = k i P as the corresponding real public key.
• Set-One-Time-Public/Private-Keys: Each signer ID i chooses x i ∈ R Z * q and y i ∈ R Z * q randomly from all of his one-time private keys, and the corresponding public keys can be computed as Finally, ID i sets his one-time private key as sk i = (x i , q i ), and sets his one-time public key as pk i = (X i , Y i ).
• LDMS-Sign: During the signing process, each signer ID i (1 ≤ i ≤ n) sets the one-time public key pk i = (X i , Y i ) as his pseudoidentity but keeps his real public key K i secret. Each signer ID i does the following operations to generate a multi-signature on the message m: 1) Selects a random number a i ∈ R Z * q and computes A i = a i P.

2) Broadcasts
and sends it to the signature collector ID 1 . 6) On receiving S i and S j (1 ≤ i, j ≤ n, i = j), ID 1 checks if the following equation holds.
If the equation (2) holds, ID 1 rejects S i and S j .
If not, ID 1 computes S 0 = i=1∼n S i and outputs the final multi-signature (A 0 , S 0 , L 0 ) on m.
• LDMS-Verify: The verifier does the following operations to verify the multi-signature (A 0 , S 0 , L 0 ) on m:

B. SECURITY ANALYSIS
Under the adaptive chosen message attack, we analyze the unforgeability of our LDMS scheme in the random oracle model [17] in this section. Under the ECDLP assumption, the proposed LDMS scheme is proved to be correct, linkable and secure against the adaptive chosen message attack through the following theorems. Theorem 1: The proposed LDMS scheme is proved to be correct and consistent.
Proof: Since we have Hence the theorem is proved. (2) holds.
Since we have If the equation (2) holds, it shows that the following equation holds, It is known that the equation (5) holds if and only if K i = K j , ID i = ID j , which means that S i and S j , the two individual signatures are generated from the same malicious user, and the malicious user forges the signature by choosing two different onetime addresses to generate a multi-signature in a short time. Proof: The security proof is based on the security model of [18]. The following game will be executed between an adversary A and a challenger C. In order to prove security of the LDMS scheme under the CMA, the adversary A VOLUME 8, 2020 and the challenger C play this game interactively. At the end of the game, assume the adversary A generates a valid signature σ * on a message m * corresponding to the signers ID * 1 , ID * 2 , . . . , ID * n . If the following conditions are satisfied, then we can say that A wins the Game.
1) The signature σ * is valid on the massage m * corresponding to the signers ID * 1 , ID * 2 , . . . , ID * n . 2) Let ID * j , j ∈ R {1, 2, . . . , n} be the honest signer, at least one of the cosigners is honest and it has never been queried by the oracle One-Time-Private-Keyqueries, Real-Private-Key-queries and Real-Public-Key-queries.
3) ID * j and X * j have never executed the LDMS-Sign query for the message m * .
Assume that the adversary A breaks our LDMS scheme, then we will prove that there is a polynomial time bounded challenger C can solve an instance of ECDLP. Assume aP, k j (aP) is a random instance of ECDLP, where k j ∈ R Z * q , and a is chosen randomly from Z * q by C . The challenger C sets the honest user ID j 's real public address as K j = k j (aP) and C tries to output k j from the random instance aP, k j (aP) . The challenger C works with the adversary A interactively by the following ways: According to the security parameter k, the challenger C sets the system's parameter set as ω = H i (i = 0, 1, 2), F q , E/F q , G q , P . Then ω will be sent to the adversary A by the challenger C. The three hash functions H 0 , H 1 and H 2 will be treated as random oracles. To avoid data inconsistency and response queries quickly, the challenger C creates five different initial-empty lists L 0 , L 1 , L 2 , L ID , L RID . Lists L i (i = 0, 1, 2) contains three different hash results during the process of H i (i = 0, 1, 2) queries, list L ID contains the one-time public/private key pairs and list L RID contains the real public/private key pairs. We donate the tuples included in the five lists as The adversary A interacts with the challenger C by asking the following queries: If the adversary A inquiries about the value of H i with an identity ID i , the challenger C consults the list L i and returns the corresponding hash value suppose that it has been queried before. If not, the challenger C chooses a number l i (h i /z i ) ∈ R Z * q and sends it to the adversary A. Then C inserts the tuples (l i , 0, 1, 2) respectively.
If the adversary A inquiries about the real private/public keys of the signer ID i , the challenger C refuses to reply if ID i = ID j holds. Else, the challenger C consults the tuple (k i , K i , ID i ) in the list L RID if this query has been asked before and outputs the real private/public keys (k i , K i ) to the adversary A. Otherwise, C chooses the number k i ∈ R Z * q , computes K i = k i (aP), and outputs the real private/public keys (k i , K i ) to the adversary A and inserts the tuple (k i , K i , ID i ) in the list L RID .

• One-Time-Private/Public-Key queries.
If the adversary A inquiries about the one-time private/public keys of the signer ID i , the challenger C responses under different conditions. If this query has been asked before, the challenger C consults the tuple (sk i , pk i , ID i ) in the list L ID and outputs the one-time private/public key (⊥, pk i ) to the adversary A if ID i = ID j holds, else, C outputs the one-time private/public key (sk i , pk i ) to the adversary A. If this query has never been asked before, C searches the tuple (k i , K i , ID i ) in the list L RID for the real public key K i , if the tuple is empty, C chooses the numbers If the adversary A asks for the signature on a message m of the signer ID i , the challenger C generates the signature under different conditions. If ID i = ID j holds, the challenger C picks random numbers S i , h i , z i ∈ R Z * q and L i ∈ G q , computes A i = −z i (Y i + L i ) − h i X i + S i (aP) and returns (A i , S i , L i ) as the signature to the adversary A. Else, the challenger C searches the tuple (k i , K i , ID i ) in the list L RID for the real public key K i , if the tuple is empty, C chooses a i , • Challenge phase.
The adversary A outputs a signature (A 0 , S 0 , L 0 ) with a hash value z corresponding to the signer ID i (1 ≤ i ≤ n) on a chosen message m. Suppose that there exists an honest signer ID j who has never been asked by the One-Time-Private-Key queries, Real-Private-Key queries and Real-Public-Key queries. According to the forking lemma [18], the challenger C is demanded to generate another valid signature (A 0 , S * 0 , L 0 ) on the same message m with a different hash value z * if the above queries are repeated. According to two forged signatures (A 0 , S 0 , L 0 ) and (A 0 , S * 0 , L 0 ), if both of them can be verified successfully, then we can write From the equation (6) and (7), we get From the equation (8), we can obtain From the equation (9), we can obtain From the equation (10), we can obtain Thus, C solves a random instance aP, k j (aP) of ECDLP that contradicts the complexity assumption of ECDLP.
In this game, it is supposed that the adversary A knows the one-time and real private keys of all signers except the honest signer ID j , and the adversary A only tries to breach the proposed LDMS scheme against the honest signer ID j . Suppose that the adversary A does not execute the queries for more than one time for the same input and asks for at most q H i times H i (i = 0, 1, 2) queries, q ok times One-Time-Private-Key queries and q l times LDMS-Sign queries. According to the work of [19], the probability that the adversary solves the ECDLP is ε ≥ 1 n 1 − q ok where ε is the probability of breaking the security of the proposed LDMS scheme.

IV. DELETING THE BLOCKCHAIN
After proposing a new multi-signature scheme, this section will introduce a deletable blockchain in detail. We donate the transaction as tx = (ID, d), where ID is a unique transaction ID number for each transaction, d is the concealed transaction contents, the real transaction contents are donated as d . The consensus mechanism used in our blockchain is proof-ofspace. In this section, we first describe how to propose a deletion request, and then give the details of the deletion protocol.

A. PROPOSING A DELETION REQUEST
In our proposed scheme, suppose that all of the transactions in a block are from the same transaction sender and we specify that only the sender of the transactions has the right to propose a deletion request. In an anonymous environment, in order to satisfy full transparency and accountability when deleting a block, we utilize different privacy-protected strategies according to different deletion reasons.
In Figure 3, we show a brief introduction to the process of proposing a deletion request. If a sender wishes to delete a block, he first classifies the deletion reasons. For the reason of an invalid identity, such as a failing company, the transaction sender can choose to reveal his worthless transaction identity. For the reason of expired transaction contents, such as abolished legal provisions, the transaction sender can choose to disclose the transaction contents. The details of the revelation process are shown as follows.

1) REVEALING THE SENDER'S REAL IDENTITY
If the transaction sender chooses to reveal his real identity, he needs to generate two traceable ring signatures [15] on the same tag L, where L is a tag used in the signing process. We donate the L as (ID, pk N ), where ID is the unique transaction ID number, pk N is the ring members in the traceable ring signature.
The specific process of revealing the identities is as follows: 1) As shown in Figure 4, each transaction sender needs to generate a traceable ring signature σ on (L, m) when the transaction is generated, where m is the hash value of the transaction contents d. We donate the signature σ as (A 1 , c N , z N ). The sender sets σ as a part of the transaction output and broadcasts σ to the network. Thus, we can extend the transaction as tx = (ID, d, σ ). 2) If the sender chooses to reveal his real identity, the transaction sender needs to generate another traceable ring signature σ on (L, m ), where m is another hash value of the transaction contents d. We donate the signature σ as A 1 , c N , z N . Then the sender broadcasts the deletion request r = (i, σ ) to the network, where i is the block's index number.  sponding public key pk i in the tuple TraceList. c) Output pk if it is the only element in TraceList, and the revealed identity is pk.

2) REVEALING THE TRANSACTION CONTENTS
If the transaction sender chooses to disclose the real transaction contents, it needs to make a hash-based Petersen commitment on the real transaction contents d . The process of revealing the transactions contents is shown as follows: 1) As shown in Figure 5, before the deletion operation, the transaction sender picks two random numbers r 1 and r 2 and computes the commitment C = h r 1 , r 2 , d , where h is a one-way hash function. Then the sender sets the commitment C and the random number r 1 as a part of the transaction output but keeps d and r 2 secret. Thus, we can extend the transaction as tx = (ID, d, σ, C, r 1 ). 2) If the sender chooses to disclose his real transaction contents d as the deletion evidence, it sets the deletion request as r = (i, d , r 2 ) and broadcasts r to the network, where i is the index number of the block.
3) The rest of the users calculate the hash value h r 1 , r 2 , d and compare the hash result with the commitment C received in step 1) to verify the validity of the real transaction contents d . If the equation (12) holds, the revealed transaction contents d is valid.

B. THE DELETION PROTOCOL DESCRIPTION
In this sub-section, we give the details of the deletion protocol. A deletion policy is introduced to determine whether a deletion operation should be accepted or not, and a valid deleted block is said to satisfy the policy, i.e. P(Chain, B * )=1, if the number of the multi-signature signers who come to an agreement to delete the block B * in the chain Chain is at least 2/3 N , and N is the number of the users in the chain. A block is deleted by the following steps: 1) On receiving a deletion request r i from the network, the rest of the users broadcast their vote results to the network according to the disclosed identity or transaction contents. If a user agrees on the deletion request, he sets his vote result as VoteDel = 1, else, he sets his vote result as VoteDel = 0.  The structure of the ith block after the deletion operation is shown in Figure 6. It can be seen from Figure 6 that after the deletion operation on the ith block, the hash relationship and the signature relationship between the previous block and the latter one are unchanged, and the transaction sub-block is replaced by the multi-signature LDMSig i . The rest of the block structure has never been changed. In this way, a large number of transactions are successfully released.
Our privacy-protected deletable blockchain protocol offers public verifications. To validate a deleted chain, the users first check each block exactly like in the underlying immutable blockchain. If an ''empty'' block is found, then the users check if the multi-signature is valid and check if the deleted block satisfies the deleting policy P(Chain, B * i ). Only if all of the verifications are successful, the deleted chain can be accepted.

C. SECURITY ANALYSIS
In this sub-section, we analyze security of the proposed privacy-protected deletable blockchain.

1) ONLY THE TRANSACTION SENDER CAN PROPOSE A DELETION REQUEST
In our proposed deletable blockchain, we suppose that all of the transactions in a block are from the same transaction sender. Due to the anonymity of the transaction contents and the addresses of both parties in one transaction, anyone except the transaction sender cannot see the real transaction contents or the real identities of both parties, the unrelated users cannot determine whether a transaction can be deleted or not. Therefore, only the sender of the transactions can reveal his real identity or disclose the real transaction contents, thus, only the sender has the absolute right to propose a deletion request and the rest of the users have no right to propose a deletion request.

2) THE PROCESS OF REVEALING THE IDENTITIES
The real transaction contents and the identity of the receiver are still concealed if the transaction sender chooses to reveal his real identity. Even if the identity of the transaction sender is exposed to the network, the receiver's identity and the transaction contents are still private to everyone. In this way, our scheme can ensure that the user's private information is protected to the greatest extent.

3) THE PROCESS OF REVEALING THE TRANSACTIONS
The identities of the transaction sender and the receiver are still concealed if the transaction sender chooses to disclose the real transaction contents. Even if the real transaction contents are exposed to the network, the identities of the transaction receiver and sender cannot be known to anybody. What's more, the secure and efficient Petersen commitment scheme used in sub-section A satisfies the following two security properties: • Message hiding property. The hash value h r 1 , r 2 , d and the random number r 1 are the commitment evidences of the transaction sender to the whole network.
In the first step, the transaction sender uses the hash function and the random numbers to prevent any malicious user in the blockchain from inverting the function to obtain the concealed message (the real transaction contents d ), that is, the one-way hash function ensures the concealment.
• Message binding property. The collision-free performance of hash function ensures that the transaction sender cannot find another data d * and a random number r 2 that satisfy the equation h r 1 , r 2 , d = h r 1 , r 2 , d * . In this way, the transaction sender cannot deceive anybody, and everyone can ensure that the transaction sender has indeed revealed the real transaction contents d .

4) TWO INVALID SUB-SIGNATURES GENERATED BY THE SAME USER CAN BE LINKED
In our privacy-protected blockchain system, the users use the one-time addresses to generate a linkable multi-signature during the deleting process. They use the one-time addresses as their pseudonyms to protect their identity privacy. As shown in equation (5), if a malicious user generates two subsignatures by using two different one-time addresses to satisfy the deletion policy P(Chain, B * ) in a short time, the designated collector ID 1 can link the two invalid subsignatures and rejects them.

V. EXPERIMENTS
We conduct several experiments to evaluate the efficiency of our proposed privacy-protected blockchain system. We invoke the functions in TomMath library [20] to manipulate big integer numbers. SHA-256 and DSA-512 are used when the blockchain is generated and ECC-200 is used to implement elliptic curve groups. The programs are written in C++ language with the following specifications: • 8GB of RAM • Intel(R) Core (TM) i7-5500U CPU @2.40GHz • Windows 10 • Visual Studio Ultimate 2013 VOLUME 8, 2020 The signature sub-block σ i = {i, ζ τ , ζ σ } records the index number i and two signatures ζ τ and ζ σ , where ζ τ = ''2AE9566BCB22A8F5582204B38EC528DBA58E78C5 A0'' is the DSA signature on the transaction sub-block τ 35 of the 35th block, and ζ σ is the DSA signature on the signature sub-block of the 34th block.
The transaction sub-block τ i = {i, ctx} records the index number i and 100 transactions tx.

C. DELETING TRANSACTIONS
Assume that the transactions of the 34th block are overdue, in order to save the storage space, the sender of the transactions reveals his own identity, generates a traceable ring signature σ and broadcasts the deletion request r = (i, σ ) to the network.
The rest of the users check the relationship between the two traceable ring signatures (σ, σ ) and trace the sender's real public address pk, the revealed public address is shown as follows: pk = 62FE1DF891F6C9EBB8675520483953209615B05 36C0D81642434202C60F7A2A6E757CF78EC52A058BE8 650B5AD8F03D5A19.
Assume that the rest of the users in the blockchain system come to a deletion agreement on October 2, 2019. According to the deletion reason pk, the deletion time ''20191002'', the index number i = ''34'', and the signature ζ τ = ''750A7DFB41A85C41DA313F14F90F85F1AF92F425'' of the 34th transaction sub-block, they generate a deletion message m, where m is shown as follows: m = 62FE1DF891F6C9EBB8675520483953209615B053 6C0D81642434202C60F7A2A6E757CF78EC52A058BE86 50B5AD8F03D5A192019100234750A7DFB41A85C41DA 313F14F90F85F1AF92F425.
Finally, these users generate an LDMS multi-signature (A 0 , S 0 , L 0 ) on the deletion message m. The results of the LDMS multi-signature is: A 0 = ED34368C12E34D4DDE4B44AF98A09DEFD840 A2094F8A5C01.
After the deletion operation, the deletion performers broadcast a new block B * that contains (A 0 , S 0 , L 0 ) in the transaction sub-block instead of the original 100 transactions to the network. All the users in the network verify the multisignature (A 0 , S 0 , L 0 ), compare the signature ζ τ included in the deletion message m with the signature ζ τ included in the signature sub-block and calculate the deletion policy P(Chain, B * ). If all of the verifications are successful, the verifier replaces the original block with the new block B * in their local chain. The new block structure is shown in Figure 9.  Finally, we give the time consumption of generating and deleting a block, and the time consumption is shown in Table 2. It can be shown that the average time of generating a block is 1740ms, and the average time of deleting a block is 3556ms. The average time of deleting a block is about twice the time of generating a block. The deletion operation does not require excessive computational resources and it shows the efficiency and feasibility of our proposed scheme.

VI. CONCLUSION
This paper proposes a privacy-protected deletable blockchain. In order to satisfy full transparency and accountability in an anonymous environment, we use a traceable ring signature to reveal the real identity of the transaction sender and use a Petersen commitment scheme to disclose the real transaction contents. Our proposed scheme guarantees that the users' privacy is protected to the greatest extent when some worthless information is revealed. During the deletion process, we propose a linkable multi-signature which allows the users to generate a signature by using their one-time addresses as pseudonyms to protect their identity privacy. If a malicious user wants to use two or more one-time addresses in a signing process, the sub-signatures generated by the same malicious user will be linked and rejected. Our proposed scheme does not need heavy cryptographic tools or any trusted party, and we have achieved a fully privacy-protected deletable blockchain.