CN112348677A

CN112348677A - Address generation and block chain online and offline transaction method, device, system and medium

Info

Publication number: CN112348677A
Application number: CN202011252937.XA
Authority: CN
Inventors: 郑杰骞
Original assignee: Individual
Current assignee: Individual
Priority date: 2020-11-11
Filing date: 2020-11-11
Publication date: 2021-02-09
Anticipated expiration: 2040-11-11

Abstract

The disclosure provides an address generation method, a block chain online transaction processing method, a block chain offline transaction processing method, a user device, an intermediate node device and a block chain transaction system, which can support privacy transaction. The address generation method comprises the following steps: acquiring a user public key; and generating a commitment address by adopting the user public key and a first generator, wherein the commitment address is used for carrying out block chain transaction, the commitment address is the sum of the user public key and a first coefficient operation result and the first generator and a second coefficient operation result, and the operation is a one-way algorithm.

Description

Address generation and block chain online and offline transaction method, device, system and medium

Technical Field

The present disclosure relates to, but not limited to, the field of computer data processing technologies, and in particular, to an address generation method, a blockchain online transaction processing method, a blockchain offline transaction processing method, a user device, an intermediate node device, a blockchain transaction system, and a storage medium.

Background

At present, a connected blockchain transaction mode is introduced, two transaction parties can check the transaction address of the other party, off-line transaction data of the two parties cannot be publicly verified after chain connection and has privacy, and when no transaction is carried out by a middleman, the two transaction parties do not know the address of the other party and the output amount, the cheating mode of the middleman is prevented.

Disclosure of Invention

The following is a summary of the subject matter described in detail herein. This summary is not intended to limit the scope of the claims.

An address generation method, a blockchain online transaction processing method, a blockchain offline transaction processing method, a user device, an intermediate node device and a blockchain transaction system are provided, which can support privacy transactions.

In a first aspect, the present disclosure provides an address generation method, including:

acquiring a user public key;

and generating a commitment address by adopting the user public key and a first generator, wherein the commitment address is used for carrying out block chain transaction, the commitment address is the sum of the user public key and a first coefficient operation result and the first generator and a second coefficient operation result, and the operation is a one-way algorithm.

In a second aspect, the present disclosure also provides a blockchain online transaction processing method for a sender to generate a first transaction, the method including:

generating a first commitment address for each recipient according to a user public key of the recipient, wherein the first commitment address of each recipient is generated by adopting the method of any one of claims 1 to 3;

generating a first transaction according to an intermediate address of an intermediate node and submitting the first transaction to the intermediate node, the first transaction comprising a set of the first commitment addresses.

In a third aspect, the present disclosure further provides a blockchain online transaction processing method, where the method is used for an intermediate node to generate a second transaction, and the method includes:

determining a recipient of the second transaction based on one or more first transactions, and obtaining a commitment address for the recipient from the first transactions; the first transaction is a transaction generated using the method of any of claims 4 to 6;

generating a receive transaction address for the recipient and an output commitment address associated with the receive transaction address;

generating a second transaction, the input of the second transaction referencing one or more first transactions, the recipient's commitment address as an input commitment address for the second transaction, the output of the second transaction including the recipient's recipient transaction address and an output commitment address.

In a fourth aspect, the present disclosure further provides a blockchain offline transaction processing method for a sender to generate an offline first transaction, the method including:

acquiring an offline transaction address of a receiver, and generating an offline first transaction, wherein the output of the offline first transaction comprises the offline transaction address of the receiver, a transfer amount and a transaction log, the transaction log comprises a commitment address of the receiver, and the commitment address of the receiver is generated by adopting the method of any one of claims 1 to 3.

In a fifth aspect, the present disclosure further provides a blockchain offline transaction processing method, where the method is used for an intermediate node to generate an offline second transaction, and the method includes:

receiving the synchronized offline transaction data, generating an offline second transaction, the input of which comprises a transaction log of the offline first transaction, the output of which comprises a receiving transaction address and an output commitment address of the recipient and a transaction amount, wherein the offline first transaction is a transaction generated by the method of any one of claims 14 to 16.

In a sixth aspect, the present disclosure also provides a computer-readable storage medium storing computer-executable instructions for implementing any one of the above methods.

In a seventh aspect, the present disclosure further provides a user device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor implements the steps of any one of the address generation method, the blockchain online transaction processing method for a sender to generate a first transaction, and the blockchain offline transaction processing method for a sender to generate an offline first transaction when executing the program.

In a seventh aspect, the present disclosure also provides an intermediate node device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor implements, when executing the program, the steps of any one of the above block chain online transaction processing method for generating a second transaction by an intermediate node, and the block chain offline transaction processing method for generating an offline second transaction by an intermediate node.

By adopting the method disclosed by the invention, the commitment address is generated by adopting a one-way algorithm, so that the privacy of the user can be ensured. Similarly, the committed address is adopted to participate in the block chain online transaction or offline transaction, so that the privacy of the user can be protected, and the two transaction parties cannot know the address of the other party.

Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

Other aspects will be apparent upon reading and understanding the attached drawings and detailed description.

Drawings

The accompanying drawings are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the example serve to explain the principles of the invention and not to limit the invention.

Fig. 1 is a flowchart of an address generation method according to an embodiment of the present disclosure;

FIG. 2 is a flow chart of a method for a sender to generate a first transaction according to an embodiment of the present disclosure;

FIG. 3 is a flow chart of a method by which an intermediate node generates a second transaction in an embodiment of the present disclosure;

FIG. 4 is a flowchart of a method for a sender to generate an offline first transaction according to an embodiment of the present disclosure;

FIG. 5 is a flow chart of a method by which an intermediate node generates an offline second transaction in an embodiment of the present disclosure;

FIG. 6 is a schematic diagram illustrating an online transaction flow between a user Alice and a user Bob according to an embodiment of the present disclosure;

FIG. 7 is a diagram illustrating a one-time user address generation;

FIG. 8 is a schematic diagram illustrating an offline transaction flow between a user Alice and a user Bob according to an embodiment of the present disclosure;

FIG. 9 is a schematic diagram illustrating an offline transaction process between a user Alice and a user Bob according to an embodiment of the present disclosure;

FIG. 10 is a schematic diagram of an offline transaction online record of a user Alice and a user Bob according to an embodiment of the present disclosure;

fig. 11 is a schematic structural diagram of an exemplary computer device according to an embodiment of the present disclosure.

Detailed Description

The present application describes embodiments, but the description is illustrative rather than limiting and it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible within the scope of the embodiments described herein. Although many possible combinations of features are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are possible. Any feature or element of any embodiment may be used in combination with or instead of any other feature or element in any other embodiment, unless expressly limited otherwise.

The present application includes and contemplates combinations of features and elements known to those of ordinary skill in the art. The embodiments, features and elements disclosed in this application may also be combined with any conventional features or elements to form a unique inventive concept as defined by the claims. Any feature or element of any embodiment may also be combined with features or elements from other inventive aspects to form yet another unique inventive aspect, as defined by the claims. Thus, it should be understood that any of the features shown and/or discussed in this application may be implemented alone or in any suitable combination. Accordingly, the embodiments are not limited except as by the appended claims and their equivalents. Furthermore, various modifications and changes may be made within the scope of the appended claims.

Further, in describing representative embodiments, the specification may have presented the method and/or process as a particular sequence of steps. However, to the extent that the method or process does not rely on the particular order of steps set forth herein, the method or process should not be limited to the particular sequence of steps described. Other orders of steps are possible as will be understood by those of ordinary skill in the art. Therefore, the particular order of the steps set forth in the specification should not be construed as limitations on the claims. Further, the claims directed to the method and/or process should not be limited to the performance of their steps in the order written, and one skilled in the art can readily appreciate that the sequences may be varied and still remain within the spirit and scope of the embodiments of the present application.

The steps illustrated in the flow charts of the figures may be performed in a computer system such as a set of computer-executable instructions. Also, while a logical order is shown in the flow diagrams, in some cases, the steps shown or described may be performed in an order different than here.

A UTXO (un-spent Transaction Output) model is usually used in blockchain transactions, and specifically, a Transaction includes one or more inputs and one or more outputs, where each input is a reference to the Output of the forward un-spent Transaction, and a corresponding unlock script. When the forward, non-spent transaction output reference is unlocked, the unlock cannot be referenced again, i.e., it cannot be double-spent. Each output comprises a corresponding token amount and a locking script, and the locking script can be unlocked only by the corresponding unlocking script, namely a new non-cost transaction output is created.

The user address in the transaction uses a one-time user address, and the one-time user address uses the generation mode of the account data chain, so that the received transaction data of the user forms a logic chain through the one-time user address. The use of one-time addresses can make it impossible for others to know who an address is, but the associated user using direct transactions can know. For example, Alice transfers to Bob, the transaction data records a primary address of Alice transferred to Bob, both parties can know a primary address of the other party in the transaction, so that the two parties to the transaction are not private and cannot be applied to a scene that the two parties to the transaction do not want to let the other party know the address.

The disclosed embodiment provides a blockchain transaction method with a commitment address, which aims to support private online, offline and overdraft transactions, and can aggregate and output the transactions, and prevent cheating by intermediaries.

An embodiment of the present disclosure provides an address generation method, as shown in fig. 1, including:

step 11, obtaining a user public key;

and step 12, generating a commitment address by using the user public key and a first generator (H), wherein the commitment address is used for carrying out block chain transaction, the commitment address is the sum of the user public key and a first coefficient operation result and the first generator (H) and a second coefficient operation result, and the operation is unidirectional operation.

Because the committed address is generated by adopting a one-way algorithm, which user belongs to cannot be reversely deduced, the committed address is adopted to participate in the blockchain transaction, and the privacy of the user can be protected.

In an exemplary embodiment, the one-way algorithm may be an elliptic curve scalar multiplication, or may be another one-way algorithm, which is not limited by this disclosure.

In an exemplary embodiment, the user public key may be a signature public key or a signature derived public key. The manner of obtaining the user public key may include:

mode 1, a second generator (G) and a third coefficient are operated to generate a signature public key as the user public key, the second generator is irrelevant to the first generator, and the third coefficient is a secret private key of the user;

in the method 2, a signature public key (i.e., the result of the operation of the second generator (G) and the third coefficient) is operated with the fourth coefficient to generate a signature-derived public key as the user public key.

In an exemplary embodiment, when there are a plurality of user public keys of one user, the commitment address is a sum of the plurality of user public keys and a plurality of first coefficient operation results and a sum of the first generator and a second coefficient operation result.

In an exemplary embodiment, the commitment address may be obtained by calculating a commitment address of a plurality of users, for example, the commitment address of the plurality of users is a sum of the commitment address of each user, and each user commitment address is a sum of the public key of the user and a first coefficient operation result of the user and a second coefficient operation result of the first generator and the user. For example, the commitment address C may be expressed as a federation mode C ═ C1, C2, …, where C1, C2, etc. are commitment addresses of different users.

The embodiment of the present disclosure provides a blockchain online transaction processing method, which is implemented based on the aforementioned commitment address, and the blockchain online transaction may include a first transaction generated by a sender (i.e., a sending user) and a second transaction generated by an intermediate node.

The blockchain online transaction processing method can be used for the sender to generate a first transaction, as shown in fig. 2, and comprises the following steps:

step 21, generating a first commitment address for each receiver (namely, a receiving user) according to a user public key of the receiver, wherein the first commitment address of each receiver can be generated by adopting the address generation method;

the recipients include all possible recipients, for example, the sender himself in the case of change.

Step 22, generating a first transaction according to the intermediate address of the intermediate node and submitting the first transaction to the intermediate node, wherein the first transaction comprises the set of the first commitment addresses.

By splitting the online transaction process into a first transaction and a second transaction, direct contact between the sender and the recipient may be avoided and user privacy may be protected. In this embodiment, the commitment address is used to complete the first transaction, and since the commitment address is generated by using a one-way algorithm, which user belongs to cannot be reversely deduced, the commitment address is used to participate in the transaction, so that the privacy of the user can be protected.

In an exemplary embodiment, the input to the first transaction comprises an unspent transaction output (UTXO) of the sender, the first transaction further comprising a transfer contract for an intermediate node to learn a transfer amount; or the input of the first transaction is null, and the first transaction is used for identifying that the transaction is an overdraft transaction.

In an exemplary embodiment, the method may further include: and generating an unlocking script, wherein the unlocking script comprises an operation used for associating the output commitment address in the referred locking script with the address of the receiver through the operation. When the sender needs to use the amount received as the receiver, an unlocking script needs to be generated and the operation is included in the unlocking script, so that the sender can only unlock the part of the amount by the correct receiver.

The blockchain online transaction processing method can also be used for generating a second transaction by the intermediate node, as shown in fig. 3, and comprises the following steps:

step 31, determining a recipient of the second transaction according to one or more first transactions, and obtaining a commitment address of the recipient from the first transactions;

for example, may be performed some time after receiving the input of one or more first transactions referenced as intermediate addresses.

Step 32, generating a receiving transaction address of the recipient and an output commitment address associated with the receiving transaction address;

step 33, generating a second transaction, the input of which refers to one or more first transactions, the commitment address of the recipient being the input commitment address of the second transaction, and the output of which comprises the recipient transaction address and the output commitment address of the recipient.

In this embodiment, the second transaction refers to a transaction referring to an output address of the first transaction, where the first transaction is a transaction generated by using the method shown in fig. 2, and the output address is an address of an intermediate node, so that the second transaction is generated by the intermediate node. The second transaction requires use of elements in the first set of committed addresses.

By splitting the online transaction process into a first transaction and a second transaction, direct contact between the sender and the recipient may be avoided and user privacy may be protected. In this embodiment, the commitment address is used to complete the second transaction, and since the commitment address is generated by using a one-way algorithm, which user belongs to cannot be reversely deduced, the commitment address is used to participate in the transaction, so that the privacy of the user can be protected.

In an exemplary embodiment, the online transaction processing method further includes: and generating a corresponding additional commitment address according to each input commitment address, wherein the input commitment address and the additional commitment address form an input commitment address pair, and the input commitment address pair is added into the input of the second transaction, the generation method of the additional commitment address is the same as that of the commitment address, and the coefficient used for generating the additional commitment address is different from that used for generating the commitment address.

In an exemplary embodiment, the online transaction processing method further includes: adding a signature of the input commitment address pair in the input of the second transaction to prove that an additional commitment address in the input commitment address pair and a commitment address are generated by the same user public key.

In an exemplary embodiment, in the online transaction processing method, all the input commit addresses and all the output commit addresses of the second transaction are equal by operation.

In an exemplary embodiment, in the online transaction processing method, the operation of equating all the input commit addresses and all the output commit addresses of the second transaction includes: the sum of all the committed addresses in the input of the second transaction is equal to the sum of all the committed addresses in the output of the second transaction plus the operation result of the first verification parameter and the first generator;

the method further comprises the following steps: the second transaction also includes the first authentication parameter for authentication by the recipient.

In an exemplary embodiment, in the online transaction processing method, all output commitment addresses of the same receiver are aggregated and then output, that is, the aggregated output commitment addresses can be aggregated to one address.

In an exemplary embodiment, the online transaction processing method further includes: obtaining a transaction amount according to the transfer contract in the first transaction, and encrypting and storing the transaction amount in the remark information of the second transaction for verification of both parties of the transaction; the remark information for the second transaction may also include some parameters of the transfer contract. For example, the transfer contract in the first transaction has a deferrable parameter, which can be acquired after the first transaction is completed and is delayed for a period of time, the intermediate node may calculate the result of the transfer contract according to the acquired deferrable parameter, and the remark information of the second transaction may include the deferrable parameter to provide the result of the user verifying the transfer contract.

The embodiment of the disclosure further provides a blockchain offline transaction processing method, which is implemented based on the commitment address, and the blockchain offline transaction includes an offline first transaction generated by a sender and an offline second transaction generated by an intermediate node.

The method for the sender to generate the offline first transaction, as shown in fig. 4, includes the following steps:

step 41, obtaining an offline transaction address of a receiver;

and 42, generating an offline first transaction, wherein the output of the offline first transaction comprises an offline transaction address of the receiver, a transfer amount and a transaction log, the transaction log comprises a commitment address of the receiver, and the commitment address of the receiver is generated by adopting the address generation method.

The offline transaction process is divided into an offline first transaction and an offline second transaction, wherein the offline first transaction is an offline transaction (offline transaction) between the sender and the receiver, and the offline second transaction is used for uplink transmission of the offline first transaction. In this embodiment, the commitment address is used to perform offline transaction, which ensures that only the correct receiving user can spend, thereby ensuring the correctness of the transaction while protecting the privacy of the user.

In an exemplary embodiment, the transaction log may further include a signature of the sender's offline transaction signature public key, a random number, and a sender's offline transaction signature private key on the transaction log, wherein a second coefficient corresponding to the first generator used in generating the recipient commitment address may be calculated from the random number and an offline transaction amount.

In an exemplary embodiment, the method further comprises: an offline request contract is sent to the intermediate node before the sender generates an offline first transaction, which may include an offline transaction address, a user public key of the sender. If the user public key of the sender is the signature derived public key, a generation parameter, that is, a fourth coefficient, needs to be carried.

The method for generating an offline second transaction by the intermediate node, the offline second transaction being used for recording the offline first transaction, as shown in fig. 5, includes the following steps:

step 51, receiving synchronous off-line transaction data;

step 52, generating an offline second transaction, wherein the input of the offline second transaction comprises a transaction log of the offline first transaction, and the output of the offline second transaction comprises a receiving transaction address and an output commitment address of the receiver and a transaction amount.

The offline transaction process is divided into an offline first transaction and an offline second transaction, wherein the offline first transaction is an offline transaction (offline transaction) between the sender and the receiver, and the offline second transaction is used for uplink transmission of the offline first transaction. In this embodiment, the intermediate node verifies the first transaction, and ensures the correctness of the transaction while protecting the privacy of the user.

In an exemplary embodiment, the transaction log includes a signature of the sender's offline transaction signature public key, the recipient's commitment address, a random number, and the sender's offline transaction signature private key on the transaction log, wherein a coefficient of a first generator of the recipient's commitment address may be a result of an operation of the random number and an offline transaction amount.

In an exemplary embodiment, all input commit addresses and all output commit addresses of the offline second transaction are equal by operation.

In an exemplary embodiment, wherein: the operation of equaling all the input commit addresses and all the output commit addresses for the offline second transaction comprises: the sum of all the committed addresses in the input of the offline second transaction is equal to the sum of all the committed addresses in the output of the offline second transaction plus the operation result of the second verification parameter and the first generator;

the method further comprises the following steps: the offline second transaction also includes the second verification parameter for verification by the recipient.

In an exemplary embodiment, all output commit addresses of the same recipient may be aggregated for output.

The above method is specifically described below.

The signature private key of the user in the system is generated and managed by the user, the system only can know the signature public key of the user, and other people only know the public key of the other party during transaction. The signature public and private key pair of the user can be generated by using an elliptic curve discrete logarithm algorithm. Let E be an elliptic curve defined over the finite field Fq, G be the base point (second generator) and the order be n.

For example, if the user Alice generates his private signature key da, his public signature key Pa ═ da × G, and the multiplication is scalar multiplication of elliptic curves, which has unidirectionality, i.e., Pa is easily obtained by da, but da is hardly obtained by Pa. Wherein G is a second generator, and da is a third coefficient of the user Alice, namely a secret private key. Likewise, if user Bob generates his private signature key db, his public signature key is Pb db G, where db is the third coefficient, i.e., the secret private key, of user Bob.

In the embodiment, an online transaction protocol involving a man-in-the-middle (middle node) is provided, and each transaction of a user does not directly perform a transaction with a receiver but needs to pass through the man-in-the-middle S. That is, the transaction needs to be divided into a first transaction (or called intermediate transaction) from the sender to the receiver and a second transaction (or called confuse transaction) from the receiver to the sender, and the confuse transaction from the receiver to the sender is controlled by the sender. The sender is sent to the intermediate transaction of S, the address is a special intermediate address of S, the address is different from a common user address, and only the address can be used for transferring to an output address which is associated with a committed address of the user, but not to any address. And can also aggregate the different committed addresses of the same receiver of different senders to output, and the senders are not aware of each other. The user can verify the transaction amount through the remark information to prevent the cheating of the man-in-the-middle S.

Take the example where sender Alice transfers a transaction to recipient Bob. Alice first needs to transfer to the particular intermediate address of the man-in-the-middle S, which is given by S and is clearly distinguished from the normal user address, e.g. by the prefix of the address. Although this address is controlled by S, S can only use this address to transfer to an output address associated with the user' S committed address. The specific method is that the input reference of the second transaction contains a first commitment address (input commitment address) and the output address contains a third commitment address (output commitment address). Optionally, S adds a second commitment address (additional commitment address) and the first commitment address to form an input commitment address pair, so that all input commitment addresses are equal to all output commitment addresses through a certain operation, and the output address is designed to be obtained by a third commitment address through an operation, thereby indirectly associating the output address with the first commitment address, and limiting that a special intermediate address of an intermediate transaction can only be output to an output address corresponding to the commitment address.

So the first transaction contains the set of committed addresses of all recipients; the first committed address contained in the input of the second transaction can only be the element in the referred committed address set in the first transaction, and can also contain a second committed address (additional committed address) to form an input committed address pair; the locking script in the second transaction output comprises an output address and an output commitment address, and all input commitment addresses and all output commitment addresses of the second transaction are equal through operation; the input of the first transaction comprises an unlocking script, the unlocking script is the unlocking cost of a locking script corresponding to the quoted unspent UTXO, and if the locking script comprises an output address and an output commitment address, the unlocking script needs to give an operation of obtaining the output address through the output commitment address, so that the output address of the second transaction is associated with the output commitment address in the second transaction through the operation.

In this embodiment, the commitment address of the user can be generated as follows: c ═ r × P + t × H, where C is the user's committed address, P is the user's public signature key, H is the first generator, r is the first coefficient, and t is the second coefficient. In other embodiments, the commitment address may be calculated using the user's signature-derived public key b P, i.e., C r (b P) + t H, where b is a fourth coefficient. r, t, b are all random numbers, and r, t, b ∈ (0, n). The signature derived public key (hereinafter referred to as derived public key) is calculated by a user's signature public key P and a coefficient b, and may also indicate a generation parameter a, where b may be a hash value calculated by a and a user generated key s, such as b ═ H3(s, a), where H3 is a hash function three. Therefore, the user can obtain his/her derived public key from the generation parameter a, but only knows the derived public key and the generation parameter, and cannot infer who the user obtained by the signature public key calculation. H is another generation point on the elliptic curve, and all does not know the private key of H with respect to G, i.e. cannot find a scalar x, so that H ═ x G.

In an exemplary embodiment, the commitment address of the user may include a plurality of signature public keys or derivative public keys of the user, where the commitment address of the user is a sum of the plurality of user public keys and a plurality of first coefficient operation results and a sum of the first generator and the second coefficient operation result, where the operation of the plurality of user public keys and the plurality of first coefficients respectively means that each user public key and a corresponding first coefficient are operated, and the first coefficients corresponding to the user signature public keys are different. For example, C r 1P 1+ r 2P 2+ … + t H.

In an exemplary embodiment, when there are the commitment addresses of a plurality of users, the commitment address is obtained by calculating the commitment address of each user, for example, the commitment address is the sum of the commitment addresses of each user, and each user commitment address is the sum of the user signature public key of the user and the first coefficient operation result of the user and the first generator and the second coefficient operation result of the user. That is, C may be represented by the sum of the committed addresses of multiple users, for example, C1 ═ r1 × P1+ t1 × H, C2 ═ r2 × P2+ t2 × H, …, so C ═ C1+ C2+ …, and t ═ t1+ t2+ …, that is, C may be represented as a joint (or aggregation) manner of multiple user committed addresses (C1, C2, …).

The commitment address is used for calculating an output address of the transaction according to the associated output commitment address, for example, if a locking script in the UTXO output includes the output address and the commitment address, the unlocking script must give an operation relationship between the output address and the commitment address. In all the confusing transactions described below, each input promise address C11 corresponds to a promise address C12 generated by the man-in-the-middle S, and forms an input promise address pair (C11, C12). But it is necessary to verify that the commitment address C12 generated by the broker S is indeed generated by the user signature public key or derivative public key of C11, assuming that the public key is P. One way of verification is given below:

s must be a multiple of C11 to produce C12, i.e., C12 x C11. Assuming that C11 is r11 is P + t11 is H, and C12 is r12 is P + t12 is H, so S calculates t12 is t11 is r12/r11, and C12 is (r12/r11) is C11, so S can give a signature with C11 as a base point and C12 as a public key, and the private key is (r12/r11), that is, C12 can be proved to be generated by P and H. If the commitment address C11 contains public keys of multiple users, C11 needs to be represented as a union of multiple user commitment addresses, namely (Ca11, Cb11, …), and C12 needs to be represented as a union of multiple user commitment addresses, namely (Ca12, Cb12, …), and a signature corresponding to each commitment address needs to be given, so that each commitment address generated by S is generated by a corresponding user public key and H, and cheating by a middleman S is prevented.

Referring to FIG. 6, the online transaction of Alice with Bob includes the following processes:

1. alice obtains the signature public key Pb of Bob or the derivative public key b Pb of Bob and the intermediate address Saddr of S. Since Bob ' S derived public key is also obtained by signature public key operation, x Pb in the following transaction can also be replaced with x ' (. b.. Pb), where x ' ═ x/b, but b value Alice does not know, S can know.

2. Alice generates random numbers ra1, ta1, rb1, tb1 e (0, n), and generates a commitment address set of all recipients, including Alice's commitment address Ca 1-ra 1 Pa + ta 1H and Bob's commitment address Cb 1-rb 1-Pb + tb 1H. An intermediate transaction is then generated with a transaction output address of Saddr, which is a special intermediate address that can only be used to transfer to an output address associated with the user's committed address (Ca1 and/or Cb 1). Alice signs the intermediate transaction using a private key corresponding to the non-spent transaction output address referenced by the intermediate transaction and generates an unlock script. Alice commits the intermediate transaction and informs S of the coefficients ra1, ta1, rb1, tb1 of the committed address, and S validates the committed address.

In this embodiment, an intermediary (i.e., an intermediate node) link is added, and one transaction is divided into an intermediate transaction (input) and an obfuscated transaction (output), so that the intermediate transaction includes an unlock script and the obfuscated transaction includes a lock script.

3. S verifies that the intermediate transaction of Alice is successful and then links the chain, and S generates a confusing transaction which refers to a plurality of intermediate transactions and outputs a plurality of addresses. For example, one input in the multiple inputs of the transaction refers to Saddr, and the input contains the commitment address to be transferred, such as Ca1 and Cb1, the commitment address can only be an element in the commitment address set contained in the intermediate transaction of the referred Saddr, and each commitment address is added with a commitment address and a signature generated by S, such as Ca1, Ca2 and a signature, respectively, to form an input commitment address pair (Ca1, Ca2), wherein Ca2 ra2 Pa + ta 2H. Similarly, Cb1 adds Cb2 and a signature to form an input commitment address pair (Cb1, Cb2), where Cb2 is rb2 Pb + tb 2H, ra2, ta2, rb2, tb2 are values generated by S.

The multiple outputs of the obfuscated transaction include the receiving transaction addresses of Alice and Bob, which are generated according to the generation manner of the account data chain, such as the receiving transaction address of Bob, through the generation parameter cb in the last receiving transaction data of Bob and the generation key sb of Bob, the primary key of Bob is generated, and then the primary user address of Bob is generated. As shown in FIG. 7, for any user, the first received transaction address Addr1 is derived based on the initial coefficient c0, the second received transaction address Addr2 is derived based on the generation parameter c1 in the first received transaction data, the third received transaction address is derived based on the generation parameter c2 in the second received transaction data, and so on.

For example, kb — H1(sb, cb) mod n, kb being the median value, H1 being the hash function one; qb kb Pb, Pb being Bob's public signature key, Qb being Bob's public primary key; lb is HL (Qb), Lb being the primary user address of Bob, the corresponding public key is Qb, and HL is the address hash function. And kb can be used as a first coefficient corresponding to Bob. Similarly, the primary public key Qa of Alice is ka, ka is an intermediate value (which may be a first coefficient corresponding to Alice), Pa is the signature public key of Alice, and the received transaction address La, which is the primary user address of Alice, is hl (Qa). So two output addresses among the multiple outputs of the transaction are La and Lb, respectively, and the output addresses are associated with output commitment addresses Ca3 ═ (ra1+ ra2) × Pa + va ═ H and Cb3 ═ rb1+ rb2) × Pb + vb × H, and Qa Ca 3-va ═ H, Qb ═ Cb 3-vb ═ H, so ra2 and rb2 are calculated from S, where ka ra1+ ra2, ra2 ═ ka-ra 1, rb1+ rb2, and rb2 ═ kb-rb 1, respectively. However, va and vb can also be calculated by S, for example, va ═ H2(sa, ca) mod n, vb ═ H2(sb, cb) mod n, and H2 is the hash function two, so that the user who outputs the commitment address can also calculate the v value by himself, and the sender of the intermediate transaction does not know who the commitment address is output. According to the UTXO model, the locking script is output, and the user needs to unlock the script to be unlocked in time. When the user generates the unlocking script, the parameter is not a public key corresponding to the referenced output address, but a coefficient v. For example, Bob needs to spend the output address Lb, the public key corresponding to the address is Qb, the output commitment address is Cb3, and as can be seen from the above, Cb 3-vb H, and Lb hl (Qb), it is possible to verify whether the referenced address is correct through vb, and use the private key corresponding to Qb to sign the transaction data to generate the unlocking script. It is guaranteed that the addresses output by the man-in-the-middle S cannot be cheated and must be generated from addresses committed by the output, otherwise the output cannot be spent.

The input of the obfuscated transaction references the output addresses of a plurality of intermediate transactions, and may also reference the output addresses of non-intermediate transactions; the output of the obfuscated transaction is a plurality of output addresses with committed addresses, and may also include output addresses without committed addresses. The number of committed addresses that are output may be different from the number of committed addresses that are input, since the output committed addresses of multiple identical users may be aggregated. The amount of the transaction is protected using the Pedersen commitment or the additive homomorphic commitment, the sum of all input amounts is equal to the sum of all output amounts, and whether the transaction amount is valid is verified through the range certification. The aliased transaction may also have a parameter t, t being the sum of the H coefficients of all incoming committed addresses minus the sum of the H coefficients of all outgoing committed addresses. It can be verified whether the sum of the input and output committed addresses plus t x H is equal. I.e. Ca1+ Ca2+ Cb1+ Cb2+ … is equal to Ca3+ Cb3+ … + t × H, where t ═ ta1+ ta2-va + tb1+ tb2-vb + …. In the online second transaction, the t can be used as a first verification parameter; in the offline second transaction, t may be used as the second verification parameter. The authentication parameters in the online second transaction and the offline second transaction may be the same or different.

The commitment address may also include signature public keys or derived public keys of multiple users, for example, the input commitment address pair includes C1 and C2, where C1 is ra1 Pa + rb1 Pb + t 1H, C2 ra2 Pa + rb2 Pb + t 2H, the output commitment address C3 is (ra1+ ra2) Pa + (rb1+ rb2) Pb + v H, Qa ka Pa, Qb kb Pb, L HL (Qa, Qb), and L is a primary address. Besides the coefficient v, the unlocking script may also include Qa and Qb, C3 may be verified to be Qa + Qb + v × H, and then the transaction data is jointly signed by using the private keys corresponding to Qa and Qb to generate the unlocking script, or an aggregated signature may be used without including Qa and Qb. The commitment address may contain the public keys of multiple users to enhance security.

Other instructions and overdraft transactions:

1. through the intermediate transaction and the obfuscation transaction, the transfer can be unlocked only by the user corresponding to the commitment address, and the outputs of a plurality of intermediate transactions with the same user commitment address, which are referenced, can be aggregated into one, but the senders of the intermediate transactions are not aware of each other, and the senders and the receivers are not aware of each other. For example, Alice transfers to Bob, which knows only Ca1 but not Ca 3; bob only knows Ca3, but not Ca 1; neither Alice nor Bob is aware of Ca 2. And the one-time user address is used, so that Alice does not know the output address of Bob, and Bob does not know the commitment address of Alice intermediate transaction and the output address of Alice change, so that the aim of privacy transaction can be fulfilled. If Alice transfers to Bob and Charlie at the same time, Bob does not know who the remaining commit addresses are, or even how many commit addresses are in the input, because neither does it know which is the input, nor does Charlie. If Alice and Charlie are transferred to Bob at the same time, Alice and Charlie do not know each other nor which is the output, and the outputs of the same user converge into one, nor does Bob know which is the input. The aggregate output of the committed addresses of the same user is that the coefficients of the public key of the same user are added and the H coefficients are added. By aggregating the outputs, it can be applied to some users' scenarios of receiving transactions at high frequency.

2. The intermediary S may control the intermediary transaction to the completion time of the obfuscated transaction, such as an hour or a day, or may cancel the transaction. The transaction is cancelled by transferring to Alice's commitment address Ca 1; the transaction is completed by transferring the change to Bob's commitment address Cb1, and if the change is available, transferring the change to Alice's commitment address Ca 1. The final transfer amount in the confusing transaction is controlled by S, which may be based on a contract for an intermediate transaction. The sender does not actually know the address of the recipient, nor the amount actually received by the recipient, so to prevent the man-in-the-middle S from cheating, notes can be added in the confusing transaction. For example, Alice transfers to Bob a remark labeled r G and r Pb, where r is Hs (sa, Cb1) mod n and Hs is a hash function four, so Alice can find which label is based on r G and can prove that Bob can also find it based on his private key, because db (r G) r Pb. If Alice uses transfer by the derivative public key b Pb of Bob, then step 1 needs to obtain the corresponding generation parameter a, which is labeled r G, r (b Pb), a, where b is H2(sb, a), so Bob can also find the label. Then using ea ═ Hs (sa, r × (Pb)) as the encryption key for Alice and eb ═ Hs (sb, r × (Pb)) as the encryption key for Bob, S randomly generates an encryption key es, encrypts the memo information that Alice transfers to Bob using es, and then encrypts es using ea and eb, respectively. Therefore, both Alice and Bob can find the label and decrypt the remark information of the transfer, the remark information can be the value (value) of (Alice) transfer (Bob), the value can be obtained according to the contract of the intermediate transaction, Bob can verify whether the actually received amount is equal to the value or not, Alice can verify whether the amount of change is equal to the input amount minus the value or not, and user information in the remark can select whether to be masked or not, namely only the (star) transfer (star) value or not, so that Bob cannot know the information of the sender, and Alice only knows the signature public key or the derivative public key of Bob, and thus, the anonymous transfer can be realized. If the aggregation output exists, the multiple inputs corresponding to the aggregation output respectively have remark information, and the corresponding user can verify whether the amount of the aggregation output is equal to the sum of the amounts of all the remark information of the user. The remark information may also include part of parameters of the transfer contract, for example, the contract of the first transaction is an offline transaction application, the contract may have part of deferrable parameters, the applicant completes the offline transaction after a period of time delay and uploads an offline transaction log, and the amount spent offline by the applicant is calculated and transferred to the broker S according to the offline transaction log as the parameters of the contract. The actual transaction amount can be verified whether to be correct or not through the amount in the remark information, and cheating by a man-in-the-middle S is prevented. A delay-able parameter is a parameter that is obtained after a period of time, such as one or more of the following: parameters requiring third party authentication, parameters generated by a sender delay (off-line transaction log), fair random numbers, voting results, and the like.

3. The online transaction may be an overdraft transaction, with only the intermediate transactions changing. The intermediate transaction of the overdraft transaction does not input citation, does not output amount or the amount is 0, the intermediate transaction also comprises a derivative public key and a generation parameter of the overdraft user, and the intermediate transaction is signed by using a private key corresponding to the derivative public key. For example, the derived public key of Alice is a × Pa, where Pa is the public signature key of Alice, a ═ H3(sa, ca), sa is the generated key of Alice, ca is the generation parameter, and H3 is the hash function three. Alice needs to inform S to generate a parameter ca, and S verifies the derived public key. The confounding transaction for the overdraft transaction need only contain the partial input amount provided by S, which is then cleared with the user of the overdraft transaction. The clearing mode is that a user is required to initiate a transaction for paying the clearing overdraft amount, the transaction remark is provided with a hash value of a user overdraft transaction list, and the user can verify whether the amount is correct through the list.

The embodiment of the disclosure also provides an offline transaction method participated by the broker, the user firstly generates an offline request contract, generates an offline transaction address, a derived public key and a generation parameter of the user, and the broker S signs the parameters of the offline transaction address, the derived public key, the offline transaction amount, the permission time and the like of the user. The offline transaction of the user can only use the offline transaction address signed by the man-in-the-middle S for transaction, and the amount must refer to the offline transaction limit signed by the S. When the off-line wallet of the user is on line, all off-line transaction data are synchronized, the broker S generates a corresponding transaction record according to the off-line transaction data, that is, an off-line obfuscated transaction (record), and different commitment addresses of the same user can be aggregated and output.

Referring to fig. 8, the whole process of the offline transaction (including the offline and online processes) between Alice and Bob is:

1. the user may be prepared in advance, such as an online application, before the transaction is offline. For example, Alice generates an offline transaction signature private key di, and the corresponding public key is Pi ═ di × G, where Pi is Alice's offline transaction signature public key. And generating a random number a epsilon (0, n), wherein the derived public key of Alice is a Pa, a is H3(sa, ca), sa is the generated key of Alice, and ca is the generated parameter. Alice generates an offline request contract, which contains (Pi, a × Pa) and may also contain a generation parameter ca of the derived public key, signs contract data by using a private key corresponding to the derived public key, then submits the offline request contract, and informs S of the generation parameter ca, and S verifies the derived public key. An offline transaction signing public key may be used as the offline transaction address.

2. S verifies that the offline contract request of Alice succeeds, and then uplinks, and S signs the data of the offline transaction address Pi, the derivative public key a x Pa, the offline transaction amount, the permission time and the like of Alice, sends the data to Alice, and encrypts and stores the data in a local wallet by Alice. It can be seen that the offline transaction amount is given by the broker S, and has no relation with the unspent transaction output on Alice' S line, which is equivalent to the overdraft amount of the user. If the offline transaction quota required to be applied is high, the online unspent transaction output can be locked, for example, a user can apply for offline request contracts through contract data of intermediate transactions of the online transaction. The locking mode is that the user initiates an intermediate transaction of the online transaction and includes the commitment address of the S. Bob also applies for offline transactions, such as his offline transaction address (public key) Pj, which is Bob's offline transaction signature private key, deriving the public key b Pb. In the off-line transaction of the user, the transaction can be carried out only by using the off-line transaction address with the S signature, and the amount must refer to the off-line transaction limit with the S signature. The offline transaction data includes log information, using the recipient's commitment address, which is generated from the derived public key. When the user carries out off-line transaction, only the off-line transaction signature private key is needed to be used, and the signature private key on the user line is not used, so that the safety is enhanced. S records the off-line transaction addresses of all users, so that the off-line transaction can be verified and the related users can be distinguished.

3. The offline transaction uses the UTXO model and the transaction amount is in clear text. For example, Alice transfers to Bob 'S offline wallet through offline wallet, Alice needs to check whether Bob' S offline transaction address passes through S signature and then generates offline transaction data, Bob needs to check whether Alice refers to the offline transaction address passes through S signature and whether the transaction amount refers to the S-signed offline transaction amount, and then verifies whether the transaction amount is correct. Log information transferred by Alice to Bob needs to include an offline transaction address Pi of Alice, a commitment address Cb1 of Bob, a random number (nonce), and a signature of an offline transaction signature private key di of Alice on the log information, wherein Cb1 is rb1 (b Pb) + tb 1H, tb1 is nonce + value b, rb1 is a random number, and additional information of the transaction includes rb1, tb1, a hash value of the transaction remark, and the like. The nonce is used by Bob to ensure that b Pb is unique as the derived public key, otherwise, the off-line receiving transaction of the repeated nonce cannot be recorded on line, and a random number + a timestamp can be used. The off-line transaction data can be valid only after being signed by a private key of the off-line transaction address of the transaction party, and other people need to verify the transaction data and the log information at the same time and verify whether the commitment address and the transaction amount are correct or not according to rb1 and tb 1. If the amount transferred to Charlie by Bob has not been signed by S, Charlie also needs to trace back to the offline transaction amount of the S signature. For example, if Bob transfers Alice to his amount and then transfers Charlie to Charlie, Charlie needs to verify and record the transaction transferred by Alice to Bob and verify whether the transaction address and transaction amount of the transfer are signed by S, otherwise, the transaction is invalid.

4. When the off-line wallet is on-line again, all off-line transaction data are synchronized to the S, the S analyzes the transaction data, and then a corresponding transaction record is generated, namely, an off-line obfuscated transaction (record). The off-line transaction data uses the UTXO model to verify whether the transaction is valid, and the data recorded on the chain is mainly log information in the transaction. And S, inputting a log containing offline transfer of Alice to Bob. For example, Alice offline transaction address Pi, Bob commitment address Cb1, nonce, and Pi correspond to signatures of private keys, then S adds Cb2 and the signature to Cb1, and similarly forms an input commitment address pair, while output address Lb is associated with output commitment address Cb3, and the output address and the output commitment address are generated in a manner consistent with that of online obfuscated transactions, and outputs of the same user may also be aggregated into one. The same as the online transaction is that Alice does not know Bob's output address and output amount, but Bob knows Alice's input log and the transaction amount, tb1-nonce, so Bob can verify whether the output amount is correct, and if there is an aggregate transaction, Bob can also verify from the sum of the amounts of the multiple input logs. Because only log information is linked up, the transaction amount and the receiver information cannot be leaked, and therefore the off-line transaction data is also private after being recorded on line. The input amount for the offline confounded transaction is provided by S, which is then cleared with the user of the offline transaction. If the clearing mode is the off-line receiving transaction of the user, S sends the aggregation output of the off-line confusing transaction on the line to the user, and the user can verify whether the amount of the off-line receiving transaction is consistent with the output amount of the off-line confusing transaction on the line. If the user sends the transaction off line, S uses the balance to pay, then the user needs to initiate the transaction of paying and clearing the amount sent off line, the transaction remark has a hash value of the user off line sending transaction list, and the user can verify whether the amount is correct through the list. When the user offline transaction is double-spending, the offline confusing transaction generated by the step S only contains the log information and the signature of the user offline transaction, and the list contains the offline transaction data which are signed by both parties and have the log information. Therefore, when even multiple flowers occur, S can correctly generate the corresponding transaction record. For example, Alice pays for Bob and Charlie offline in double blossoms, and when Bob and Charlie come online respectively, S can generate a correct offline obfuscated transaction and perform accountability for Alice.

As shown in fig. 9, the offline process of Alice and Bob for offline transaction includes:

1. bob sends the S-signed offline transaction address Pj, the derived public key b Pb, and the generated random number rb1, nonce to Alice. The nonce is required to ensure that b × Pb is unique as the derived public key, and may be a random number + a timestamp.

2. And (3) verifying the offline transaction address and the derived public key of the Bob by Alice, and generating log information: pi, Cb1, nonce, and sign the log using Pi's private key di, where committed address Cb1 is rb1 (b Pb) + tb 1H, and tb1 is nonce + value b.

The UTXO, which references the S signature, then generates offline transaction data. Inputting UTXO with reference of Alice; outputting an offline transaction address Pj and value B with 1 as Bob and outputting an offline transaction address Pi and value-value B with 2 as Alice, wherein value is the output amount of the UTXO which is input for reference; journal information and additional information including rb1, tb1, hash value of transaction notes, etc. Alice sends the offline transaction data to Bob. Only the log information now has Alice's signature.

3. Bob verifies Alice's off-line transaction address and traces back whether Alice's UTXO is correct, then verifies whether log information and signature are valid, whether additional information is correct, whether transaction amount is correct, whether license time is valid, if verification is successful, signature is carried out on off-line transaction data by using Bob's off-line transaction signature private key dj, and a signature value is sent to Alice.

4. And the Alice verifies whether the signature value of the Bob is valid, if the verification is successful, the offline transaction data is signed by using the offline transaction signature private key di of the Alice, and the signature value is sent to the Bob.

5. And Bob verifies whether the signature value of Alice is valid, and if the verification is successful, the offline transaction is successful.

FIG. 10 is a schematic diagram of an offline transaction online recording process of a user Alice and a user Bob, the offline transaction in which Alice transfers to Bob, the online recording process including a transaction in which Alice transfers to S and a transaction in which S transfers to Bob.

The embodiment of the disclosure divides the online transaction protocol of the user into the intermediate transaction and the mixed transaction, ensures that only the user corresponding to the intermediate transaction committed address can spend through the committed address, and can support the overdraft transaction. The user's offline transaction agreements are divided into online offline request contracts and offline obfuscated transactions (records) and offline transactions, where intermediaries participate online. The offline transaction can only use the offline transaction address and the offline transaction amount signed by the man-in-the-middle S, and ensure that the output can only be spent by the corresponding user through the commitment address. The online transaction and the offline transaction have privacy after online recording, the commitment address of the same user can be output in an aggregation mode, the commitment address can also contain signature public keys of a plurality of users, and signature derivation public keys of the users can be supported.

An exemplary embodiment of the present disclosure also provides a computer storage medium storing a computer program; the computer program, when executed, is capable of implementing the methods provided by one or more of the foregoing exemplary embodiments, e.g., performing one or more of the methods shown in fig. 1-5. Including volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by a computer.

An exemplary embodiment of the present disclosure also provides a computer apparatus (or computer device). The computer apparatus may include a processor, a memory, and a computer program stored on the memory and executable on the processor, the processor when executing the computer program may implement the operations performed by a sender or a receiver in the present disclosure (e.g., implement the methods of fig. 1, 2, or 4), when the computer device is a user device; the processor, when executing the computer program, may implement the operations of the intermediate node in the present disclosure (e.g., implement the method of fig. 3 or fig. 5), in which case the computer device is an intermediate node device. The structure of the above-described computer apparatus is explained below by way of an example.

As shown in fig. 11, in one example, a computer device may include: a processor 101, a memory 102, a bus system 103 and a transceiver 104, wherein the processor 101, the memory 102 and the transceiver 104 are connected via the bus system 103, the memory 10 is used for storing instructions, and the processor 101 is used for executing the instructions stored in the memory 102 to control the transceiver 104 to transmit signals.

It should be understood that the processor 101 may be a Central Processing Unit (CPU), and the processor 101 may be other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), off-the-shelf programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

Memory 102 may include both read-only memory and random access memory and provides instructions and data to processor 101. A portion of the memory 102 may also include non-volatile random access memory. For example, the memory 102 may also store device type information.

The bus system 103 may include a power bus, a control bus, a status signal bus, and the like, in addition to the data bus. For clarity of illustration, however, all buses are labeled as bus system 103 in fig. 11.

In implementation, the processing performed by the computer device may be performed by instructions in the form of hardware, integrated logic circuits, or software in the processor 101. That is, the steps of the method disclosed in the embodiments of the present disclosure may be implemented by a hardware processor, or implemented by a combination of hardware and software modules in a processor. The software module may be located in a storage medium such as a random access memory, a flash memory, a read only memory, a programmable read only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 102, and the processor 101 reads the information in the memory 102 and completes the steps of the method in combination with the hardware thereof. To avoid repetition, it is not described in detail here.

It will be understood by those of ordinary skill in the art that all or some of the steps of the methods, systems, functional modules/units in the devices disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof. In a hardware implementation, the division between functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed by several physical components in cooperation. Some or all of the components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on computer readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media). The term computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data, as is well known to those of ordinary skill in the art. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by a computer. In addition, communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media as known to those skilled in the art.

The foregoing shows and describes the general principles and features of the present application, together with the advantages thereof. The present application is not limited to the above-described embodiments, which are described in the specification and drawings only to illustrate the principles of the application, but also to provide various changes and modifications within the spirit and scope of the application, which are within the scope of the claimed application.

Claims

1. An address generation method, comprising:

acquiring a user public key;

2. The address generation method according to claim 1, wherein the obtaining the user public key includes:

operating a second generator and a third coefficient to generate a signature public key as the user public key, wherein the second generator is irrelevant to the first generator, and the third coefficient is a secret private key of the user; or

And operating the signature public key and the fourth coefficient to generate a signature derived public key as the user public key.

3. The address generation method according to claim 1,

when a plurality of user public keys of one user exist, the commitment address is the sum of the plurality of user public keys and a plurality of first coefficient operation results and the sum of the first generating element and a second coefficient operation result respectively; or

The commitment address is obtained by calculating the commitment addresses of a plurality of users.

4. A blockchain online transaction processing method for a sender to generate a first transaction, the method comprising:

5. The blockchain online transaction processing method of claim 4, wherein:

the input for the first transaction comprises an unspent transaction output (UTXO) of the sender, the first transaction further comprising a transfer contract for an intermediate node to learn a transfer amount; or

The input of the first transaction is null for identifying the transaction as an overdraft transaction.

6. The blockchain online transaction processing method of claim 4, further comprising:

and generating an unlocking script, wherein the unlocking script comprises an operation used for associating the output commitment address in the referred locking script with the address of the receiver through the operation.

7. A blockchain online transaction processing method for an intermediate node to generate a second transaction, the method comprising:

8. The blockchain online transaction processing method of claim 7, further comprising:

and generating a corresponding additional commitment address according to each input commitment address, wherein the input commitment address and the additional commitment address form an input commitment address pair, and the input commitment address pair is added into the input of the second transaction, the generation method of the additional commitment address is the same as that of the commitment address, and the coefficient used for generating the additional commitment address is different from that used for generating the commitment address.

9. The blockchain online transaction processing method of claim 8, further comprising:

adding a signature of the input commitment address pair in the input of the second transaction to prove that an additional commitment address in the input commitment address pair and a commitment address are generated by the same user public key.

10. The blockchain online transaction processing method of claim 7, 8 or 9, wherein all input commit addresses and all output commit addresses of the second transaction are equal through operation.

11. The blockchain online transaction processing method of claim 10, wherein the operation of equating all input commit addresses and all output commit addresses of the second transaction includes:

the sum of all the committed addresses in the input of the second transaction is equal to the sum of all the committed addresses in the output of the second transaction plus the operation result of the first verification parameter and the first generator;

12. The blockchain online transaction processing method of claim 7, wherein all the output commitment addresses of the same receiver are aggregated and then output.

13. The blockchain online transaction processing method of claim 7, further comprising: and obtaining a transaction amount according to the transfer contract in the first transaction, encrypting and storing the transaction amount in remark information of the second transaction for verification of both parties of the transaction, wherein the remark information also comprises part of parameters of the transfer contract.

14. A blockchain offline transaction processing method for a sender to generate an offline first transaction, the method comprising:

15. The blockchain offline transaction processing method of claim 14, wherein,

the transaction log further comprises an offline transaction signature public key of the sender, a random number and a signature of the offline transaction signature private key of the sender on the transaction log, wherein a second coefficient used for generating the commitment address of the receiver is obtained by calculating the random number and the offline transaction amount.

16. The blockchain offline transaction processing method of claim 14, further comprising sending an offline request contract to the intermediate node before the sender generates the offline first transaction, the offline request contract comprising an offline transaction address, a user public key of the sender.

17. A blockchain offline transaction processing method for an intermediate node to generate an offline second transaction, the method comprising:

18. The blockchain offline transaction processing method of claim 17, wherein the transaction log comprises a signature of a sender's offline transaction signature public key, a recipient's commitment address, a random number, and a sender's offline transaction signature private key on the transaction log, wherein a coefficient of a first generator of the recipient's commitment address is calculated from the random number and an offline transaction amount.

19. The blockchain offline transaction processing method of claim 17 or 18, wherein all input commit addresses and all output commit addresses of the offline second transaction are equal by operation.

20. The blockchain offline transaction processing method of claim 19, wherein: the operation of equaling all the input commit addresses and all the output commit addresses for the offline second transaction comprises:

the sum of all the committed addresses in the input of the offline second transaction is equal to the sum of all the committed addresses in the output of the offline second transaction plus the operation result of the second verification parameter and the first generator;

21. The method of claim 17, wherein all output commit addresses of the same recipient are aggregated and output.

22. A computer-readable storage medium storing computer-executable instructions for performing the method of any of claims 1-3 or 4-6 or claims 7-13 or claims 14-16 or claims 17-21.

23. A user device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the processor, when executing the program, carries out the steps of the method according to any of claims 1-3 or 4-6 or claims 14-16.

24. An intermediate node apparatus comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor when executing the program implements the steps of the method as claimed in any one of claims 7 to 13 or claims 17 to 21.

25. A blockchain transaction system comprising a user device according to claim 23 and an intermediate node device according to claim 24.