1. Introduction

An important issue in the current financial sector is blockchain technology, which is based on fintech, i.e. finance and IT (Information Technology) combined [1]. In blockchain technology, all members have the same information linked in a chain form, which prevents data tampering [2]. 

Conventional centralized financial systems determine the ownership rights for property using ledgers that are managed by trusted third parties. However, a large amount of social capital must be expended to establish, maintain, and guarantee the reliability of the trusted third party. As such, blockchain-style financial systems have garnered interest. These systems have the advantage of not requiring a trusted third party because all users record and manage the ledger [1]. 

However, security problems exist when using blockchain technology in the financial sector. An advantage of blockchain is security; however, this is different from the security that is required by the financial sector. Blockchain security aims to disable the falsification of past transaction data or disable double payments; however, in the financial sector, security implies that current users’ property is not hacked. Therefore, the high security of the blockchain approach is not suitable for the security required by the financial sector [3]. In actual attacks on blockchain-based cryptocurrency, the main attack targets are currency exchanges and wallets rather than past transactions [4]. 

Recent studies have reported that the private keys of transaction principals can be leaked via signature values used in major cryptocurrency bitcoins [5][6]. This threat is due to the blockchain’s property of sharing transaction information and transaction signature values, and it can occur regardless of the security strength provided by the blockchain. However, because the property is owned by the owner of the private key and not the user, an attacker can steal the property if the user’s private key is leaked. 

In this study, scenarios in which private keys can be recovered are applied to prove that users’ private keys can be recovered in an actual bitcoin environment. In Section 2, centralized and blockchain financial systems are compared and the operating principles of ECDSA (Elliptic Curve Digital Signature Algorithm), bitcoin signatures, and previous studies are discussed. Additional threats that are not discussed in previous studies are analyzed in Section 3. Duplicated signatures that are determined by blockchain platform users are defined in Section 4. Additionally, two scenarios in which duplicated signatures are generated and users’ private keys are recovered are proposed. In Section 5, the two proposed scenarios are used to demonstrate the process of recovering actual bitcoin private keys, and Chapter 6 presents the conclusions of this paper.

2. Related Work

2.1 Digital Signature

Digital signatures are used to secure electronic transactions as attached values to guarantee the data source, integrity, and non-repudiation. Fig. 1 shows the operation of a digital signature. To view the message, the receiver decrypts the signature and then recalculates the hash value. If the hash value matches, the authenticity of the message and the sender are proven. The integrity of the message can be confirmed through the hash function, which produces different results if the text has been changed if even slightly. The sender can be confirmed because only the correct sender can generate a signature with the correct private key [7].

Fig. 1. Operation of Digital Signature

2.2 ECDSA

ECDSA is an implementation of the DSA (the National Institute of Standards and Technology’s signature algorithm) on an elliptic curve. The elliptic curve and domain parameters for ECC calculations were predefined. In an ECDSA, a mathematically related private and public key pair are used to generate and verify the digital signature [8]. This section describes the process of generating and verifying ECDSA signatures. 

2.2.1 Generating ECDSA Signature

The signer’s public key Q is calculated as Q = dG through a private key d and a generator G. Based on the discrete logarithm problem, d cannot be obtained from G and Q. Shown below is the process of using a private key to sign a message in an ECDSA [9]. If the message is signed, the signature pair (r, s) is generated. 

① Select a nonce: k (1 ≤ k ≤ n − 1) 

② (x₁, y₁) = kG

③ r = x₁ mod n

④ e = SHA256(message) 

⑤ s = k^-1(e + dr)mod n

Result: Signature (r, s)

2.2.2 Verifying ECDSA Signature

Shown below is the process of using a public key to verify the validity of a signature [9]. Ultimately, if ‘r’ and ‘t’ are the same, the message can be confirmed as signed with a private key that is mathematically related to the public key. 

① e = SHA256(message) 

② a = s^-1e mod n

③ b = s^-1r mod n

④ (x₂, y₂) = aG + bQ 

⑤ t = x₂ mod n 

Result: if ‘t’ is equal to ‘r’, verification is successful

2.3 Additional Cryptographic Algorithms

Supplementary cryptological algorithms used for the ECDSA include a nonce generation algorithm and a hash function. 

Nonce is important in cryptography for a variety of security applications, and nonce generation requires randomness and unpredictability [10]. Table 1 shows the randomness and unpredictability required for nonce generation. 

Table 1. Requirements for Nonce Generation

The hash function receives a message of random length as input and produces a hash value of a fixed length. The hash function serves to generate unchangeable proof values for the message to provide integrity such that it message errors or falsifications can be detected. When long messages are signed, a short hash value is calculated for the entire message, and this value is signed. For the hash function to be secure, it must be difficult to find collisions [11]. Table 2 shows the strength of the SHA-256 used in bitcoin. 

Table 2. Strength of SHA-256

2.4 Bitcoin

Bitcoin is a system designed such that users can trust each other without a trusted third party, and it was proposed in 2009 by Satoshi Nakamoto [14]. Because all members have the same ledger, tampering is not possible. When new transactions occur, new blocks are connected to the existing ledger block in the form of a chain [2]. Because bitcoin is an electronic currency that only moves between transaction parties, it does not require a trusted party, and P2P networks are used to prevent double payments. Furthermore, the anonymity of members can be ensured by maintaining the anonymity of the public keys [14]. As of June 9, 2019, bitcoin contains 579,952 blocks in its chain [15]. All of the block data included in bitcoin can be synchronized with the bitcoin core [16]. 

The header of a bitcoin block contains a magic number that distinguishes the block, block size, block version, previous block’s hash, current block’s hash, time of block creation, target that shows the block creation level of difficulty, and the nonce for proof-of-work. Furthermore, the number of transactions and the transaction data are included after the header. Table 3 shows the structure of a bitcoin block [17]. 

Table 3. Structure of Bitcoin Block

Bitcoin transactions comprises the transaction’s version, input, and output. The input includes the input number, previous transaction’s hash, previous output’s index, scriptSig length, the scriptSig that contains the signature data, and a 4-byte sequence. The output includes the output number, the value that is the coin amount in Satoshi units, scriptPubKey length, scriptPubKey that contains the sender’s public key hash data, and locktime at which the transaction was created. Table 4 shows the structure of a bitcoin transaction [17]. 

Table 4. Structure of Bitcoin Transaction

2.5 Nonce Reusing Problems

Nicolas T. Courtois et al. [5] analyzed a problem in which ECDSA private keys can be recovered when nonces that have already been used by bitcoin are reused. When previously used nonces are used, the same r value of signature is generated without regard to the signer’s private key and message (Order 1–3 in Section 2.2.1). Because the nonces that were used in the signatures can be found, private key recovery attacks can be performed via the nonces used in the signatures. The Courtois study classified three types of private key recovery attacks that can occur according to the number of reused nonces and the number of users. Shown below are descriptions of the classified attacks. 

• Attack on ECDSA with Bad RNG 

When two users use the same nonce, the two users can calculate each other’s private keys. 

• Bad RNG ECDSA Same User Attack 

When one user uses the same nonce two or more times, anyone can calculate the user’s private key. 

• Attack with Two Bad Random Events 

When two users each use two of the same nonces, anyone can calculate the two users’ private keys. 

2.6 Occurrences of Same Signatures on Bitcoin

Michael Brengel et al. [6] proposed a specific recovery process for private key recovery attacks that are classified according to the study by Nicolas T. Courtois et al. [5]. In the study, data in which the same r value of signature occurred are presented. Table 5 shows some of the r values that were used two or more times and the number of occurrences, as reported in the paper. 

Table 5. Five Most Frequent Occurrences of R Values

Shown below are two situations in which an attack can recover a user’s private key as well as the recovery processes, as reported by Michael Brengel et al. [6]. Private key recovery is accomplished by modifying the formula for the signature value as in Order 5 of Section 2.2.1. 

2.6.1 Bad RNG ECDSA Same User Attack

When User A uses the same key two or more times, the attacker can calculate the user’s private key. Shown below are the processes of signature generation, in which one user uses the same nonce, and the attacker’s private key recovery process.

Step 1. User A uses nonce k to generate two signatures 

s₁ = k^-1(e₁ + rd_A) mod n, s₂ =  k^-1(e₂ + rd_A) mod n

Step 2. Two formulas are established for k

s₁s₂k = s₂(e₁ + rd_A) mod n, s₁s₂k = s₁(e₂ + rd_A) mod n

Step 3. The first formula in Step 2 is subtracted from the second 

s₂(e₁ + rd_A) - s₁(e₂ + rd_A) = 0 mod n, then r(s₁-s₂)d_A = s₂e₁ - s₁e₂ mod n

Step 4. Step 3’s formula is established for d_A and calculated

d_A = (s₂e₁ - s₁e₂ ) [r(s₁ - s₂)]^-1

2.6.2 Attack with Two Bad Random Events

When two users each use two nonces one or more times, the attacker can calculate the two users’ private keys. Shown below are the processes of signature generation, in which the two users use the two nonces one time or more, and the attacker’s private key recovery process. The process below shows the steps by which one user’s private key is recovered. The other user’s private key is recovered by the same process.

Step 1. User A uses nonces k₁ and k₂ to generate two signatures

s_1,A = k₁^-1(e_1,A + r₁d_A) mod n, s_2,A = k₂^-1(e_2,A + r₂d_A) mod n

Step 2. User B uses nonces 𝑘𝑘1 and 𝑘𝑘2 to generate two signatures

s_1,B = k₁^-1(e_1,B + r₁d_B) mod n, s_2,B = k₂^-1(e_2,B + r₂d_B) mod n

Step 3. The four formulas used in Steps 1 and 2 are established for k₁ and k₂

k₁ = (e_1,A + r₁d_A)s_1,A^-1 mod n, k₁ = (e_1,B + r₁d_B)s_1,B^-1 mod n

k₂ = (e_2,A + r₂d_A)s_2,A^-1 mod n, k₂ = (e_2,B + r₂d_B)s_2,B^-1 mod n

Step 4. The two formulas in Step 3 are established for d_B

d_B = ((e_1,A + r₁d_A)s_1,A^-1s_1,B - e_1,B) r₁^-1 mod n

d_B = ((e_2,A + r₂d_A)s_2,A^-1s_2,B - e_2,B) r₂^-1 mod n

Step 5. The second formula in Step 4 is subtracted from the first formula

(r₂s_1,Bs_2,Ae_1,A + r₁r₂s_1,Bs_2,Ad_A - r₂s_1,As_2,Ae_1,B ) -  (r₁s_1,As_2,Be_2,A + r₁r₂s_1,As_2,Bd_{A -} r₁s_1,As_2,Ae_2,B ) = mod n

Step 6. The formula in Step 5 is established for d_A and calculated

(s_1,As_2,B - s_1,Bs_2,A)r₁r₂d_A = (r₂s_2,As_1,Be_1,A - r₂s_2,Ae_1,B - r₁s_1,As_2,Be_2,A + r₁s_1,Ae_2,B) = mod n

d_A = [r₁s_1,A(e_2,B - s_2,Be_2,A) - r₂s_2,A(e_1,B - s_1,Be_1,A)]r₁r₂(s_1,As_2,B - s_1,Bs_2,A)]^-1 mod n

The study reported that the same r values of signatures can occur not only in cases where the same nonce was reused, but also in cases in which the used nonces have a complementary relationship with previously used nonces. Owing to the properties of the elliptic curve, when nonces k and -k (inverse of addition for n) are used in Order 1-2 of Section 2.2.1, kG = (x₁, y₁) and −kG = (x₁, −y₁). This yields the same r value of signature in Order 3 of Section 2.2.1.

3. Analyses of Inverse Nonce Problems

Michael Brengel et al. [6] proposed that the same r values of signatures occur because the same nonces are used and nonces that complement each other are used. The study analyzed the private key recovery process that can occur when the same nonce is used. Therefore, the private key recovery process that can occur when using nonces that complement each other is analyzed in this section. 

When the same nonces are used, two or more formulas are subtracted from the signature values during private key recovery. However, when two nonces that complement each other are used, the formulas are added during private key recovery. 

3.1 Inverse RNG ECDSA Same User Attack

In this threat, the private key recovery for when the user uses the same nonces, as mentioned in Section 2.7.1, is changed into a private key recovery for when the user uses nonces that complement each other. Fig. 2 shows the private key recovery process when the duplicate nonce k that was used in Section 2.7.1 is changed to k₁, −k₁. 

Fig. 2. Processes of Inverse RNG ECDSA Same User Attack

Step 1. User A uses nonces k₁ and −k₁ to generate two signatures 

Step 2. The two transactions’ messages and signatures are collected from the bitcoin block 

Step 3. User A’s private key is calculated from the collected data

3.2 Attack with Two Inverse Random Events

In this threat, the private key recovery for when two users have reused two nonces, as mentioned in Section 2.7.2, is changed into the private key recovery for when nonces that complement each other are used. When User A has used nonces k₁ and k₂ and User B uses one pair from among (k₁, −k₂), (−k₁, k₂), and (−k₁, −k₂), private key recovery is possible. Fig. 3 shows the private key recovery when User A uses nonces k₁ and k₂ and User B uses (−k₁, −k₂). 

Fig. 3. Processes of Attack with Two Inverse Random Events

Step 1. User A uses nonces (k₁, k₂) to generate two signatures 

Step 2. User B uses nonces (−k₁, −k₂) to generate two signatures 

Step 3. The two transactions’ messages and signatures are collected from the bitcoin block 

Step 4. The private keys of Users A and B are calculated from the collected data

Table 6 shows the threats by which anyone can recover a user’s private key through a bad/inverse RNG. 

Table 6. Four Recovery Attacks with Bad/Inverse RNG

4. Proposed Private Key Recovery Scenarios

The threat of private key recovery can occur because the blockchain shares all transaction information. Therefore, in this section, duplicated signatures that can be used in private key recovery threats is defined, and scenarios in which private keys can be recovered because of duplicated signatures are proposed. 

4.1 Definition of Duplicated Signatures

Duplicated signatures are r values of signatures for which anyone can find the nonce that was used to generate a bitcoin transaction’s signature. As described in Section 2.2, nonces that are used in signature generation are kept secure based on the discrete logarithm problem. However, if a case belongs to one of the attack types in Table 6, anyone can obtain the nonce that corresponds to the r value of signature, thus resulting in duplicated signatures. Therefore, duplicated signatures are not selected beforehand but depend on the user that is using the blockchain. Moreover, as the number of signatures that are used in bitcoin increases, the number of duplicated signatures can increase. 

4.2 Recovery Scenarios with Duplicated Signatures

Cases in which private keys can be recovered through duplicated signatures are divided into cases of generating duplicated signatures and cases of using duplicated signatures. These two cases are explained below. 

4.2.1 Recovery of Private Key Generating Duplicated Signatures

Fig. 4 shows cases in which a user’s private key can be recovered when the user uses a duplicated nonce or nonces that complement each other, as in the attack types shown in Table 6. Furthermore, the r value of signature used by the user is a duplicated signature. Figs. 2 and 3 show the recovery of user’s nonces and private keys that belong to these attack types.

Fig. 4. Cases of Generating Duplicated Signatures

4.2.2 Recovery of Private Key Using Duplicated Signatures

Fig. 5 shows the private key recovery of users who use duplicated signatures. The first step is to verify whether the signature that was generated by the user is one of the duplicated signatures that were generated by the attack types in Table 6. If the signature is one of the duplicated signatures, the nonce that was used to generate the signature can be calculated, and the nonce can be used to recover the user’s private key. Because two nonces can generate one signature value, two private keys and two public keys are generated with the nonces. Therefore, the two generated public keys and the user’s actual public key can be compared to determine the user’s actual private key. Shown below is a description of the private key recovery from Fig. 5. 

Fig. 5. Cases of Using Duplicated Signatures

Step 1. New public keys Q₁ and Q₂ are generated from the two recovered private keys d₁ and d₂ 

Step 2. The generated public keys Q₁ and Q₂ are compared to the user’s public key to determine the user’s private key

Even if a signature is not a duplicated signature when it is generated, the user’s private key can be recovered if the r value of signature becomes a duplicated signature. Furthermore, recovery of private keys that generate duplicated signatures can only occur if the user generates two or more signatures, but recovery of private keys that use duplicated signatures can occur even if the user generates only one signature. 

5. Bitcoin Private Key Recovery

The actual private key recovery by applying the proposed private key recovery scenario is described in this section. The process of synchronizing bitcoin block data via the bitcoin core and the recovery of users’ private keys from synchronized block data are described. Table 7 details the environment in which this study was performed.

Table 7. Analysis Environment

5.1 Collecting Data from Bitcoin 

This section includes the processes of synchronizing bitcoin blocks and extracting message and signature values from synchronized block data. 

5.1.1 Synchronizing Block Data of Bitcoin

In this study, the bitcoin core was used to participate in bitcoin and synchronize the entire bitcoin block data, as shown in Fig. 6. The synchronized block data was saved as a file named “blkxxxxx.dat”. It was synchronized up to the 481,614th chain included in the block on August 22, 2017, and the total size of the synchronized data was approximately 121 GB.

Fig. 6. Synchronizing Block Data with Bitcoin Core

Fig. 7 shows a part of the “blk00974.dat” file that has more than 130 block data including the 481,614th block. The total size of the 481,614th block is 999,263 (0xF3F5F) bytes, and it includes data on 1,652 (0x674) transactions.

Fig. 7. A Part of ‘blk00974.dat’

Fig. 8 shows the blocks and signature data that are stored in each “blkxxxxx.dat” file. During signature value extraction, the entire data file must be divided into blocks, each block into transactions, and each transaction into an input and output. The ultimately divided inputs include signature values and public keys, and the outputs include the public keys’ hash values. Therefore, each transaction is a message, and the input can be analyzed to extract the signature value and public key.

Fig. 8. Structure of Bitcoin Block Data

The process of extracting messages from the block data can be divided into two types according to the number of inputs included in the transaction. The left side of Fig. 9 shows the case of a single input. An area in the input script contains the signature value, but it must be filled with a different value because the message is from before the signature has been performed. Therefore, the area is filled as shown below. All of the outputs are combined, as shown in the figure, and the message is used. 

Script Length: 0x19 

Script: 0x76A914 || RIPEMD160[SHA256(sender’s pubkey)] || 0x88AC 

Fig. 9. Structure of Bitcoin Transaction Message

The right side of Fig. 9 shows a case with two inputs. Therefore, two messages must exist, and the messages are organized as shown below. The ‘0x00’ in the length means a value of size 1 byte, and ‘–’ means no value. 

• i-st Message 

Input #i’s Script Length: 0x19 

Input #i’s Script: 0x76A914 || RIPEMD160[SHA256(sender’s pubkey)] || 0x88AC

Others’ Script Length: 0x00 

Others’ Script: - 

Transactions that have two or more inputs contain a message that is similar to that above, and all outputs are added after the input, as in the case of a single input.

5.1.3 Extracting Signatures from Block Data

To collect signature values from the block data, the bitcoin Wiki and the bitcoin API were referenced to write the data collecting source code. The source code consists of “main,” “divide_blocks,” “divide_transactions,” and “extract_sign” functions. Shown below is a summary of the source code’s structure and roles. The “main” function, shown in Table 8, extracts the signature values of all “blkxxxxx.dat” files. Namely, each file is read and transferred to the extraction function, and this process is repeated. By executing this function, all signature values and public keys are extracted. 

Table 8. Pseudo Code of “main”

The “divide_blocks” function in Table 9 divides all the blocks stored in a single file. In this process, a magic number is used to find the beginning of a block, and the block’s size is used to find the end of the block. By executing this function, all the divided blocks in the file are returned. 

Table 9. Pseudo Code of “divide_blocks”

The “divide_transactions” function in Table 10 takes a block array and extracts the scripSig from the transaction input included in each block. Data are not extracted from the output, but the size of the output must be calculated to divide the transactions. By passing the scriptSig through the “extract_sign” function, the signature value (r, s) and public key are divided. By executing this function, a set of the signature value (r, s) and public key is returned.

Table 10. Pseudo Code of “divide_transactions”

The “extract_sign” function in Table 11 extracts the signature value and public key from the scriptSig. By executing this function, a set that adds the signature value (r, s) and public key to the sign set that was received as input is returned. 

Table 11. Pseudo Code of “extract_sign”

5.2 Private Key Recovery with Proposed Scenarios

The proposed scenario is applied to the data from bitcoin’s first block to its 481,614th block, which was included in the chain on August 22, 2017, to demonstrate the user private key recovery. Among the 515,429,782 r values of signatures collected from the block data, 1,231 r values of signatures were used two or more times, and Table 12 shows some of them.

Table 12. Five Most Frequent R Values in Block Data

Table 13 shows a list and the description of parameters used in the bitcoin user private key recovery presented in the following sections. 

Table 13. Description of Parameters for Private Key Recovery

5.2.1 Recovery of Private Key Generating Duplicated Signatures 

Regarding the use of r values of signatures that have been used two or more times to recover private keys and signature values, the cases were divided according to the four attack types shown in Table 6, and private key recovery formulas were calculated according to the type. Data analysis demonstrated that duplicated signatures belonged to the first type. Therefore, the actual private key recovery is shown via the private key recovery formula from Section 2.7.1. Tables 14 and 15 show two signatures of users who have generated duplicated signatures; as shown, the public keys and r values of signatures are the same.

Table 14. 1st Signature Values Generating Duplicated Signatures

Table 15. 2nd Signature Values Generating Duplicated Signatures

Table 16 shows the recovery of private keys and nonces of users who have generated duplicated signatures via the data in Tables 14 and 15. To confirm that the recovered private key (d’) matches the user’s actual private key, a new public key (Q_x’, Q_y’) was generated. Because the newly generated value matches that of the public key (Q_x,Q_y) in Table 14, the recovered private key is the same as the user’s actual private key. To confirm that the recovered nonce (k’) is the nonce used in the actual signature, a new signature value (r’) was generated. Because the newly generated value matches the r signature value in Table 14, the recovered nonce is the same as the nonce used in the actual signature.

Table 16. Recovery of Private Key Generating Duplicated Signatures

In the analyzed block data, 1,194 private keys generated duplicated signatures, and these private keys can be recovered from the block data by attackers. 

5.2.2 Recovery of Private Key Using Duplicated Signatures

The analysis of the bitcoin block data indicated cases where duplicated signatures were used in addition to cases where duplicated signatures were generated. Table 17 shows the user transaction data for which the signature value was generated only once. Although the user generated the signature value only once, the r value of signature is the same as those of the duplicated signatures shown in Table 14, 15. 

Table 17. Parameters of Signatures Using Duplicated Signatures

The nonce that corresponds to the r value of signature in Table 17 can be found, and this is presented in Table 18. Therefore, an attacker can use the nonce to find the user’s private key. 

Table 18. Example of Signature and Corresponding Nonce

Table 19 shows the recovery of a user’s private key using a nonce that corresponds to the duplicated signature shown in Table 18. ‘k’ and ‘-k’ are the nonces that can generate the same value as the r value of signature in Table 18, and the private keys are calculated for both cases. The public keys (Q¹, Q²) calculated from the two private keys (d₁,d₂) are compared to the user’s actual public key (Q) in Table 17 to determine the private key. A comparison between the two public keys (Q¹, Q²) and the user’s actual public key demonstrates that 𝑑₁ is the user’s actual private key. 

Table 19. Recovery of Private Key Using Duplicated Signatures

An analysis of the block data indicated that 621 private keys used duplicated signatures. These private keys can be recovered from the block data by attackers.

Table 20 shows the number of private keys that generated or used duplicated signatures, and the number of private keys that could be recovered from the analyzed block data; 239,039,487 private keys were used in the block data that was analyzed in this study; 1,815 private keys could be recovered owing to the generation and use of duplicated signatures. 

Table 20. The # of Recoverable Private Key

5.2.3 Possible Recovery of Private Key with Duplicated Signatures

All duplicated signatures in bitcoin block data were generated by reusing same nonce. However, someone may use complementary nonce to create digital signature and it can result duplicated signatures. Table 21 shows an artificial transaction data for which the signature value was generated with complementary nonce shown in Table 18. 

Table 21. Parameters of Signatures with Complementary Nonce

Table 22 shows the recovery of a user’s private key with nonce. ‘k’ and ‘-k’ are the nonces that can generate the same value as the r value of signature in Table 18, and the private keys are calculated for both cases. The public keys (Q¹, Q²) calculated from the two private keys (d₁,d₂) are compared to the user’s actual public key (Q) in Table 21 to determine the private key. A comparison between the two public keys (Q¹, Q²) and the user’s actual public key demonstrates that d₂ is the user’s actual private key.

Table 22. Recovery of Private Key with Duplicated Signatures

6. Conclusion

A user private key recovery scenario that could occur because of the characteristics of blockchain systems where all transaction information is shared was presented herein. It demonstrated the possibility of recovering private keys in an actual bitcoin environment. The analysis of the actual bitcoin environment showed that 1,815 among 239,039,487 private keys could be recovered. As bitcoin usage increases, a larger number of private keys could be recovered from the overall block data. Because the blockchain grants property ownership rights to the private key owner, private key leaks can result in property theft. Therefore, to provide secure and efficient blockchain systems to the financial sector, continued research on the prevention of private key recovery threats is necessitated.

Acknowledgment

This research was supported by the MSIT(Ministry of Science and ICT), Korea, under the ITRC(Information Technology Research Center) support program (IITP-2019-2016-0-00304) supervised by the IITP(Institute for Information & communications Technology Planning & Evaluation)