KR102052835B1 - Recipient-oriented transaction verification method and apparatus for preventing double spending - Google Patents

Abstract

The present invention provides a recipient-oriented transaction verification method for preventing double expenditure and an apparatus thereof. According to the present invention, the recipient-oriented transaction verification method comprises: a step of using a public key of a recipient to generate a unique one-time public key if a transmitter node inputs details for generation of a transaction, wherein the generated transaction is transmitted to a node participating in a network in a non-approval state; a step in which the recipient node uses the unique one-time public key to detect a transaction transferred to the recipient node; a step in which the recipient node uses the recipient private key to verify validity of the detected transaction; a step in which the recipient node changes the transaction with verified validity to an approval state; and a step in which the recipient node sets a time of dissemination to a node participating in a network of the transaction changed to the approval state.

Description

Recipient-oriented transaction verification method and apparatus for preventing double spending

The present invention relates to a recipient-oriented transaction for preventing double spending, and more particularly, to a method and apparatus capable of preventing a double payment problem by a malicious node in a private blockchain.

Bitcoin first emerged as a cryptocurrency that allows untrusted participants to conduct secure transactions without relaying to a trusted central third party.

Blockchain technology is a logical way of keeping transactions secure in a distributed network environment. Even so, there is a weakness in the trading process where tokens are exchanged between participants.

In traditional cryptocurrencies such as Bitcoin, digital signatures are used to prove the owner of the token and show it to the sender of the transaction.

However, the receiver cannot intervene to verify the legitimacy of the token. This asymmetry prevents digital signatures from properly addressing double payment issues.

For example, if a sender owns one token and uses a previously used token to send a transaction to multiple recipients with the sender's signature, the multiple recipients can confirm that the sender sent the transaction. The receiver does not know whether this is a double payment transaction.

The problem is that only transactions that are considered valid are recorded in the distributed ledger. There is also no basis for what kind of transactions should be accepted.

Therefore, the receiver must determine whether the transaction between senders is correct.

In addition, even if the recipient has confirmed that the transaction is recorded in the ledger, there is a possibility of invalidating the transaction using a structure that recognizes the longer blockchain as the default valid chain.

This problem can occur in private blockchains, which are led by only authorized users during the read, write and consensus process. In private blockchains, not only token transactions, but also asset transactions between companies occur. Various studies have already been carried out to prevent attacks on private blockchains, but do not consider the asymmetry of the receiver and sender.

In order to solve the above problems of the prior art, we propose a receiver-oriented transaction for preventing double spending in a private blockchain considering the asymmetry of the receiver and the sender.

In order to achieve the above object, according to an embodiment of the present invention, as a receiver-oriented transaction verification method for preventing double payment in the blockchain of the receiver node, which is a computing device, the sender node inputs the details for creating a transaction The receiver node generates a unique one-time public key using the recipient's public key, wherein the generated transaction is sent to a node participating in the network in an unapproved state; Detecting, by the recipient node, a transaction delivered to it using the unique one-time public key; Validating, by the receiver node, the detected transaction using a receiver private key; The receiver node changing the validated transaction to an approved state; And setting a propagation point of time to the node participating in the network of the transaction in which the receiver node has changed to the approved state.

The unique one-time public key may be generated by mixing the receiver's account information and any data.

The unique one-time public key may be defined as a stealth address for the recipient node to access the detected transaction.

Validation of the receiver node generates a public key of the transaction by calculating the receiver private key by a predetermined encryption algorithm, and determines whether the public key of the generated transaction matches the public key of the receiver It can be performed as.

According to another aspect of the present invention, a receiver-oriented transaction verification apparatus for preventing double payment in a blockchain, the communication unit for receiving a transaction and a unique one-time public key generated by the sender node-the unique one-time public key is the recipient-oriented Generated using a public key of a transaction verification device, the transaction being received in an unapproved state; A validating unit for validating the detected transaction using its private key; And a state changer for changing the validated transaction to an approved state. And a propagation time setting unit for setting a propagation time of a transaction changed to the approved state.

According to the present invention, when generating a sender's transaction, a unique one-time public key can be generated, an authorized recipient can change the transaction to an approved state using the public key described above, and set a propagation time of the transaction changed to the approved state This prevents the occurrence of double payment transactions.

1 is a diagram showing the configuration of a receiver-oriented transaction verification system according to an embodiment of the present invention.
2 is a flowchart of a receiver oriented transaction verification process according to an embodiment of the present invention.
3 is a diagram illustrating a configuration of a receiver node according to an exemplary embodiment of the present invention.

As the present invention allows for various changes and numerous embodiments, particular embodiments will be illustrated in the drawings and described in detail in the written description.

However, this is not intended to limit the present invention to specific embodiments, it should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the present invention.

1 is a diagram showing the configuration of a receiver-oriented transaction verification system according to an embodiment of the present invention.

As shown in FIG. 1, the system according to the present embodiment includes a sender node 100 that generates a transaction, a receiver node 102 that accepts the sender's transaction and determines a propagation time, and a network participating node 104-n. It may include.

In a blockchain network, multiple nodes can participate to process transactions such as issuing, paying, and paying virtual currency. For example, a transaction may represent a transaction identifier including cryptocurrency transaction information (information related to deposit and withdrawal), a hash value, and the like.

The transceiver node and the network participating nodes are used as desktop PCs, laptops, smartphones, tablets, etc., and can install dedicated applications or web-based programs to participate in the blockchain network.

Hereinafter, for convenience of description, the sender node is referred to as a 'sender' and the receiver node is referred to as a 'receiver'.

Receiver-oriented transaction verification in accordance with the present invention allows the receiver to directly verify and broadcast (propagate) the validity of a transaction before writing the transaction to a block.

In this case, two concepts, a stealth address and a master node, are included.

A stealth address guarantees the recipient's personal information, which is a unique one-time public key that is a combination of the recipient's public key and any data. Here, the public key of the receiver may be personal information such as account information of the receiver.

In the algorithm according to the present embodiment, the stealth address is used to indicate an address for the receiver to access the transaction.

When the sender creates a transaction, a unique one-time air catch of the transaction is automatically generated. When a unique one-time public key is delivered to the receiver, the receiver can access the transaction using the unique one-time public key. The receiver's private key is used for transactional access.

The transaction can then be approved and the transaction propagated through the receiver's private key.

The master node performs special tasks different from other normal nodes. Here, the special task may be a paid service such as InstantSend.

According to this embodiment, the receiver plays the role of a master node for his transaction. The receiver verifies the transaction. If the receiver acknowledges that the transaction is intact, the transaction is locked and approved.

Thus, the locked resource is filtered while other recipients confirm.

The present invention is such that at the locked time the sender cannot predict the locked and grant time. In other words, the recipient can set the propagation time of the transaction changed to the approved state to prevent the double payment problem by the malicious node.

Hereinafter, the stealth address, the master mode and the operation process according to the present embodiment will be described in detail.

Stealth Address: A stealth address uses a unique one-time public key that combines arbitrary data and the recipient's public view key and public spend key.

Every transaction automatically generates its own stealth address, important information such as who can use the money in that transaction.

The recipient can then detect the information using the recipient's private key.

Master node: The master node plays the role of endorsement and arbitration for InstantSend and PrivateSend. In this embodiment, the receiver plays the role of a master node.

The PrivateSend task mixes incoming transactions to make it impossible to track incoming transactions. The master node immediately acknowledges the transaction through the InstantSend operation.

However, because the master node does not create a block, the transaction must be included in a later block.

Instead, when writing to a block, name it with a special mark.

To prevent double payments before a transaction is written to the block, the master node changes and locks the state of the transaction so that resources are not paid multiple times in the blockchain network.

In this embodiment, a receiver-oriented method is proposed so that the receiver can perform a check on a transaction using this concept.

According to one preferred embodiment of the present invention, each transaction is completed only if the receiver determines that the transaction is valid within a fixed wait time.

That is, the transaction is completed when the receiver changes the transaction to the approved state and waits for the set propagation time to determine that it is valid for the waiting time.

2 is a flowchart of a receiver oriented transaction verification process according to an embodiment of the present invention.

Referring to FIG. 2, the sender Sender A inputs information necessary for transaction details as in the existing distance process (step 200).

The sender generates a unique one-time public key for the transaction using the recipient's public key (step 202).

The sender creates the transaction in an unauthorized state (step 204).

The sender then delivers a unique one-time public key to the receiver (step 206).

The receiver detects a transaction delivered to the receiver using the unique one-time public key described above in step 204 (step 208).

The receiver performs validation of the transaction (step 210).

Once validated, the receiver changes the transaction to the approved state using the recipient's private key (step 212).

Here, the validation may be a process of decrypting the public key through the receiver private key by a predetermined encryption algorithm, through which the receiver can access the transaction.

After changing the transaction state, the receiver sets the propagation time (step 214).

The approved transaction is broadcast after the set propagation time (step 216).

The process after the broadcast of the transaction is the same as the conventional process.

3 is a diagram illustrating a configuration of a receiver node according to an exemplary embodiment of the present invention.

As shown in FIG. 3, the receiver node according to the present embodiment may include a communication unit 300, a validity verification unit 302, a state change unit 304, and a propagation time setting unit 306.

The communication unit 300 receives a transaction generated by the sender node 100 and a unique one-time public key. Here, the unique one-time public key is generated using the public key of the receiver-oriented transaction verification apparatus, and the transaction is in an unapproved state.

The communication unit 300 also performs a process of broadcasting a transaction in which the approval is completed as follows.

The validator 302 validates the detected transaction using its private key.

The state change unit 304 changes the validated transaction to the approved state.

The propagation time setting unit 306 sets the propagation time of the transaction changed to the approved state.

The method according to this embodiment is similar to the existing blockchain, but the receiver intervenes during the verification and propagation of the transaction. According to this embodiment, in order to prevent malicious delay of the receiver, a fixed wait time may be set to initiate a transaction. In this case, the transaction is automatically returned to the sender.

-Stealth address and master node adaptation

According to this embodiment, the sender waits for the receiver since all transactions are initially "unapproved". Transaction and propagation state can be performed using the recipient's private key and a unique one-time public key.

The process of obtaining a unique one-time address T that allows the receiver to detect and control the transaction is as follows.

1. Recipient's public key:

2. Sender's public key:

3. Presence of shared key S using Diffie-Hellmann:

및 개인키

:

및

4. Stealth Address

And private key

:

And

5. The receiver gets the transport address T to detect the transaction:

는 수신자의 개인키,

는 송신자의 개인키이며, H는 해쉬함수, H`는 또 다른 해쉬함수이다. here,

Is the recipient's private key,

Is the sender's private key, H is the hash function, and H` is another hash function.

If the receiver attempts to access the transaction using a unique one-time address T, the transaction checks whether the receiver private key can generate the transaction's public key by calculating the recipient private key using elliptic curve encryption.

If the generated public key exactly matches the transaction's public key, the receiver is authenticated.

In other words, through the generated address T, only the transaction receiver is authorized to process the transaction process.

-Approval and delay

The transaction receiver approves the transaction by determining whether the resource used in the transaction is valid, such as a token. This allows the propagation of a transaction to begin with the receiver, not the sender. According to this embodiment, it is possible to prevent the sender from distributing multiple double payment transactions over the network.

At this time, since the transaction confirmation time is hidden, it is difficult for the cooperative malicious node to transmit the double payment transaction as soon as the normal node approves. Even if the acknowledgment is correct, double payment prevention can be achieved by a sequence that allows the recipient to set the propagation time after the acknowledgment.

The embodiments of the present invention described above are disclosed for the purpose of illustration, and those skilled in the art having various ordinary knowledge of the present invention may make various modifications, changes, and additions within the spirit and scope of the present invention. Should be considered to be within the scope of the following claims.

Claims (7)

A receiver-oriented transaction verification method for preventing double payment in the blockchain of a receiver node, which is a computing device,
When the sender node inputs details for creating a transaction, the receiver node generates a unique one-time public key by using the receiver's public key. The generated transaction is transmitted to a node participating in the network in an unapproved state. -;
Detecting, by the recipient node, a transaction delivered to it using the unique one-time public key;
The receiver node validating the detected transaction using a receiver private key;
The receiver node changing the validated transaction to an approved state; And
Establishing a propagation point to a node participating in the network of the transaction in which the recipient node has changed to the approved state. The method of claim 1,
And said unique one-time public key is generated by mixing account information and arbitrary data of a recipient. The method of claim 2,
And wherein said unique one-time public key is defined as a stealth address for said recipient node to access said detected transaction. The method of claim 1,
Validation of the receiver node generates a public key of the transaction by calculating the receiver private key by a predetermined encryption algorithm, and determines whether the public key of the generated transaction matches the public key of the receiver -Oriented transaction verification method performed by the server. Recipient-oriented transaction verification device for preventing double payment in blockchain,
A communication unit for receiving a transaction generated by a sender node and a unique one-time public key, wherein the unique one-time public key is generated using the public key of the receiver-oriented transaction verification apparatus, and the transaction is received in an unapproved state;
A validator for verifying, using its private key, the validity of a transaction detected to be delivered to the user using the unique one-time public key; And
A state changer for changing the validated transaction to an approved state; And
And a propagation time setting unit for setting a propagation time of the transaction changed to the approved state. The method of claim 5,
And said unique one-time public key is generated by mixing account information and arbitrary data of a recipient. The method of claim 6,
And the unique one-time public key is defined as a stealth address for the recipient-oriented transaction verification device to access the detected transaction.

Images