CN113205346A - Depocenter encryption authentication and authentication method capable of canceling bill - Google Patents

Abstract

The invention discloses a depocenter encryption authentication and authentication method capable of canceling a bill, which relates to the field of bill authenticity determination, can cancel the bill, perform verification authentication at any time and ensure authenticity and effectiveness; because the bills are linked up, the real surnames of the bills can be ensured, frequent verification is avoided, distributed multi-chain authentication also better conforms to the trend of the Internet, distributed management is realized, and revocation can be performed; the method for applying the block chain technology to bill verification is an innovative experiment, because all the bills are not decentralized at present, the decentralized style of the block chain well accords with the revocable decentralized encryption authentication and authentication method.

Description

Depocenter encryption authentication and authentication method capable of canceling bill

Technical Field

The invention relates to the field of bill authenticity determination, in particular to a revocable decentralized encryption authentication method for bills.

Background

The invention discloses a depocenter encryption authentication and authentication method with removable bill, which can determine the authenticity of the bill and can be withdrawn.

Disclosure of Invention

The invention aims to overcome the defects of the prior art and provides a revocable decentralized encryption authentication and authentication method for bills, which can revoke bills, check and authenticate bills at any time and ensure the authenticity and effectiveness.

In order to solve the technical problems, the invention provides the following technical scheme:

the invention relates to a depocenter encryption authentication and authentication method with bill revocable, which adopts a block chain technology, wherein the block chain is a decentralized, distrusted and non-falsifiable distributed account book technology; the distributed mode is not only embodied as distributed storage of data, but also embodied as distributed recording of the data, namely, the data are commonly maintained by participants of the system; decentralization, security and non-tamperable traceability of the blockchain can enable trust to be established between participating principals: data ownership, transaction and authorization range are recorded on the block chain, the data ownership can be confirmed, and the refined authorization range can standardize the use of data; meanwhile, each step from acquisition to distribution of data can be recorded on the block chain, so that the data source can be traced, the data source is further restrained, the data quality is enhanced, and bills can be better managed by a decentralized data management platform based on the block chain;

the block chain uses asymmetric encryption, which is generally divided into three main modes: a large integer decomposition problem class, a discrete logarithm problem class and an elliptic curve class;

the problem class of large integer decomposition refers to that the product of two large prime numbers is used as an encrypted number, and because the prime numbers have irregularity, cracking can only be searched and decoded through continuous trial calculation; the discrete logarithm problem class refers to an asymmetric distributed encryption algorithm based on the difficulty of discrete logarithm and using a strong one-way hash function; the elliptic curve class refers to that a group of asymmetric special values are calculated by using a plane elliptic curve;

the method uses an upgraded ECDSA encryption algorithm of an elliptic curve, based on a block chain, a distributed authentication mechanism is established by using a multi-chain architecture, the authentication adopts a block chain consensus algorithm, the multi-chain architecture, namely the multi-chain, is divided into three layers, a chain management layer SMC manages verification node deposit through a contract SMC, the verification nodes are randomly sampled and the like; date is a specific transaction data layer, and each sub-chain respectively maintains the full-state data of each sub-chain and the full state of the main chain; the state layer is mainly a generation layer of transaction, and can also be called an execution layer of an intelligent contract; if the processing capacity of one computer is C transactions, the main chain node can observe C subcohains, and the whole system can process C-C transactions;

most users in a multi-chain system run two parts of programs, as follows:

(i) a full node (requiring O (c) resources) or a lightweight node (requiring O (log (c)) resources) on the backbone;

(ii) a "child client" that interacts with the backbone via RPC (since this client is also running on the current user's computer, it is considered trusted); it can also be a light client for any child chain, a full client for a particular child chain (a user needs to specify that they are "monitoring" a particular child chain), or as a verifier node; in these cases, the storage and computation requirements of one child chain client will also not exceed o (c); the main chain is used for generating random numbers, storing relevant information of verification nodes, managing the verification nodes and tracking sub-chain blocks, and the sub-chains are used for processing transactions and storing the state of account contracts;

in the protocol, a central main chain is used for storing and managing a current effective verifier set, a transaction containing 50000 is sent in the current main chain to become an initial verifier, the transaction is sent out, and when the main chain processes the block, a transaction sender enters a verifier sequencing stage and finally becomes an effective (active) verifier until the transaction sender voluntarily logs out or is forcibly logged out due to improper behaviors;

the main load sources on the daughter strands are attestations (attests), one attest has a dual role:

(1) validating a parent block in the backbone;

(2) confirm chunk hash in the daughter strand (a sufficient number of such proofs create a "cross-link", confirming that the chunk is fragmented into the backbone);

each child chain (say 1024 total) is itself a chain for storage transactions and accounts; crosslinking is the primary means by which the daughter strands can communicate with each other, i.e., by "confirming" the daughter strands into the main chain; alternatively, a simpler "minimal subchain algorithm" could be envisioned, where cross-linking is simply the hashing of proposed data blocks that are not linked to each other;

once validated, blockchain techniques are always validated, and therefore it is desirable to provide a way to revoke transactions, and since transactions cannot be cancelled, a way to configure transactions as unusable is provided, as follows:

each party is given a revocation key, if the other party tries to cheat, punishment can be carried out, in order to explain the revocation key, the bill is subjected to interactive verification among different service terminals, the revocation key can also be used, the server is compared with different exchanges, the verification cost is compared with bitcoin, and a more complex verification channel is constructed between two servers of the server A and the server B; the server A and the server B are respectively assumed to be at different places; the user of server B often sends payment to the user of server a and vice versa; the method comprises the following six cases:

(1) the server A and the server B start the channel through cooperative establishment, and each person invests X cost data (check cost) into the channel; the initial balance is that server A has X cost data and server B has X cost data; the check ticket locks the channel state in 2-2 multiple signatures, as in the simple channel example;

(2) check ticket may have one or more inputs from server a (plus X cost data coins or more) and server B (plus X cost or more); investments must slightly exceed channel capacity to pay for verification costs; the transaction has an output that locks a total of 2X cost data to 2-of-2 multiple addresses controlled by server a and server B; if their input exceeds the value they need to contribute, the ticket proof may also have one or more cost data outputs returning changes to server A and server B; this is a single check formed by multiple inputs provided and signed by both parties;

(3) before sending, the ticket must be collaboratively built and signed by the parties; server a has a commitment check with two outputs; the first outputs X cost data owed by the immediate payment server B to her; the second output pays for X cost data owed to itself by server a, but provided that only after a time lock of Z block times, server B has a different commitment transaction with two outputs; the first outputs X cost data which are owed to the server B by the payment server A; the second output payment server B owes X cost data of itself, but only has a time lock after Z block time, so that two parties have a commitment transaction to spend 2-2 fund output; the commitment-verified input is signed by the other party; at any time, the party holding the commitment verification can sign (complete 2-2 signature) and broadcast; however, if both servers broadcast a commitment check, the commitment check will pay the other party immediately, and both servers must wait for a short time for the lock to expire; by enforcing redemption hold-offs at one of the outputs, the algorithm can be made slightly penalizing to the parties in choosing to unilaterally broadcast the commitment check; but time delay alone is not sufficient to encourage fair behavior; a revocation key allowing a rogue party to punish abnormal operators by taking hold of all balances of the channel;

(4) there is one "delayed" output per commitment check; one party server can exchange the output script after Z block time, or the other party can exchange the output script if the other party has the revocation KEY KEY; so when server a signs a commitment check for server B, server a will define the second output as an output that can be paid to itself after Z block times, or anyone who can present the revocation key; server a constructs this check and creates a revocation key kept secret by server a; when server a is ready to transition to a new channel state and wishes to revoke this commitment, it will not reveal the revocation key to server B

(5) Server B can freely open the check because server B will pay its owed cost data immediately once sent; server a holds the check, but knows that if he sends when the unilateral channel is closed, he will have to wait Z block times before getting the check;

(6) when the channel enters the next state, server a must revoke this commitment check before server B agrees to sign the next commitment check; to do this, all he needs to do is send the revocation KEY to the server B; once server B has the revocation KEY KEY for this commitment, server B may start the next commitment check; if server a attempts to cheat by issuing a previous commitment transaction, server B may redeem the deferred output of server a with a revocation key; if the server A cheats, the server B can obtain BOTH (two parties) output;

the revocation agreement is bilateral, which means that in each round, as the status of the verification channel develops further, both parties exchange new commitment verifications, exchange revocation keys for previous commitments, and sign each other's commitment transactions; when they accept the new state, both servers previously penalized any cheating activity by giving the necessary revocation key to the other, making the previous state impossible to use.

Compared with the prior art, the invention has the following beneficial effects:

because the bills are linked up, the real surnames of the bills can be ensured, frequent verification is avoided, distributed multi-chain authentication also better conforms to the trend of the Internet, distributed management is realized, and revocation can be performed; the method for applying the block chain technology to bill verification is an innovative experiment, because all the bills are not decentralized at present, the decentralized style of the block chain well accords with the revocable decentralized encryption authentication and authentication method.

Detailed Description

It should be understood that the preferred embodiments described herein are for purposes of illustration and explanation only and are not intended to limit the present invention.

Example 1

The invention provides a method for canceling centralized encryption authentication and authentication of bills, which uses a block chain technology, wherein the block chain is a decentralized, distrusted and non-falsifiable distributed account book technology; the distributed mode is not only embodied as distributed storage of data, but also embodied as distributed recording of the data, namely, the data are commonly maintained by participants of the system; decentralization, security and non-tamperable traceability of the blockchain can enable trust to be established between participating principals: data ownership, transaction and authorization range are recorded on the block chain, the data ownership can be confirmed, and the refined authorization range can standardize the use of data; meanwhile, each step from acquisition to distribution of data can be recorded on the block chain, so that the data source can be traced, the data source is further restrained, the data quality is enhanced, and bills can be better managed by a decentralized data management platform based on the block chain;

the block chain uses asymmetric encryption, which is generally divided into three main modes: a large integer decomposition problem class, a discrete logarithm problem class and an elliptic curve class;

the problem class of large integer decomposition refers to that the product of two large prime numbers is used as an encrypted number, and because the prime numbers have irregularity, cracking can only be searched and decoded through continuous trial calculation; the discrete logarithm problem class refers to an asymmetric distributed encryption algorithm based on the difficulty of discrete logarithm and using a strong one-way hash function; the elliptic curve class refers to that a group of asymmetric special values are calculated by using a plane elliptic curve;

ECDSA is a standard of the united states government, is an upgraded version using elliptic curves, and is widely regarded as safe and reliable after years of detailed cryptanalysis. The method and bitcoin use the ECDSA encryption algorithm. Taking the bit currency system as an example, the asymmetric encryption mechanism is that the bit currency system generally generates 256-bit random numbers as a private key by calling a random number generator at the bottom of an operating system. The total amount of the bit coin private key is large, and the private key with the bit coin is extremely difficult to obtain by traversing all private key spaces, so that the cryptography is safe. For identification, the 256-bit binary form of the bitcoin private key is converted by the SHA256 hashing algorithm and the Base58 to form a 50-character-length easily-identified and written private key which is provided for the user. The public key of the bitcoin is a random number of 65 bytes in length generated by the private key first through the Secp256k1 elliptic curve algorithm. The public key can be used for generating an address used in bitcoin transaction, and the generation process comprises the steps of firstly carrying out SHA256 and RIPEMD160 double-Hash operation on the public key to generate a digest result (namely a result of Hash 160) with the length of 20 bytes, and then carrying out SHA256 Hash algorithm and Base58 conversion to form a bitcoin address with the length of 33 characters. The public key generation process is irreversible, i.e. the private key cannot be deduced by public key back-reflection. The public and private keys of bitcoin are typically kept in a bitcoin wallet file, with the private key being the most important. Losing the private key means that all bitcoin assets for the corresponding address are lost. In the existing bit currency and block chain system, a multi-private key encryption technology has been derived according to the actual application requirements so as to meet more flexible and complex scenes such as multiple signatures and the like.

The method uses an upgraded ECDSA encryption algorithm of an elliptic curve, based on a block chain, a distributed authentication mechanism is established by using a multi-chain architecture, the authentication adopts a block chain consensus algorithm, the multi-chain architecture, namely the multi-chain, is divided into three layers, a chain management layer SMC manages verification node deposit through a contract SMC, the verification nodes are randomly sampled and the like; date is a specific transaction data layer, and each sub-chain respectively maintains the full-state data of each sub-chain and the full state of the main chain; the state layer is mainly a generation layer of transaction, and can also be called an execution layer of an intelligent contract; if the processing capacity of one computer is C transactions, the main chain node can observe C subcohains, and the whole system can process C-C transactions;

most users in a multi-chain system run two parts of programs, as follows:

(i) a full node (requiring O (c) resources) or a lightweight node (requiring O (log (c)) resources) on the backbone;

(ii) a "child client" that interacts with the backbone via RPC (since this client is also running on the current user's computer, it is considered trusted); it can also be a light client for any child chain, a full client for a particular child chain (a user needs to specify that they are "monitoring" a particular child chain), or as a verifier node; in these cases, the storage and computation requirements of one child chain client will also not exceed o (c); the main chain is used for generating random numbers, storing relevant information of verification nodes, managing the verification nodes and tracking sub-chain blocks, and the sub-chains are used for processing transactions and storing the state of account contracts;

herein, the term ShardBlock is used to distinguish from Block (tile) because: (i) they are different rlp (recurivelengtprefix) objects: transaction is a layer 0 object, ShardBlock is a first layer object used to package transactions, and block is a second layer object used to package ShardBlock (header); (ii) this is more clear in the context of sub-chains. Typically, ShardBlock must consist of ShardBlockHeader and TransactionList. The specific architecture design can be divided into 4 layers, namely a main chain, a sub chain, execution processing of contracts and an application layer. The interaction between each layer and the interaction between each module adopt BU communication protocol (P2P, RPC, json, http).

In the protocol, a central main chain is used for storing and managing a current effective verifier set, a transaction containing 50000 is sent in the current main chain to become an initial verifier, the transaction is sent out, and when the main chain processes the block, a transaction sender enters a verifier sequencing stage and finally becomes an effective (active) verifier until the transaction sender voluntarily logs out or is forcibly logged out due to improper behaviors;

the main load sources on the daughter strands are attestations (attests), one attest has a dual role:

(1) validating a parent block in the backbone;

(2) confirm chunk hash in the daughter strand (a sufficient number of such proofs create a "cross-link", confirming that the chunk is fragmented into the backbone);

each child chain (say 1024 total) is itself a chain for storage transactions and accounts; crosslinking is the primary means by which the daughter strands can communicate with each other, i.e., by "confirming" the daughter strands into the main chain; alternatively, a simpler "minimal subchain algorithm" could be envisioned, where cross-linking is simply the hashing of proposed data blocks that are not linked to each other;

once validated, blockchain techniques are always validated, and therefore it is desirable to provide a way to revoke transactions, and since transactions cannot be cancelled, a way to configure transactions as unusable is provided, as follows:

each party is given a revocation key, if the other party tries to cheat, punishment can be carried out, in order to explain the revocation key, the bill is subjected to interactive verification among different service terminals, the revocation key can also be used, the server is compared with different exchanges, the verification cost is compared with bitcoin, and a more complex verification channel is constructed between two servers of the server A and the server B; the server A and the server B are respectively assumed to be at different places; the user of server B often sends payment to the user of server a and vice versa; currently, these checks occur on the blockchain, but this means paying for cost data and waiting for several blocks to confirm; the cost is greatly reduced and the checking process is accelerated by arranging the checking channel between the servers, and the method comprises the following six conditions:

(1) the server A and the server B start the channel through cooperative establishment, and each person invests X cost data (check cost) into the channel; the initial balance is that server A has X cost data and server B has X cost data; the check ticket locks the channel state in 2-2 multiple signatures, as in the simple channel example;

(2) check ticket may have one or more inputs from server a (plus X cost data coins or more) and server B (plus X cost or more); investments must slightly exceed channel capacity to pay for verification costs; the transaction has an output that locks a total of 2X cost data to 2-of-2 multiple addresses controlled by server a and server B; if their input exceeds the value they need to contribute, the ticket proof may also have one or more cost data outputs returning changes to server A and server B; this is a single check formed by multiple inputs provided and signed by both parties;

(3) before sending, the ticket must be collaboratively built and signed by the parties; server a has a commitment check with two outputs; the first outputs X cost data owed by the immediate payment server B to her; the second output pays for X cost data owed to itself by server a, but provided that only after a time lock of Z block times, server B has a different commitment transaction with two outputs; the first outputs X cost data which are owed to the server B by the payment server A; the second output payment server B owes X cost data of itself, but only has a time lock after Z block time, so that two parties have a commitment transaction to spend 2-2 fund output; the commitment-verified input is signed by the other party; at any time, the party holding the commitment verification can sign (complete 2-2 signature) and broadcast; however, if both servers broadcast a commitment check, the commitment check will pay the other party immediately, and both servers must wait for a short time for the lock to expire; by enforcing redemption hold-offs at one of the outputs, the algorithm can be made slightly penalizing to the parties in choosing to unilaterally broadcast the commitment check; but time delay alone is not sufficient to encourage fair behavior; a revocation key allowing a rogue party to punish abnormal operators by taking hold of all balances of the channel;

(4) there is one "delayed" output per commitment check; one party server can exchange the output script after Z block time, or the other party can exchange the output script if the other party has the revocation KEY KEY; so when server a signs a commitment check for server B, server a will define the second output as an output that can be paid to itself after Z block times, or anyone who can present the revocation key; server a constructs this check and creates a revocation key kept secret by server a; when server a is ready to transition to a new channel state and wishes to revoke this commitment, it will not reveal the revocation key to server B

(5) Server B can freely open the check because server B will pay its owed cost data immediately once sent; server a holds the check, but knows that if he sends when the unilateral channel is closed, he will have to wait Z block times before getting the check;

(6) when the channel enters the next state, server a must revoke this commitment check before server B agrees to sign the next commitment check; to do this, all he needs to do is send the revocation KEY to the server B; once server B has the revocation KEY KEY for this commitment, server B may start the next commitment check; if server a attempts to cheat by issuing a previous commitment transaction, server B may redeem the deferred output of server a with a revocation key; if the server A cheats, the server B can obtain BOTH (two parties) output;

the revocation agreement is bilateral, which means that in each round, as the status of the verification channel develops further, both parties exchange new commitment verifications, exchange revocation keys for previous commitments, and sign each other's commitment transactions; when they accept the new state, both servers previously penalized any cheating activity by giving the necessary revocation key to the other, making the previous state impossible to use.

The following illustrates one working example thereof:

one of the users of server B wishes to send X cost data to the user of server a. To transmit X cost data over the check channel, server a and server B must update the channel state to reflect the new cost balance. They will commit a new state (state number 2), split the Z (M + N) cost data for the channel, with M cost data belonging to server a and N cost data belonging to server B. To update the status of the channel, they will each create a new commitment check reflecting the cost balance of the new channel.

As noted above, these commitment checks are asymmetric, so the commitment check held by each party forces the server to wait for redemption. It is essential that both servers must first exchange the revocation KEY to invalidate the previous commitment before signing the new commitment transaction. In this case, the benefit of server a is consistent with the true state of the channel, so server a has no reason to broadcast the previous state. However, for server B, the balance left for server B in state number 1 is higher than in state 2. When server B gives server a revocation KEY of the previous commitment check (state number 1), server a effectively revokes its own ability to benefit from rolling back the channel state to the previous state. With the revocation KEY, server B can redeem the two outputs of the previous commitment check without delay. That is, server a may exercise the right to possess all of the output once server B broadcasts the previous state.

Importantly, revocation does not occur automatically. While server a has the ability to penalize server B's anomalous behavior, server a must observe signs of cheating in the blockchain. If server a sees the previous committed transaction broadcast, he has Z block times to take action and uses the revocation key to prevent fraud by server B and to punish server B with all balances, i.e., all 2X cost data.

An asymmetric revocable commitment with a relative time lock (CSV) is a better way to implement a payment channel, and can also be used on top of a revocation ticket, bringing a variable of the revocation ticket. With this architecture, channels can remain open indefinitely and can hold billions of intermediate commitment transactions. In a prototype implementation of a lightning network, committed states are identified by a 48-bit index, allowing over 281 million (2.8 x 10^14) state transitions in any single channel.

The invention has the following beneficial effects:

because the bills are linked up, the real surnames of the bills can be ensured, frequent verification is avoided, distributed multi-chain authentication also better conforms to the trend of the Internet, distributed management is realized, and revocation can be performed. The method for applying the block chain technology to bill verification is an innovative experiment, because all the bills are not decentralized at present, the decentralized style of the block chain well accords with the revocable decentralized encryption authentication and authentication method.

Finally, it should be noted that: although the present invention has been described in detail with reference to the foregoing embodiments, it will be apparent to those skilled in the art that changes may be made in the embodiments and/or equivalents thereof without departing from the spirit and scope of the invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims (1)

1. A bill revocable decentralized encryption authentication and authentication method is characterized in that a blockchain technology is used, wherein the blockchain is a decentralized, distrusted and non-falsifiable distributed account book technology; the distributed mode is not only embodied as distributed storage of data, but also embodied as distributed recording of the data, namely, the data are commonly maintained by participants of the system; decentralization, security and non-tamperable traceability of the blockchain can enable trust to be established between participating principals: data ownership, transaction and authorization range are recorded on the block chain, the data ownership can be confirmed, and the refined authorization range can standardize the use of data; meanwhile, each step from acquisition to distribution of data can be recorded on the block chain, so that the data source can be traced, the data source is further restrained, the data quality is enhanced, and bills can be better managed by a decentralized data management platform based on the block chain;

the block chain uses asymmetric encryption, which is generally divided into three main modes: a large integer decomposition problem class, a discrete logarithm problem class and an elliptic curve class;

the problem class of large integer decomposition refers to that the product of two large prime numbers is used as an encrypted number, and because the prime numbers have irregularity, cracking can only be searched and decoded through continuous trial calculation; the discrete logarithm problem class refers to an asymmetric distributed encryption algorithm based on the difficulty of discrete logarithm and using a strong one-way hash function; the elliptic curve class refers to that a group of asymmetric special values are calculated by using a plane elliptic curve;

the method uses an upgraded ECDSA encryption algorithm of an elliptic curve, based on a block chain, a distributed authentication mechanism is established by using a multi-chain architecture, the authentication adopts a block chain consensus algorithm, the multi-chain architecture, namely the multi-chain, is divided into three layers, a chain management layer SMC manages verification node deposit through a contract SMC, the verification nodes are randomly sampled and the like; date is a specific transaction data layer, and each sub-chain respectively maintains the full-state data of each sub-chain and the full state of the main chain; the state layer is mainly a generation layer of transaction, and can also be called an execution layer of an intelligent contract; if the processing capacity of one computer is C transactions, the main chain node can observe C subcohains, and the whole system can process C-C transactions;

most users in a multi-chain system run two parts of programs, as follows:

(i) a full node (requiring O (c) resources) or a lightweight node (requiring O (log (c)) resources) on the backbone;

(ii) a "child client" that interacts with the backbone via RPC (since this client is also running on the current user's computer, it is considered trusted); it can also be a light client for any child chain, a full client for a particular child chain (a user needs to specify that they are "monitoring" a particular child chain), or as a verifier node; in these cases, the storage and computation requirements of one child chain client will also not exceed o (c); the main chain is used for generating random numbers, storing relevant information of verification nodes, managing the verification nodes and tracking sub-chain blocks, and the sub-chains are used for processing transactions and storing the state of account contracts;

in the protocol, a central main chain is used for storing and managing a current effective verifier set, a transaction containing 50000 is sent in the current main chain to become an initial verifier, the transaction is sent out, and when the main chain processes the block, a transaction sender enters a verifier sequencing stage and finally becomes an effective (active) verifier until the transaction sender voluntarily logs out or is forcibly logged out due to improper behaviors;

the main load sources on the daughter strands are attestations (attests), one attest has a dual role:

(1) validating a parent block in the backbone;

(2) confirm chunk hash in the daughter strand (a sufficient number of such proofs create a "cross-link", confirming that the chunk is fragmented into the backbone);

each child chain (say 1024 total) is itself a chain for storage transactions and accounts; crosslinking is the primary means by which the daughter strands can communicate with each other, i.e., by "confirming" the daughter strands into the main chain; alternatively, a simpler "minimal subchain algorithm" could be envisioned, where cross-linking is simply the hashing of proposed data blocks that are not linked to each other;

once validated, blockchain techniques are always validated, and therefore it is desirable to provide a way to revoke transactions, and since transactions cannot be cancelled, a way to configure transactions as unusable is provided, as follows:

each party is given a revocation key, if the other party tries to cheat, punishment can be carried out, in order to explain the revocation key, the bill is subjected to interactive verification among different service terminals, the revocation key can also be used, the server is compared with different exchanges, the verification cost is compared with bitcoin, and a more complex verification channel is constructed between two servers of the server A and the server B; the server A and the server B are respectively assumed to be at different places; the user of server B often sends payment to the user of server a and vice versa; the method comprises the following six cases:

(1) the server A and the server B start the channel through cooperative establishment, and each person invests X cost data (check cost) into the channel; the initial balance is that server A has X cost data and server B has X cost data; the check ticket locks the channel state in 2-2 multiple signatures, as in the simple channel example;

(2) check ticket may have one or more inputs from server a (plus X cost data coins or more) and server B (plus X cost or more); investments must slightly exceed channel capacity to pay for verification costs; the transaction has an output that locks a total of 2X cost data to 2-of-2 multiple addresses controlled by server a and server B; if their input exceeds the value they need to contribute, the ticket proof may also have one or more cost data outputs returning changes to server A and server B; this is a single check formed by multiple inputs provided and signed by both parties;

(3) before sending, the ticket must be collaboratively built and signed by the parties; server a has a commitment check with two outputs; the first outputs X cost data owed by the immediate payment server B to her; the second output pays for X cost data owed to itself by server a, but provided that only after a time lock of Z block times, server B has a different commitment transaction with two outputs; the first outputs X cost data which are owed to the server B by the payment server A; the second output payment server B owes X cost data of itself, but only has a time lock after Z block time, so that two parties have a commitment transaction to spend 2-2 fund output; the commitment-verified input is signed by the other party; at any time, the party holding the commitment verification can sign (complete 2-2 signature) and broadcast; however, if both servers broadcast a commitment check, the commitment check will pay the other party immediately, and both servers must wait for a short time for the lock to expire; by enforcing redemption hold-offs at one of the outputs, the algorithm can be made slightly penalizing to the parties in choosing to unilaterally broadcast the commitment check; but time delay alone is not sufficient to encourage fair behavior; a revocation key allowing a rogue party to punish abnormal operators by taking hold of all balances of the channel;

(4) there is one "delayed" output per commitment check; one party server can exchange the output script after Z block time, or the other party can exchange the output script if the other party has the revocation KEY KEY; so when server a signs a commitment check for server B, server a will define the second output as an output that can be paid to itself after Z block times, or anyone who can present the revocation key; server a constructs this check and creates a revocation key kept secret by server a; when server a is ready to transition to a new channel state and wishes to revoke this commitment, it will not reveal the revocation key to server B

(5) Server B can freely open the check because server B will pay its owed cost data immediately once sent; server a holds the check, but knows that if he sends when the unilateral channel is closed, he will have to wait Z block times before getting the check;

(6) when the channel enters the next state, server a must revoke this commitment check before server B agrees to sign the next commitment check; to do this, all he needs to do is send the revocation KEY to the server B; once server B has the revocation KEY KEY for this commitment, server B may start the next commitment check; if server a attempts to cheat by issuing a previous commitment transaction, server B may redeem the deferred output of server a with a revocation key; if the server A cheats, the server B can obtain BOTH (two parties) output;

the revocation agreement is bilateral, which means that in each round, as the status of the verification channel develops further, both parties exchange new commitment verifications, exchange revocation keys for previous commitments, and sign each other's commitment transactions; when they accept the new state, both servers previously penalized any cheating activity by giving the necessary revocation key to the other, making the previous state impossible to use.