JP6776396B2 - Trading system - Google Patents

Description

The present invention relates to a trading system for trading decentralized virtual currencies.

For example, Non-Patent Document 1 discloses a technique for trading virtual currencies based on blockchain technology (that is, decentralized virtual currency: hereinafter simply referred to as "virtual currency").

As described in Non-Patent Document 1, virtual currency transactions are stored in the blockchain of the virtual currency network. Specifically, when trading virtual currency, the transaction that memorizes the transaction is broadcast to the virtual currency network. One or more transactions broadcast one or more transactions. The one or more transactions are grouped into one block and connected to the blockchain. The transaction stored in the transaction is confirmed when the block's connection to the blockchain is approved. According to Non-Patent Document 1, it takes about 30 minutes to 1 hour from the broadcast of the transaction to the confirmation of the transaction.

For example, assuming a transaction in which user A transfers virtual currency from the virtual currency account α to user B's account β, the account α is from the broadcast of the transaction that stores the transaction (remittance) to the confirmation of the remittance. The balance is not fixed. Therefore, in order for the user A to make the next remittance from the account α, he / she must wait for about 30 minutes to 1 hour. That is, there is a waiting time of about 30 minutes to 1 hour between the two remittances of the virtual currency.

Patent Document 1 discloses a technique for reducing such a waiting time. According to the technique disclosed in Patent Document 1, an internal account corresponding to an external account which is an account of virtual currency is provided, and real-time transactions without using a blockchain are performed by the internal account. In addition, the balance of the external account is matched with the balance of the internal account at a predetermined timing asynchronous with the transaction by the internal account.

Japanese Unexamined Patent Publication No. 2018-088076

Hitoshi Okada, 2 outsiders "Virtual Currency Technology / Law / System", Toyo Keizai Inc., June 11, 2015

According to the technique of Patent Document 1, what is used in real-time transactions is the value secured by the virtual currency, not the virtual currency. That is, the technique disclosed in Patent Document 1 is not a technique for reducing the waiting time for transactions using virtual currency.

Therefore, an object of the present invention is to provide a trading system capable of reducing the waiting time for trading using virtual currency.

The present invention is a first trading system.
A trading system for transactions including remittance of virtual currency
The remittance of the virtual currency is confirmed after the transaction storing the remittance is broadcast to the virtual currency network and incorporated into a block of the virtual currency network, and the block is connected to the blockchain of the virtual currency network.
The trading system is communicably connected to one or more user systems, and can receive a remittance request, which is a remittance request from the virtual currency account, from the user system.
When the transaction system receives the predetermined remittance request, which is the remittance request, from the predetermined account, which is the account, the transaction system is the transaction that stores the remittance in response to the predetermined remittance request. To the virtual currency network
When the transaction system receives the subsequent remittance request, which is the remittance request from the predetermined account, from the user system when the predetermined transaction is broadcast with multiple signatures, the remittance request is made by the predetermined remittance request. Provided is a trading system that broadcasts the transaction storing the remittance to the virtual currency network in response to the subsequent remittance request regardless of whether the remittance is confirmed.

Further, the present invention is a first trading system as a second trading system.
The trading system sends a minimum fee to the user system and
The minimum fee provides a trading system that indicates the basis of the fee when the transaction is incorporated into the block.

Further, the present invention is a user system that is communicably connected to a second trading system as a first user system.
The user system provides a user system that transmits the transaction for which the minimum fee is specified as the reward amount in the remittance request to the transaction system.

Further, the present invention, as a first program,
A program for making a computer function as a first user system is provided.

Further, the present invention is a second trading system as a third trading system.
The user system can specify the fee in the remittance request.
The trading system provides a trading system that broadcasts the transaction in response to the remittance request when the designated fee satisfies the fee condition.

Further, the present invention is any of the first to third trading systems as the fourth trading system.
The trading system provides a trading system that, when the block connected to the blockchain is lost, rebroadcasts the transaction stored in the lost block.

According to the present invention, when the transaction system receives a subsequent remittance request after broadcasting a transaction in response to a predetermined remittance request, the transaction system accepts the subsequent remittance request regardless of whether or not the remittance by the predetermined remittance request is confirmed. .. Therefore, the user can continue to remit without waiting for the confirmation of the remittance in advance. According to the present invention, it is possible to provide a trading system capable of reducing the waiting time for trading using virtual currency.

It is a figure which shows the network of the trading system and the user system by embodiment of this invention. It is a figure which shows an example of the trading system of FIG. 1 together with an example of a user system and a schematic structure of a virtual currency network. It is a figure which shows an example of the data structure of the user key which the user system of FIG. 2 has. It is a figure which shows an example of the data structure of the user information which the transaction system of FIG. 2 has. The relationship with the user system is shown by the broken line. It is a figure which shows an example of the data structure of the trading account which the trading system of FIG. 2 has. The relationship with the account address of the user system and the relationship with the user-specific data of the user information are shown by broken lines. It is a figure which shows an example of the data structure of the deposit key which the transaction system of FIG. 2 has. The relationship between the account address of the user system and the first private key is shown by the broken line. It is a figure which shows the data structure of the transaction broadcast to the virtual currency network of FIG. 2 partially and schematically. It is a figure which shows a specific example of the transaction of FIG. It is a figure which shows the data structure of a block in the virtual currency network of FIG. 2 partially and schematically. It is a figure which shows an example of the data structure of the fee information which the transaction system of FIG. 2 has. It is a figure which shows the branch of a blockchain in the virtual currency network of FIG. It is a figure which shows the process performed between the transaction system, the user system and the virtual currency network of FIG. It is a flowchart which shows the process of the fee management server of the transaction system of FIG. It is a flowchart which shows the process of the transaction server of the transaction system of FIG. It is a flowchart which shows the process of the retry server of the trading system of FIG. It is a flowchart which shows the modification of the process of the user system of FIG.

Referring to FIGS. 1 and 2, the trading system 10 according to the embodiment of the present invention is for trading virtual currency based on blockchain technology (that is, decentralized virtual currency: hereinafter simply referred to as "virtual currency"). System. The transaction of virtual currency in the trading system 10 includes at least the remittance of virtual currency. That is, the trading system 10 is a trading system for transactions including remittance of virtual currency.

Referring to FIG. 1, the trading system 10 is communicably connected to one or more user systems 60 via various communication means. The communication means for connecting the trading system 10 and the user system 60 to each other is not particularly limited. For example, the user system 60 may be communicably connected to the trading system 10 by a wired communication network 92 in which communication lines such as optical fibers (not shown) and metal fibers (not shown) are combined, or may be a base. It may be communicably connected to the trading system 10 via a wireless communication network 94 controlled by a station (not shown). The wired communication network 92 and the wireless communication network 94 may be a part of the Internet. Further, the trading system 10 and the user system 60 may be systems within the same organization. In this case, the user system 60 may be communicably connected to the trading system 10 by a LAN (Local Area Network) 96.

Referring to FIG. 2, the user system 60 of the present embodiment includes a trading terminal 60T. The trading terminal 60T is a computer operated by a user. The user who operates the trading terminal 60T may be an individual or an organization such as a company. When the user is an individual, the trading terminal 60T may be, for example, a desktop PC (Personal Computer) or a smartphone. When the user is an organization, the user system 60 may be composed of a plurality of various server computers (hereinafter, simply referred to as "servers"). In this case, the trading terminal 60T may be the operating terminal of the server.

The trading terminal 60T of the present embodiment includes a trading application 62, a user key 64, an input device 66, and a display device 68. The transaction application 62 is a computer program (hereinafter, simply referred to as “program”) for causing the computer to function as the user system 60. The trading application 62 is stored in a storage device (not shown) of the trading terminal 60T. The transaction application 62 is executed after being loaded into a main storage device (not shown) by the CPU (Central Processing Unit) of the transaction terminal 60T, whereby the transaction terminal 60T functions as the user system 60. The trading application 62 of the present embodiment is installed on one trading terminal 60T. However, the present invention is not limited to this. For example, various functions of the trading application 62 may be distributedly installed on a plurality of computers. In this case, the transaction application 62 may make a plurality of computers function as the user system 60.

The user key 64 is data stored in a storage device (not shown) of the trading terminal 60T. The trading terminal 60T may include only one user key 64, or may include two or more user keys 64. The input device 66 is, for example, a keyboard or a touch panel. The display device 68 is, for example, a liquid crystal screen. The user of the user system 60 operates the transaction application 62 using the input device 66, thereby trading virtual currency using one or more user keys 64. Information regarding virtual currency transactions is displayed on the display device 68 in a timely manner.

Referring to FIG. 3 together with FIG. 2, in the present embodiment, the user key 64 is a data structure including a first private key 642, a first public key 644, and an account address 646. The first private key 642 and the first public key 644 are a pair of two keys in public key cryptography. The first private key 642 is used to sign the transaction of virtual currency, and the first public key 644 is used to verify the signature. The account address 646 is data for identifying an account of the virtual currency to be traded, and is generated from the first public key 644 using a publicly available algorithm. For example, when a user of the user system 60 remits virtual currency, the remittance source account of the virtual currency can be specified by the account address 646.

The user key 64 of the present embodiment is stored inside the user system 60 and has the above-mentioned data structure. However, the present invention is not limited to this. For example, the user key 64 may be stored outside the user system 60. More specifically, the user key 64 may be stored in a USB (Universal Serial Bus) memory owned by the user. In this case, the user system 60 may be a terminal installed in a public facility. Further, the account address 646 does not have to be included in the user key 64. In this case, the trading application 62 may generate an account address 646 from the first public key 644 each time it is needed. Further, the first private key 642 and the first public key 644 are not stored as electronic data, and even if only a paper document describing the first private key 642 and the first public key 644 exists. Good.

Referring to FIG. 2, the trading system 10 of the present embodiment is a system operated by an organization such as a company. The transaction system 10 includes a transaction server 20, a fee management server 30, a retry server 40, and a storage device 50. Each of the transaction server 20, the fee management server 30, and the retry server 40 is a computer operated by the operator of the transaction system 10. The storage device 50 is, for example, a magnetic disk. Each of the transaction server 20, the fee management server 30, and the retry server 40 is communicably connected to the storage device 50. That is, each of the transaction server 20, the fee management server 30, and the retry server 40 can write (store) data in the storage device 50, and can read (acquire) the data stored in the storage device 50. ).

The physical structure of the transaction server 20, the fee management server 30, the retry server 40, and the storage device 50 in the transaction system 10 is not particularly limited. For example, each of the transaction server 20, the fee management server 30, and the retry server 40 may be one computer or may be composed of two or more computers. Further, one computer may have all the functions of the transaction server 20, the fee management server 30, and the retry server 40. The storage device 50 may be one magnetic disk or may be composed of two or more magnetic disks.

The storage device 50 stores various data structures referred to by the trading system 10. In the present embodiment, as a data structure, the storage device 50 includes one or more user information 52 corresponding to the user system 60, and one or more transaction accounts 53 used for virtual currency transactions. One or more storage keys 54 corresponding to the user key 64 of the user system 60, fee information 56, and transaction storage space 58 are stored. However, the present invention is not limited to this. For example, in the storage device 50, in addition to the above-mentioned data structure, another data structure may be stored. On the other hand, each of the above-mentioned data structures may be stored in the storage device 50 as needed. Further, the data structure of the above-mentioned data structure is not limited to the data structure described below, and can be variously deformed.

Referring to FIG. 4 together with FIG. 2, the user information 52 includes one or more user-specific data 522 corresponding to the user system 60 and one or more users corresponding to the user-specific data 522. Authentication data 524 and the like are included. Each of the user-specific data 522 is data that can uniquely identify the corresponding user system 60. For example, each of the user identification data 522 is a user ID (identifier) or an e-mail address when the corresponding user system 60 creates an account of the transaction system 10. Each of the user authentication data 524 is data for authenticating the corresponding user system 60. Each of the user authentication data 524 may be, for example, a password or biometric information such as fingerprint information.

Referring to FIG. 5 together with FIG. 2, the trading account 53 includes one or more account addresses 532 corresponding to the account address 646 of the user system 60, and one or more user identification corresponding to the account address 532. Data 534 and are included. The same data as the corresponding account address 646 is stored in each of the account addresses 532. Each of the user-specific data 534 stores the same data as the user-specific data 522 that identifies the user system 60 having the corresponding account address 532 (account address 646).

The trading account 53 in the present embodiment is used to verify whether or not the account used for trading virtual currency is a legitimate account of a user who trades virtual currency. For example, when a user of a predetermined user system 60 (predetermined user system 60) tries to remit virtual currency from a predetermined account address 646 (predetermined account address 646), the predetermined account address 646 is any of the trading accounts 53. When the user-specific data 534 that matches the account address 532 and corresponds to the matched account address 532 matches the user-specific data 522 that corresponds to the predetermined user system 60, the transaction system 10 determines. It is determined that the account address 646 is the legitimate account of the user.

Referring to FIG. 6 together with FIG. 2, the deposit key 54 includes one or more account addresses 542 corresponding to the account address 646 of the user system 60, and one or more second secrets corresponding to the account addresses 542, respectively. Includes key 544 and. The same data as the corresponding account address 646 is stored in each of the account addresses 532. The second private key 544 is a private key for applying multiple signatures (multi-signature) to a virtual currency transaction. For example, when a user of the user system 60 tries to remit virtual currency from a predetermined account address 646 (predetermined account address 646), the user system 60 uses a first private key 642 corresponding to the predetermined account address 646. It is used to sign the virtual currency remittance, and the trading system 10 further signs the virtual currency remittance using the second private key 544 corresponding to the account address 542 that matches the predetermined account address 646.

As described above, according to the present embodiment, a multi-signature using two private keys (first secret key 642 and second secret key 544) corresponding to each other is applied to the transaction of virtual currency. To. However, the method of applying the multi-signature is not limited to the present embodiment and can be variously modified. Further, the multi-signature may not be adopted, and only the signature by the first private key 642 may be given to the transaction of the virtual currency. In this case, the trading system 10 does not have to include the second private key 544 corresponding to the first private key 642 used for signing.

The user system 60 and the trading system 10 trade virtual currencies with reference to the above-mentioned data structure. In particular, the transaction system 10 can receive a remittance request, which is a remittance request from a virtual currency account, from the user system 60.

Hereinafter, the basic flow from the occurrence to the confirmation of a transaction in which the user system 60 remits virtual currency to another user system 60 via the transaction system 10 will be described.

Referring to FIG. 2, first, the transaction application 62 of the user system 60 transmits a remittance request to the transaction system 10 in response to the operation of the user ((1) of FIG. 2). More specifically, the transaction application 62 creates a transaction 88 that stores the remittance, signs it with the first private key 642 (see FIG. 3), and transmits it to the transaction server 20 of the transaction system 10.

Generally, transactions such as remittance are stored in each transaction 88. As will be described later, the transaction system 10 broadcasts the transaction 88 whose validity has been confirmed to the virtual currency network 80. The transaction 88 broadcast by the trading system 10 is propagated to a large number of nodes included in the virtual currency network 80 and stored by each node. Further, the transaction system 10 stores the broadcast transaction 88 in the transaction storage space 58. A large number of nodes, including the trading system 10, propagate transactions 88 to each other to align the transactions 88 they have stored. That is, transaction 88 is managed in a decentralized manner by the virtual currency network 80, and there is no specific node that centrally manages all transactions 88. However, the present invention is also applicable when such a specific node exists.

FIG. 7 schematically shows only the data required in the following description among the data included in the transaction 88. Each transaction 88 includes n (n is an integer of 1 or more) input units 88I, m (m is an integer of 1 or more) output units 88O, and a fee 889. The data for identifying the remittance source account of the virtual currency and the data for guaranteeing the validity of the remittance source account are stored in each of the input units 88I. Data for specifying the remittance destination account of the virtual currency and data indicating the remittance amount of the virtual currency to the remittance destination account are stored in each of the output units 88O.

More specifically, each of the output units 88O includes a remittance destination address 886 and a virtual currency remittance amount 888. The remittance destination address 886 is data for identifying the remittance destination account of the virtual currency. Referring to FIG. 7 together with FIGS. 2 and 3, the remittance destination address 886 stores the account address 646 (remittance destination account address 646) of the user key 64 of the user system 60 of the remittance destination. In the virtual currency remittance amount 888, the remittance amount (a number larger than zero) to the remittance destination account address 646 is stored.

Each of the input units 88I includes a remittance source address 882 and signature data 884. The remittance source address 882 is data that identifies the remittance source account of the virtual currency. Specifically, the remittance source address 882 stores data that can identify the output unit 88O (preceding output unit 88O) of the transaction 88 (preceding transaction 88) broadcast prior to this transaction 88 (subsequent transaction 88). There is. The remittance destination address 886 of the advance output unit 88O of the preceding transaction 88 stores the remittance source account (remittance source account address 646) of the input unit 88I of the succeeding transaction 88. The signature data 884 is data for guaranteeing the validity of the remittance source account address 646, and is signed by the first private key 642 corresponding to the remittance source account address 646.

As will be described later, the fee 889 stores the incentive amount (numerical value of zero or more) of the virtual currency received by the miner who mined the transaction 88. In each transaction 88, the total deposit amount, which is the sum of the fee 889, the virtual currency remittance amount 888 of the n advance output units 88O specified by the remittance source address 882 of the n input units 88I, and m outputs. The total remittance amount, which is the sum of the virtual currency remittance amount 888 of the part 88O, satisfies the relational expression of fee 889 = total deposit amount-total remittance amount. As can be understood from this relational expression, the reward amount can be calculated from the total deposit amount and the total transfer amount even if the transaction 88 does not include the data of the fee 889. Therefore, transaction 88 may not include a data item with a fee of 889.

Referring to FIGS. 2 and 8, for example, a user of the user system 60 performs a part of the balance of account A (200 units of virtual currency) (150 units of virtual currency) after a transaction involving a preceding transaction 88. Transaction 88 (subsequent transaction 88) is transmitted to the transaction server 20 when the money is transferred to the account B.

Subsequent transaction 88 includes one input unit 88I and two output units 88O. The remittance source address 882 of the input unit 88I stores "address A" which is data for specifying the output unit 88O of the preceding transaction 88. In one of the output units 88O of the subsequent transaction 88, "account B" is stored in the remittance destination address 886, and "150" is stored in the virtual currency remittance amount 888. In the other one of the output units 88O of the subsequent transaction 88, "account A" is stored in the remittance destination address 886, and "49" is stored in the virtual currency remittance amount 888.

As can be understood from the structure of transaction 88 described above, each of the input units 88I of transaction 88 is linked to UTXO (Unspent Transaction Output) which is the output unit 88O of another transaction 88. That is, the transaction 88 is connected in a chain shape via the UTXO, thereby forming a transaction ledger.

With reference to FIG. 2, when the transaction system 10 receives the transaction 88 from the user system 60 ((1) in FIG. 2), the transaction system 10 checks the validity of the data stored in the transaction 88, as will be described later. The validity of transaction 88 is confirmed by. When the transaction system 10 determines that the data stored in the transaction 88 is appropriate, the second private key 544 (see FIG. 7) corresponding to the signature data 884 (see FIG. 7) of the transaction 88 with the sender address 882 (see FIG. 7). The transaction 88 is issued by signing according to (see FIG. 6) ((2) in FIG. 2). At this time, the transaction system 10 broadcasts the transaction 88 to the virtual currency network 80. The transaction 88 broadcast by the transaction system 10 is stored in the transaction storage space 58 of the transaction system 10 ((3) in FIG. 2).

As can be understood from the above description, one transaction 88 is broadcast to the virtual currency network 80 in response to one remittance of the virtual currency. That is, when the remittance is performed one or more times, one or more transactions 88 corresponding to the remittance are broadcast. One or more transactions 88 broadcast to the virtual currency network 80 are taken into the block 84 by the mining system 70, which is one of the nodes of the virtual currency network 80, and connected to the blockchain 82. In other words, the mining system 70 collectively creates one block 84 by collecting one or more transactions 88 that have not yet been incorporated into the block 84, and connects the created block 84 to the block chain 82. Further, the mining system 70 broadcasts the created block 84 to the virtual currency network 80.

The blockchain 82 is a chain composed of one or more blocks 84. When the blockchain 82 is in the normal state, all the blocks 84 form one continuous chain, and the block 84 newly created by the mining system 70 is connected to the end of the blockchain 82. .. For example, when the blockchain 82 is connected from the first block 84 (not shown) to the Kth block 84, the newly created block 84 is the Kth block 84 of the blockchain 82 as the K + 1th block 84. Is connected to the block 84 of. As a result, one or more transactions 88 included in the block 84 of the K + 1th block 84 are incorporated into the blockchain 82.

FIG. 9 schematically shows only the data required in the following description among the data contained in the block 84. Each of the blocks 84 includes a block header 84H and a transaction area 848. In the transaction area 848, one coinbase transaction 88C (described later) and one or more transactions 88 incorporated in the block 84 are stored. The block header 84H includes a block hash 842 and a nonce 846.

Referring to FIG. 9 together with FIG. 2, a newly created block 84 (K + 1st block 84 in FIG. 2) is connected to the block hash 842 (Kth block 84 in FIG. 2). The hash value of the block header 84H of is stored. This hash value is obtained by hashing the block header 84H with a hash algorithm that is open to the public (hereinafter, referred to as "predetermined hash algorithm").

When the block 84 is newly created, the mining system 70 repeatedly calculates the hash value of the block header 84H by using a predetermined hash algorithm while changing the setting value of the nonce 846 of the block 84. The mining system 70 repeats the calculation of the hash value until a predetermined hash value satisfying a predetermined condition is obtained. The mining system 70 sets the set value of the nonce 846 when the predetermined hash value is obtained to the nonce 846 of the block 84. That is, the nonce 846 stores a value such that a predetermined hash value can be obtained when the block header 84H is hashed.

Referring to FIG. 2, the above-mentioned new block 84 is created by the plurality of mining systems 70 in parallel. Each of the mining systems 70 includes a transaction storage space 78. Each of the transaction storage spaces 78 includes a blockchain 82 and a transaction 88 that has not been incorporated into the blockchain 82. When one of the mining systems 70 creates a new block 84 and broadcasts it, the other mining system 70 receives the broadcasted block 84, verifies the validity of the received block 84, and then validates it. The recognized block 84 is connected to the blockchain 82 of its own transaction storage space 78.

Similar to the mining system 70, the trading system 10 receives the block 84 broadcast by the mining system 70, verifies the validity of the received block 84, and then stores the block 84 whose validity is recognized in its own transaction storage space. Connect to the blockchain 82 of 58. Other nodes of the virtual currency network 80 perform the same processing.

The new block 84 is approved by being justified by a number of nodes in the crypto network 80. At this time, the block 84 is deterministically connected to the blockchain 82. The mining system 70 that created the approved block 84 can get a reward in virtual currency. Specifically, the mining system 70 creates a coinbase transaction 88C that stores the reward amount to be obtained when the block 84 is created, and together with the transaction 88 created in response to the transaction of the virtual currency, the transaction area 848 ( (See Fig. 9). The reward amount stored in the coinbase transaction 88C is an amount obtained by adding a predetermined predetermined reward amount to the total reward amount obtained by adding the commission 889 (see FIG. 7) of the transaction 88 incorporated in the block 84.

As described above, the virtual currency remittance transaction occurs when the user system 60 requests the remittance system 10 to remit. Further, the virtual currency remittance transaction is confirmed when the transaction 88 issued by the transaction system 10 is taken into the block 84 and the block 84 is connected to the blockchain 82 at a large number of nodes. In other words, the transfer of virtual currency from the user system 60 to another user system 60 is blocked by the transaction 88 that stores the transfer being broadcast to the virtual currency network 80 and taken into the block 84 of the virtual currency network 80. It is confirmed after 84 is connected to the blockchain 82 of the virtual currency network 80.

As can be understood from the above explanation, it takes a relatively long waiting time (for example, about 30 minutes to 1 hour) from the remittance request by the user system 60 ((1) in FIG. 2) to the confirmation of the remittance. Needs. Until the waiting time elapses, the balance of the account address 646 (see FIG. 3) used by the user system 60 for remittance is not fixed. Therefore, in order for the user system 60 to make the next remittance from this account address 646, it is necessary to wait for about 30 minutes to 1 hour. That is, a general remittance transaction of virtual currency is confirmed with a waiting time of about 30 minutes to 1 hour. On the other hand, the virtual currency remittance transaction is not confirmed no matter how long it waits unless the mining system 70 incorporates the transaction 88 by the remittance transaction into the new block 84.

Each of the mining systems 70 is operated by a miner such as a company. In general, miners create new blocks 84 with the goal of getting the highest possible bounty. Therefore, if the reward amount set in the transaction 88 fee 889 (see FIG. 7) is low, the transaction 88 is unlikely to be incorporated into block 84. In other words, by setting a high reward amount for the fee 889, the waiting time can be made relatively short. On the other hand, from the viewpoint of reducing the loss of the user due to the payment of the incentive, it is preferable to set the incentive amount as low as possible for the commission 889. Therefore, it is preferable to set an appropriate incentive amount for the fee 889, which is neither too low nor too high.

The storage device 50 of the transaction system 10 of the present embodiment stores the fee information 56 in addition to the user information 52, the transaction account 53, the deposit key 54, and the transaction storage space 58. According to this embodiment, the user system 60 can set an appropriate reward amount for the transaction 88 fee 889 (see FIG. 7), as described below.

Referring to FIG. 10 together with FIG. 2, the fee information 56 stores a minimum fee of 562. The minimum fee 562 indicates a criterion for the incentive amount for the miner when transaction 88 is incorporated into block 84 by the mining system 70, i.e., fee 889 (see FIG. 7). For example, the minimum fee 562 may be the absolute value of the incentive to be paid to the miner, or the incentive ratio according to the number of bytes in transaction 88. In this embodiment, the minimum fee 562 is set by the fee management server 30 of the trading system 10.

Referring to FIGS. 12 and 13, the fee management server 30 periodically monitors the virtual currency network 80, whereby the fees 889 (see FIG. 7) of the plurality of transactions 88 captured in the block 84 are periodically monitored. (1- (1) in FIG. 12 and S1302 in FIG. 13). For example, the fee management server 30 refers to the block 84 located at the end of the blockchain 82 (the Kth block 84 in FIG. 12) to acquire the fee 889 of the transaction 88 stored in the block 84.

Next, the fee management server 30 uses the acquired one or more fees 889 (see FIG. 4) to set the minimum amount or the minimum ratio (minimum) of the reward to be set in the fee 889 when the user system 60 creates the transaction 88. Reward) is calculated (1- (2) in FIG. 12 and S1304 in FIG. 13). Next, the fee management server 30 sets the calculated minimum reward to the minimum fee 562 (see FIG. 10) of the fee information 56 (1- (3) in FIG. 12 and S1306 in FIG. 13). Next, the fee management server 30 continues to regularly monitor the virtual currency network 80 (1- (1) in FIG. 12 and S1302 in FIG. 13).

The method by which the fee management server 30 seeks the minimum reward is not particularly limited. For example, the fee management server 30 may set the lowest value of the acquired fees 889 (see FIG. 4) as the lowest reward. On the other hand, the fee management server 30 may analyze the tendency of the reward paid to the miner from the acquired fee 889 and obtain the minimum reward accordingly. Further, the fee management server 30 may acquire the fee 889 from two or more blocks 84 located at the end of the blockchain 82.

With reference to FIGS. 12 and 14, when the user of the user system 60 activates the transaction application 62 (2- (1) in FIG. 12), the transaction application 62 indicates the user ID and the user ID to the transaction server 20. A login request including login data such as a password is transmitted (2- (2) in FIG. 12). When the transaction server 20 receives login data from the user system 60 (transaction application 62) (S1402 in FIG. 14), the transaction server 20 authenticates the user system 60 using the received login data (2- (FIG. 12-2). 3) and S1404 in FIG. For example, the transaction server 20 collates the user ID and password with the user identification data 522 (see FIG. 4) and the user authentication data 524 (see FIG. 4) of the user information 52 to perform the user system 60. Certify.

If the transaction server 20 cannot authenticate the validity of the user system 60 (NG in S1404 of FIG. 14), the transaction server 20 refuses to log in to the user system 60 (S1406 in FIG. 14). On the other hand, when the transaction server 20 can authenticate the validity of the user system 60 (OK in S1404 of FIG. 14), the balance of the account of the user system 60 and the minimum fee 562 stored in the fee information 56 (FIG. 14). 10) and (2 (4) in FIG. 12 and S1408 in FIG. 14).

For example, the transaction server 20 collates the user ID received from the user system 60 with the user identification data 534 (see FIG. 5) of the transaction account 53, so that one or more account addresses 532 of the user system 60. (See FIG. 5) is acquired. The transaction server 20 collates the acquired account address 532 with the remittance destination address 886 (see FIG. 7) of the transaction 88 stored in the transaction storage space 58, and the virtual currency remittance amount 888 to the account address 532 (FIG. 7). By obtaining (see), the balance corresponding to one or more acquired account addresses 532 is obtained.

The transaction server 20 transmits the balance of the account acquired as described above and the minimum fee 562 (see FIG. 10) to the user system 60 (transaction application 62) (2- (5) in FIG. 12 and S1410 in FIG. 14). ). The trading application 62 displays the balance of the received account and the minimum fee 562 (that is, an appropriate reward amount) on the display device 68 (2- (6) in FIG. 12). The user of the user system 60 can perform the remittance operation while referring to the displayed balance of the account and the appropriate incentive amount (2- (7) in FIG. 12).

In the remittance operation, the user of the user system 60 uses the input device 66 to input data such as the remittance source account, the remittance destination account, the remittance amount and the incentive amount (2- (7) in FIG. 12). .. The transaction application 62 checks the validity of the input data such as the remittance amount and the incentive amount (2- (8) in FIG. 12). For example, the trading application 62 displays an error message on the display device 68 when the input remittance amount exceeds the total balance of the remittance source account or the input incentive amount is less than the appropriate incentive amount. , Wait for valid data input (not shown). On the other hand, when the transaction application 62 determines that the input data is appropriate, it creates a transaction 88 based on the input data and the user key 64, sends it to the transaction server 20, and requests remittance by this. (2- (9) in FIG. 12).

When the transaction server 20 receives the transaction 88 associated with the remittance request from the user system 60 (transaction application 62) (S1420 in FIG. 14), the virtual currency remittance amount 888 (see FIG. 7) and the fee 889 (see FIG. 7) of the received transaction 88 (see FIG. 7). Check the validity of the data such as (see FIG. 7) (2- (10) in FIG. 12 and S1422 in FIG. 14). For example, the transaction server 20 determines that the input virtual currency remittance amount 888 exceeds the total balance of the remittance source account, or the fee 889 is less than the minimum fee 562 (see FIG. 10) (S1422 in FIG. 14). NG), the user system 60 (transaction application 62) is notified that the remittance cannot be made (S1424 in FIG. 14).

On the other hand, when the transaction server 20 determines that the received transaction 88 data is valid (OK in S1422 in FIG. 14), the transaction server 20 signs the received transaction 88 with the second secret key 544 (see FIG. 6). , Issue transaction 88 (2- (11) in FIG. 12 and S1426 in FIG. 14). At this time, the transaction server 20 broadcasts the transaction 88 to the virtual currency network 80. Further, the transaction server 20 stores the issued transaction 88 in the transaction storage space 58 (2- (12) in FIG. 12). Next, the transaction server 20 notifies the user system 60 (transaction application 62) of the completion of the remittance regardless of whether or not the remittance is confirmed (2- (13) in FIG. 12 and S1428 in FIG. 14). ..

Upon receiving the remittance completion notification from the transaction server 20, the transaction application 62 displays the remittance completion on the display device 68 (2- (14) in FIG. 12). As a result, the user of the user system 60 can know that the remittance has been confirmed, and can immediately perform the next remittance.

Referring to FIG. 12, as described above, according to the present embodiment, the user system 60 can specify the transaction 88 fee 889 (see FIG. 7) in the remittance request. The transaction system 10 broadcasts transaction 88 in response to a remittance request if the designated fee 889 satisfies the fee condition. On the other hand, the transaction system 10 does not broadcast the transaction 88 in response to the remittance request if the designated fee 889 does not meet the fee conditions. The fee condition in the present embodiment is a condition that the fee 889 ≧ the minimum fee 562 (see FIG. 10) stored in the fee information 56. However, the fee conditions are not limited to this. For example, the fee condition may be fee 889 ≥ transaction 88 size (number of bytes) × minimum fee 562 stored in fee information 56.

According to the present embodiment, when the user of the user system 60 requests remittance ((2-9) in FIG. 12), the reward amount to be set in the fee 889 (see FIG. 7) of transaction 88 is set. A reward amount equal to or greater than the appropriate reward amount displayed on the display device 68 can be input. In addition, the trading app 62 does not request the trading server 20 to transfer money if the entered reward amount is less than the appropriate reward amount. Further, the transaction server 20 does not issue transaction 88 if the fee 889 is less than the minimum fee 562 (see FIG. 10).

Due to the above-mentioned valid input by the user, validation by the trading application 62, and validation by the trading server 20, transaction 88, which is easily incorporated into the block 84 by the mining system 70, is transmitted to the virtual currency network 80. However, the present invention is not limited to this. For example, only one of the validation by the trading application 62 and the validation by the trading server 20 may be performed. Further, it is not necessary to verify the validity by the trading application 62 and the validity by the trading server 20.

With reference to FIGS. 12 and 16, the functions of the trading application 62 (user system 60) can be further modified. For example, the trading application 62 according to the modified example receives the balance of the account and the minimum fee 562 (see FIG. 10) from the trading system 10 (see 2- (5) and FIG. 16 of FIG. 12), as in the above-described embodiment. S1602) and the balance of the received account and the minimum fee 562 are displayed on the display device 68 (2- (6) in FIG. 12). Next, the transaction application 62 according to the present modification waits until the remittance operation by the user of the user system 60 is detected, as in the above-described embodiment (NO in S1604 of FIG. 16).

According to this modification, the user of the user system 60 inputs data such as the remittance source account, the remittance destination account, and the remittance amount in the remittance operation (2- (7) in FIG. 12), while the reward amount. Do not enter. When the transaction application 62 according to this modification detects the remittance operation by the user (YES in S1604 of FIG. 16), it checks the validity of the input data such as the remittance amount, but does not check the validity of the reward amount. (S1606 in FIG. 16).

When the transaction application 62 according to this modification determines that the input data is appropriate, it creates a transaction 88 based on the input data and the user key 64, sends it to the transaction server 20, and remits money thereby. Request (2- (9) in FIG. 12). At this time, the transaction application 62 according to this modification creates and transmits a transaction 88 for which a minimum fee of 562 (see FIG. 10) is specified (S1608 in FIG. 16). For example, the minimum fee 562 may be set and specified as the transaction 88 fee 889 (see FIG. 7). On the other hand, if transaction 88 does not include a data item for fee 889, the minimum fee 562 may be specified by adjusting the total remittance amount to be the total deposit amount minus the minimum fee 562.

As described above, the user system 60 according to the present modification transmits the transaction 88 to which the minimum fee 562 (see FIG. 10) is specified as the reward amount in the remittance request to the transaction system 10. Also in this modification, the transaction 88, which is easily incorporated into the block 84 by the mining system 70, can be transmitted to the virtual currency network 80.

With reference to FIG. 12, as described above, when the transaction system 10 receives a predetermined remittance request, which is a remittance request from a predetermined account, which is an account of the user system 60, the transaction system 10 receives a predetermined remittance request. In response to this, a predetermined transaction 88, which is a transaction 88 that stores the remittance, is broadcast to the virtual currency network 80. When the transaction system 10 receives a subsequent remittance request, which is a remittance request from the predetermined account, from the user system 60 after broadcasting the predetermined transaction 88, regardless of whether or not the remittance by the predetermined remittance request is confirmed. In response to the subsequent remittance request, the transaction 88 that stores the remittance is broadcast to the virtual currency network 80.

According to the present invention, when the transaction system 10 receives a subsequent remittance request after broadcasting transaction 88 in response to a predetermined remittance request, the subsequent remittance request is made regardless of whether or not the remittance by the predetermined remittance request is confirmed. Accept. Therefore, the user can continue to remit without waiting for the confirmation of the remittance in advance. According to the present invention, it is possible to provide a trading system 10 capable of reducing the waiting time for trading using virtual currency.

In particular, when the transaction system 10 of the present embodiment receives a subsequent remittance request, which is a remittance request from the predetermined account, from the user system 60 after the predetermined transaction 88 is broadcast with multiple signatures, it is predetermined. Regardless of whether or not the remittance by the remittance request is confirmed, the transaction 88 that stores the remittance is broadcast to the virtual currency network 80 in response to the subsequent remittance request.

According to this embodiment, the remittance request from the predetermined account of the user system 60 is always made via the transaction system 10. Based on this premise, the transaction system 10 can trust the balance of the predetermined account and can accept the subsequent remittance request regardless of whether or not the remittance by the predetermined remittance request is confirmed. In addition, according to the present embodiment, the trading system 10 does not keep the virtual currency of the predetermined account of the user system 60, and the second private key 544 of the predetermined account of the user system 60 (see FIG. 6). I keep only. That is, the trading system 10 has only one of the keys required for remittance from a predetermined account. With this configuration, it is possible to prevent illegal remittance by the operator of the trading system 10 and prevent theft of virtual currency from the outside of the trading system 10. However, the present invention is not limited to this, and can be applied to a remittance request that does not use multiple signatures.

The trading system 10 may have various functions in addition to the functions already described.

For example, referring to FIG. 11, two mining systems 70 (see FIG. 2) have two blocks 84 (K + 1th in FIG. 11) in block 84 (Kth block 84 in FIG. 11) at the end of the blockchain 82. The two blocks 84) may be connected to each other. As a result, the blockchain 82 branches into two chains (a broken line chain and a solid line chain in FIG. 11). When the blockchain 82 branches, a new block 84 is further connected to each of the chains, which extends each of the chains. When one of the chains (solid chain in FIG. 11) extends to a predetermined length, the block chain 82 is rolled back and the block 84 (broken line in FIG. 11) of the other chain (dashed chain in FIG. 11). K + 1st block 84 and K + 2nd block 84) in the chain may be lost.

When the block 84 is lost, the transaction 88 captured in the lost block 84 is also lost, which means that there was no virtual currency transaction. As described below, the transaction system 10 of the present embodiment confirms the stored transaction even when the transaction 88 in which the transaction using the virtual currency is stored disappears after being incorporated into the blockchain 82. it can.

With reference to FIGS. 12 and 15, the retry server 40 of the trading system 10 periodically monitors whether or not the block 84 connected to the blockchain 82 has disappeared (3- (1) of FIG. 12 and FIG. 15). S1502). For example, the retry server 40 detects the disappearance of the original block 84 when the block hash 842 (see FIG. 9) of the block 84 connected to the block chain 82 changes. When the retry server 40 detects the loss of the block 84 connected to the blockchain 82 (3- (2) in FIG. 12 and S1504 in FIG. 15), the retry server 40 reissues the transaction 88 stored in the lost block 84. (Broadcast) (3- (3) in FIG. 12 and S1506 in FIG. 15).

As described above, when the block 84 connected to the blockchain 82 is lost, the trading system 10 of the present embodiment broadcasts the transaction 88 stored in the lost block 84 again. Since the transaction system 10 functions in this way, the transactions stored in the transaction 88 broadcast by the transaction system 10 are always fixed with the passage of time. Therefore, it is possible to notify the user system 60 of the confirmation of the transaction without waiting for the actual confirmation of the transaction.

As described above, according to the transaction system 10 of the present embodiment, it is possible to guarantee that the remittance transaction is confirmed with respect to the user system 60. For example, even if a rollback occurs in the blockchain 82, the user system 60 does not need to redo the remittance. Further, when remittance is made from a predetermined account of the user system 60 to a predetermined account of another user system 60, the transaction system 10 can guarantee that the remittance transaction is confirmed to the other user system 60 as well. For example, when the user of the other user system 60 is a retail store and the user of the user system 60 is a consumer, the retail store transfers the product to the consumer at the same time as the transfer of the virtual currency from the consumer. Can be provided with peace of mind.

10 Trading system 20 Trading server 30 Fee management server 40 Retry server 50 Storage device 52 User information 522 User specific data 524 User authentication data 53 Trading account 532 Account address 534 User specific data 54 Deposit key 542 Account address 544 Second Private key 56 Fee information 562 Minimum fee 58 Transaction storage space 60 User system 60T Trading terminal 62 Trading application 64 User key 642 1st private key 644 1st public key 646 Account address 66 Input device 68 Display device 70 Mining system 78 Transaction Storage space 80 Virtual currency network 82 Blockchain 84 Block 84H Block header 842 Block hash 846 Nance 848 Transaction area 88 Transaction 88C Coin-based transaction 88I Input unit 882 Remittance source address 884 Signed data 88O Output unit 886 Remittance destination address 888 Virtual currency remittance amount 889 Fee 92 Wired communication network 94 Wireless communication network 96 LAN

Claims (3)

A trading system for transactions including remittance of virtual currency
The remittance of the virtual currency is confirmed after the transaction storing the remittance is broadcast to the virtual currency network and incorporated into a block of the virtual currency network, and the block is connected to the blockchain of the virtual currency network.
The trading system is communicably connected to one or more user systems, and can receive a remittance request, which is a remittance request from the virtual currency account, from the user system.
When the transaction system receives the predetermined remittance request, which is the remittance request, from the predetermined account, which is the account, the transaction system is the transaction that stores the remittance in response to the predetermined remittance request. To the virtual currency network
When the transaction system broadcasts the predetermined transaction with multiple signatures, and then receives a subsequent remittance request, which is the remittance request from the predetermined account, from the user system, the said remittance request is made. Regardless of whether the remittance is confirmed or not, in response to the subsequent remittance request, the transaction that stores the remittance is broadcast to the virtual currency network .
The trading system re-broadcasts the transaction stored in the lost block when the block connected to the blockchain is lost . The trading system according to claim 1.
The trading system sends a minimum fee to the user system and
The minimum fee is a trading system that indicates a standard of fees when the transaction is incorporated into the block. The trading system according to claim 2.
The user system can specify the fee in the remittance request.
The transaction system is a transaction system that broadcasts the transaction in response to the remittance request when the designated fee satisfies the fee condition.

Images