JP5858506B1 - Virtual currency management program and virtual currency management method - Google Patents

Abstract

The present invention provides a virtual currency management program and a virtual currency management method that allow a virtual currency used before the update to be continuously used even after the key pair is updated. Means for storing mapping information indicating a correspondence relationship between a user identifier and a user public key, including a first user identifier in a first transaction in which a virtual currency is transferred to the first user The first public information and the first electronic signature of the first user in the second transaction in which the first user remits at least a part of the first transaction information and the amount remitted by the first transaction And the first public key included in the second transaction information is associated with the identifier of the first user included in the first transaction information in the mapping information. Based on whether the first electronic signature included in the second transaction information can be verified with the first public key included in the second transaction information. Means for verifying validity. [Selection] Figure 7

Description

  The present invention relates to a virtual currency management program, a virtual currency management method, and the like.

In recent years, not only transactions of goods using real money such as yen and dollars but also business transactions using virtual currency such as electronic money have been carried out. Non-Patent Document 1 discloses a technique for performing a transaction using a virtual currency called bitcoin.
In the transaction using Bitcoin, the integrity of the transaction data is secured using a hash function and a public key cryptosystem. Transactions performed using encryption (hereinafter, bitcoin transactions are also referred to as “transactions”) are distributed by broadcast to all terminals using bitcoins. The delivered transaction is verified by terminal software called a miner (excavator), compiled into excavated blocks, recorded in a ledger called blockchain, and confirmed by other miners Approved by

  Non-Patent Document 1 discloses a method for identifying the owner of a bit coin using a public key. According to the method described in Non-Patent Document 1, when the current owner of the coin pays the coin to the opponent, the current coin (data of the coin addressed to him) and the data of the opponent's public key are combined. On the other hand, a hash function is applied, and a signature is applied using its own secret key. The recipient of the coin verifies the signature using the public key of the coin recipient in the previous transaction, and recalculates the hash value, so that the coin is delivered to himself / herself from the rightful owner. Can be confirmed.

By Kengo Saito, “Bitcoin I understand now [Conditions for Surviving Currency]”, first edition, Taro Jiro Editors, May 5, 2014, p. 92

  In the case of the method described in Non-Patent Document 1, in the Bitcoin system, the user is identified by the public key and proves that it is the coin owner by the private key. Therefore, for example, if the user loses the secret key, the user cannot prove that the user is the same user as the user before the key is lost. As a result, the user cannot use the coins that have been owned so far.

  Therefore, in view of the above circumstances, the present invention provides a virtual currency management program and a virtual currency management method for making it possible to continuously use a virtual currency that has been used before the update even after the key pair is updated. It is intended to do.

  The virtual currency management program according to the present invention is a first transaction in which a computer stores storage information for storing mapping information indicating a correspondence relationship between a user identifier and a public key of the user, and remits the virtual currency to the first user. In the second transaction in which the first user remits at least part of the first transaction information including the identifier of the first user and the amount remitted by the first transaction. The storage means for storing the first public key and the second transaction information including the first electronic signature, and the first public key included in the second transaction information are included in the first transaction information in the mapping information. Whether or not the first electronic signature included in the second transaction information can be verified with the first public key included in the second transaction information, whether or not it is associated with the identifier of the first user included Based on whether or not Including those which function as a verification means for verifying the validity of the second transaction.

  The virtual currency management method according to the present invention includes a step in which a computer stores mapping information indicating a correspondence relationship between a user identifier and the public key of the user, and a first remittance of the virtual currency to the first user. The first user in the second transaction in which the first user remits at least a part of the first transaction information including the identifier of the first user in the transaction and the amount repaid by the first transaction Storing the first public key and the second transaction information including the first electronic signature, and the first public key included in the second transaction information is the first transaction information in the mapping information. The first electronic signature included in the second transaction information can be verified with the first public key included in the second transaction information. Based on whether or not Including how to perform the steps of verifying the validity of the second transaction, the.

  The program of the present invention can be installed or loaded on a computer through various recording media such as an optical disk such as a CD-ROM, a magnetic disk, or a semiconductor memory, or via a communication network.

  Further, in this specification and the like, the “unit” does not simply mean a physical configuration, but also includes a case where the functions of the configuration are realized by software. In addition, functions of one configuration may be realized by two or more physical configurations, or functions of two or more configurations may be realized by one physical configuration.

  According to the present invention, it is possible to provide a virtual currency management program and a virtual currency management method for making it possible to continuously use a virtual currency that has been used before the update even after the key pair is updated.

It is a block diagram of the virtual currency system in embodiment of this invention. It is a figure which shows an example of the functional block of the terminal in embodiment of this invention. It is a figure which shows an example of the structure of the mapping information in embodiment of this invention. It is a figure which shows an example of the correspondence of the elapsed time and the depreciation of the virtual currency in the embodiment of the present invention. It is a figure which shows an example of the remittance transaction in embodiment of this invention. It is a figure which shows an example of the map transaction in embodiment of this invention. It is a figure which shows an example of the flow of ID authentication processing in embodiment of this invention. It is a figure which shows an example of the flow of the update permission process in embodiment of this invention. It is a figure which shows an example of the flow of the mining process in embodiment of this invention. It is a figure which shows an example of the hardware constitutions of the terminal in embodiment of this invention.

[First Embodiment]
Hereinafter, one embodiment of the present invention will be described in detail. The following embodiments are examples for explaining the present invention, and are not intended to limit the present invention only to the embodiments. The present invention can be variously modified without departing from the gist thereof. Furthermore, those skilled in the art can employ embodiments in which the elements described below are replaced with equivalent ones, and such embodiments are also included in the scope of the present invention. Furthermore, positional relationships such as up, down, left, and right shown as needed are based on the display shown unless otherwise specified. Furthermore, various dimensional ratios in the drawings are not limited to the illustrated ratios.

<1. Overview of system configuration>
FIG. 1 shows an example of the configuration of the virtual currency system 10. As shown in FIG. 1, the virtual currency system 10 has a P2P configuration in which a plurality of client devices that have installed the virtual currency management program according to the present invention communicate with each other. In the example of FIG. 1, client terminals of users who perform transactions using virtual currency are terminals 100A to 100C (hereinafter, terminals 100A to 100C are collectively referred to as “terminal 100”), and remittance transactions are verified and approved. The user's client terminal will be described as terminals 200A to 200C (hereinafter, terminals 200A to 200C are collectively referred to as “terminal 200”).

  The terminal 100 and the terminal 200 are computers connected to a network 400 such as the Internet or a dedicated line. Specific examples include a mobile phone, a smartphone, a PC (Personal Computer), a PDA (Personal Digital Assistant), a tablet, and a wearable terminal. The devices 100 and 200 connected to the network 400 by wire or wirelessly are set to be communicable with each other, so that the virtual currency system 10 is configured. In the present embodiment, the virtual currency system 10 is described as being a P2P type system, but is not limited thereto. For example, the virtual currency system 10 may be configured as a cloud computing system. In this case, the user uses the computer processing of the virtual currency system 10 as a service via the network. Moreover, the virtual currency system 10 may be configured as a system including an ASP (Application Service Provider) server.

<2. Overview of virtual currency>
First, the outline of the virtual currency provided by the virtual currency system 10 (hereinafter, the virtual currency provided by the virtual currency system 10 is also referred to as “orb”) will be described. Orb is a P2P digital currency using the Internet, like the existing Bitcoin, and the integrity of transaction information is secured by a digital signature using a public key cryptosystem and a hash function. In addition, information and history regarding orb transactions are distributed and managed in the entire virtual currency system 10. In the present embodiment, the orb will be described as a currency whose minimum unit is “1Orb”.

  A user who uses an orb must first install a virtual currency management program. The virtual currency management program preferably includes a wallet tool and a mining tool. The wallet tool is a tool necessary to purchase orbs and conduct transactions using the orbs. On the other hand, the mining tool refers to a tool necessary for verifying the integrity and consistency of a transaction using an orb and approving the transaction.

  A user who has installed the wallet tool on the client terminal needs to generate a unique ID in the network 400. The ID is, for example, a hash value of a character string that combines a user's mail address and an arbitrary word. The generated ID is associated with a public key used for orb purchase and remittance, and is managed by a structure called mapping information described later. Data relating to the generation and update of mapping information (hereinafter, data relating to the generation and update of mapping information is also referred to as “map transaction”) is shared by the entire network 400.

  The user who generated the mapping information can purchase the orb. “Purchase an orb” means that a new orb is generated in the virtual currency system 10. Specifically, it means that an arbitrary amount of real currency is converted into an orb by the user.

  Further, the user can remit the purchased orb to another user. “Transmit the orb” means that the orb is transferred from the original owner to the new owner.

  Data related to orb purchase and remittance (hereinafter, data related to orb purchase and remittance is also referred to as “remittance transaction”. In particular, data related to orb purchase is also referred to as “currency generation transaction”) is referred to as a block chain described later. Managed by a structure. The block chain is a series of data called blocks, and serves as a ledger that records the remittance of orbs. A user who has installed the mining tool on the client terminal in addition to the wallet tool (hereinafter, a user who has installed only the wallet tool is simply referred to as “user”, and a user who has installed the wallet tool and mining tool is referred to as “minor”) Can verify the validity of the remittance transaction and approve the valid remittance transaction. Further, the miner can generate a block composed of approved remittance transactions (hereinafter, generating the block is also referred to as “excavating the block”) and connecting it to the block chain.

  The orb is configured to depreciate as time passes from the time of purchase. Therefore, the user who purchased the orb needs to consume it before the orb disappears due to depreciation. By configuring the orb to depreciate, the user is not the target of the investment, and as a result, the value of the orb can be stabilized.

<3. Functional configuration>
Next, the functional configuration of the terminals 100 and 200 installed with the virtual currency management program according to the present embodiment will be described with reference to FIG.
<3-1. Wallet Tool Functions>
FIG. 2A is a diagram illustrating an example of a functional block diagram of the terminal 100 in which the wallet tool is installed. The terminal 100 in which the wallet tool is installed has a remittance transaction DB 131, a block information DB 132, a mapping information DB 133, an account information DB 134, a map transaction information DB 135, a remittance acceptance unit 101, an input data creation unit 102, and an output. It is desirable to construct a data creation unit 103, a remittance transaction delivery unit 104, and a mapping unit 105.

  The remittance transaction information DB 131 stores a history of remittance transactions distributed by the terminal 100 or 200 to the network 400 by broadcast. In general, it is desirable that one remittance transaction includes input data, output data, the time when the remittance transaction occurred, and the time when the remittance transaction was added to the block chain described later. Note that the currency generation transaction distributed at the time of purchasing the orb may not include input data.

  The output data of the remittance transaction preferably includes the amount of the orb to be remittance and the user ID of the remittance destination.

  The input data of the remittance transaction includes a pointer to the output data of the remittance transaction that the remittance user received the orb to be retransmitted this time, the electronic signature of the remittance source user created by the electronic signature creation process described later, and the remittance source It is desirable to include the user's public key.

  In a transaction using an orb, an orb received or purchased in the past is designated as a remittance target and remittance to another user. For this reason, when performing remittance, it is necessary to designate output data in which the remittance source user has become the remittance destination user from the past remittance transaction as the remittance target this time. As described above, the orb remittance transaction has a structure in which the input data has a pointer to the previous output data. As a result, all remittance transactions have a data structure that is linked to each other through a pointer to the currency generation transaction.

The block information DB 132 stores information about the generated block. The block stores a plurality of remittance transactions and map transactions that the miner has verified and approved. Orb purchase and remittance, and generation and update of mapping information are managed by a structure called a block chain. A block chain refers to data called blocks arranged in time series. The block chain is shared by all terminals of the virtual currency system 10, but the user only needs to have a portion of the block chain that he is interested in. It is desirable that the minor possesses the entire block chain.
The block includes a hash value of the previous block and a plurality of remittance transactions.

  The mapping information DB 133 stores mapping information of all users who have installed the wallet tool. FIG. 3 is a conceptual diagram showing an example of the structure of mapping information generated and updated by a map transaction. As shown in FIG. 3, the mapping information includes an ID, a public key, a public key spare (hereinafter, a public key spare is also referred to as a “spare key”), and IDs of a plurality of management users. It has a structure.

The ID is an identifier unique in the network 400 created by the user when the wallet tool is installed.
The administrative user is a user who is permitted to update the public key associated with the ID. For example, there are three administrative users: an owner of a public key, an orb issuer such as a local government or a company, and an orb manufacturer. The management user may be arbitrarily set by the owner of the public key. Moreover, although it is desirable that there are two or more management users, the present invention is not limited to this.
In the example of FIG. 3, only one spare key is registered. However, the present invention is not limited to this, and a plurality of spare keys may be registered. Furthermore, a configuration in which no spare key is registered may be used.
Note that the management user mapping information is also stored in the mapping information DB 133.

  The account information DB 134 stores the secret key of the user who uses the terminal 100.

  The map transaction information DB 135 stores a history of map transactions distributed by the terminal 100 or 200 to the network 400 by broadcast. In general, it is desirable that one map transaction includes input data and output data. The map transaction is performed when the user creates an ID (hereinafter, the map transaction delivered when the user creates an ID is also referred to as an “ID generation transaction”), or when the user uses an old key pair (hereinafter updated). The old key pair is called the "old key pair", the old public key is also called the "old key") and the new key pair (hereinafter the new key pair is called the "new key pair"). This is a transaction that is distributed when a key pair is updated to a new key.

  In the output data of the map transaction, new mapping information in which the new key is associated with the user ID (hereinafter, the new mapping information is also referred to as “new mapping”. The old mapping information to be updated is referred to as “old mapping”. Is also stored.

The input data of the map transaction preferably includes a pointer, a digital signature and a public key of a predetermined number of management users. The pointer indicates the output data of the map transaction in which the user has updated or generated mapping information in the past by designating the old key updated this time as the public key.
The predetermined number of management users is a management user of at least a part of the plurality of management users specified by the mapping information to be updated. Specifically, when the key registered by the user as the spare key in the old mapping is specified as the public key in the new mapping, only the electronic signature of the owner of the public key is included in the input data as the electronic signature of the management user. Is included. On the other hand, when a new key that is not registered in the old mapping is registered as a new key, for example, two or more electronic signatures of three management users are required.

  Similar to the remittance transaction, the map transaction has a structure in which the input data has a pointer to the previous output data. As a result, all the map transactions also have a data structure that is connected in a daisy chain through the pointer to the ID generation transaction. It is desirable that input data is not included in the ID generation transaction.

Returning to FIG. 1, the continuation of each component of the terminal 100 in which the wallet tool is installed will be described.
The remittance accepting unit 101 accepts designation of the remittance destination user and the amount of money to be remittance from the user. It is desirable that the remittance acceptance unit 101 presents a remittance acceptance screen on the display of the terminal 100. Further, the remittance accepting unit 101 may present the currency purchase screen on the display and accept the purchase of the orb from the user.

The input data creation unit 102 creates input data for a remittance transaction according to the remittance amount received by the remittance accepting unit 101. The input data creation unit 102 performs the following four processes in order to create input data.
・ Remittance object search processing ・ Price reduction calculation processing ・ Pointer designation processing ・ Digital signature creation processing

(Remittance target search process)
As the remittance target search process, the input data creation unit 102 can first search the remittance transaction information DB 131 for a remittance transaction having output data that can be used as a remittance target. For example, the input data creation unit 102 is a remittance transaction having an output in which the remittance source user ID is specified as the remittance destination ID from the remittance transaction information DB 131, and is used as a pointer for input data of another remittance transaction. It is desirable to extract remittance transactions that have unspecified output data.

(Depreciation calculation processing)
Next, the input data creation unit 102 refers to the remittance amount included in the output data of the extracted remittance transaction, and calculates the amount (reduced price) that has been reduced to date. First, the input data creation unit 102 sequentially refers to the pointers included in the input data of the extracted remittance transaction, and extracts a currency generation transaction. Then, the input data creation unit 102 refers to the transaction occurrence time of the currency generation transaction, and calculates the depreciation rate based on the difference from the current time.

FIG. 4 is a diagram illustrating an example of a correspondence relationship between the passage of time and the balance rate of the orb. In the example of FIG. 4, a state in which the current amount is deducted by 10% every 10 days after the orb is purchased is shown. When the depreciation rate of the orb is defined as shown in the table of FIG. 4, the input data creation unit 102, for example, for an orb that has passed 22 days from the purchase, the current balance is 81 of the balance at the time of purchase. % And the depreciation rate is calculated to be 19%. In addition, the aspect of the depreciation of the orb is not limited to the example of FIG. 4. For example, a certain amount of money may be reduced with the passage of time, or the depreciation rate may change with the passage of time.
The input data creation unit 102 can calculate a reduction amount of the amount using the amount of output data of the extracted remittance transaction and the calculated current depreciation rate.

(Pointer specification processing)
Next, the input data creation unit 102 selects output data suitable for designating a pointer from the extracted remittance transactions based on the remittance amount received by the remittance accepting unit 101. Specifically, the input data creation unit 102 calculates the balance of each output data based on the amount of the extracted output data and the calculated depreciation rate. Then, a pointer to output data in which the calculated balance exceeds the remittance amount accepted by the remittance accepting unit 101 can be designated as current input data.
When there is no output data in which the calculated balance exceeds the remittance amount accepted by the remittance acceptance unit 101, in this embodiment, the input data creation unit 102 changes the remittance amount to some amount. After dividing, it is desirable to search again for output data in which the calculated balance exceeds the divided amount. Note that the present invention is not limited to this, and when there is no remittance transaction having output data having an amount larger than the current remittance amount, the input data creation unit 102 designates a plurality of output data pointers. A plurality of input data may be created.

  When the remittance accepting unit 101 accepts remittance to a plurality of users, the input data creating unit 102 desirably selects a pointer based on the total amount of accepted remittance amounts.

(Digital signature creation process)
Further, the input data creation unit 102 creates an electronic signature of the remittance source user. For example, the input data creation unit 102 generates a digest using a hash function from the entire data of the remittance transaction being created, excluding the part that stores the electronic signature. The input data creation unit 102 can create an electronic signature by encrypting the generated digest with the private key of the remittance source user.

  The input data creation unit 102 can create input data by storing the pointer designated in the pointer designation process, the digital signature created in the digital signature creation process, and the remittance user public key.

Returning to FIG. 2A, the continuation of the function of each functional block will be described.
The output data creation unit 103 creates output data of a remittance transaction based on the remittance destination user and the amount to be remittance received by the remittance accepting unit 101. For example, the output data creation unit 103 can specify the ID of the transmission destination user in the output data with reference to the mapping information DB 133.
Further, the output data creation unit 103 subtracts the total amount of the current remittance amount from the balance of the output data designated by the input data creation unit 102, and outputs the difference as a remittance to the remittance source user. It is desirable to create data.

  In addition, when the remittance accepting unit 101 accepts the purchase of the orb from the user, the output data creating unit 103 desirably creates the output data with the user who inputs the orb purchase as the remittance destination user. .

The remittance transaction distribution unit 104 creates a remittance transaction related to the current remittance and distributes it to the network 400. The remittance transaction distribution unit 104 performs processing for creating the following two types of remittance transactions.
-Normal transaction (hereinafter, the normal transaction is also simply referred to as “remittance transaction”)
-Currency generation transaction

(Normal transaction)
The normal transaction refers to a remittance transaction distributed by the remittance transaction distribution unit 104 when orb remittance is performed. The normal transaction includes input data, output data, a time when the remittance transaction occurs, and a time when the remittance transaction is added to the block chain.
The remittance transaction delivery unit 104 stores the input data created by the input data creation unit 102 and the output data created by the output data creation unit 103 in a normal transaction, and specifies the current time as the transaction occurrence time. Thus, the normal transaction can be distributed to the network 400 by broadcast.

(Currency transaction)
The currency generation transaction is a remittance transaction distributed by the remittance transaction distribution unit 104 when an orb is purchased. All remittance transactions converge to a currency generation transaction by referring to the input data pointer.
The currency generation transaction should not include input data. The remittance transaction distribution unit 104 stores the output data created by the output data creation unit 103 and used as the remittance user as the remittance destination user, and further specifies the current time as the transaction occurrence time. Thus, the currency generation transaction can be broadcast to the network 400.

The mapping unit 105 receives generation and update of mapping information from the user, and distributes the map transaction to the network 400 by broadcasting. The mapping unit 105 is configured to perform the following processing.
・ Issuance acceptance processing ・ Pointer designation processing ・ Management user designation processing ・ Distribution processing

(Issuance acceptance process)
The mapping unit 105 accepts input of ID issue information as issue acceptance processing. The ID issue information is, for example, a public key of a key pair newly used by the user and a user ID associated with the user who uses the public key. The mapping unit 105 may accept an ID designation directly from the user, or may accept an e-mail address or input of an arbitrary character string. When the mapping unit 105 receives an input of an email address or an arbitrary character string, the mapping unit 105 can generate a hash value from the received email address or an arbitrary character string and use it as an ID. The mapping unit 105 can present the issuance acceptance screen on the display of the terminal 100 and accept registration of the public key. At this time, the mapping unit 105 can also accept registration of a spare key.
In the ID generation transaction, the mapping unit 105 may receive the management user information together with the ID issue information. The management user information is an ID of a user registered as a management user. The management user information may be determined by the system administrator and cannot be determined freely by the user.

(Pointer specification processing)
The mapping unit 105 designates a pointer to be stored in the input data of the map transaction as the pointer designation process. The mapping unit 105 first refers to the mapping information DB 133 and identifies the public key (old key) corresponding to the user ID received in the issue reception process. Next, the mapping unit 105 extracts a map transaction in which the identified old key is specified as output data. The mapping unit 105 selects a map transaction having output data that is not referenced as a pointer from other input data from the extracted map transaction. The mapping unit 105 then designates a pointer to the output data of the selected map transaction as the current input data.

(Digital signature creation process)
The mapping unit 105 acquires the electronic signature of the management user registered in the mapping information as the electronic signature creation process. Specifically, a digest is created using a hash function for the entire data of the map transaction being created, excluding the part that stores the electronic signature. Then, an electronic signature is created by encrypting the created digest using the secret key of the management user.

(Delivery process)
The mapping unit 105 broadcasts a map transaction storing input data and output data to the network 400 as a distribution process. The mapping unit 105 performs the following processing in each case of an ID generation transaction and another map transaction.

In the case of an ID generation transaction The mapping unit 105 performs a distribution process after performing an issue acceptance process. The mapping unit 105 creates mapping information based on the ID issue information and the management user information received in the issue reception process, and stores the mapping information in the output data. In the ID generation transaction, the map transaction has no input data. Therefore, the mapping unit 105 stores only output data and distributes the ID generation transaction to the network 400 by broadcast.

In the case of a map transaction other than an ID generation transaction The mapping unit 105 performs a distribution process after performing an issue acceptance process, a pointer designation process, and an electronic signature creation process. First, the mapping unit 105 extracts mapping information corresponding to the ID received in the issue reception process with reference to the mapping information DB 133 in order to create output data. The mapping unit 105 updates the public key (old key) of the extracted mapping information to the new key and stores it in the output data. In this case, it is desirable that the mapping unit 105 excludes the old key from the new mapping stored in the output data.
Next, the mapping unit 105 stores, in the input data, the pointer designated in the pointer designation process, the electronic signature created in the electronic signature creation process, and the public key corresponding to the electronic signature.
The mapping unit 105 broadcasts a map transaction storing the created input data and output data to the network 400.

<3-2. Orb remittance processing flow>
Next, a processing flow when the user A remits the orb to the user B will be described with reference to FIG. FIG. 5 is a diagram schematically showing a remittance transaction when the user A remits the purchased orb to the user B using the terminal 100A.
In this example, the terminal used by the user A who is the orb remittance source user is described as the terminal 100A, and the terminal used by the user B who is the orb remittance destination user is described as the terminal 100B. Also, in the example of FIG. 5, the description will be made assuming that the elapsed time and the orb depreciation rate have the correspondence shown in FIG.

  In FIG. 5, block B02 is the last block in the block chain, and block B01 is the block immediately preceding block B02. The remittance transaction T11 is a currency generation transaction, and the remittance transaction T12 is a normal transaction related to the remittance of the orb from the user A to the user B. Further, O11 to O13 each represent output data, and I11 represents input data.

  First, it is assumed that user A purchases 10,000 orbs. In this case, the remittance accepting unit 101 presents a currency purchase screen on the display of the terminal 100A. User A designates the amount of the orb to be purchased as 10,000 Orb from the presented currency purchase screen. At this time, the output data creation unit 103 refers to the mapping information DB 136 and creates the output data O11 by designating the remittance amount of 10,000 Orb and the remittance destination as the user A and specifying the ID of the user A.

  Next, the remittance transaction distribution unit 104 stores the output data O11 in the remittance transaction T11, specifies the current time as the transaction occurrence time, creates a currency generation transaction, and distributes it to the network 400. When the distributed currency generation transaction is approved by the mining excavation process described later and connected to the block chain, the user A can use the purchased orb for the transaction.

  For example, assume that the user A remits a part of the purchased orb (7000 Orb) to the user B 11 days after the purchase of the orb. In this case, the input data creation unit 102 first executes a remittance target search process and searches for a remittance transaction having output data for which user A has been designated as a remittance destination user. In the example of FIG. 5, since the corresponding remittance transaction is only the remittance transaction T11, the input data creation unit 102 extracts the remittance transaction T11.

  Next, the input data creation unit 102 executes a depreciation calculation process, and calculates a depreciation of the output data O11. Since this remittance is made 11 days after the purchase of the orb, the depreciation rate is 10%. Therefore, the input data creation unit 102 calculates that the reduced price of the output data O11 is 1000 Orb. The input data creation unit 102 subtracts the calculated price reduction (1000 Orb) from the remittance amount (10000 Orb) of the output data O11, and calculates the balance of the output data O11 to be 9000 Orb. This exceeds the current remittance amount of 7000 Orb, so the input data creation unit 102 designates the pointer of the output data O11 as the current input data I11. Further, the input data creation unit 102 executes digital signature creation processing. Specifically, a digest is created using a hash function for the entire data of the remittance transaction being created, excluding the part that stores the electronic signature. Then, using the user A's private key stored in the account information DB 134, the input data creation unit 102 encrypts the generated digest and creates an electronic signature. The input data creation unit 102 creates the input data I11 by storing the designated pointer, the created electronic signature, and the public key of the remittance source user.

  Next, the output data creation unit 103 sets the remittance amount to 7000 Orb, the remittance destination to the user B, refers to the record corresponding to the ID of the user B from the mapping information DB 136, and specifies the ID and public key of the user B Output data O12. Further, the output data creation unit 103 subtracts 7000 Orb, which is the remittance amount of the current output data O 12, from the balance 9000 Orb of the output data O 11, and outputs 2000 Orb, which is the difference, with the ID of user A as the remittance destination. Data O13 is created.

  The remittance transaction distribution unit 104 stores the input data I11, output data O12, and output data O13 in the remittance transaction T12, and distributes the remittance transaction T12 by designating the current time as the transaction occurrence time.

  In the above example, when the remittance amount is 9500 Orb, for example, the remittance amount exceeds 9000 Orb, which is the balance of the output data O11, and therefore the input data creation unit 102 designates the pointer of the output data O11. I can't. In this case, the input data creation unit 102 can divide the remittance amount into two amounts, for example, 9000 Orb and 500 Orb. At this time, it is desirable that the input data creation unit 102 creates input data corresponding to each remittance amount and retrieves output data referred to by a pointer. Further, in this case, the output data creation unit 103 may create output data with a remittance amount of 9000 Orb and output data with 500 Orb.

  As described above, the wallet tool according to the present embodiment makes the orb less likely to be an investment target by causing the terminal 100 to function so that the orb is reduced over time, and it is possible to suppress fluctuations in currency value. It becomes.

<Mapping information update processing flow>
A processing flow in the case where the user A updates the mapping information will be described with reference to FIG. FIG. 6 is a diagram schematically showing a map transaction when the public key registered in the mapping information is updated to a new key. In this example, it is assumed that IDs of three users, user A, user B, and user C, are registered in the mapping information DB 133 as the management user of user A. A terminal used by user A is terminal 100A, and a terminal used by user B is terminal 100B.

  In FIG. 6, block B22 is the last block of the block chain, and block B21 is a block including an ID generation transaction in which user A has created an ID. The map transaction T21 is an ID generation transaction, and the map transaction T22 is a transaction in which the user A updates the mapping information from the old key to the new key. Further, O21 and O22 represent output data, and I22 represents input data.

  First, user A creates a new ID. In this case, the mapping unit 105 presents an issue acceptance screen on the display of the terminal 100A. The user inputs an arbitrary character string such as an email address or a telephone number as ID issue information on the presented issue acceptance screen, and registers a public key and a spare key. Furthermore, the user A designates the ID of the user to be registered (user A, user B, user C in the example of FIG. 6) as management user information. The mapping unit 105 creates an ID from the hash value of the input character string. The mapping unit 105 creates mapping information for the user A by associating the created ID, the received ID issuance information, and the management user information, and stores the mapping information in the output data O21. The mapping unit 105 stores the output data O21 created in the ID generation transaction T21 and distributes it to the network 400 by broadcast. When the distributed ID generation transaction T21 is approved by a minor excavation process described later, it is connected to the block chain. When the ID generation transaction T21 is connected to the block chain, it is shared by the network 400 as mapping information of the user A.

It is assumed that the mapping information is updated because the user A has created a new ID and lost the private key paired with the registered public key. In this case, the mapping unit 105 first performs issue acceptance processing, and accepts the new key to be registered and the registered ID of the user A.
The mapping unit 105 refers to the mapping information DB 133 and extracts mapping information (old mapping) corresponding to the received ID. The mapping unit 105 creates a new mapping in which the extracted public key (old key) of the old mapping is updated to a new key, and stores the new mapping in the output data O22.

  Next, the mapping unit 105 performs pointer designation processing. Specifically, the mapping unit 105 first specifies a public key (old key) corresponding to the user A ID from the old mapping of the user A registered in the mapping information DB 133. Further, the mapping unit 105 extracts a map transaction in which mapping information using the identified old key as a public key is specified as output data. In the example of FIG. 6, since the public key is updated for the first time this time, the mapping unit 105 extracts the ID generation transaction T21. The mapping unit 105 stores a pointer referring to the output data O21 of the ID generation transaction T21 in the current input data I22.

  Next, the mapping unit 105 executes an electronic signature creation process. In this example, the mapping unit 105 creates electronic signatures for the user B and the user C. Specifically, a digest is created using a hash function for the entire mapping data being created, excluding the part for storing the electronic signature. Then, the digest is encrypted using the private key of user B, and an electronic signature of user B is created. In addition, the digest is encrypted using the secret key of the user C, and the electronic signature of the user C is created.

  The mapping unit 105 stores the electronic signatures of the users B and C, the public keys of the users B and C, and a pointer to the output data O21 in the input data I22.

  The mapping unit 105 stores the input data I22 and the output data O22 in the map transaction T12 and distributes them.

  In the above example, if the user A has not lost the private key and wants to change the public key and spare key of the mapping information, the mapping unit 105 displays the user A's electronic signature and the public signature in the input data I22. The key and the pointer to the output data O21 may be stored, and the electronic signatures of other management users may not be stored. In this case, the old key may be deleted from the mapping information (new mapping) stored in the output data O21.

Returning to FIG. 2, the function of the terminal 200 will be described.
<3-4. Mining Tool Functions>
FIG. 2B is a diagram illustrating an example of a functional block diagram of the terminal 200 in which a mining tool is installed in addition to the wallet tool. In the terminal 200 in which the mining tool is installed, a verification unit 201, an excavation unit 202, a reward calculation unit 203, and an update permission unit 204 are constructed in addition to the functional blocks created by the wallet tool described above. Is desirable.

The verification unit 201 executes the following three processes in order to verify the validity of the received remittance transaction.
ID verification process / integrity verification process / consistency verification process As a result of the above three verification processes, the verification unit 201 approves a remittance transaction with an ID, integrity, and consistency recognized as a valid remittance transaction It may be possible.

(ID verification processing)
As the ID verification process, the verification unit 201 verifies whether or not the remittance source user who performed the remittance this time is a valid owner of the remittance orb by verifying the ID. For example, the verification unit 201 verifies whether the electronic signature included in the input data of the received remittance transaction and the ID included in the output data referred to by the pointer belong to the same user.
FIG. 7 is a diagram illustrating a processing flow of the ID verification processing.
First, the verification unit 201 acquires the electronic signature and public key of the remittance source user from the input data of the received remittance transaction (S11). In addition, the verification unit 201 acquires an ID (ID1) stored in the output data referred to by the pointer included in the input data of the received remittance transaction (S12).
Next, the verification unit 201 refers to the mapping information DB 133, extracts the user ID (ID2) associated with the acquired public key (S13), and verifies whether ID1 and ID2 match. (S14). If they match, the verification unit 201 further verifies whether the electronic signature included in the remittance transaction can be decrypted with the public key linked to ID2 (S15). If the decryption is successful, the verification unit 201 authenticates that the user who sent the money was the correct owner of the sent orb (S16). The verification of the electronic signature in S15 may be performed with the public key stored in the input data in the received remittance transaction.
Thus, according to the virtual currency management program according to the present embodiment, the remittance source user is authenticated by the ID. Thereby, even when the user updates the public key, it can be identified that the user is the same as that before the update.

(Integrity verification process)
The verification unit 201 verifies whether the received remittance transaction has been tampered with as the integrity verification process. Specifically, the verification unit 201 first refers to the mapping information DB 133, decrypts the electronic signature included in the input data of the received remittance transaction with the public key of the original owner, and generates an input data creation unit The digest created by 102 is taken out. Further, the verification unit 201 generates a digest by using a hash function from data excluding a part for storing an electronic signature in the entire data of the received remittance transaction. The verification unit 201 verifies whether or not the decrypted digest and the generated digest match, and if they match, can confirm the completeness of the remittance transaction data. The verification unit 201 may be able to approve the completeness of the remittance transaction when the electronic signatures of all input data included in the remittance transaction can be verified.

(Consistency verification process)
As the consistency verification process, the verification unit 201 verifies whether the received remittance transaction is a transaction that is consistent with the entire block chain. Specifically, the verification unit 201 executes a process similar to the above-described price reduction calculation process, calculates the balance of input data, and verifies whether the calculated balance exceeds the amount of output data.
In addition, as the consistency verification process, the verification unit 201 confirms whether the remittance transaction referring to the same output data as the input data of the remittance transaction to be verified has already been approved, and verifies the double transaction. It may be done. Specifically, the verification unit 201 refers to the block information DB 132 and extracts the output data referred to by the pointer of the input data of the remittance transaction included in the block connected to the block chain. Further, the verification unit 201 verifies whether the output data referred to by the pointer designated as the input data of the current remittance transaction to be verified is already referred to. When the output data referred to by the pointer specified as the input data of the current remittance transaction is not designated by the pointer from the input data of the past remittance transaction, the verification unit 201 remits the current remittance target. The consistency of transaction input data can be approved.
The verification unit 201 may be able to approve the consistency of the remittance transaction when the consistency of all input data included in the remittance transaction has been approved.

The excavation unit 202 performs mining processing in order to generate a block for storing a legitimate remittance transaction in which the remittance source user is authenticated by the processing of the verification unit 201 and integrity and consistency are recognized. Specifically, the excavation unit 202 calculates a hash value at the end of the current block chain using a hash function. For the data obtained by combining the calculated hash value and a predetermined value with the block to be generated, the excavation unit 202 calculates a hash value using a hash function. This data may include the generation time of the block. When the hash value is equal to or less than a predetermined value, it is said that “the block has been excavated” in the present embodiment. When the block is excavated, the excavation unit 202 can connect the block to the end of the block chain.
When the excavating unit 202 connects a block to the block chain, it is desirable to specify the current time as the block chain addition time of the remittance transaction stored in the block.

The reward calculation unit 203 calculates a minor reward based on the reduced value of the legitimate remittance transaction stored in the block. For example, the remuneration calculation unit 203 may calculate the total reduction amount of the amount of the output data specified as the input data pointer as the minor remuneration. Specifically, the reward calculation unit 203 sequentially refers to the pointers included in the input data, and extracts a currency generation transaction. And the reward calculation part 203 calculates the depreciation rate based on the difference with the present time with reference to the transaction generation time of a currency generation transaction. This process may be the same process as the depreciation calculation process of the input data creation unit 102. The reward calculation unit 203 can calculate the total reduction amount of each remittance transaction stored in the block generated by the excavation unit 202 as a minor reward.
Further, the remuneration calculation unit 203 designates the amount of remuneration for which the remittance amount has been calculated, designates the transmission destination as a minor using the terminal 200, creates output data, and creates a currency generation transaction based on the output data It is desirable to do. The reward calculation unit 203 distributes the created currency generation transaction to the network 400 by broadcast. It is desirable to broadcast this currency generation transaction by including it in a block to be generated. When the currency generation transaction is approved by any of the minor terminals connected to the network 400, the minor using the terminal 200 can receive a reward.

The update permission unit 204 verifies the validity based on whether or not the mapping information has been updated by the management user, and permits the update if it is valid. For example, the update permission unit 204 uses the electronic signature and public key included in the map transaction to verify whether the electronic signature belongs to the user registered as the management user in the mapping information to be updated. I do.
FIG. 8 is a chart illustrating an example of an update permission process flow of the update permission unit 204. FIG. 8 illustrates an example in which the update permission unit 204 verifies the update of mapping information performed in the map transaction illustrated in T22 of FIG.

  First, when receiving the map transaction, the update permission unit 204 acquires the ID of the user A from the mapping information stored in the output data O22 (S21). Next, with reference to the mapping information DB 133, it is confirmed whether or not the acquired ID of the user A is an already registered ID (S22). When the acquired ID of the user A is an ID not registered in the mapping information DB 133 (S22: NO), the acquired mapping information is registered in the mapping information DB 133.

  On the other hand, when the acquired ID of the user A is an ID registered in the mapping information DB 133 (S22: YES), the update permission unit 204 refers to the input data I22 and corresponds to the number of persons necessary for the update process. It is verified whether the correct electronic signature is stored (S23). The number of people required for the update process is, for example, 2 out of 3 people.

  The update permission unit 204 acquires the public keys of the users B and C stored in the input data I22 together with the electronic signature. With reference to the mapping information DB 133, the update permission unit 204 confirms the user ID corresponding to the acquired public key, and verifies whether the user ID matches the ID registered as the management user. If they match, the update permission unit 204 further verifies whether each electronic signature can be decrypted with the public keys of the acquired users B and C.

  If correct electronic signatures are stored for the required number of persons (S23: YES), the update permission unit 204 determines whether the new key specified as the public key in the new mapping is a unique key in the network 400. Is confirmed (S24). Specifically, the update permission unit 204 refers to the mapping information DB 133 and confirms that it is not registered as a public key of another user. If the public key designated as the new key is a unique key (S24: YES), the update permission unit 204 allows the mapping information to be updated.

  As described above, according to the virtual currency management program according to the present embodiment, when the user updates the mapping information, the mapping information indicates whether the assigned electronic signature belongs to the user registered as the management user. Is referenced recursively. Thereby, it can be ensured that the updated user can be identified with the user before the update.

<3-5. Mining process flow>
With reference to FIG. 9, the processing flow of the mining process of the terminal 200 in which the mining tool is installed will be described by taking an example in which a remittance transaction is stored in a block.
First, the verification unit 201 refers to the remittance transaction DB 131 and confirms whether there are unverified remittance transactions that have not been verified among the received remittance transactions (S101). When the unverified remittance transaction remains (S101: YES), the verification unit 201 acquires the unverified remittance transaction for verification (S102).

  Next, when there is unverified input data among the input data included in the acquired remittance transaction to be verified (S103: YES), the verification unit 201 acquires the unverified input (S104), Validate the data. First, the verification unit 201 extracts an orb currency generating transaction used for the input data from the pointer of the acquired input data (S105). Further, the verification unit 201 calculates a price reduction and a balance of input data from the difference between the transaction occurrence time and the current time of the currency generation transaction (S106).

  Next, the verification unit 201 verifies whether the total amount of remittance of output data included in the remittance transaction to be verified exceeds the calculated balance, and verifies the validity of the input data (S107). . If the total amount of remittance exceeds the calculated balance (S107: NO), the verification unit 201 assumes that the remittance transaction to be verified is an illegal remittance transaction and does not store it in the block (S151). . On the other hand, if the total amount of the remittance amount of the output data included in the verification target remittance transaction does not exceed the calculated balance (S107: YES), the verification remittance transaction is assumed to be valid input data. Approve the input data. The verification unit 201 repeatedly executes the processes from S103 to S107 until verification of all input data included in the remittance transaction is completed. If all input data included in the remittance transaction is approved as valid, verification stores the remittance transaction in the block as a valid remittance transaction.

  The verification unit 201 repeatedly executes the processing from S101 to S107 until there is no unverified remittance transaction. When there is no unverified remittance transaction in the remittance transaction received by the terminal 200 (S101: NO), the remuneration calculation unit 203 calculates a minor remuneration based on the total amount of depreciation of the remittance transaction stored in the block. Further, the remuneration calculation unit 203 sets the remittance amount as a total amount, designates the remittance destination as the minor, creates a currency generation transaction, and distributes it to the network 400 by broadcast (S108). When the distributed currency generation transaction is approved by another miner, a reward is given to the miner who distributed the currency generation transaction (S109).

  As described above, the mining tool according to the present embodiment does not deplete the reward for the miner by causing the terminal 200 to function based on the reduced price of the remittance transaction included in the approved block. It becomes possible to do so.

(4 hardware configuration)
Hereinafter, an example of a hardware configuration when the terminal 100 and the terminal 200 described above are realized by the computer 800 will be described with reference to FIG. The function of each device can be realized by dividing it into a plurality of devices.

  As illustrated in FIG. 10, the computer 800 includes a processor 801, a memory 803, a storage device 805, an input I / F unit 807, a data I / F unit 809, a communication I / F unit 811, and a display device 813.

  The processor 801 controls various processes in the computer 800 by executing a program stored in the memory 803. For example, the remittance accepting unit 101, the input data creating unit 102, the output data creating unit 103, the remittance transaction delivery unit 104, the mapping unit 105, the verification unit 201, the excavating unit 202, the reward calculating unit 203, and the update of the terminal 200 The permission unit 204 or the like can be realized as a program that mainly operates on the processor 801 after being temporarily stored in the memory 803.

  The memory 803 is a storage medium such as a RAM (Random Access Memory). The memory 803 temporarily stores a program code of a program executed by the processor 801 and data necessary for executing the program.

  The storage device 805 is a non-volatile storage medium such as a hard disk drive (HDD) or a flash memory. The storage device 805 stores an operating system and various programs for realizing the above-described configurations. In addition, the storage device 805 can store a remittance transaction information DB 131, a block information DB 132, a mapping information DB 133, an account information DB 134, and a mapping transaction information DB 135. Such programs and data are referred to by the processor 801 by being loaded into the memory 803 as necessary.

  The input I / F unit 807 is a device for receiving input from the user. Specific examples of the input I / F unit 807 include a keyboard, a mouse, a touch panel, various sensors, and a wearable device. The input I / F unit 807 may be connected to the computer 800 via an interface such as a USB (Universal Serial Bus).

  A data I / F unit 809 is a device for inputting data from the outside of the computer 800. Specific examples of the data I / F unit 809 include a drive device for reading data stored in various storage media. The data I / F unit 809 may be provided outside the computer 800. In this case, the data I / F unit 809 is connected to the computer 800 via an interface such as a USB.

  The communication I / F unit 811 is a device for performing data communication with the external device of the computer 800 via the Internet N by wire or wireless. The communication I / F unit 811 may be provided outside the computer 800. In that case, the communication I / F unit 811 is connected to the computer 800 via an interface such as a USB.

  The display device 813 is a device for displaying various information. Specific examples of the display device 813 include a liquid crystal display, an organic EL (Electro-Luminescence) display, and a wearable device display. The display device 813 may be provided outside the computer 800. In that case, the display device 813 is connected to the computer 800 via, for example, a display cable.

[Other embodiments]
Although the embodiments of the present invention have been described above, the present invention is not limited to the above-described embodiments, and various modifications and changes can be made based on the technical idea of the present invention.

  For example, in the above-described embodiment, the mining tool has been described as being installed together with the wallet tool, but the present invention is not limited to this. For example, the terminal 200 may be configured to install only a mining tool. In this case, it is desirable that a remittance transaction information DB 131, a block information DB 132, and a public key information DB 133 are installed in the terminal 200 together with the verification unit 201, the excavation unit 202, and the reward calculation unit 203. Further, in the above-described embodiment, the virtual currency has been described by taking an example of a configuration in which the virtual currency is depreciated as time passes. Furthermore, the virtual currency only needs to be electronically managed or traded as an asset, and may correspond to an actual currency, stock, bond, land, or the like.

DESCRIPTION OF SYMBOLS 10 Virtual currency system 100 Terminal 101 Remittance reception part 102 Input data creation part 103 Output data creation part 104 Remittance transaction delivery part 105 Mapping part 131 Remittance transaction information DB
132 Block information DB
133 Mapping information DB
134 Account Information DB
135 Mapping transaction information DB
200 Terminal 201 Verification Unit 202 Excavation Unit 203 Reward Calculation Unit 204 Update Permission Unit 400 Network

Claims (3)

Computer
An identifier of the user, memory means shows the correspondence between the public key of the user, and stores the mapping information including the public key of the administrative user to allow updates of the public key,
The first transaction information including the identifier of the first user in the first transaction for transferring the virtual currency to the first user, and at least a part of the amount remitted by the first transaction Storage means for storing second transaction information including a first public key and a first electronic signature of the first user in a second transaction remittance by the user, and in the second transaction information Whether the first public key included is associated with the identifier of the first user included in the first transaction information in the mapping information, and included in the second transaction information Verifying means for verifying the validity of the second transaction based on whether the first electronic signature included in the second transaction information can be verified with the first public key.
Storage means for storing update information including an identifier of the second user, a second public key, and a second electronic signature; and
In the mapping information, the second electronic signature included in the update information can be verified with the third public key of the management user associated with the identifier of the second user included in the update information. Update means for updating the second public key of the second user associated with the identifier of the second user in the mapping information to the second public key included in the update information,
Virtual currency management program to function as. The mapping information includes fourth and fifth public keys as public keys associated with the second user identifier,
The update information further includes the fifth public key,
The updating means includes
In the mapping information, when the second electronic signature can be verified with the third public key or the fifth public key, the public key associated with the identifier of the second user is set to the fourth public key. The virtual currency management program according to claim 1, wherein the second public key and the fifth public key are updated to the second public key and the fifth public key. Computer
And storing the identifier of the user, and shows the correspondence between public key of the user, the mapping information including the public key of the administrative user to allow updates of the public key,
The first transaction information including the identifier of the first user in the first transaction for transferring the virtual currency to the first user, and at least a part of the amount remitted by the first transaction Storing second transaction information including a first public key and a first electronic signature of the first user in a second transaction sent by the user of
Whether or not the first public key included in the second transaction information is associated with the identifier of the first user included in the first transaction information in the mapping information; and The validity of the second transaction is verified based on whether or not the first electronic signature included in the second transaction information can be verified with the first public key included in the second transaction information. And steps to
Storing update information including a second user identifier, a second public key, and a second electronic signature; and
In the mapping information, the second electronic signature included in the update information can be verified with the third public key of the management user associated with the identifier of the second user included in the update information. And updating the second public key of the second user associated with the identifier of the second user in the mapping information to the second public key included in the update information,
Virtual currency management method to execute.

Images