CN112348677B

CN112348677B - Address generation and blockchain online and offline transaction method, device, system and medium

Info

Publication number: CN112348677B
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: 2024-04-26
Anticipated expiration: 2040-11-11
Also published as: CN112348677A

Abstract

The disclosure provides 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, which can support private transactions. The address generation method comprises the following steps: acquiring a user public key; and generating a promised address by adopting the user public key and a first generator, wherein the promised address is used for carrying out blockchain transaction, the promised address is the sum of the user public key and a first coefficient operation result and the sum of the first generator and a second coefficient operation result, and the operation is a one-way algorithm.

Description

Address generation and blockchain online and offline transaction method, device, system and medium

Technical Field

The present disclosure relates to the field of computer data processing technology, 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, the transaction mode of the connected blockchain is quoted, the transaction two sides can check the transaction address of the other side, the off-line transaction data of the two sides cannot be overtly verified after being linked, the transaction data has privacy, and when the transaction passing through the middle person is lacking, the two sides of the transaction do not know the address and the output amount of the other side, and the cheating of the middle person 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.

Provided herein are 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, which can support private transactions.

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

Acquiring a user public key;

And generating a promised address by adopting the user public key and a first generator, wherein the promised address is used for carrying out blockchain transaction, the promised address is the sum of the user public key and a first coefficient operation result and the sum of 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 generating a first transaction by a sender, the method comprising:

Generating a first promise address for each recipient according to the recipient's user public key, wherein the first promise address of each recipient is generated by the method of any one of claims 1 to 3;

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 first promised addresses.

In a third aspect, the present disclosure further provides a blockchain online transaction processing method for generating a second transaction by an intermediate node, the method including:

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

generating a received transaction address for the recipient and an outgoing committed address associated with the received transaction address;

Generating a second transaction, an input of the second transaction referencing one or more first transactions, a commitment address of the recipient as an input commitment address of the second transaction, an output of the second transaction comprising a received transaction address and an output commitment address of the recipient.

In a fourth aspect, the present disclosure further provides a blockchain offline transaction processing method for generating an offline first transaction by a sender, the method comprising:

Obtaining an offline transaction address of a receiver, generating an offline first transaction, and outputting the offline first transaction, wherein the offline transaction address, the transfer amount and the transaction log of the receiver are included in the transaction log, and the promise 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 for generating an offline second transaction by an intermediate node, the method including:

receiving synchronized offline transaction data, generating an offline second transaction, the input of the offline second transaction comprising a transaction log of an offline first transaction, the output of the offline second transaction comprising a recipient's received transaction address and output commitment address and a transaction amount, wherein the offline first transaction is a transaction generated using the method of any 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 methods described above.

In a seventh aspect, the present disclosure also provides a user device including a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor implementing any one of the address generation method, the blockchain online transaction processing method for generating a first transaction by a sender, and the blockchain offline transaction processing method for generating an offline first transaction by a sender when the program is executed.

In a seventh aspect, the present disclosure further provides an intermediate node apparatus, including a memory, a processor, and a computer program stored on the memory and executable on the processor, where the processor executes the program to implement any one of the above-mentioned blockchain online transaction processing method for the intermediate node to generate the second transaction, and the blockchain offline transaction processing method for the intermediate node to generate the offline second transaction.

By adopting the method disclosed by the invention, the one-way algorithm is adopted to generate the promised address, so that the privacy of the user can be ensured. Similarly, the adoption of the promised address to participate in the blockchain online transaction or offline transaction can protect the privacy of the user, so that the two parties of the transaction 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 become apparent upon reading and understanding the accompanying drawings and detailed description.

Drawings

The accompanying drawings are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate and do not limit the application.

FIG. 1 is a flow chart of an address generation method according to an embodiment of the present disclosure;

FIG. 2 is a flow chart of a method of a sender generating a first transaction in accordance with an embodiment of the present disclosure;

FIG. 3 is a flow chart of a method for an intermediate node to generate a second transaction in accordance with an embodiment of the present disclosure;

FIG. 4 is a flow chart of a method for a sender to generate an offline first transaction in accordance with an embodiment of the present disclosure;

FIG. 5 is a flow chart of a method for an intermediate node to generate an offline second transaction in accordance with an embodiment of the present disclosure;

FIG. 6 is a schematic diagram of an online transaction flow for user Alice and user Bob in accordance with an embodiment of the present disclosure;

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

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

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

FIG. 10 is a schematic diagram of an offline transaction line record of user Alice and user Bob according to an embodiment of the 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 has been described in terms of several embodiments, but the description is illustrative and not restrictive, 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 described embodiments. 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 in place of any other feature or element of any other embodiment unless specifically limited.

The present application includes and contemplates combinations of features and elements known to those of ordinary skill in the art. The disclosed embodiments, features and elements of the present application may also be combined with any conventional features or elements to form a unique inventive arrangement as defined by the claims. Any feature or element of any embodiment may also be combined with features or elements from other inventive arrangements to form another unique inventive arrangement as defined in the claims. It is therefore to be understood that any of the features shown and/or discussed in the present application may be implemented alone or in any suitable combination. Accordingly, the embodiments are not to be restricted except in light of the attached claims and their equivalents. Further, various modifications and changes may be made within the scope of the appended claims.

Furthermore, 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 sequences of steps are possible as will be appreciated by those of ordinary skill in the art. Accordingly, the particular order of the steps set forth in the specification should not be construed as limitations on the claims. Furthermore, 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 flowchart of the figures may be performed in a computer system, such as a set of computer-executable instructions. Also, while a logical order is depicted in the flowchart, in some cases, the steps depicted or described may be performed in a different order than presented herein.

A UTXO (Unspent Transaction Output, unexpired transaction output) model is typically employed in blockchain transactions, specifically a transaction that contains one or more inputs and one or more outputs, each input being a reference to a forward unexpired transaction output, and a corresponding unlock script. When the forward unconsumed transaction output reference is unlocked, the unlock cannot be referenced again, i.e., double-flower cannot be performed. Each output contains a corresponding token amount and a locking script, which is unlocked only by a corresponding unlocking script, i.e., a new, unexpired transaction output is created.

The user address in the transaction uses a primary user address, and the primary user address uses the generation mode of the account data chain, so that the received transaction data of the user form a logic chain through the primary user address. The way an address is used once can make it impossible for others to know who an address is, but the relevant user using a direct transaction can. For example, alice transfers to Bob, and the transaction data records an address of Alice transferring to Bob, and both parties can know the address of the other party in the transaction, so that the two parties in the transaction are not private and cannot be applied to a scene that the two parties in the transaction do not want the other party to know the address.

The embodiment of the disclosure provides a blockchain transaction method with a promised address, which aims to support private online, offline and overdraft transactions, and can aggregate and output the transactions, and prevent middle people from cheating.

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

Step 11, obtaining a user public key;

And 12, generating a promised address by adopting the user public key and a first generating element (H), wherein the promised address is used for carrying out blockchain transaction, the promised address is the sum of the user public key and a first coefficient operation result and the sum of the first generating element (H) and a second coefficient operation result, and the operation is unidirectional operation.

Because the promised address is generated by adopting a one-way algorithm, which user can not be reversely deduced, the promised 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 other one-way algorithms, as this disclosure is not limited in this regard.

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

In the mode 1, a signature public key is generated by operating a second generator (G) and a third coefficient, wherein the second generator is not related to the first generator, and the third coefficient is a secret private key of a user;

In embodiment 2, a signature derivative public key is generated by performing an operation on a signature public key (i.e., an operation result of the second generator (G) and the third coefficient) and the fourth coefficient, as the user public key.

In an exemplary embodiment, when there are a plurality of user public keys of a user, the promised 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 respectively.

In an exemplary embodiment, the promised address may be obtained by calculation from promised addresses of a plurality of users, for example, the promised addresses of the plurality of users are the sum of promised addresses of each user, and each promised address of the user is the sum of the 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. For example, the promise address C may be represented as a federation c= (C1, C2, …), where C1, C2, etc. are promise addresses of different users.

The disclosed embodiments provide a blockchain online transaction processing method implemented based on the aforementioned promised address, which can 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 promise address for each receiver according to the user public key of the receiver (i.e. the receiving user), wherein the first promise address of each receiver can be generated by adopting the address generation method;

the recipient includes all possible recipients, for example, the sender himself if a change is made.

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 first promised addresses.

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

In an exemplary embodiment, the input of the first transaction includes an unexpired transaction output (UTXO) of the sender, the first transaction further including a transfer contract for the intermediate node to learn the transfer amount; or the input of the first transaction is null for identifying the transaction as a overdraft transaction.

In an exemplary embodiment, the method may further include: an unlock script is generated, wherein the unlock script comprises an operation for correlating an output promised address in the referenced lock script with an address of a receiver through the operation. When the sender needs to use the amount received as the recipient, an unlocking script needs to be generated and the above operations included therein to ensure that only the correct recipient can unlock the partial amount.

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

step 31, determining a receiver of the second transaction according to one or more first transactions, and acquiring a promised address of the receiver from the first transactions;

for example, may be performed after a period of time after receiving one or more first transactions in which the input references are intermediate addresses.

Step 32, generating a received transaction address of the receiver and an output promise address associated with the received transaction address;

Step 33, generating a second transaction, wherein the input of the second transaction refers to one or more first transactions, the promise address of the receiver is used as the input promise address of the second transaction, and the output of the second transaction comprises the receiving transaction address and the output promise address of the receiver.

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

By splitting the online transaction process into a first transaction and a second transaction, direct contact between the sender and the receiver may be avoided, and user privacy may be protected. In this embodiment, the second transaction is completed by using the promised address in the middle, and since the promised address is generated by adopting a one-way algorithm, which user belongs to cannot be deduced in reverse, the promised address is adopted 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: generating a corresponding additional promise address according to each input promise address, wherein the input promise address and the additional promise address form an input promise address pair, and the input promise address pair is added into the input of the second transaction, wherein the generation method of the additional promise address is the same as that of the promise address, and the coefficient used when generating the additional promise address is different from that used when generating the promise address.

In an exemplary embodiment, the online transaction processing method further includes: the signature of the input pair of promised addresses is added to the input of the second transaction to prove that the additional promised addresses and promised addresses of the input pair of promised addresses are generated by the same user public key.

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

In an exemplary embodiment, in the online transaction processing method, the operation equaling all input promise addresses and all output promise addresses of the second transaction includes: the sum of all promise addresses in the input of the second transaction is equal to the sum of all promise 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 steps of: the second transaction also includes the first verification parameter for verification by the recipient.

In an exemplary embodiment, in the online transaction processing method, all output promised addresses of the same receiver are aggregated and output, i.e. 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 remark information of the second transaction for verification of both transaction parties; the remark information of the second transaction may further include a part of parameters of the transfer contract. For example, the transfer contract in the first transaction has a deferrable parameter that is required to be obtained after the first transaction is completed and delayed for a period of time, the intermediate node may calculate the result of the transfer contract according to the obtained deferrable parameter, and the remark information of the second transaction may include the deferrable parameter to provide the result of the user verification transfer contract.

The embodiment of the disclosure also provides a blockchain offline transaction processing method, which is realized based on the promised address, wherein the blockchain offline transaction comprises an offline first transaction generated by a sender and an offline second transaction generated by an intermediate node.

The method for generating the offline first transaction by the sender, as shown in fig. 4, comprises the following steps:

Step 41, obtaining the offline transaction address of the receiver;

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

The present embodiment divides the offline transaction process into an offline first transaction, which is an offline transaction (off-line transaction) of the sender and the receiver, and an offline second transaction for linking the offline first transaction. In this embodiment, the promised address is used to conduct the downlink transaction, so that only the correct receiving user can spend, and the correctness of the transaction is ensured while the privacy of the user is protected.

In an exemplary embodiment, the transaction log may further include a public key of an offline transaction signature of the sender, a random number, and a signature of the transaction log by the private key of the offline transaction signature of the sender, wherein a second coefficient corresponding to the first generator used in generating the receiver promised address may be calculated from the random number and the 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 the offline first transaction, the offline request contract may contain the offline transaction address, the sender's user public key. If the sender's user public key is a signature derivative public key, then the generation parameter, i.e. the fourth coefficient, needs to be carried.

A method for generating an offline second transaction by the intermediate node, wherein the offline second transaction is used for recording an offline first transaction, as shown in fig. 5, and comprises the following steps:

step 51, receiving synchronous offline transaction data;

Step 52, generating an offline second transaction, the input of which includes a transaction log of the offline first transaction, and the output of which includes the recipient's received transaction address and output commitment address and transaction amount.

The offline transaction process is divided into an offline first transaction, which is an offline transaction (off-line transaction) of the sender and the receiver, and an offline second transaction for linking 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 public key of an offline transaction signature of the sender, a commitment address of the receiver, a random number, and a signature of the offline transaction signature private key of the sender on the transaction log, wherein a coefficient of a first generator of the commitment address of the receiver may be calculated by the random number and the offline transaction amount.

In an exemplary embodiment, all incoming commitment addresses and all outgoing commitment addresses of the offline second transaction are equal by operation.

In an exemplary embodiment, wherein: all incoming commitment addresses and all outgoing commitment addresses of the offline second transaction are equal by operation comprising: the sum of all promise addresses in the input of the offline second transaction is equal to the sum of all promise addresses in the output of the offline second transaction plus the operation result of the second verification parameter and the first generation element;

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

In an exemplary embodiment, all output promise addresses of the same receiver may be aggregated and output.

The above method will be 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. An algorithm of elliptic curve discrete logarithms can be used to generate a user's signature public-private key pair. 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 Alice generates his private signature key as da, then his private signature key is pa=da×g, and the multiplication is a scalar multiplication of elliptic curves, and has a unidirectional property, that is, pa is easily obtained by da, but it is difficult to obtain da by Pa. Wherein G is the second generator, da is the third coefficient of user Alice, i.e. the secret private key. Also, user Bob generates his signature private key as db, and his signature public key is pb=db×g, where db is the third coefficient of user Bob, i.e., the secret private key.

In this embodiment, an online transaction protocol involving a man-in-the-middle (intermediate node) is provided, and each transaction of the user is not directly performed with the receiver, but needs to pass through the man-in-the-middle S. That is, the transaction needs to be split into a first transaction from sender to S (or intermediate transaction) and a second transaction from S to receiver (or confusing transaction), and the confusing transaction from S to receiver is controlled by S. The sender 'S intermediate transaction to S, the address being a special intermediate address of S, is different from the normal user address, and can only be transferred to the output address associated with the user' S promised address, but not to any address. And different promised addresses of the same receiver of different senders can be aggregated and output, and the senders are mutually unaware. The user can verify the transaction amount by remarking information to prevent the interlude S from cheating.

Take sender Alice to transfer a transaction to recipient Bob as an example. Alice first needs a special intermediate address to be transferred to the man-in-the-middle S, which address is given by S and is clearly distinguishable from the ordinary user address, e.g. by the prefix of the address. While the address is controlled by S, S can only use the address to transfer to an outgoing address associated with the user' S promised address. The specific method is that the input reference of the second transaction contains the first promise address (input promise address) and the output address contains the third promise address (output promise 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 and all output commitment addresses are equal through a certain operation, and the output address is designed to be obtained through a third commitment address through an operation, so that the output address is indirectly associated with the first commitment address, and the special intermediate address of the intermediate transaction is limited to be output only to the output address of the corresponding commitment address.

The first transaction includes a set of committed addresses for all recipients; the first promised address contained in the input of the second transaction can only be an element in the promised address set in the cited first transaction, and can also contain a second promised address (additional promised address) to form an input promised address pair; the locking script in the second transaction output comprises an output address and an output promise address, and all input promise addresses of the second transaction are equal to all output promise addresses through operation; the input of the first transaction comprises an unlocking script, the unlocking script is the unlocking expense of the locking script corresponding to the quoted unused UTXO, if the locking script comprises an output address and an output promise address, the operation of obtaining the output address through the output promise address is required to be given out in the unlocking script, so that the output address of the second transaction is related to the output promise address in the second transaction through the operation.

In this embodiment, the promised address of the user may be generated in the following manner: c=r+p+t×h, where C is the user promised address, P is the user's signature public key, H is the first generator, r is the first coefficient, and t is the second coefficient. In other embodiments, the signature derivative public key b×p of the user may be used to calculate the commitment address, i.e., c=r× (b×p) +t×h, where b is a fourth coefficient. r, t, b are random numbers and r, t, b e (0, n). The signature derivative public key (hereinafter referred to as derivative public key) is calculated from the signature public key P of the user and the coefficient b, and may also show a generation parameter a, where b may be a hash value calculated from a and the user generation key s, such as b=h3 (s, a), where H3 is a hash function three. Therefore, the user can obtain the own derivative public key from the generation parameter a, but only knows the derivative public key and the generation parameter, and cannot infer from whom the signature public key is calculated. H is another generation point on the elliptic curve, and the owner does not know the private key of H with respect to G, i.e. cannot find a scalar x, such that h=x×g.

In an exemplary embodiment, the promised address of the user may include a plurality of signature public keys or derivative public keys of the user, where the promised address of the user is a sum of a plurality of user public keys and a plurality of first coefficient operation results and a sum of the first generating element and the second coefficient operation results, where the plurality of user public keys and the plurality of first coefficient operations are that each user public key performs an operation with a corresponding first coefficient, and the first coefficients corresponding to the signature public keys of the users are different. For example, c=r1×p1+r2×p2+ … +t×h.

In an exemplary embodiment, when there are multiple promised addresses of users, the promised addresses are obtained by calculation from the promised address of each user, for example, the promised address is the sum of the promised address of each user, and each promised address of each user is the sum of the user signature public key of the user and the first coefficient calculation result of the user and the first generator and the second coefficient calculation result of the user. That is, C may be represented by the sum of the promised addresses of multiple users, such as 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 aggregate) manner (C1, C2, …) of promised addresses of multiple users.

The effect of the commitment address is that the output address of the transaction must be calculated according to the associated output commitment address, for example, the locking script in the UTXO output contains the output address and the commitment address, and the unlocking script must give the calculation relation between the output address and the commitment address. In all of the confusing transactions described below, each input commitment address C11 corresponds to a commitment address C12 generated by the intermediary S, forming an input commitment address pair (C11, C12). However, it is necessary to verify that the promise address C12 generated by the man-in-the-middle S is indeed generated by the user signature public key or the derivative public key of C11, assuming that the public key is P. One way of verification is given below:

S generates C12 by a multiple of C11, i.e. c12=x×c11. Assuming c11=r11×p+t11×h, c12=r12×p+t12×h, so S calculates t12=t11×r12/r11, c12= (r 12/r 11) ×c11, so S can give a signature with C11 as the base point and C12 as the public key, whose private key is (r 12/r 11), it can prove that C12 is generated from P and H. If the promised address C11 contains public keys of multiple users, C11 needs to be expressed as a joint way of promised addresses of multiple users, namely (Ca 11, cb11, …), and C12 needs to be expressed as a joint way of promised addresses of multiple users, namely (Ca 12, cb12, …), and a signature corresponding to each promised address needs to be given, so each promised address generated by S is generated by the corresponding public key of the user and H, preventing the intermediaries S from cheating.

Referring to fig. 6, an online transaction of alice with Bob includes the following process:

1. Alice obtains Bob 'S signature public key Pb or Bob' S derivative public key b x Pb, and the intermediate address Saddr of S. Since Bob 'S derivative public key is also obtained by signature public key operation, x' Pb may be used instead of x '(b x Pb) in the following transaction, where x' =x/b, but the value of b Alice is not known and S can be known.

2. Alice generates random numbers ra1, ta1, rb1, tb1 e (0, n) and generates a set of committed addresses for all recipients, including Alice's committed address ca1=r1×pa+ta1×h and Bob's committed address cb1=rb1×pb+tb1×h. An intermediate transaction is then generated, the transaction output address being Saddr, which is a special intermediate address that can only be used to transfer to the output address associated with the user commitment address (Ca 1 and/or Cb 1). Alice signs the intermediate transaction using a private key corresponding to the unconsumed transaction output address referenced by the intermediate transaction and generates an unlock script. Alice submits an intermediate transaction and informs S of the coefficients ra1, ta1, rb1, tb1, S of the commitment address, which is verified.

In this embodiment, a man-in-the-middle (i.e., intermediate node) link is added to divide a transaction into an intermediate transaction (input) and a mixed transaction (output), so that the intermediate transaction contains an unlocking script and the mixed transaction contains a locking script.

3. S verifies that Alice' S intermediate transactions succeed and then uplinks, S generates a confusing transaction that references multiple intermediate transactions and outputs multiple addresses. For example, there is an input reference Saddr in multiple inputs of the transaction, and the input contains promised addresses, such as Ca1 and Cb1, to be transferred, which can only be elements in the promised address set contained in the middle transaction of the cited Saddr, and each promised address is added with a promised address generated by S and a signature, such as Ca1 adding Ca2 and a signature, to form an input promised address pair (Ca 1, ca 2), wherein ca2=ra2×pa+ta2×h. Also Cb1 adds Cb2 and a signature, forming an input commitment address pair (Cb 1, cb 2), where Cb2 = rb2 Pb + tb 2H, ra2, ta2, rb2, tb2 are the values generated by S.

The multiple outputs of the confusing transaction include Alice and Bob's received transaction address, where the received transaction address is generated according to the generation mode of the account data chain, for example, bob's received transaction address is generated by using Bob's generation parameter cb in the last received transaction data and Bob's generation key sb, so as to generate Bob's primary key, and further generate Bob's primary user address. As shown in fig. 7, for any user, the first received transaction address Addr1 is obtained based on the initial coefficient c0, the second received transaction address Addr2 is obtained based on the generation parameter c1 in the first received transaction data, the third received transaction address is obtained based on the generation parameter c2 in the second received transaction data, and so on.

For example, kb=h1 (sb, cb) mod n, kb is an intermediate value, H1 is a hash function one; qb=kb×pb, pb is Bob's signature public key, qb is Bob's primary public key; lb=hl (Qb), lb is Bob's primary user address, the corresponding public key is Qb, HL is an address hash function. Where kb may be the first coefficient to which Bob corresponds. Similarly, the primary public key qa=ka=pa, ka is an intermediate value (which may be a first coefficient corresponding to Alice), pa is a public signature key of Alice, and la=hl (Qa), which is a primary user address of Alice, is generated. So there are two output addresses in the transaction being 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 respectively, and qa=ca3-va H, qb=cb3-vb H respectively, so ra2 and rb2 are calculated from S, where ka=ra1+ra2, then ra2=ka-ra 1, =kb 1+rb2, then rb2=kb-rb1. And va and vb can also be calculated from S, for example va=h2 (sa, ca) mod n, vb=h2 (sb, cb) mod n, H2 is a hash function two, so the user outputting 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, a locking script is output, and the user spends time in unlocking the script. When the user generates an 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 promised address is Cb3, and qb=cb 3-vb×h and lb=hl (Qb) are known from the above, so that whether the referenced address is correct or not can be verified through vb, and the private key corresponding to Qb is used to sign the transaction data to generate the unlocking script. It is ensured that the address output by the man-in-the-middle S cannot be cheated, and must be generated by the address of the output commitment, otherwise the output cannot be spent.

The input of the confusing transaction refers to the output addresses of a plurality of intermediate transactions, and also can refer to the output addresses of non-intermediate transactions; the output of the confusing transaction is a plurality of output addresses with promised addresses, and can also contain output addresses without promised addresses. The number of outgoing committed addresses may be different from the number of incoming committed addresses, as the outgoing committed addresses of multiple identical users may be aggregated. The amount of the transaction is secured using the Pedersen commitment or additive homomorphic commitment, the sum of all amounts entered equals the sum of all amounts output, and the validation of the transaction amount is verified by the scope proof. The obfuscated transaction may also have a parameter t that is the sum of the H coefficients of all incoming commitment addresses minus the sum of the H coefficients of all outgoing commitment addresses. It is possible to verify whether the sum of the input commitment addresses and the sum of the output commitment addresses plus t H are equal. I.e. if ca1+ca2+cb1+cb2+ … is equal to ca3+cb3+ … +t H, where t=ta1+ta2-va+tb1+tb2-vb+ …. In an online second transaction, the t may be the first verification parameter; in an offline second transaction, the t may be the second verification parameter. The verification parameters in the online second transaction and the offline second transaction may be the same or different.

The promise address may also include a signature public key or derivative public key of a plurality of users, such as an input promise address pair including C1 and C2, where c1=ra1×pa+rb1×pb+t1×h, c2=ra2×pa+rb2×pb+t2×h, an output promise address c3= (ra 1+ra 2) ×pa+ (rb1+rb2) ×pb+v×h, qa=ka×pa, qb=kb, l=hl (Qa, qb), and L is a primary address. Besides the coefficient v, the unlocking script can also contain Qa and Qb, and can verify that C3=qa+qb+v×H, then the private keys corresponding to Qa and Qb are used for carrying out joint signature on transaction data to generate the unlocking script, and an aggregate signature mode can also be adopted without containing Qa and Qb. The promised address may contain public keys of a plurality of users to enhance security.

Other instructions and overdraft transactions:

1. The transfer can be unlocked only by the user corresponding to the promised address by the intermediate transaction and the confusing transaction, and the output of the plurality of intermediate transactions with the same promised address of the user input the reference can be aggregated into one, but the sender of the intermediate transaction does not know each other, and the sender and the receiver do not know each other's address. For example, alice transfers to Bob, alice knows Ca1 only, but does not know Ca3; while Bob knows only Ca3, but not Ca1; while neither Alice nor Bob knows about Ca2. And the user address is used once, so that Alice does not know the output address of Bob, and Bob also does not know the promise address of the middle transaction of Alice and the changed output address of Alice, and the purpose of privacy transaction can be achieved. If Alice transfers to Bob and Charlie simultaneously, bob does not know who the remaining promised addresses are, or even how many promised addresses are in the input, as neither is what is the input, nor is Charlie. If Alice and Charlie transfer to Bob at the same time, alice and Charlie are not aware of each other nor which is the output, and the output of the same user is aggregated into one, nor is Bob aware of which is the input. The aggregate output of the promised addresses of the same user is to add the coefficients of the public key of the same user and to add the H coefficients. By aggregating the output, the method can be applied to the scene of high-frequency receiving transaction of some users.

2. The intermediate S may control the time of completion of the intermediate transaction to the confounding transaction, such as an hour or a day, or may cancel the transaction. The mode of canceling the transaction is transferring to Alice a promised address Ca1; the transaction is completed by transferring to Bob the commitment address Cb1, and if there is change, transferring the change to Alice's commitment address Ca1. The final transfer amount in the confounding transaction is controlled by S, which may be derived from the contract for the intermediate transaction. The sender does not actually know the address of the recipient nor the amount actually received by the recipient, so in order to prevent the intermediate person S from cheating, notes may be added to the confounding transaction. For example, alice transfers to Bob remarks with labels r×g and r×pb, where r=hs (sa, cb 1) mod n, hs is a hash function of four, so Alice can find which label is based on r×g and can prove that Bob can also find the label based on his private key, because db×hs=r×pb. If Alice uses the derivative public key b of Bob to transfer the transfer, in step 1, the corresponding generation parameters a need to be obtained, and the labels are r× G, r ×pb, a, where b=h2 (sb, a), so Bob can also find the label. Then using ea=hs (sa, r×pb) as Alice ' S encryption key, eb=hs (sb, r×pb) as Bob ' S encryption key, S randomly generates an encryption key es, encrypts Alice ' S transfer remark information to Bob using es, and then encrypts es using ea and eb, respectively. So Alice and Bob can find the tag 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, alice can verify whether the amount of change is equal to the input amount minus the value, and the user information in the remark can select whether to mask, that is, only (in x) transfer (in x) value, so Bob cannot know the sender information, and Alice only knows the public signature key or the derivative public key of Bob, so that anonymous transfer can be realized. If there is an aggregate output, then the multiple inputs corresponding to the aggregate output each have remark information, and the corresponding user can verify whether the amount of aggregate output is equal to the sum of the amounts in all remark information of the user. The remark information may further include a part of parameters of the transfer contract, for example, the contract of the first transaction is an offline transaction application, the contract may have a part of delays, the delay is performed on the offline transaction by the applicant after a period of time, and the offline transaction log is uploaded, and according to the offline transaction log as the parameters of the contract, the amount of offline spending of the applicant is calculated and transferred to the intermediate person S. The actual transaction amount can be verified to be correct by remarking the amount in the information, and the cheating of the intermediate person S is prevented. The deferrable parameters refer to parameters that are not available until a period of time has elapsed, such as one or more of the following: the parameters requiring the third party authentication, the parameters generated by the sender delay (offline transaction log), the fair random number, the voting result and the like can be verified.

3. The online transaction may be a overdraft transaction, where only intermediate transactions have been changed. The intermediate transaction of overdraft transaction has no input reference and no output amount or amount of 0, the intermediate transaction also comprises a derivative public key and a generation parameter of overdraft user, and the private key corresponding to the derivative public key is used for signing the intermediate transaction. For example, alice's derivative public key is a×pa, where Pa is Alice's signature public key, a=h3 (sa, ca), sa is Alice's generation key, ca is the generation parameter, and H3 is the hash function three. Alice needs to tell S that the generation parameter ca, S verifies the derivative public key. The confusing transaction of the overdraft transaction need only contain a portion of the input amount provided by S, which is then cleared with the user of the overdraft transaction. The clearing mode is that the user is required to initiate a transaction for paying the clearing overdraft amount, the transaction remark has 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 involving the middleman, wherein the user firstly generates an offline request contract, generates an offline transaction address, a derivative public key and generation parameters of the user, and the middleman S signs the parameters such as the offline transaction address, the derivative public key, the offline transaction amount, the permission time and the like of the user. The user' S offline transaction can only be conducted using the S-signed offline transaction address of the middleman, the amount must reference the S-signed offline transaction amount. When the user' S offline wallet is online, all offline transaction data are synchronized, and a corresponding transaction record, namely offline confusing transaction (record), is generated by the middleman S according to the offline transaction data, and different promised addresses of the same user can be aggregated and output.

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

1. The user may be pre-prepared, e.g., on-line, prior to the offline transaction. For example, alice generates an offline transaction signature private key di, the corresponding public key is pi=di×g, and 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=h3 (sa, ca), sa is a generated key of Alice, and ca is a generated parameter. Alice generates an offline request contract including (Pi, a×pa), or may include a generation parameter ca of the derivative public key, signs the synthesized data by using a private key corresponding to the derivative public key, submits the offline request contract, and informs S of the generation parameter ca, and S verifies the derivative public key. The offline transaction signature public key may be used as an offline transaction address.

2. S, after verifying that the offline request contract of Alice is successful, the system is uplink, and S signs data such as an offline transaction address Pi, a derivative public key a Pa, an offline transaction limit, a permission time and the like of Alice, sends the data to Alice, and is stored in a local wallet in an encrypted mode by Alice. It can be seen that the off-line transaction amount is given by the middleman S, and has no relation with the non-spent transaction output on Alice' S line, which is equivalent to the overdraft amount of the user. If the offline transaction amount to be applied is high, the non-spent transaction output on the line can be locked, for example, the user can apply for offline request contracts through contract data of intermediate transactions of the online transaction. The locking mode is an intermediate transaction of an online transaction initiated by the user and comprises a promised address of S. Bob also applies for an offline transaction, such as his offline transaction address (public key) Pj, deriving a public key b x Pb, where pj=dj x G, dj being Bob's offline transaction signature private key. In the offline transaction of the user, only the S-signed offline transaction address can be used for the transaction, and the amount must refer to the S-signed offline transaction amount. The offline transaction data has log information therein using the recipient's promise address, which is generated from the derivative public key. When the user performs offline transaction, only the offline transaction signature private key is needed, and the signature private key on the user line is not used, so that the security 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. Offline transactions use the UTXO model and the transaction amount is plain text. For example, alice transfers to Bob ' S offline wallet through the offline wallet, alice needs to check whether Bob ' S offline transaction address is signed by S, then generates offline transaction data, bob needs to check whether Alice ' S referenced offline transaction address is signed by S, and whether the transaction amount references S signed offline transaction amount, then verifies whether the transaction amount is correct. The log information transferred by Alice to Bob needs to include Alice's offline transaction address Pi, bob's promised address Cb1, a random number (nonce), and Alice's offline transaction signature private key di, where Cb1 = rb1 (b Pb) +tb1 x H, tb1 = nonce+ valueB, rb1 is a random number, and additional information of the transaction includes rb1, tb1, hash value of the transaction remark, and so on. nonce is unique when Bob guarantees b×pb as the derived public key, otherwise, the offline received transaction of repeated nonce cannot be recorded online, and a random number + timestamp can be used. The offline transaction data can be validated after being signed by the private key of the offline transaction address of both transaction parties, and other people need to verify the transaction data and log information at the same time, and verify whether the promised address and the transaction amount are correct according to rb1 and tb 1. If Bob transfers the amount of Charlie without S-signature, charlie also needs to trace back to the S-signed off-line transaction line. If Bob transfers Alice to his amount and then to Charlie, charlie needs to verify and record the transaction transferred from Alice to Bob, and verify if both the transferred transaction address and transaction amount are S signed, otherwise the transaction is invalid.

4. When the offline wallet is online again, all offline transaction data are synchronized to S, the S analyzes the transaction data, and then a corresponding transaction record, namely offline mixed transaction (record), is generated. The offline transaction data uses the UTXO model to verify whether the transaction is valid, while the data recorded on the chain is primarily log information in the transaction. S, the offline confusion transaction generated by S inputs a log containing Alice to Bob offline transfer. For example, alice offline trading addresses Pi, bob promised addresses Cb1, nonce and Pi correspond to the signature of the private key, then S adds Cb2 and the signature to Cb1, and the input promised address pair is also formed, while the output address Lb is associated with the output promised address Cb3, and the output address and the output promised address are generated in a manner consistent with the manner of online confusion trading, and the output of the same user may be aggregated into one. As with online transactions, alice does not know Bob's output address and output amount, but Bob knows Alice's input log, and transaction amount valueB = tb1-nonce, so Bob can verify if the output amount is correct, and Bob can also verify from the sum of the amounts of the multiple input logs if there is an aggregate transaction. Since only log information is linked up, transaction amount and receiver information are not revealed, and thus the offline transaction data is also privacy after being recorded online. The input amount for the offline obfuscated transaction is provided by S, which then proceeds to liquidate with the user of the offline transaction. If the manner of clearing is offline received transactions of the user, S sends the aggregate output of offline mixed transactions on-line to the user, who can verify whether the amount of offline received transactions is consistent with the output amount of offline mixed transactions on-line. If the transaction is the offline transmission transaction of the user, the S uses the balance to pay, and then the user is required to initiate the transaction of paying and clearing the offline transmission amount, one user in the transaction remark sends the hash value of the transaction list offline, and the user can verify whether the amount is correct through the list. When the user offline transaction is double-colored, the offline mixed transaction generated by the S only comprises log information and signature of the user offline transaction, and the offline transaction data which are signed by both sides and have the log information are contained in the list. So that when double flowers or even multiple flowers occur, the S can correctly generate corresponding transaction records. For example, alice pays Bob and Charlie off-line with double flowers, and when Bob and Charlie are on-line respectively, S can generate a correct off-line confusion transaction and perform responsibility for Alice.

As shown in fig. 9, the offline process of Alice and Bob off-line transactions includes:

1. Bob sends an S-signed offline transaction address Pj, a derivative public key b x Pb, and a generated random number rb1, nonce to Alice. Here, nonce needs to be guaranteed to be unique when b×pb is the derived public key, and a random number+timestamp may be used.

2. Alice verifies Bob's offline transaction address and derivative public key to generate log information: pi, cb1, nonce, and signs the log using the private key di of Pi, where the commitment addresses Cb1 = rb1 (b Pb) +tb1H, and tb1 = nonce+ valueB.

The UTXO referencing the S signature then generates offline transaction data. Inputting UTXO quoted as Alice; output 1 is Bob's offline transaction address Pj, valueB, output 2 is Alice's offline transaction address Pi, value-valueB, where value is the output amount of UTXO to which reference is input; log information and additional information including rb1, tb1, hash values of transaction notes, and the like. Alice sends offline transaction data to Bob. Only the log information has Alice's signature at this time.

3. Bob verifies the offline transaction address of Alice and traces back whether Alice's UTXO is correct, then verifies whether the log information and signature are valid, whether the additional information is correct, whether the transaction amount is correct, and whether the permission time is valid, if verification is successful, uses Bob's offline transaction signature private key dj to sign the offline transaction data, and sends the signature value to Alice.

4. Alice verifies whether the signature value of Bob is valid, if so, uses Alice's offline transaction signature private key di to sign the offline transaction data, and sends the signature value to Bob.

5. Bob verifies if Alice's signature value is valid and if so, the offline transaction is successful.

FIG. 10 is a schematic diagram of an online recording process of an offline transaction between Alice and Bob, where Alice transfers to Bob, and the online recording process includes 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 intermediate transaction and confusion transaction, ensures that only the user corresponding to the intermediate transaction promised address can spend through the promised address, and can support overdraft transaction. The offline transaction agreements of users are divided into offline request contracts and offline obfuscated transactions (records) on-line and offline transactions off-line, with intermediaries engaged on-line. The offline transaction can only use the offline transaction address and the offline transaction amount signed by the man-in-the-middle S, and ensures that the output can only be spent by the corresponding user through the promised address. The online transaction and the offline transaction have privacy after online recording, and the promised addresses of the same user can be aggregated and output, and the promised addresses can also contain signature public keys of a plurality of users and can support signature derivative public keys of the users.

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 exemplary embodiments described above, e.g., performing one or more of the methods shown in fig. 1-5. 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. 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 be accessed by a computer.

An exemplary embodiment of the present disclosure also provides a computer apparatus (or computer device). The computer apparatus may comprise a processor, a memory, and a computer program stored on the memory and executable on the processor, which when executed may implement 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), where the computer device is an intermediate node device. The structure of the above-described computer device will be described below by way of one example.

As shown in fig. 11, in one example, a computer device may include: the device comprises 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 through the bus system 103, the memory 10 is used for storing instructions, and the processor 101 is used for executing the instructions stored by the memory 102 to control the transceiver 104 to send signals.

It should be appreciated that the processor 101 may be a central processing unit (Central Processing Unit, simply "CPU"), and the processor 101 may also 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, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

Memory 102 may include 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 information of the device type.

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

In implementation, the processing performed by the computer device may be performed by integrated logic circuits of hardware in the processor 101 or by instructions in the form of software. That is, the steps of the methods disclosed in the embodiments of the present disclosure may be embodied as hardware processor execution or as a combination of hardware and software modules in a processor. The software modules may be located in random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, and other storage media. The storage medium is located in the memory 102, and the processor 101 reads information in the memory 102, and in combination with its hardware, performs the steps of the method described above. To avoid repetition, a detailed description is not provided herein.

Those of ordinary skill in the art will appreciate that all or some of the steps, systems, functional modules/units in the apparatus, and methods disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof. In a hardware implementation, the division between the 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 cooperatively by several physical components. 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 both 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 known to those skilled 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 be accessed by a computer. Furthermore, as is well known to those of ordinary skill in the art, 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.

The foregoing has shown and described the basic principles and main features of the present application and the advantages of the present application. The present application is not limited to the above-described embodiments, and the above-described embodiments and descriptions are merely illustrative of the principles of the present application, and various changes and modifications may be made therein without departing from the spirit and scope of the application, which is defined in the appended claims.

Claims

1. A blockchain online transaction processing method for implementing a sender-to-receiver online transaction, the transaction comprising a sender-generated first transaction and an intermediate node-controlled and generated second transaction, wherein:

the sender generating a first transaction includes: the sender generates a first promise address for each receiver according to the user public key of the receiver; generating a first transaction according to the intermediate address of the intermediate node and submitting the first transaction to the intermediate node, wherein the output of the first transaction comprises: the intermediate address of the intermediate node, the output of the unexpired transaction of the sender, the promised address of the sender and the set of the first promised address of the receiver, wherein the promised address is the sum of a user public key and a first coefficient operation result and a first generation element and a second coefficient operation result, and the operation is a one-way algorithm;

The process of the intermediate node controlling and generating a second transaction includes: the intermediate node determines a receiver of the second transaction according to one or more first transactions, and obtains a promised address of the receiver from the first transactions; generating a received transaction address for the recipient and an outgoing committed address associated with the received transaction address; generating a second transaction, an input of the second transaction referencing one or more first transactions, a commitment address of the recipient as an input commitment address of the second transaction, an output of the second transaction comprising a received transaction address of the recipient and an output commitment address, the received transaction address being a one-time user address, the output commitment address being computationally associated with the received transaction address of the recipient.

2. The blockchain online transaction processing method of claim 1, wherein a user public key used in generating the commitment address is obtained by:

Calculating a second generation element and a third coefficient to generate a signature public key as the user public key, wherein the second generation element is irrelevant to the first generation element, and the third coefficient is a secret private key of the user; or alternatively

And calculating the signature public key and the fourth coefficient to generate a signature derivative public key serving as the user public key.

3. The blockchain online transaction processing method of claim 1, wherein,

When a plurality of user public keys of one user exist, the promise address is the sum of the plurality of user public keys, a plurality of first coefficient operation results and the first generating element and the second coefficient operation results; or alternatively

The promised addresses are obtained by calculation through promised addresses of a plurality of users.

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

the input of the first transaction includes an unexpired transaction output (UTXO) of the sender, the first transaction further including a transfer contract for an intermediate node to learn a transfer amount to cause the intermediate node to control a final transfer amount in the second transaction; or alternatively

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

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

And the sender generates an unlocking script, wherein the input of the first transaction comprises the unlocking script, the unlocking script is the unlocking cost of the locking script corresponding to the referenced UTXO, and when the locking script comprises an output address and an output promise address, the unlocking script comprises operation for obtaining the output address through the output promise address, and the operation is used for correlating the output promise address in the referenced locking script with the address of the receiver.

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

The intermediate node generates a corresponding additional promise address according to each input promise address, the input promise address and the additional promise address form an input promise address pair, and the input promise address pair is added in the input of the second transaction, wherein the generation method of the additional promise address is the same as that of the promise address, and the coefficient used when the additional promise address is generated is different from that used when the promise address is generated.

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

The intermediary node adds a signature of the input pair of promised addresses to the input of the second transaction to prove that the additional promised addresses and promised addresses of the input pair of promised addresses are generated by the same user public key.

8. The blockchain online transaction processing method of claim 1, 6 or 7, wherein all input commitment addresses and all output commitment addresses of the second transaction are equal by operation.

9. The blockchain online transaction processing method of claim 8, wherein the operational equality of all incoming commitment addresses and all outgoing commitment addresses of the second transaction includes:

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

10. The blockchain online transaction processing method of claim 1, wherein the intermediate node aggregates all outgoing committed addresses of the same recipient for output.

11. The blockchain online transaction processing method of claim 1, further comprising: the intermediate node obtains the transaction amount according to the transfer contract in the first transaction, encrypts and stores the transaction amount in remark information of the second transaction for verification of both transaction parties, and the remark information also comprises part of parameters of the transfer contract.

12. The blockchain online transaction processing method of claim 1, wherein the final transfer amount in the second transaction is controlled by the intermediate node, and whether the transfer amount is properly verified by the recipient.

13. A blockchain offline transaction processing method for implementing an offline transaction from a sender to a receiver, the transaction comprising an offline first transaction generated by the sender and an offline second transaction controlled and generated by an intermediate node, wherein:

the sender generating an offline first transaction includes: the method comprises the steps that a sender obtains an offline transaction address of a receiver, an offline first transaction is generated, 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 promise address of the receiver, the promise address of the receiver is the sum of a user public key of the receiver and a first coefficient operation result and a first generation element and a second coefficient operation result, and the operation is a one-way algorithm;

The process of the intermediate node controlling and generating an offline second transaction includes: the intermediate node receives the synchronized offline transaction data, generates an offline second transaction, the input of the offline second transaction comprises a transaction log of the offline first transaction, the output of the offline second transaction comprises a received transaction address of a receiver, an output promise address and a transaction amount, the received transaction address is a primary user address, and the output promise address is related to the received transaction address of the receiver through operation.

14. The blockchain offline transaction processing method of claim 13, wherein the user public key used in generating the commitment address is obtained by:

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

16. The blockchain offline transaction processing method of claim 13, wherein,

The transaction log also includes a public signature key of the sender's offline transaction signature, a random number, and a signature of the sender's offline transaction signature private key on the transaction log, wherein a second coefficient used to generate the commitment address of the receiver is calculated from the random number and the offline transaction amount.

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

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

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

20. The blockchain offline transaction processing method of claim 19, wherein: all incoming commitment addresses and all outgoing commitment addresses of the offline second transaction are equal by operation comprising:

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

21. The blockchain offline transaction processing method of claim 13, wherein all outgoing committed addresses of the same recipient are aggregated for output.

22. A computer readable storage medium storing computer executable instructions for performing the method of any one of claims 1-12 or 13-21.