Method for hiding receiver address and verifying transaction attribution

Abstract

The invention discloses a method for hiding a receiver address and verifying transaction attribution, and the method comprises the steps: a receiver generates and discloses a receiver original address, and the receiver original address comprises a first receiver public key and base point indication information corresponding to a public base point; the sender obtains the original address of the receiver and generates a corresponding target receiver hidden address so as to construct a UTXO transaction based on the target receiver hidden address; the target receiver hidden address comprises a locking public key which is different from a public key contained in the receiver original address, a sender public key, and verification information which can be verified by a shared secret; for any UTXO transaction in the block chain, the receiver performs point multiplication calculation on a first receiver private key and a sender public key in a receiver hidden address of the any UTXO transaction, and verifies verification information in the receiver hidden address of the any UTXO transaction based on a calculation result; and if the verification is successful, the receiver determines that the receiver is the receiver of any UTXO transaction.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a method for hiding a recipient's address and verifying transaction ownership. Background Art

[0002] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. In the blockchain system, data blocks are combined into a chain data structure in a sequential manner according to time sequence, and a distributed ledger that cannot be tampered with or forged is guaranteed by cryptography. Due to the characteristics of blockchain such as decentralization, information cannot be tampered with, and autonomy, blockchain has also received more and more attention and application.

[0003] The Unspent Transaction Output (UTXO) model is a common transaction model in blockchain. The sender can transfer funds to the receiver by initiating a UTXO transaction in the blockchain system and including the receiver's corresponding receiving address in the UTXO transaction. Summary of the invention

[0004] In view of this, this specification provides a method for hiding the recipient address and verifying transaction ownership to address the deficiencies in the related art.

[0005] Specifically, this specification is implemented through the following technical solutions:

[0006] According to a first aspect of an embodiment of this specification, a method for hiding a recipient address and verifying transaction attribution is provided, comprising:

[0007] The receiver generates and discloses the receiver's original address, wherein the receiver's original address includes a first receiver's public key and base point indication information corresponding to a public base point, wherein the first receiver's public key is a point multiplication result of a first receiver's private key maintained by the receiver and the public base point;

[0008] The sender obtains the original address of the receiver and generates a corresponding hidden address of the target receiver to construct a UTXO transaction based on the hidden address of the target receiver; the hidden address of the target receiver includes a locked public key different from the public key contained in the original address of the receiver, a sender public key, and verification information that can be verified by a shared secret, wherein: the sender public key is the point product of the sender private key maintained by the sender and the public base point determined based on the base point indication information, and the shared secret is the point product of the first receiver public key and the sender private key;

[0009] For any UTXO transaction in the blockchain, the receiver performs a dot product calculation on the first receiver's private key and the sender's public key in the receiver's hidden address of any UTXO transaction, and verifies the verification information in the receiver's hidden address of any UTXO transaction based on the calculation result; if the verification is successful, the receiver determines that it is the receiver of any UTXO transaction.

[0010] According to a second aspect of an embodiment of this specification, a method for hiding a recipient address is provided, which is applied to a sender, and the method includes:

[0011] Obtaining a receiver's original address disclosed by the receiver, the receiver's original address including a first receiver's public key and base point indication information corresponding to a public base point, the first receiver's public key being a point multiplication result of a first receiver's private key maintained by the receiver and the public base point;

[0012] Generate a target recipient hidden address corresponding to the recipient original address to construct a UTXO transaction based on the target recipient hidden address; the target recipient hidden address includes a locked public key different from the public key contained in the recipient original address, a sender public key, and verification information that can be verified by a shared secret, wherein: the sender public key is a point product of a sender private key maintained by the sender and a public base point determined based on the base point indication information, and the shared secret is a point product of the first recipient public key and the sender private key.

[0013] According to a third aspect of an embodiment of this specification, a method for verifying transaction attribution is applied to a verifier; the method includes:

[0014] Obtain a UTXO transaction to be verified; the UTXO transaction to be verified is constructed by the sender based on the target recipient hidden address, and the target recipient hidden address is generated by the original recipient address disclosed by the sender to the recipient; the original recipient address includes a first recipient public key and base point indication information corresponding to a public base point, and the first recipient public key is the point product result of the first recipient private key maintained by the recipient and the public base point; the target recipient hidden address includes a locked public key different from the public key contained in the original recipient address, a sender public key, and verification information that can be verified by a shared secret, wherein: the sender public key is the point product result of the sender private key maintained by the sender and the public base point determined based on the base point indication information, and the shared secret is the point product result of the first recipient public key and the sender private key;

[0015] The private key maintained by the target object is multiplied by the sender's public key in the target recipient's hidden address, and the verification information in the target recipient's hidden address is verified based on the calculation result; if the verification is successful, the target object is determined to be the recipient of the UTXO transaction to be verified.

[0016] According to a fourth aspect of an embodiment of this specification, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the steps of the method described in the first aspect, the second aspect, and / or the third aspect are implemented.

[0017] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided, on which a computer program is stored, and when the program is executed by a processor, the steps of the method described in the first aspect, the second aspect and / or the third aspect are implemented.

[0018] According to the sixth aspect of the embodiments of this specification, a computer program product is provided, comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method described in the first aspect, the second aspect and / or the third aspect.

[0019] In the technical solution provided in this specification, although the receiver needs to disclose its original receiver address, the original receiver address is not directly used as the receiving address of the UTXO transaction created by the sender, and the public key contained in the original receiver address is not directly used as the locked public key in the above-mentioned receiving address. Instead, the sender replaces the original receiver address with the corresponding target receiver hidden address, and ensures that the locked public key is different from the public key contained in the original receiver address. Therefore, except for the receiver and the sender, any third party will not be able to establish an association relationship between the locked public key and the public key contained in the original receiver address when viewing the locked public key contained in the receiving address (i.e., the target receiver hidden address) of the UTXO transaction, and will not be able to infer the identity of the real receiver of the UTXO transaction, thereby achieving privacy protection for the receiver.

[0020] At the same time, by carrying the base point indication information in the receiver's original address, the receiver and the sender can generate the first receiver public key and the sender public key respectively based on the same common base point, and then by carrying the first receiver public key in the receiver's original address and the sender public key in the target receiver hidden address, the sender can perform a dot multiplication of the first receiver public key and the sender private key to generate a shared secret and then generate corresponding verification information, and the receiver can perform a dot multiplication of the first receiver private key and the sender public key to generate a shared secret and then verify the verification information in the receiver hidden address of the UTXO transaction, thereby accurately identifying the corresponding target receiver hidden address and finding the UTXO transaction sent to itself, that is, this manual will not affect the normal transfer process based on UTXO transactions, and no third party can complete the verification process.

[0021] In addition, the above technical solution only involves the sender and the receiver in the entire process of constructing UTXO transactions and verifying transaction ownership, and does not need to expose private information to any third party, which has extremely high privacy security. Moreover, each UTXO transaction can be created, submitted and verified independently, without the need to establish a connection with other UTXO transactions, such as no need to wait for other UTXO transactions, no need to mix and submit with other UTXO transactions, and no need to involve other UTXO transactions in the verification process. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 It is a flowchart of a method for hiding a recipient's address and verifying transaction ownership, shown in an exemplary embodiment of this specification;

[0023] Figure 2 It is a flowchart of a method for hiding a recipient's address shown in an exemplary embodiment of this specification;

[0024] Figure 3 It is a flowchart of a method for verifying transaction ownership shown in an exemplary embodiment of this specification;

[0025] Figure 4 is a schematic diagram of the structure of an electronic device shown in an exemplary embodiment of this specification;

[0026] Figure 5 It is a structural schematic diagram of a device for hiding a recipient's address as shown in an exemplary embodiment of this specification;

[0027] Figure 6 It is a structural diagram of a device for verifying transaction ownership shown in an exemplary embodiment of this specification. DETAILED DESCRIPTION

[0028] Blockchains can use different transaction models to record transactions between users. Exemplary transaction models include the UTXO model described above. In the UTXO model, each UTXO transaction contains one or more outputs, each of which can be called a UTXO. Each UTXO defines the address of the recipient and the amount transferred, so that only the recipient can control the amount transferred by the UTXO. Specifically, the recipient can create another UTXO transaction, which contains one or more inputs, each of which references a UTXO that the recipient can control (i.e., the output of a previously executed UTXO transaction), and when the UTXO transaction is executed, the UTXO referenced by these inputs will be marked as spent and cannot be used again.

[0029] In the UTXO model, a locked public key is used to indicate the address of the recipient corresponding to each UTXO. The recipient generates a set of public-private key pairs in advance through an asymmetric encryption and decryption algorithm. The recipient maintains the private key and makes the corresponding public key public. Accordingly, the sender can obtain the public key disclosed by the recipient, and when it is necessary to transfer money to the recipient through a UTXO transaction, create a UTXO transaction based on the obtained public key, so as to use the public key or its derivative data as the locked public key corresponding to the output of the UTXO transaction. For example, the derivative data can be the hash calculation result of the public key, that is, the public key hash.

[0030] In some embodiments, the locking public key does not exist alone in the output of the UTXO transaction, but is included in the public key script (Public Key Script) in the output. The public key script is also called the locking script. The public key script is used to indicate the conditions for unlocking the corresponding output, and usually contains the locking public key and some operation codes. An exemplary public key script may include:

[0031] OP_DUP

[0032] OP_HASH160

[0033] [PubKeyHash]

[0034] OP_EQUALVERIFY

[0035] OP_CHECKSIG

[0036] The function of the operation code OP_DUP is to copy the top element of the stack. Here, if the input of another UTXO transaction references the output, the operation code OP_DUP is specifically used to copy the signature and public key contained in the input.

[0037] The function of the opcode OP_HASH160 is to perform a hash calculation on the public key at the top of the stack to generate a hash value to be verified. The public key at the top of the stack is the public key copied by the opcode OP_DUP.

[0038] [PubKeyHash] is a data push operation used to push the lock public key into the stack. The lock public key here is the public key hash obtained by hashing the public key of the real recipient.

[0039] The purpose of the opcode OP_EQUALVERIFY is to compare whether the two elements at the top of the stack are equal. If they are not equal, it will cause the entire script to fail. Here, it compares whether the hash value generated by the opcode OP_HASH160 is consistent with the public key hash pushed by [PubKeyHash].

[0040] The purpose of the opcode OP_CHECKSIG is to verify the signature. Here, it compares the signature at the top of the stack (i.e. the signature pushed by the opcode OP_DUP) with the public key verified by the opcode OP_EQUALVERIFY to check whether the signature is valid. If the signature is valid, the corresponding output will be unlocked and spent; otherwise, the script execution fails.

[0041] Based on the introduction to the public key script, we can know that: if Alice transfers money to Bob through a UTXO transaction, then in the public key script contained in the output of the UTXO transaction, the locking public key (such as "PubKeyHash" in the above example) will be generated based on the public key disclosed by Bob. Since the private key corresponding to the public key is only held by Bob, only Bob can provide the correct public key and signature, so only Bob can unlock the output.

[0042] Of course, when Alice transfers money to Bob, Bob may not know it in advance. Therefore, in order to know which UTXOs he holds, Bob needs to scan the transactions contained in the blockchain. As mentioned earlier, the output of the UTXO transaction carries a locking public key, and the locking public key is the public key or its derivative data disclosed by the actual recipient. Then: Bob can generate a locking public key based on his own public key and match it with the output of each UTXO transaction contained in the blockchain. If an output carries the locking public key, it means that the output is held by Bob.

[0043] However, since the locked public key contained in the output of the UTXO transaction is in a public state, and Bob's public key is also in a public state, not only can Bob scan the output he holds from the blockchain, but any other user can also scan the output held by Bob from the blockchain in the same way, and even track every UTXO held by Bob. This is obviously not conducive to the protection of Bob's privacy. In fact, there is a risk of privacy leakage for any user participating in the UTXO transaction.

[0044] In order to solve the above-mentioned technical problem of privacy leakage, this specification proposes the following technical solution.

[0045] Figure 1 FIG. 1 is a flowchart of a method for hiding a recipient's address and verifying transaction ownership, as shown in an exemplary embodiment of this specification. Figure 1 As shown, the method may include the following steps:

[0046] Step 102, the receiver generates and discloses the receiver's original address, the receiver's original address includes the first receiver's public key and base point indication information corresponding to the public base point, the first receiver's public key is the point product result of the first receiver's private key maintained by the receiver and the public base point.

[0047] For ease of description, the first recipient's private key is referred to as viewing key, or vk, below. As can be seen from the following description, the function of the private key vk is to scan a specific transaction from the blockchain, which contains the output belonging to the recipient. Based on the asymmetric encryption and decryption algorithm in the relevant technology, the corresponding public key can be generated by performing a point multiplication calculation on the private key vk and a base point in an elliptic curve system; for example, the selected base point is the above-mentioned public base point (for example, the public base point is Gd), then the first recipient's public key vpk is the point multiplication result of the above-mentioned private key vk and the public base point Gd, that is:

[0048] vpk=vk·Gd

[0049] The original address of the receiver can be the receiver's long-term public receiving address, which has nothing to do with the specific UTXO transaction. Of course, the receiver can regularly update its own public original address of the receiver, such as updating the first receiver private key and / or public base point to increase randomness and further enhance the privacy protection effect. Of course, the original address of the receiver can also be the receiving address temporarily generated and disclosed by the receiver for a certain transfer (and the corresponding UTXO transaction), and this specification does not limit this.

[0050] The recipient can include the original address of the recipient in a blockchain transaction to store the original address of the recipient in the blockchain, so that any user can obtain the receiving address corresponding to the recipient from the blockchain, and generate the corresponding target recipient hidden address accordingly, and then transfer money to the recipient. Of course, the recipient can also disclose the original address of the recipient in other ways, and this specification does not limit this.

[0051] The original address of the receiver contains the base point indication information d corresponding to the public base point Gd, which enables other users to determine the corresponding public base point Gd based on the base point indication information d after obtaining the original address of the receiver. For example, the base point indication information d can be the public base point Gd itself; for another example, the base point indication information d can be the information of a certain standard elliptic curve, such as the name and parameters of the curve, and the standard elliptic curve contains a predefined base point Gd. Of course, other methods can also be used to describe the base point indication information d, as long as it can be used to characterize the above-mentioned public base point Gd, it can be applied to the technical solution of this specification.

[0052] Step 104, the sender obtains the receiver's original address and generates a corresponding target receiver's hidden address to construct a UTXO transaction based on the target receiver's hidden address; the target receiver's hidden address includes a locked public key that is different from the public key contained in the receiver's original address, a sender's public key, and verification information that can be verified by a shared secret, wherein: the sender's public key is a point product of a sender's private key maintained by the sender and a public base point determined based on the base point indication information, and the shared secret is a point product of the first receiver's public key and the sender's private key.

[0053] The sender private key can be a private key maintained by the sender for a long time. The sender private key can be used by the sender to generate corresponding hidden addresses for all receiver original addresses, regardless of who the receiver original address corresponds to. In this way, the sender only needs to maintain a unique sender private key. Of course, the sender can also maintain multiple sender private keys for different situations: for example, the sender can maintain different sender private keys for each receiver or receiver original address (the same receiver can correspond to one or more receiver original addresses); for another example, the sender can temporarily generate a corresponding sender private key for each UTXO transaction, thereby improving randomness.

[0054] For ease of description, the sender's private key can be called esk. Based on the base point indication information d contained in the receiver's original address, the sender can determine the corresponding public base point Gd, and then calculate the point product between the sender's private key esk and the public base point Gd to obtain the corresponding sender's public key epk, that is:

[0055] epk=esk·Gd

[0056] The reason why the base point indication information needs to be carried in the receiver's original address is to ensure that both the receiver and the sender can know the same common base point, and use the common base point to generate the corresponding first receiver public key and sender public key, so that the sender and the receiver can generate the same shared secret respectively.

[0057] As mentioned above, the shared secret is calculated as the dot product of the first receiver's public key and the sender's private key. For example, the shared secret can be called SharedSecret, or SS for short, then:

[0058] SS=vpk·esk=vk·Gd·esk

[0059] Furthermore, since the dot product calculation satisfies the commutative law, vk·Gd·esk=vk·esk·Gd=vk·epk, that is:

[0060] SS=vk·epk

[0061] Among them, vk is the first receiver private key maintained by the receiver, and epk is the sender public key mentioned above. It can be seen that as long as the receiver can know the sender public key epk, the shared secret SS can also be calculated, which means that the shared secret is shared between the sender and the receiver. In addition, since the calculation process of the shared secret SS requires at least the first receiver private key vk or the sender private key esk, only the sender and the receiver can calculate it, and a third party cannot calculate the shared secret SS.

[0062] The verification information contained in the target recipient's hidden address can be called C. Since the verification information C can be verified by the shared secret, it can be understood that only when the shared secret SS can be correctly calculated, the verification information C can be verified. As mentioned above, only the sender and the receiver can correctly calculate the shared secret SS, so only the sender and the receiver can verify the verification information C. Therefore, the verification result of the verification information C can be used as an identification condition for the UTXO transaction: that is, as described in the following step 106, when the recipient successfully verifies the verification information contained in a UTXO transaction, it can be determined that it is the recipient of the UTXO transaction, that is, the UTXO transaction contains the output belonging to the recipient; if the verification fails, it means that it is not the recipient of the UTXO transaction, that is, the UTXO transaction does not contain the output belonging to the recipient.

[0063] Step 106, the receiver, for any UTXO transaction in the blockchain: performs a dot product calculation on the first receiver's private key and the sender's public key in the receiver's hidden address of any UTXO transaction, and verifies the verification information in the receiver's hidden address of any UTXO transaction based on the calculation result; if the verification is successful, the receiver determines itself as the receiver of any UTXO transaction.

[0064] In one embodiment, the verification information is the shared secret itself. Taking any UTXO transaction as an example, assuming that the sender's public key in the recipient's hidden address is epk' and the verification information is C'; accordingly, the verification of the verification information C' may include: first, the recipient obtains the sender's public key epk' contained in any UTXO transaction, and performs a point multiplication calculation with the first recipient's private key vk maintained by itself, and obtains the corresponding point multiplication result vk·epk'. Then, the point multiplication result vk·epk' is compared with the verification information C' contained in any UTXO transaction. From the foregoing, it can be seen that: if any UTXO transaction contains an output belonging to the recipient, then the point product result vk·epk' should be the shared secret as described above, and since the verification information in this embodiment is the shared secret itself, the comparison result of the point product result vk·epk' and the verification information C' should be the same; in other words, if the comparison result of the point product result vk·epk' and the verification information C' is the same, it indicates that any UTXO transaction contains an output belonging to the recipient, if they are different, it indicates that any UTXO transaction does not contain an output belonging to the recipient.

[0065] In another embodiment, the verification information is derived data of the shared secret. For example, the verification information is obtained by encrypting the plain text information with a symmetric key, the symmetric key is generated based on the shared secret, and the plain text information includes predefined verification content. The so-called predefined verification content can be the content agreed upon in advance between the sender and the receiver. This specification does not limit the specific content, for example, it can be called SomeMessage. The symmetric key can be obtained by processing the shared secret with a symmetric key generation algorithm in the related art, for example, it can be called Key, then:

[0066] C=Enc Key (“SomeMessage”)

[0067] Among them, Enc Key () is a symmetric encryption function, and its key is key.

[0068] Then, the verification of the above verification information C' may include: generating a corresponding symmetric key based on the calculation result (i.e., the point product result vk·epk'), and decrypting the verification information C' in the recipient's hidden address of any of the above UTXO transactions accordingly; if the decryption obtains the predefined verification content, the verification is determined to be successful, otherwise the verification fails. Among them, the method of generating the symmetric key based on the calculation result is consistent with the symmetric key generation algorithm used by the sender when generating the symmetric key. Then: if any UTXO transaction contains an output belonging to the recipient, then the point product result vk·epk' should be the shared secret as described above, so the generated symmetric key should be the Key as described above, and the verification information C' is successfully decrypted to obtain SomeMessage; in other words, if the symmetric key generated by the point product result vk·epk' successfully decrypts the verification information C' and obtains the predefined verification content SomeMessage, it indicates that any UTXO transaction contains an output belonging to the recipient. If the decryption fails or the verification content obtained is not SomeMessage, it indicates that any UTXO transaction does not contain an output belonging to the recipient.

[0069] Regarding the above symmetric keys, although they are all generated based on shared secrets, there are many situations in the specific generation process. For example, the shared secret can be directly encoded to generate a symmetric key, that is:

[0070] Key=Encode(SS)

[0071] Among them, Encode(SS) means encoding the shared secret to generate the shared secret SS into a symmetric key Key. Since both the sender and the real receiver can correctly generate the shared secret SS, as long as Encode() is consistent between the sender and the receiver, it can ensure that both the sender and the real receiver can correctly generate the symmetric key Key. Of course, Encode() can be an encoding function negotiated only between a certain sender and the real receiver, or it can be a globally unified encoding function. For another example, the shared secret and other information can be jointly encoded to generate a symmetric key, that is:

[0072] Key=Encode(SS||Other)

[0073] Of course, it is necessary to ensure that the other information Other is information that both the sender and the real receiver can know. For example, the other information Other can be the sender's public key epk as mentioned above, that is:

[0074] Key=Encode(SS||epk)

[0075] Among them, the sender public key epk is generated by the sender and can be obtained by the sender himself, and the receiver can obtain the sender public key epk from the UTXO transaction.

[0076] For another example, the other information Other may be the first receiver public key vpk as described above, that is:

[0077] Key=Encode(SS||vpk)

[0078] The first receiver public key vpk is generated by the receiver and can be obtained by the receiver himself, and the sender can obtain the first receiver public key vpk from the receiver's original address.

[0079] As mentioned above, the output of the UTXO transaction needs to contain a locking public key, referred to herein as pkL. In the related art, the locking public key pkL is the public key disclosed by the user in the public receiving address, such as the first recipient public key vpk disclosed by the user in the recipient's original address. Accordingly, the user scans the locking public key pkL contained in each UTXO transaction in the blockchain. If the locking public key pkL contained in any UTXO transaction is the same as the first recipient public key vpk, the user determines that he is the recipient of the UTXO transaction. However, since the first recipient public key vpk has been made public, a third party can also scan all UTXO transactions of the user as a recipient in the above manner, resulting in the disclosure of his privacy.

[0080] Therefore, when the sender in this specification generates the corresponding target recipient hidden address based on the original address of the recipient, the lock public key pkL is set to be different from the public key contained in the original address of the recipient (such as the first recipient public key vpk, the second recipient public key upk described below, etc.), so that the third party cannot scan the UTXO transaction corresponding to the recipient from the blockchain based on the match between the public key contained in the original address of the recipient and the lock public key, thereby hiding the recipient's receiving address and avoiding the exposure of the recipient's privacy data. Of course, by designing the verification information as described above, the recipient can verify the verification information contained in each UTXO transaction in the blockchain, so as to accurately screen out the UTXO transaction corresponding to itself according to the verification result. It can be seen that this specification takes into account the realization of the normal transfer of UTXO transactions and the privacy protection of the receiving address.

[0081] As long as the locking public key pkL is different from the public key contained in the original address of the recipient, and the recipient can master the unlocking private key corresponding to the locking public key pkL, the privacy of the receiving address can be ensured while the recipient can successfully unlock and spend the corresponding UTXO. To this end, there can be many specific values ​​for the locking public key pkL, and this manual does not limit this.

[0082] For example, as mentioned above, the plaintext information also includes: a random number r selected by the sender, then the calculation formula of the verification information C can be adjusted to:

[0083] C=Enc Key ("SomeMessage"||Encode(r))

[0084] Among them, Encode(r) is used to encode the random number r to ensure that the sender and the receiver can reach an agreement on the representation of the random number r, so as to avoid ambiguity in the receiver's reading of the random number r after decrypting the verification information C (for example, the difference between big-endian storage and little-endian storage data).

[0085] The locked public key pkL can be the point multiplication result of the random number r and any public key disclosed by the recipient. Take the first recipient's public key vpk as an example:

[0086] pkL=r·vpk=r·vk·Gd=(r·vk)·Gd

[0087] It can be seen that the recipient can regard (r·vk) as a whole, and then the whole can be used as the unlocking private key. The unlocking private key (r·vk) and the locking public key pkL constitute a set of public-private key pairs. Therefore, the recipient can unlock and spend the corresponding UTXO based on the unlocking private key (r·vk).

[0088] In addition to the first recipient public key vpk, the recipient original address may also contain other public keys, which can be used to generate the above-mentioned locking public key pkL. For example, the recipient original address may also include the second recipient public key upk, and the recipient also maintains the second recipient private key uk corresponding to the second recipient public key upk. Then, taking the second recipient public key upk as an example:

[0089] pkL=r·upk=r·uk·Gd=(r·uk)·Gd

[0090] It can be seen that the receiver can regard (r·uk) as a whole, and then the whole can be used as the unlocking private key. The unlocking private key (r·uk) and the locking public key pkL constitute a set of public-private key pairs. Therefore, the receiver can unlock and spend the corresponding UTXO based on the unlocking private key (r·uk).

[0091] Since the random number r is included in the above-mentioned plaintext information, and the plaintext information is encrypted into the verification information as mentioned above by the symmetric key key generated based on the shared secret SS, and the shared secret SS can only be generated by the sender and the real receiver, the random number r can only be obtained by the sender and the real receiver. Therefore, since the third party cannot obtain the random number r, even if the third party knows the locking public key pkL and the public key disclosed by the receiver in the receiver's original address, it is impossible to establish an association between the locking public key pkL and the public key disclosed in the receiver's original address, so it is impossible to infer the receiver of the UTXO based on the locking public key pkL. At the same time, although the random number is increased, due to the characteristics of the point multiplication algorithm, the receiver can use the point multiplication result of the random number r and any public key disclosed by the receiver as the unlocking private key, thereby protecting privacy while ensuring that the receiver can successfully unlock and spend the corresponding UTXO.

[0092] In one embodiment, in addition to protecting the privacy of the receiving address, the privacy of the transaction output amount can also be protected. For example, in a UTXO transaction constructed based on the target recipient's hidden address, the amount of the transaction output corresponding to the recipient can be recorded as the corresponding commitment value. The commitment value here refers to the ciphertext amount generated after the original transaction output amount is encrypted and calculated using an encryption algorithm based on homomorphic encryption technology. Among them, the homomorphic encryption technology used can include, for example, the Pedersen commitment algorithm, etc., and this specification does not limit this.

[0093] Figure 2 FIG. 1 is a flow chart of a method for hiding a recipient's address as shown in an exemplary embodiment of this specification. Figure 2 As shown, the method can be applied to the sender; the method can include the following steps:

[0094] Step 202, obtaining the original address of the receiver disclosed by the receiver, wherein the original address of the receiver includes a first receiver public key and base point indication information corresponding to a public base point, and the first receiver public key is a point multiplication result of a first receiver private key maintained by the receiver and the public base point.

[0095] Step 204, generate a target recipient hidden address corresponding to the recipient original address to construct a UTXO transaction based on the target recipient hidden address; the target recipient hidden address includes a locked public key different from the public key contained in the recipient original address, a sender public key, and verification information that can be verified by a shared secret, wherein: the sender public key is a point product of a sender private key maintained by the sender and a public base point determined based on the base point indication information, and the shared secret is a point product of the first recipient public key and the sender private key.

[0096] Optionally, the verification information is obtained by encrypting plaintext information with a symmetric key, the symmetric key is generated based on the shared secret, and the plaintext information includes predefined verification content.

[0097] Optionally, the symmetric key is generated by any of the following methods:

[0098] Encoding and generating the shared secret;

[0099] Encoding and generating the shared password and the sender's public key together;

[0100] The shared password and the first recipient's public key are jointly encoded and generated.

[0101] Optional,

[0102] The plaintext information also includes: a random number selected by the sender;

[0103] The locked public key is the dot product of the random number and any public key disclosed by the recipient.

[0104] Optionally, any of the public keys includes:

[0105] The first recipient's public key; or,

[0106] The second recipient's public key; wherein the recipient's original address also includes the second recipient's public key, and the recipient also maintains the second recipient's private key corresponding to the second recipient's public key.

[0107] Optionally, in a UTXO transaction constructed based on the target recipient's stealth address, the amount of the transaction output corresponding to the recipient is recorded as the corresponding commitment value.

[0108] Those skilled in the art will understand that: Figure 2 The embodiment shown in the figure describes the technical solution of this specification from the perspective of the sender. Figure 1 In the embodiment shown, the technical solution of this specification has been described in detail from the perspective of the sender and the receiver, and the contents related to the sender are applicable to the present invention. Figure 2 Therefore, you can refer to the above content to understand Figure 2 The illustrated embodiments and other contents related to the sender will not be described in detail here.

[0109] Figure 3 FIG. 1 is a flow chart of a method for verifying transaction ownership as shown in an exemplary embodiment of this specification. Figure 3As shown, the method can be applied to a verifier; the method can include the following steps:

[0110] Step 302, obtaining the UTXO transaction to be verified; the UTXO transaction to be verified is constructed by the sender based on the target recipient hidden address, and the target recipient hidden address is generated by the sender's original address of the recipient disclosed to the recipient; the recipient original address includes a first recipient public key and a base point indication information corresponding to a public base point, and the first recipient public key is a point product result of a first recipient private key maintained by the recipient and the public base point; the target recipient hidden address includes a locked public key different from the public key contained in the recipient original address, a sender public key, and verification information that can be verified by a shared secret, wherein: the sender public key is a point product result of a sender private key maintained by the sender and a public base point determined based on the base point indication information, and the shared secret is a point product result of the first recipient public key and the sender private key.

[0111] Step 304, perform a dot multiplication calculation on the private key maintained by the target object and the sender's public key in the target recipient's hidden address, and verify the verification information in the target recipient's hidden address based on the calculation result; if the verification is successful, the target object is determined to be the recipient of the UTXO transaction to be verified.

[0112] Optionally, the verification information is obtained by encrypting plain text information with a symmetric key, the symmetric key is generated based on the shared secret, and the plain text information includes predefined verification content;

[0113] The verifying the verification information in the target recipient's hidden address based on the calculation result includes:

[0114] Generate a corresponding symmetric key based on the calculation result, and decrypt the verification information in the target recipient's hidden address accordingly;

[0115] If the predefined verification content is obtained through decryption, it is determined that the verification is successful.

[0116] Optionally, the symmetric key is generated by any of the following methods:

[0117] Encoding and generating the shared secret;

[0118] Encoding and generating the shared password and the sender's public key together;

[0119] The shared password and the first recipient's public key are jointly encoded and generated.

[0120] Optional,

[0121] The plaintext information also includes: a random number selected by the sender;

[0122] The locked public key is the dot product of the random number and any public key disclosed by the recipient;

[0123] The method also includes: calculating a point product result of the random number and a private key corresponding to any public key, and using the point product result as a private key corresponding to the locked public key to spend the corresponding transaction output in the UTXO transaction to be verified.

[0124] Optionally, any of the public keys includes:

[0125] The first recipient's public key; or,

[0126] The second recipient's public key; wherein the recipient's original address also includes the second recipient's public key, and the recipient also maintains the second recipient's private key corresponding to the second recipient's public key.

[0127] Optionally, in the UTXO transaction to be verified, the amount of the transaction output corresponding to the recipient is recorded as the corresponding commitment value.

[0128] Optionally, the verifier includes any one of the following: the target object itself, the verifier being a third party entrusted by the target object, and a supervisor.

[0129] Those skilled in the art will understand that: Figure 3 The embodiment shown in the figure describes the technical solution of this specification from the perspective of the verifier. Figure 1 In the embodiment shown, the technical solution of this specification has been described in detail from the perspective of the sender and the receiver, and the contents related to verifying the ownership of the transaction are applicable to the present invention. Figure 3 Therefore, you can refer to the above content to understand Figure 3 The illustrated embodiments and other contents related to verifying transaction ownership are not described in detail here.

[0130] It should be pointed out that: Figure 1 In the embodiment shown, the recipient verifies the transaction ownership, that is, verifies whether the UTXO transaction contains the output belonging to the recipient, corresponding to Figure 3The embodiment shown is the case where the verifier is the target object itself, that is, the verifier at this time is the recipient. In fact, in addition to this case, the verifier can also be other identities, for example: the verifier can be a third party entrusted by the target object, and the target object can entrust the private key maintained by itself to the verifier, so that the verifier can use the private key to verify the ownership of the transaction. Of course, this trusteeship does not mean that the verifier can directly obtain the private key, but only enables it to obtain the authority to use or call the private key to avoid the security risks caused by this. For example: the verifier can be a regulator, and the regulator can obtain the use or call authority of the target object's private key to verify the ownership of the transaction.

[0131] In addition, whether it is a recipient, a sender or a verifier, it should be understood to be the electronic device used by the relevant user, rather than the user himself.

[0132] In summary, in the technical solution provided in this specification, although the receiver needs to disclose its original receiver address, the original receiver address is not directly used as the receiving address of the UTXO transaction created by the sender, and the public key contained in the original receiver address is not directly used as the locked public key in the above-mentioned receiving address. Instead, the sender replaces the original receiver address with the corresponding target receiver hidden address, and ensures that the locked public key is different from the public key contained in the original receiver address. Therefore, except for the receiver and the sender, any third party will not be able to establish an association relationship between the locked public key and the public key contained in the original receiver address when viewing the locked public key contained in the receiving address (i.e., the target receiver hidden address) of the UTXO transaction, and will not be able to infer the identity of the real receiver of the UTXO transaction, thereby achieving privacy protection for the receiver.

[0133] At the same time, by carrying the base point indication information in the receiver's original address, the receiver and the sender can generate the first receiver public key and the sender public key respectively based on the same common base point, and then by carrying the first receiver public key in the receiver's original address and the sender public key in the target receiver hidden address, the sender can perform a dot multiplication of the first receiver public key and the sender private key to generate a shared secret and then generate corresponding verification information, and the receiver can perform a dot multiplication of the first receiver private key and the sender public key to generate a shared secret and then verify the verification information in the receiver hidden address of the UTXO transaction, thereby accurately identifying the corresponding target receiver hidden address and finding the UTXO transaction sent to itself, that is, this manual will not affect the normal transfer process based on UTXO transactions, and no third party can complete the verification process.

[0134] In addition, the above technical solution only involves the sender and the receiver in the entire process of constructing UTXO transactions and verifying transaction ownership, and does not need to expose private information to any third party, which has extremely high privacy security. Moreover, each UTXO transaction can be created, submitted and verified independently, without the need to establish a connection with other UTXO transactions, such as no need to wait for other UTXO transactions, no need to mix and submit with other UTXO transactions, and no need to involve other UTXO transactions in the verification process.

[0135] Figure 4 is a schematic diagram of the structure of an electronic device in an exemplary embodiment. Figure 4 At the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory, and may also include other required hardware. The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming a device for hiding the recipient's address or a device for verifying the ownership of the transaction at the logical level. Of course, in addition to the software implementation, this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0136] Corresponding to the aforementioned embodiment of the method for hiding the recipient address, this specification also provides an embodiment of an apparatus for hiding the recipient address.

[0137] Please refer to Figure 5 , Figure 5 The figure is a schematic diagram of the structure of a device for hiding a recipient's address, shown as an exemplary embodiment.

[0138] like Figure 5 As shown, in a software implementation, the device is applied to a sender; the device may include:

[0139] The original address acquisition unit 502 is used to obtain the original address of the receiver disclosed by the receiver, wherein the original address of the receiver includes a first receiver public key and base point indication information corresponding to a public base point, and the first receiver public key is a point multiplication result of a first receiver private key maintained by the receiver and the public base point.

[0140] The stealth address generation unit 504 is used to generate a target recipient stealth address corresponding to the recipient original address, so as to construct a UTXO transaction based on the target recipient stealth address; the target recipient stealth address includes a locked public key different from the public key contained in the recipient original address, a sender public key, and verification information that can be verified by a shared secret, wherein: the sender public key is a point product result of a sender private key maintained by the sender and a public base point determined based on the base point indication information, and the shared secret is a point product result of the first recipient public key and the sender private key.

[0141] Optionally, the verification information is obtained by encrypting plaintext information with a symmetric key, the symmetric key is generated based on the shared secret, and the plaintext information includes predefined verification content.

[0142] Optionally, the symmetric key is generated by any of the following methods:

[0143] Encoding and generating the shared secret;

[0144] Encoding and generating the shared password and the sender's public key together;

[0145] The shared password and the first recipient's public key are jointly encoded and generated.

[0146] Optionally, the plaintext information further includes: a random number selected by the sender;

[0147] The locked public key is the dot product of the random number and any public key disclosed by the recipient.

[0148] Optionally, any of the public keys includes:

[0149] The first recipient's public key; or,

[0150] The second recipient's public key; wherein the recipient's original address also includes the second recipient's public key, and the recipient also maintains the second recipient's private key corresponding to the second recipient's public key.

[0151] Optionally, in a UTXO transaction constructed based on the target recipient's stealth address, the amount of the transaction output corresponding to the recipient is recorded as the corresponding commitment value.

[0152] Please refer to Figure 6 , Figure 6 FIG. 1 is a schematic diagram of a structure of a device for verifying transaction ownership according to an exemplary embodiment. Figure 6 As shown, in a software implementation, the device is applied to a verifier; the device may include:

[0153] The transaction acquisition unit 602 is used to obtain the UTXO transaction to be verified; the UTXO transaction to be verified is constructed by the sender based on the target recipient hidden address, and the target recipient hidden address is generated by the recipient original address disclosed by the sender to the recipient; the recipient original address includes a first recipient public key and a base point indication information corresponding to a public base point, and the first recipient public key is the point product result of the first recipient private key maintained by the recipient and the public base point; the target recipient hidden address includes a locked public key different from the public key contained in the recipient original address, a sender public key, and verification information that can be verified by a shared secret, wherein: the sender public key is the point product result of the sender private key maintained by the sender and the public base point determined based on the base point indication information, and the shared secret is the point product result of the first recipient public key and the sender private key.

[0154] The stealth address verification unit 604 is used to perform a dot multiplication calculation on the private key maintained by the target object and the sender public key in the target recipient stealth address, and verify the verification information in the target recipient stealth address based on the calculation result; if the verification is successful, the target object is determined to be the recipient of the UTXO transaction to be verified.

[0155] Optionally, the verification information is obtained by encrypting plain text information with a symmetric key, the symmetric key is generated based on the shared secret, and the plain text information includes predefined verification content;

[0156] The hidden address verification unit 604 is specifically used for:

[0157] Generate a corresponding symmetric key based on the calculation result, and decrypt the verification information in the target recipient's hidden address accordingly;

[0158] If the predefined verification content is obtained through decryption, it is determined that the verification is successful.

[0159] Optionally, the symmetric key is generated by any of the following methods:

[0160] Encoding and generating the shared secret;

[0161] Encoding and generating the shared password and the sender's public key together;

[0162] The shared password and the first recipient's public key are jointly encoded and generated.

[0163] Optionally, the plaintext information further includes: a random number selected by the sender;

[0164] The locked public key is the dot product of the random number and any public key disclosed by the recipient;

[0165] The device also includes:

[0166] The private key determination unit 606 is used to calculate the point product result of the random number and the private key corresponding to any public key, and use the point product result as the private key corresponding to the locked public key to spend the corresponding transaction output in the UTXO transaction to be verified.

[0167] Optionally, any of the public keys includes:

[0168] The first recipient's public key; or,

[0169] The second recipient's public key; wherein the recipient's original address also includes the second recipient's public key, and the recipient also maintains the second recipient's private key corresponding to the second recipient's public key.

[0170] Optionally, in the UTXO transaction to be verified, the amount of the transaction output corresponding to the recipient is recorded as the corresponding commitment value.

[0171] Optionally, the verifier includes any one of the following: the target object itself, the verifier being a third party entrusted by the target object, and a supervisor.

[0172] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0173] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can refer to the partial description of the method embodiments. The device embodiments described above are only schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this specification. Ordinary technicians in this field can understand and implement it without paying creative work.

[0174] Based on the same concept as the above method, this specification also provides an electronic device, including: a processor; a memory for storing processor executable instructions; wherein the processor implements the steps of the method described in any of the above embodiments by running the executable instructions.

[0175] Based on the same concept as the above method, this specification also provides a computer-readable storage medium on which computer instructions are stored. When the instructions are executed by a processor, the steps of the method described in any of the above embodiments are implemented.

[0176] Based on the same concept as the above method, this specification also provides a computer program product, including a computer program / instruction, which implements the steps of the method described in any of the above embodiments when executed by a processor.

Claims

1. A method for hiding a recipient's address and verifying transaction ownership, comprising: The receiver generates and discloses the receiver's original address, wherein the receiver's original address includes a first receiver's public key and base point indication information corresponding to a public base point, wherein the first receiver's public key is a point multiplication result of a first receiver's private key maintained by the receiver and the public base point; The sender obtains the original address of the receiver and generates a corresponding hidden address of the target receiver to construct a UTXO transaction based on the hidden address of the target receiver; the hidden address of the target receiver includes a locked public key different from the public key contained in the original address of the receiver, a sender public key, and verification information that can be verified by a shared secret, wherein: the sender public key is the point product of the sender private key maintained by the sender and the public base point determined based on the base point indication information, and the shared secret is the point product of the first receiver public key and the sender private key; For any UTXO transaction in the blockchain, the receiver performs a dot product calculation on the first receiver's private key and the sender's public key in the receiver's hidden address of any UTXO transaction, and verifies the verification information in the receiver's hidden address of any UTXO transaction based on the calculation result; if the verification is successful, the receiver determines that it is the receiver of any UTXO transaction.

2. According to the method of claim 1, the verification information is obtained by encrypting plain text information with a symmetric key, the symmetric key is generated based on the shared secret, and the plain text information includes predefined verification content; The verifying the verification information in the recipient hidden address of any UTXO transaction based on the calculation result includes: Generate a corresponding symmetric key based on the calculation result, and decrypt the verification information in the recipient's hidden address of any UTXO transaction accordingly; If the predefined verification content is obtained through decryption, it is determined that the verification is successful.

3. According to the method of claim 2, the symmetric key is generated by any of the following methods: Encoding and generating the shared secret; Encoding and generating the shared password and the sender's public key together; The shared password and the first recipient's public key are jointly encoded and generated.

4. The method according to claim 2, The plaintext information also includes: A random number chosen by the sender; The locked public key is the dot product of the random number and any public key disclosed by the recipient.

5. The method according to claim 4, wherein any one of the public keys comprises: The first recipient's public key; or, The second recipient's public key; wherein the recipient's original address also includes the second recipient's public key, and the recipient also maintains the second recipient's private key corresponding to the second recipient's public key.

6. According to the method of claim 1, in the UTXO transaction constructed based on the target recipient's stealth address, the amount of the transaction output corresponding to the recipient is recorded as the corresponding commitment value.

7. A method for hiding a recipient's address, applied to a sender, the method comprising: Obtaining a receiver's original address disclosed by the receiver, the receiver's original address including a first receiver's public key and base point indication information corresponding to a public base point, the first receiver's public key being a point multiplication result of a first receiver's private key maintained by the receiver and the public base point; Generate a target recipient hidden address corresponding to the recipient original address to construct a UTXO transaction based on the target recipient hidden address; the target recipient hidden address includes a locked public key different from the public key contained in the recipient original address, a sender public key, and verification information that can be verified by a shared secret, wherein: the sender public key is a point product of a sender private key maintained by the sender and a public base point determined based on the base point indication information, and the shared secret is a point product of the first recipient public key and the sender private key.

8. According to the method of claim 7, the verification information is obtained by encrypting plain text information with a symmetric key, the symmetric key is generated based on the shared secret, and the plain text information includes predefined verification content.

9. The method according to claim 8, wherein the symmetric key is generated by any of the following methods: Encoding and generating the shared secret; Encoding and generating the shared password and the sender's public key together; The shared password and the first recipient's public key are jointly encoded and generated.

10. The method according to claim 8, The plaintext information also includes: A random number chosen by the sender; The locked public key is the dot product of the random number and any public key disclosed by the recipient.

11. The method according to claim 10, wherein any one of the public keys comprises: The first recipient's public key; or, The second recipient's public key; wherein the recipient's original address also includes the second recipient's public key, and the recipient also maintains the second recipient's private key corresponding to the second recipient's public key.

12. According to the method of claim 7, in the UTXO transaction constructed based on the target recipient's stealth address, the amount of the transaction output corresponding to the recipient is recorded as the corresponding commitment value.

13. A method for verifying transaction ownership, applied to a verifier; the method comprising: Get the UTXO transaction to be verified; The UTXO transaction to be verified is constructed by the sender based on the target recipient's hidden address, and the target recipient's hidden address is generated by the sender's original address of the recipient disclosed to the recipient; the recipient's original address includes a first recipient's public key and base point indication information corresponding to a public base point, and the first recipient's public key is the point product result of the first recipient's private key maintained by the recipient and the public base point; the target recipient's hidden address includes a locked public key that is different from the public key contained in the recipient's original address, a sender's public key, and verification information that can be verified by a shared secret, wherein: the sender's public key is the point product result of the sender's private key maintained by the sender and the public base point determined based on the base point indication information, and the shared secret is the point product result of the first recipient's public key and the sender's private key; The private key maintained by the target object is multiplied by the sender's public key in the target recipient's hidden address, and the verification information in the target recipient's hidden address is verified based on the calculation result; if the verification is successful, the target object is determined to be the recipient of the UTXO transaction to be verified.

14. The method according to claim 13, wherein the verification information is obtained by encrypting plain text information with a symmetric key, the symmetric key is generated based on the shared secret, and the plain text information includes predefined verification content; The verifying the verification information in the target recipient's hidden address based on the calculation result includes: Generate a corresponding symmetric key based on the calculation result, and decrypt the verification information in the target recipient's hidden address accordingly; If the predefined verification content is obtained through decryption, it is determined that the verification is successful.

15. The method according to claim 14, wherein the symmetric key is generated by any of the following methods: Encoding and generating the shared secret; Encoding and generating the shared password and the sender's public key together; The shared password and the first recipient's public key are jointly encoded and generated.

16. The method according to claim 14, The plaintext information also includes: A random number chosen by the sender; The locked public key is the dot product of the random number and any public key disclosed by the recipient; The method also includes: calculating a point product result of the random number and a private key corresponding to any public key, and using the point product result as a private key corresponding to the locked public key to spend the corresponding transaction output in the UTXO transaction to be verified.

17. The method according to claim 16, wherein any one of the public keys comprises: The first recipient's public key; or, The second recipient's public key; wherein the recipient's original address also includes the second recipient's public key, and the recipient also maintains the second recipient's private key corresponding to the second recipient's public key.

18. The method according to claim 13, wherein in the UTXO transaction to be verified, the amount of the transaction output corresponding to the recipient is recorded as the corresponding commitment value.

19. The method according to claim 13, wherein the verifier includes any one of the following: the target object itself, the verifier being a third party entrusted by the target object, and a supervisor.

20. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of any method according to claim 7-19 when executing the program.

21. A computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the steps of the method according to any one of claims 7 to 19.

22. A computer program product, comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method according to any one of claims 7 to 19.

Images