Computer-implemented systems and methods for using a blockchain to perform an atomic swap

The present invention relates generally to computer-implemented security methods and cryptographic techniques. More particularly, the present invention relates to a method for atomically exchanging control of resources. The present invention is particularly suited, but not exclusively, for use on one or more blockchains and associated protocols.

This article uses the term "blockchain" to include all forms of electronic, computer-based, and distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. Although the most widely known application of blockchain technology is the Bitcoin ledger, other blockchain implementations have been proposed and developed. Although reference may be made herein to Bitcoin for convenience and explanation, the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols may be used. , is within the scope of the present invention. The term "user" herein may refer to a human or processor-based resource. Additionally, the term "Bitcoin" as used herein is intended to include all versions and variations of protocols or implementations derived from the Bitcoin protocol.

A blockchain is a peer-to-peer electronic ledger that is implemented as a computer-based, decentralized, distributed system made up of blocks, which are made up of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset or resource between participants in a blockchain system, and includes at least one input and at least one output. Each block contains a hash of the previous block, thereby chaining the blocks together to create a permanent, unalterable record of all transactions written to the blockchain since its inception. . A transaction has small programs, known as scripts, embedded in its inputs and outputs that specify who can access the transaction's output and how. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

In order for a transaction to be written to the blockchain, it must be "validated." Network nodes (miners) perform work to ensure that each transaction is valid, and invalid transactions are rejected from the network. A software client installed on a node collects unspent transactions by running its lock and unlock scripts. This validation work is performed for transactions (UTXO). If the lock and unlock script execution evaluates to true, the transaction is valid and the transaction is written to the blockchain. Thus, in order for a transaction to be written to the blockchain, the transaction must i) be validated by the first node that receives the transaction; If the transaction is validated, the node relays it to other nodes in the network. The transaction must be ii) added to a new block constructed by the miner and iii) mined. That is, it is added to the public ledger of past transactions.

Although blockchain technology is most widely known for its use in cryptocurrency implementations, digital entrepreneurs are using both Bitcoin's underlying cryptographic security system and the data that can be stored on blockchain to create new We are starting to consider implementing a system. It would be highly advantageous if blockchain could be used for automated tasks and processes that are not limited to the realm of cryptocurrencies. Such a solution would be able to take advantage of blockchain's benefits (e.g., permanent, immutable records of events, distributed processing, etc.) while having more diverse applications.

The concept of atomic swaps has been discussed in the cryptocurrency community for some time. The exchange between the parties is "atomic" in the sense that either all participants receive the desired resource (eg, a cryptocurrency token or coin), or no one receives it. At the time of writing, Wikipedia describes atomic swaps as "a proposed feature in cryptocurrencies that would allow the exchange of one cryptocurrency for another without the need for a trusted third party." are doing. Traditional cryptocurrencies require a trusted third party, such as a cryptocurrency exchange, to perform a cryptocurrency swap to prevent parties from sending currency without receiving it in return. is required. The atomic swap system uses hash time-locked smart contracts where parties must surrender the swapped currency within a specified time or the transaction will be cancelled. This preserves ``atomicity'' in the sense that either a swap takes place or no currency is swapped at all.

Atomic swaps thus provide increased security for transfers conducted through blockchain. Eliminating the need for a trusted third party eliminates the risk of abuse or malicious intervention. In fact, there have been several security breaches or "hacks" of cryptocurrency exchanges, such as the Mt. Gox incident.

<p><nplcit><text>https://en.wikipedia.org/wiki/Atomic_swap</text></nplcit></p>

<p>However, the proposed atomic swap solution involves the use of only one secret, and the swap is performed asynchronously. This creates the drawback that other transactions can only be consumed after one transaction has been consumed.</p><p>As such, it is a cryptographically implemented method for atomically exchanging resources or assets with the trustlessness and immutability provided by blockchain technology, increasing the security regarding transfers conducted through blockchain implementation networks. It is desirable to provide a method for exchanging resources.</p><p>Such an improved solution has now been devised.</p>

<p>According to the present invention, a computer-implemented exchange, replacement, or transfer method is provided. According to additional or alternative definitions, the present invention provides a security method for controlling when resources may or may not be transmitted across a network from a sender to a receiver. provide. Additionally or alternatively, the invention provides a method and corresponding system configured to perform atomic exchange or transmission of resources via a blockchain.</p><p>The method may include the following steps: (i) transmitting a first veiled secret value from a first user to a second user; and (ii) communicating a first veiled secret value of a first blockchain and a second veiled secret value, respectively; constructing a transaction and a second blockchain transaction, wherein the transactions are each configured to be unlockable to transfer control of a first or second resource, wherein unlocking of the first blockchain transaction causes the first secret value to be unlocked; is revealed to the second user, and unlocking the second blockchain transaction reveals the second secret value to the first user.</p><p>The method includes at least two transactions (Tx1 and Tx2), each transaction being unlocked only when the required criteria to multiple puzzles or scripts associated with the respective output are provided. By having at least one unspent output (UTXO) available, an atomic exchange mechanism can be provided. In other words, the locking and unlocking criteria for unused outputs in the first transaction may be the same as the locking criteria for unused outputs in the other or some other transaction, and may be mirrored thereby. good.</p><p>Providing the required unlock criteria to the unused output in the first transaction may reveal one or more secret values required to unlock the unused output in the other or some other transaction. Alternatively, the secret value may be made accessible.</p><p>The unlock script containing the secret value may be provided at the input of a subsequent transaction that consumes the output in the first transaction or the second transaction. Once the subsequent transaction's unlock script is executed together with the first or second transaction's lock script, the subsequent transaction can be validated and then published on the blockchain. This makes the secret value or values provided in the input of subsequent transactions accessible or readable from the blockchain.</p><p>This method provides a secure way to ensure that secret values are exchanged atomically in an untrusted environment, and any user of this method has greater control over this method than any other user. It never has.</p><p>Although it is not realistically possible to determine a secret value from a veiled secret value, it is realistically possible to determine a veiled secret value from a secret value. is associated with the corresponding veiled secret value. As an example of this relationship, applying a one-way function such as hashing or modulo arithmetic to a secret value yields a veiled secret value. Thus, according to one definition, a veiled (secret) value can be derived from the original (secret) value, or is derived but It may be a value that cannot be used to make a decision. It may not be realistically possible to reverse engineer it to provide the original value.</p><p>The phrase "unlocking a transaction" may include the meaning of unlocking or consuming at least one unused output (UTXO) provided in a transaction. This may be accomplished by providing the required data/unlock scripts to satisfy lock scripts associated with unused outputs.</p><p>at least one of the first transaction and the second transaction is configured to be redeemable (expendable) only upon application or provision of the respective first private key and second private key; Good too. This offers the advantage that only the intended recipient, indicated by the private key, can unlock the transaction.</p><p>The method includes: (a) a first derived public key based at least in part on a first public key of said first user; and (b) a second public key at least in part of said second user. The method may further include calculating at least one of a second derived public key based on the key. The first derived public key is part of a cryptographic key pair that includes the first private key, and the second derived public key is part of a cryptographic key pair that includes the second private key. be.</p><p>This allows assets or resources to be stored at a derived address rather than a known address, providing additional privacy and security to users of the method. It should be noted that the terms "asset" and "resource" may be used interchangeably herein. The term "asset" should not be construed as having only a financial context or use. An asset may be, for example, a token representing some other entity on or outside the blockchain.</p><p>(a) a first derived public key based at least in part on a first public key of said first user; and (b) a second derived public key based at least in part on a second public key of said second user. The step of calculating at least one of the two derived public keys may further include a combination of the first and second veiled secret values.</p><p>This offers the advantage of providing a recorded, non-erasable link between the transaction and the atomic swap performed.</p><p>The combination of the first and second veiled secret values includes the concatenation of the first veiled secret value and the second veiled secret value, and the combination of the at least one veiled secret value. The information may include at least one of concatenating a secret value with a random value or a pseudo-random value.</p><p>This offers the advantage of further increasing transaction security through additional deterministic obfuscation.</p><p>The method further includes a third blockchain transaction configured to return control of the first resource to the first user in response to the passage of a first time period in which the first transaction is not redeemed. and a fourth blockchain transaction configured to return control of the second resource to the second user in response to the passage of a second period of time in which the second transaction is not redeemed; It may include the step of constructing at least one.</p><p>This allows at least one user of the method to have control returned to the respective resource if another user does not fully participate in the exchange, thereby increasing the versatility of the method. .</p><p>At least one of the first veiled secret value and the second veiled secret value is connected to at least one of the first secret value and the second secret value, and to the first user and the second veiled secret value. may include a combination with a shared secret value that is accessible by both users.</p><p>This provides the advantage of increasing the privacy and security provided by the method.</p><p>The shared secret value may be established as a common secret before step (i).</p><p>This provides the advantage of further increasing the security of the method.</p><p>The method may further include the steps of: (iii) generating at least one sequence of veiled secret values starting from at least one of the first secret value and the second secret value; (iv) performing the method of any of the preceding claims using at least one of the first secret value and the second secret value; (v) performing at least one blockchain transaction; redeeming to reveal at least one of the first secret value and the second secret value, thereby revealing at least one veiled secret value of said sequence.</p><p>This allows performing a series of secure atomic exchanges with higher efficiency than a simple repetition of the method since less storage space is required to store the secret. Furthermore, the number of rounds of communication is reduced. This saves time and improves security.</p><p>Performing at least step (ii) of the method may use at least one veiled secret value disclosed in step (v) of the method.</p><p>This offers the advantage of further increasing the efficiency of the method.</p><p>These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described herein.</p><p>Embodiments of the invention will now be described, by way of example only and not in a restrictive sense, with reference to the accompanying drawings, in which: FIG.</p>

<figref num="1">1 shows a flowchart illustrating the steps taken in a method embodying the invention.</figref><figref num="2">1 is a schematic diagram of an exemplary system for determining a common secret for a first node and a second node that may be used in accordance with the present invention to securely transmit sensitive information; FIG.</figref><figref num="3">1 is a flowchart of a computer-implemented method for determining a common secret that may be used in accordance with the present invention to securely transmit sensitive information.</figref><figref num="4">2 is a flowchart of a computer-implemented method for registering first and second nodes.</figref><figref num="5">2 is another flowchart of a computer-implemented method for determining a common secret that may be used in accordance with the present invention to securely transmit sensitive information.</figref>

An atomic transaction exchange on the blockchain allows for two transactions from a first user, Alice, to a second user, Bob, and another transaction from Bob to Alice, with both transactions completing. or else neither will be completed.

Referring to FIG. 1, the present invention provides that Alice and Bob each₀and B₀This includes being able to generate (30) a secret written as . If Alice and Bob are trusted, they can exchange information containing these secrets using communication channels that are not part of the blockchain protocol. The two may use the secure secret exchange described below under the subheading "Determining a Common Secret."

Suppose one party cannot be trusted and will not share his secrets. According to the invention, the only way for this party to spend his funds is to reveal his secrets on the blockchain, thereby making them public knowledge and available to other users. This is due to the structure of the transactions used in the exchange. Therefore, the method does not require either party to trust the other party.

In an embodiment of the invention, there are two secrets: one created by Alice and accessible to Alice, and one created by Bob and accessible to Bob. These are communicated through channels outside the blockchain.

<u style="Single">single atomic swap</u>P_A0private key S corresponding to_A0Denote Alice's elliptic curve digital signature algorithm (ECDSA) public key with P_B0is the private key S_B0Let us denote Bob's public key with .

In 1.30, Alice has a secret that only she knows.<math num="1"><img file="JP7371015B2_D0001.tif" /></math>Bob chooses a secret that only he knows.<math num="2"><img file="JP7371015B2_D0002.tif" /></math>Choose. (These secrets are not related to Alice's and Bob's public or private keys.) where n is the order of the elliptic curve generating point G. The secret may be in the form of a general data structure passed through the SHA256 (mod n) algorithm.

2. Alice and Bob open a communication channel between them. This may be a secure communication channel created using the method described below under the subheading "Determining a common secret". The two then hash their respective secrets (step 34) and share the public key and hash of their respective secrets (step 36). A₀and B₀The hash value of H(A₀) and H(B₀), where a standard hash function such as SHA-256 may be used. The value H(A₀) and H(B₀) can also be shared publicly. Alice and Bob are both P_A0,P_B0, H(A₀), H(B₀)know.

3.38, Alice and Bob have a deterministic key H(A₀)|H(B₀) (where "|" indicates the OP_CAT operation) or alternatively H(H(A₀)|H(B₀)).

In 4.40, Alice and Bob derive their public keys here<math num="3"><img file="JP7371015B2_D0003.tif" /></math>generate. These have the following corresponding private keys:

<math num="4"><img file="JP7371015B2_D0004.tif" /></math> Alice and Bob have derived public keys P_A1,P_B1Perform an atomic swap using In principle, two people have the original public key P_A0,P_B0However, the derived public key is tied to an atomic swap and can be easily computed by Alice and Bob, but (H(A₀) and H(B₀) has the advantage that it cannot be easily calculated by anyone else unless it is made public.

38, H(A₀)|H(B₀Additional privacy can be achieved if deterministic pseudorandom-looking values such as )|Z are also incorporated. Here, Z is something that both parties can calculate, such as a pre-agreed zeta function, based on a shared starting value.

In 5.42, Alice and Bob construct the following lock script. The script is described schematically here, and an example implementation in a Bitcoin script is shown later.

<math num="5"><img file="JP7371015B2_D0005.tif" /></math>Process CheckSigH(P_A1) is the public/private key pair P_A1,S_A1This is the standard ECDSA signature validation operation for. Instead, public/private key pair P_A0,S_A0CheckSigH(P_A0) may be used. Process SolveH(A₀) is the solution A₀It is a hash puzzle with In other words, the unlock script uses the H(A₀) is a valid value equal to A₀must be included. The unlock script is given as follows.

<math num="6"><img file="JP7371015B2_D0006.tif" /></math>As you can see, if either Alice or Bob unlocks their funds, the value A₀and B₀will be exposed on the blockchain.

In 6.42, Alice uses the locking script LockingScript(B) to_B1transaction tx to₁and Bob uses the locking script LockingScript(A) to generate P_A1transaction tx to₂Create. At this stage, both Alice and Bob have P_A1and P_B1You cannot use the funds in Because neither party has A₀and B₀This is because I don't know both. These transactions are sent to the network and then appear on the blockchain.

In 7.46C, Alice tells Bob a secret A₀Bob sends Alice the secret B₀send. This is done using the communication channel between Alice and Bob established above. Alice and Bob assume that these hash values are H(A₀) and H(B₀) can be checked to ensure that these are correct values.

8. Assuming that Alice and Bob are both honest and share the correct secret, both parties know both secrets (step 48C) and both P_A1and P_B1The locked funds can be spent (step 50C) and the atomic swap is completed.

9. For example, if Bob knows his correct secret B₀Suppose that you did not send ``to Alice''. That is, only Alice sends her secret, and step 46B occurs instead of 46C. Because of the shape of the locking script LockingScript(B), Bob_B1In order to use the funds locked in₀must be made public. As a result, as soon as Bob spends the funds, Alice learns Bob's secret (step 48B) and therefore P_A1(step 50B). This ensures that either Alice and Bob can both use their funds, or neither can use their funds.

Below are example lock and unlock scripts for Alice in step 4 above that are compatible with the Bitcoin blockchain.

Lock script about Alice: OP_DUP OP_HASH160&lt;Hash160 P_A1&gt;OP_EQUALVERIFY OP_CHECKSIG OP_HASH256&lt;Hash256 A₀&gt;OP_EQUALVERIFY OP_HASH256&lt;Hash256 B₀&gt;OP_EQUALVERIFY unlock script for Alice:&lt;B₀&gt; &lt;A₀&gt; &lt;SigP_A1&gt; &lt;P_A1&gt;Transactions to Pay To Public Key Hash (P2PKH) and Script Hash (Pay To Script Hash, P2SH) addresses are both locked and unlocked using the above types of lock scripts. Note that scripts are allowed. For P2SH addresses, the lock script is presented as a hash of the redemption script containing the same information.

The above method is described with reference to a blockchain that uses a public/private key cryptography system similar to ECSDA used in the Bitcoin blockchain. However, the method can be generalized to general cryptographic mechanisms that require a general form of secret (which can be any data structure) to be disclosed in the unlock script. What is needed is a locking script, transaction, and blockchain, which is a secure and verifiable communication channel.

<u style="Single">Time lock refund transaction</u>If Bob tells Alice his true secret B₀and refuses to give address P_B1If Bob also does not unlock the funds stored in P, Bob's secret will not be revealed to Alice and Alice will_A1It is not possible to unlock funds stored in . Additionally, Alice sent Bob, P_B1It is also not possible to retrieve funds stored in the .

This problem can be solved by introducing a new transaction from Bob to Alice that is configured to send the funds back after a certain amount of time if they are not spent. This also requires slight modifications to LockingScript(A) and LockingScript(B), which will be discussed below.

This new transaction takes advantage of time-dependent behavior in the lock script that allows transactions to be accepted by the block only after some pre-specified amount of time has elapsed. For example, in a Bitcoin script, this could be a Check Sequence Verify (CSV) behavior for a relative time since a specified value, or a Check Lock Time Verify (CSV) behavior for a fixed time value. Lock Time Verify (CLTV) operation may also be used.

The lock script from step 4 above is modified as follows to include an option to consume if both Alice and Bob agree to sign:<math num="7"><img file="JP7371015B2_D0007.tif" /></math>

At 44, after step 4 and before step 5 of the above method, two new transactions are generated. Alice returns all of Bob's funds, P_A1transaction from t to bob_x4generate. This transaction is time-locked so that it is accepted within the block only after a certain amount of time (eg, 24 hours). Bob is P_B1Similar transaction tx from to Alice₃generate. transaction tx₃and tx₄are each lock script<math num="8"><img file="JP7371015B2_D0008.tif" /></math>have.

alice tx₄and sends it to Bob, who signs it and sends it to the network. Similarly, bob tx₃signs it and sends it to Alice, who signs it and sends it to the network.

If at this stage neither party complies, the process will be stopped and no funds will be transferred. If both parties are compliant, step 5 of the above method is executed (42). Here, if neither party uses the funds exchanged in an atomic swap (46A), the funds are returned to their original owners after 24 hours (48A, 50A).

Here, a CSV relative time of 24 hours was used as an example, but it is possible to use any relative time in the future, or any specific time in the future (e.g. using the CLTV operator). Will.

Here is an example lock script that uses the Bitcoin blockchain to return funds to Alice after 24 hours.

"24h" OP_CHECKSEQUENCEVERIFY OP_DROP OP_DUP OP_HASH160&lt;Hash160 P_A1&gt;OP_EQUALVERIFY OP_CHECKSIG The corresponding unlock script is &lt;Sig P_A1&gt; &lt;P_A1&gt; given by

<u style="Single">Masking secret values</u>A further alternative embodiment is that the value A₀and B₀includes a masking step 32 so that the information is known only to Alice and Bob and is never disclosed to the public.

At first, both Alice and Bob share a secret that only they know._CWe agree on the following. This can be accomplished through the secure exchange of secrets using the methods described below under the subheading "Determination of Common Secrets."

Alice and Bob then define a new secret.

A'₀=A₀+S_CB'₀=B₀+S_CThe two then proceed as outlined above, but with the masked secret A' instead of the original secret.₀,B'₀Use. During an atomic swap, only masked secrets are publicly available on the blockchain.

This is the secret value A₀and B₀is also useful when used in other contexts, such as in further embodiments described below.

A further alternative embodiment allows Alice and Bob to perform a series of n atomic swaps. Each party starts with a random secret and creates a sequence of hash values of this secret called an access chain. When an atomic swap is performed, the next secret hash value to be used in the next atomic swap is disclosed. This process is iterably repeated up to n times.

This method provides efficiency savings compared to a series of separate swaps in that Alice and Bob only need to store one secret at a time, requiring less storage space for the secrets. Ru. The next secret can be calculated by hashing the previous secret. There is no need to communicate the secret hash every time, so there are fewer communication rounds between each other. This saves time and improves security.

The method is as follows: Alice and Bob agree on the number n of iterative exchanges. The two people each have a random value A_nand B_ngenerate. Alice computes the following access chain:<math num="9"><img file="JP7371015B2_D0009.tif" /></math>Bob is B_nCompute the equivalent chain starting from . These chains correspond to secret values used in a series of swaps. The number of possible swaps is in the sequence {0,1,...,n}. That is, both parties can use these values for swapping between 0 and n transactions before a new chain needs to be reinitialized.

The manner in which these swaps are performed is outlined below. It should be understood that Bob follows an equivalent process.

1. Alice owns chain A₀,A₁,...,A_n, Bob's public key P_B0, Bob's secret hash H(B₀). As before, H(B₀) may be shared publicly by Bob.

2. Alice derives the public key<math num="10"><img file="JP7371015B2_D0010.tif" /></math>, then the lock script<math num="11"><img file="JP7371015B2_D0011.tif" /></math>Calculate.

Note that the time-dependent refunds mentioned in the previous embodiments can be included in the above locking script without any substantial changes to the logic.

3. Alice and Bob perform their first swap. As mentioned earlier, this is the A between Alice and Bob.₀and B₀Involved in the exchange of This means that after the swap Alice has H(B₁)=B₀It means knowing.

4. Alice repeats step 2 of this method, but with Bob's second secret hash H(B₁) is used. Specifically, Alice has the derived public key<math num="12"><img file="JP7371015B2_D0012.tif" /></math>and lock script<math num="13"><img file="JP7371015B2_D0013.tif" /></math>Calculate.

5. Once the second swap is completed, Alice has H(B₂)=B₁know. Alice has Bob's third secret hash H(B₂) and repeat step 2 again.

6. This process repeats in a repeatable manner until either the swap is not completed or the maximum number of n swaps is reached.

As mentioned in the previous embodiment, the pseudorandom value Z_iCompute H(A_i)|H(B_i)|Z_iAdditional security can be built in by introducing In this case the function is, for example, the hash function Z_i-1=H(Z_i) should be converted for each successive iteration.

The atomic swaps outlined above are not constrained by the Bitcoin blockchain. A key component in the atomic swap method described above is that when one party spends the funds in step 7, they reveal their secrets on the blockchain. This means that the above method can be used to perform atomic swaps on any blockchain that allows locking and unlocking scripts of the form given in step 4. .

Additionally, atomic swap methods can be used to exchange cryptocurrencies. For example, it may be used for Alice to send Bitcoin to Bob on the Bitcoin blockchain and for Bob to send Ethereum to Alice on the Ethereum blockchain.

<tables><img file="JP7371015B2_D0014.tif" /></tables>

The only constraint on atomic swaps between two different blockchains is that they allow the use of the same hash function in the hash puzzle in the lock script (or equivalent). The reason is this: suppose Alice's blockchain only allows the use of the SHA-256 hashing algorithm, and Bob's blockchain only allows the SHA-384 algorithm. Bob sends Alice a SHA-256 hash of one secret, but in Bob's lock script he sets up a SHA-384 hash puzzle for a different secret. When Bob spends the funds, the unlock script reveals secrets that are useless to Alice, and Alice has no way of knowing this until Bob uses up the funds.

According to a further embodiment, a method for enabling two parties to each generate a public key, for which a corresponding private key is made accessible to both parties or is not accessible to either party. Methods are provided that are either very accessible or not. This method utilizes the atomic swap method described above to exchange two secret values between both parties. These secret values are used to calculate the secret key.

One application of this method is to allow two parties to exchange multiple types of cryptocurrencies controlled by a single public/private key pair. This method allows Alice and Bob to each generate a public key for which the private key is not known until the atomic swap takes place. An atomic swap ensures that either Alice and Bob can either compute their corresponding private keys, or neither can compute their private keys.

This method is described below using ECSDA private and public key pairs, such as those used in Bitcoin, Ethereum, and Dash. However, this method does not depend deterministically on the ECDSA protocol, but rather can be used with any public/private key-based cipher that can deterministically generate a new secure public key from an existing private key and a known deterministic key. Can be easily adapted to the system.

This method is pseudonymous in the sense that partial information about the new private key is stored in one or more blockchains, which are open ledgers. However, only parties involved in the process can decrypt this information and security is never compromised.

1.Alice has the corresponding public key P_A=S_A.Private key S with G_AAnd a secret that only I know₂Start with Bob has the corresponding public key P_B=S_B.Private key S with G_BAnd a secret that only I know₁Start with

2.Alice P to Bob₂=S₂.Send G, Bob sends P to Alice₁=S₁.Send G. Their secrets are multiplied by the base points of the elliptic curve, so they are not disclosed in this process and P₂and P₁may be publicly known.

3. Alice receives a new public key P that can be used as an address to receive Bitcoin transactions (or something similar for altcoins)_A.E.=P_A+P₁Create. Bob has a new public key P_BE=P_B+P₂Create.

According to the characteristics of elliptic curve cryptography, P_A.E.The private key corresponding to is S_A.E.=S_A+S₁, that is, P_A.E.=S_A.E..It is G. P_BEThe private key corresponding to is S_BE=S_B+S₂It is.

At this stage Alice has S₁Therefore, P_A.E.I don't know the private key for. Bob is S₁I know, but S_ATherefore, P_A.E.I don't know the private key for. By the same logic, both Alice and Bob are P_BEI don't know the private key for.

4. Alice is Bob's address P_BEBob makes a transaction to Alice's address P_A.E.Perform a transaction to. These transactions may be some kind of cryptocurrency exchange using a public key/private key system, or a token or even a physical asset with a public key P_A.E.and P_BEmay be transferred to the possession of A combination of the above may be used.

5.Alice and Bob now have S₂and S₁Initialize an atomic swap as described above using an arbitrary blockchain with each as a secret.

6.Alice and Bob exchange secrets. In other words,<tables><img file="JP7371015B2_D0015.tif" /></tables> Alice and Bob are official P₁=S₁.G, P₂=S₂- G may be used to check that the correct secret has been received. You cannot consume the output of that atomic swap without exchanging the correct values.

7. Alice is now S₁holds, and P_A.E.The private key corresponding to can be calculated. Alice's private key S to everyone other than Alice_ASince I don't know, even if S₁Even if P_A.E.It is not possible to calculate the private key corresponding to . Similarly, now Bob has a secret S₂holds, and P_BEcan calculate the private key corresponding to , but no one but Bob can do this.

If neither Alice nor Bob uses their own transaction output of that atomic swap, Alice's secret S₂is not disclosed to Bob and is Bob's secret S₁is not disclosed to Alice. In this case, both Alice and Bob are P_A.E.and P_BEIt is not possible to calculate the private key corresponding to .

Blockchain uses a public/private key cryptographic system to sign transactions and prove ownership of transaction outputs. This can be done in several cryptocurrencies at the same time using the method of the above embodiment._A.E.and P_BEallows you to send transactions to For example, in step 3 above, P_A.E.and P_BEAfter establishing , Alice transfers her BCH and ETH funds to P_BEBob transfers the BCH and DASH funds to P_A.E.Move to.

Once the atomic swap is performed, P_BEand P_A.E.The private key to is unlocked. These unlock funds in the Bitcoin and Ethereum public keys held by Alice and the Bitcoin and Dash public keys held by Bob. Thus, the next transaction from Alice to Bob can be safely completed.

<tables><img file="JP7371015B2_D0016.tif" /></tables>

Note that these blockchains do not need to allow the same hash functions in lock scripts.

The above provides a general method for two parties to unlock a public key through an exchange of secrets using an atomic swap. This has applications beyond the exchange of cryptocurrencies and is relevant for any system that uses public/private key cryptography similar to ECDSA. For example, other use cases include, but are not limited to: 1. Providing access to Distributed Hash Tables (DHTs); 2. Encrypted computations; 3. Private email Client; 4. Access to logistics data and exchange; 5. Swap of goods and services; 6. Private value exchange; 7. Hierarchy of keys.

<u style="Single">common secret determination</u>Where appropriate, security can be improved by using a secure method of exchanging information between two parties, using public/private key systems such as those described below.

A common secret (CS) is established between the two parties and can then be used to generate a secure encryption key for transmission of one or more of the shares. A common secret (CS) is some secret (S_A,B,1,2), generated and used, for example, to enable the secure exchange of secret values, keys, or shares thereof.

Hereinafter, for convenience, Alice and Bob will be referred to as a first node (C) and a second node (S). The objective is to generate a common secret (CS) that both nodes know, but that common secret was not sent over the communication channel. Thus, the possibility of its fraudulent discovery is eliminated.

Secure transmission techniques involve CS being generated at each end of the transmission in an independent manner. Thus, although both nodes knew about the CS, the CS did not have to travel through a potentially insecure communication channel. Once the CS is established at both ends, the CS can be used to generate secure cryptographic keys that both nodes can use for subsequent communication.

FIG. 2 shows a system 1 comprising a first node 3 communicating with a second node 7 via a communication network 5. The system 1 shown in FIG. The first node 3 has an associated first processing device 23 and the second node 5 has an associated second processing device 27. The first and second nodes 3, 7 may include electronic devices such as computers, telephones, tablet computers, mobile communication devices, computer servers, etc. In one example, the first node 3 may be a client (user) device and the second node 7 may be a server. The server may be a server of a digital wallet provider.

The first node 3 stores the first node's master private key (V_1C) and the master public key of the first node (P_1C) is associated with the first asymmetric cryptographic pair. The second node (7) has the second node's master private key (V_1S) and the master public key of the second node (P_1S) is associated with a second asymmetric cryptographic pair. In other words, the first and second nodes each hold a respective public-private key pair.

The first and second asymmetric crypto pairs for the respective first and second nodes 3, 7 may be generated during a registration process, such as registration for a wallet. The public key for each node may be publicly shared through the communication network 5.

In order to determine the common secret (CS) in both the first node 3 and the second node 7, the nodes 3, 7 use the respective methods 300, 400 without communicating the secret key through the communication network 5. Execute the steps.

The method 300 performed by the first node 3 includes at least the first node's master private key (V_1C) and the generator value (GV), the second private key (V_2C). The generator value may be based on a message (M) shared between the first node and the second node, which transmits the message over the communication network 5, as will be explained in more detail later. May include sharing. The method 300 also includes at least a second node's master public key (P_1S) and the generator value (GV) of the second node's second public key (P_2S) including determining (370). Method 300 includes a first node's second private key (V_2C) and the second public key of the second node (P_2S), determining a common secret (CS) (380).

The same common secret (CS) can also be determined at the second node 7 by method 400. Method 400 uses the first node's master public key (P_1C) and the generator value (GV), the second public key (P_2C). The method 400 further includes determining the second node's master private key (V_1S) and the generator value (GV) of the second node (V_2S) including determining (470). The method 400 includes a second private key (V_2S) and the second public key of the first node (P_2C), determining a common secret (CS) (480).

Communication network 5 may include a local area network, a wide area network, a cellular network, a wireless communication network, the Internet, etc. These networks, in which data may be transmitted via communication media such as electrical wires, optical fibers, or wirelessly, may be subject to eavesdropping, such as by eavesdroppers 11. The method 300, 400 may allow both the first node 3 and the second node 7 to independently determine a common secret without transmitting the common secret over the communication network 5.

Thus, one advantage is that the common secret (CS) can be determined securely and independently by each node without the need to transmit the secret key over a potentially insecure communication network 5. The common secret is then used as a private key (or as the basis for a private key) for encrypted communications between the first node 3 and the second node 7 through the communication network 5. Good too.

Methods 300, 400 may include additional steps. The method 300 includes, at a first node 3, a message (M) and a second private key (V_2C), the signed message (SM1) may be generated. The method 300 further includes transmitting (360) the first signed message (SM1) to the second node 7 over the communication network. The second node 7 may then perform a step 440 of receiving the first signed message (SM1). The method 400 also includes determining the second public key (P_2C) to validate the first signed message (SM2) 450 and authenticate the first node 3 based on the result of validating the first signed message (SM1) 460 including. Advantageously, this allows the second node 7 to authenticate that the claimed first node (where the first signed message was generated) is the first node 3. do. This means that only the first node 3 has the first node's master private key (V_1C) and thus only the first node 3 has access to the first node's second private key (V_2C) can be determined. Similarly, a second signed message (SM2) can be generated at the second node 7 and sent to the first node 3, so that the first node 3 It is understood that the second node 7 can be authenticated.

Sharing a message (M) between a first node and a second node can be accomplished in a variety of ways. In one example, a message is generated at a first node 3 and then sent through a communication network 5 to a second node 7. Alternatively, the message may be generated at the second node 7 and then sent to the second node 7 via the communication network 5. In yet another example, the message may be generated at the third node 9 and the message sent to both the first node 3 and the second node 7. In yet another alternative, the user may enter a message through the user interface 15, which is received by the first and second nodes 3, 7. In yet another example, the message (M) may be retrieved from the data store 19 and sent to the first and second nodes 3,7. In some examples, the message (M) may be public and thus may be transmitted over an insecure network 5.

In a further example, one or more messages (M) may be stored in data stores 13, 17, 19, where the messages are stored in some entity, such as a digital wallet, or between the first node 3 and the first node 3. 2 may be associated with a communication session established with node 7. The message (M) is thus retrieved and used at each first and second node 3, 7 to regenerate the common secret (CS) associated with that wallet or session. It's okay.

Advantageously, a record that allows the reproduction of a common secret (CS) may be maintained without the need for the record itself to be stored privately or transmitted securely. This may be advantageous if a large number of transactions are performed on the first and second nodes 3, 7 and it is not practical to store all messages (M) on the nodes themselves.

Examples of the registration methods 100, 200 will be described with reference to FIG. In FIG. 4, method 100 is performed by the first node 3 and method 200 is performed by the second node 7. This includes establishing a first and second asymmetric cryptographic pair for each first and second node 3, 7.

An asymmetric cryptographic pair includes an associated private key and public key, such as those used in public key cryptography. In this example, an asymmetric cryptographic pair is generated using the characteristics of elliptic curve cryptography (ECC) and elliptic curve operations.

Standards for ECC may include known standards such as those described by the Standards for Efficient Cryptography Group (www.sceg.org). Elliptic curve cryptography is also known as 78,667, Also described in US6,792,530.

In methods 100, 200, this includes the first and second nodes agreeing on a common ECC system and using a basis point (G). (Note: Although a base point can be referred to as a Common Generator, the term base point is used to avoid confusion with the generator value GV.) In one example, a common ECC The system may be based on secp256K1, the ECC system used by Bitcoin. The base points (G) can be selected, randomly generated, or assigned.

Turning now to the first node 3, the method 100 includes determining 110 a common ECC system and base point (G). This may include receiving a common ECC system and base point from the second node 7 or the third node 9. Alternatively, a user interface 15 may be associated with the first node 3, by which a user may selectively provide a common ECC system and/or base point (G). In yet another alternative, one or both of the common ECC systems and/or base points (G) may be randomly selected by the first node 3. The first node 3 may send a notification via the communication network 5 to the second node 7 indicating the use of a common ECC system with the base point (G). The second node 7 may then settle (210) by sending a notification acknowledging the use of the common ECC system and base point (G).

Method 100 includes the first node 3 acquiring the first node's master private key (V_1C) and the master public key of the first node (P_1C) generating 120 a first asymmetric cryptographic pair. This is based at least in part on a first master private key (V_1C). This is also the first node's master private key (P_1C) and base point (G) formula: P_1C=V_1CBased on the elliptic curve point multiplication according to ×G (Equation 1), the first node's master public key (P_1C).

Thus, the first asymmetric crypto pair includes:V_1C:The master private key of the first node, kept secretly by the first node, P_1C:The master public key of the first node that is made public.

The first node 3 stores the first node's master private key (V_1C) and the master public key of the first node (P_1C) may be stored in the first data store 13 associated with the first node 3. For security, the first node's master private key (V_1C) may be stored in a secure part of the first data store 13 to ensure that the keys remain private.

The method 100 further includes transmitting the first node's master public key (P_1C) to the second node 7. The second node 7 uses the first node's master public key (P_1C) is received 220, the first node's master public key (P_1C) may be stored 230 in the second data store 17 associated with the second node 7.

Similar to the first node 3, the method 200 of the second node 7 uses the second node's master private key (V_1S) and the master public key of the second node (P_1S) generating 240 a second asymmetric cryptographic pair comprising: The master private key of the second node (V_1S) is also a random integer within the acceptable range. Next, the second node's master public key (P_1S) is determined by the following formula:P_1S=V_1S×G (Formula 2)

Thus, the second asymmetric crypto pair includes: V_1S: the master private key of the second node, held secretly by the second node, P_1S:The master public key of the second node that is made public.

The second node 7 may store the second asymmetric cryptographic pair in the second data store 17. The method 200 further includes providing the first node 3 with the second node's master public key (P_1S) including sending 250. The first node 3 then uses the second node's master public key (P_1S) may be received 140 and stored 150.

It will be appreciated that in some alternatives, the respective public master keys may be received and stored in a third data store 19 associated with a third node 9 (e.g., a trusted third party). Ru. This may include a third party acting as a public directory, such as a certificate authority. Thus, in some examples, the first node's master public key (P_1C) may be requested and received by the second node 7 (and vice versa) only when a common secret (CS) is required.

The registration step may be required only once, for example, as the initial setup of a digital wallet.

Next, an example of determining the common secret (CS) will be described with reference to FIG. A common secret (CS) may be used for a particular session, time, transaction, or other purpose between the first node 3 and the second node 7, and the same common secret (CS) ) may be undesirable or unsafe to use. Thus, the common secret (CS) may change between different sessions, times, transactions, etc.

The following is given to explain the secure transmission techniques described above.

In this example, the method 300 performed by the first node 3 includes generating 310 a message (M). The message (M) may be random, pseudo-random, or user-defined. In one example, the message (M) is based on Unix time and nonce (and any value). For example, message (M) may be given as follows.

Message (M) = Unix time + nonce (Formula 3)

In some examples, the message (M) is arbitrary. However, it is understood that the message (M) may have optional values (eg, Unix time, etc.) that may be useful in some applications.

The method 300 includes transmitting 315 a message (M) to the second node 7 over the communication network 3 . Since the message (M) does not contain information about the private key, the message (M) may be sent over an insecure network.

The method 300 further includes determining 320 a generator value (GV) based on the message (M). In this example, this includes determining a cryptographic hash of the message. Examples of cryptographic hashing algorithms include SHA-256, which generates a 256-bit generator value (GV). That is, GV=SHA-256(M) (Equation 4)

It is understood that other hashing algorithms may be used. This may include other algorithms from the Secure Hash Algorithm (SHA) family. Some specific examples include instances within the SHA-3 subset including SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256. Other hashing algorithms may include those of the RACE Integrity Primitives Evaluation Message Digest (RIPEMD) family. Specific examples may include RIPEMD-160. Other hash functions may include families based on Zemor-Tillich hash functions and knapsack-based hash functions.

The method 300 then determines the second node's master private key (V_1C) and the generator value (GV) of the first node's second private key (V_2C). This is the first node's master private key (V_1C) and the generator value (GV): V_2C=V_1C+GV (Equation 5)

In this way, the second private key of the first node (V_2C) is not a random value, but is derived deterministically from the first node's master private key. The corresponding public key in the crypto pair, i.e. the second public key of the first node (P_2C) has the following relationship:P_2C=V_2C×G (Equation 6)V from Equation 5_2CSubstituting into equation 6, we get the following equation:P_2C=(V_1C+GV)×G (Formula 7) Here, the '+' operator refers to elliptic curve point addition.

Noting that the elliptic curve cryptographic algebra satisfies the distributive law, equation 7 can be expressed as follows:P_2C=V_1C×G+GV×G (Equation 8)Finally, by substituting Equation 1 into Equation 7, we can obtain the following expression:P_2C=P_1C+GV×G (Formula 9.1)P_2C=P_1C+SHA-256(M)×G (Formula 9.2)

In this way, the corresponding first node's second public key (P_2C) is the first node's master public key (P_1C) and the message (M). The second node 7 receives the first node's second public key (P_2C), which is discussed in further detail below with respect to method 400.

The method 300 further includes a message (M) and a determined first node's second private key (V_2C), generating 350 a first signed message (SM1). Generating the signed message includes applying a digital signature algorithm to digitally sign the message (M). In one example, this means that in the Elliptic Curve Digital Signature Algorithm (ECDSA) a first node's second private key (V_2C) to obtain a first signed message (SM1).

Examples of ECDSA include those based on ECC systems using secp256k1, secp256r1, secp384r1, sec3cp521r1.

The first signed message (SM1) is signed by the corresponding first node's second public key (P_2C) can be verified using This verification of the first signed message (SM1) may be used by the second node 7 to authenticate the first node 3, which is discussed in method 400 below.

The first node 3 then obtains the second public key (P_2S) may be determined 370. As discussed above, the second public key (P_2S) is at least the second node's master public key (P_1S) and generator value (GV). In this example, the public key is determined 370' as the private key multiplied by the base point (G) and the elliptic curve point, so the second public key (P2S) of the second node is In this way, it can be expressed as follows :P_2S=V_2S×G (Equation 10.1)P_2S=P_1S+GV×G (Equation 10.2)The mathematical proof of Equation 10.2 is that the second public key (P_2C) is the same as that described above to derive Equation 9.1 for ). It is understood that the first node 3 can determine 370 the second public key of the second node independently of the second node 7.

The first node 3 then uses the determined first node's second private key (V_2C) and the determined second public key of the second node (P_2S) may determine 380 a common secret (CS). The common secret (CS) may be determined by the first node 3 by the following formula: S=V_2C×P_2S (Formula 11)

<u style="Single">Method 400 performed on second node 7</u>A corresponding method 400 performed on the second node 7 will now be described. It will be appreciated that some of these steps are similar to the above steps performed by the first node 3.

The method 400 includes receiving 410 a message (M) from the first node 3 over the communication network 5 . This may include the message (M) sent by the first node 3 in step 315. The second node 7 then determines 420 a generator value (GV) based on the message (M). The step 420 of determining the generator value (GV) by the second node 7 is similar to the step 320 performed by the first node described above. In this example, the second node 7 performs this determination step 420 independently from the first node 3.

The next step is to use the first node's master public key (P_1C) and the generator value (GV), the second public key (P_2C). In this example, the public key is determined 430' as the private key multiplied by the base point (G) and the elliptic curve point, so the second public key (P_2C) can be expressed in a manner similar to Equation 9 as: P_2C=V_2C×G (Equation 12.1)P_2C=P_1C+GV×G (Equation 12.2) The mathematical proof of Equations 12.1 and 12.2 is the same as discussed above for Equations 10.1 and 10.2.

The method 400 may include steps performed by the second node 7 to authenticate that the claimed first node 3 is the first node 3. As discussed above, this includes receiving 440 a first signed message (SM1) from the first node 3. The second node 7 then uses the first node's second public key (P_2C) may be used to validate 450 the signature on the first signed message (SM1).

Verification of the digital signature may be done according to the Elliptic Curve Digital Signature Algorithm (ECDSA) discussed above. Importantly, the second private key of the first node (V_2C) is the first signed message (SM1) signed using V_2Cand P_2Cform a cryptographic pair, so the corresponding first node's second public key (P_2C) should be correctly verified only when used. These keys are the first node's master private key (V_1C) and the master public key of the first node (P_1C) is deterministic, so verifying the first signed message (SM1) means that the claimed first node sending the first signed message (SM1) It can be used as a basis for authenticating the same first node 3 during registration. In this way, the second node 7 may further perform the step of authenticating (460) the first node 3 based on the result of validating (450) the first signed message.

The above authentication may be suitable for scenarios where one of the two nodes is a trusted node and only one of those nodes needs to be authenticated. For example, the first node 3 may be a client and the second node 7 may be a server trusted by the client, such as a wallet provider. Thus, the server (second node 7) may need to authenticate the credentials of the client (first node 3) in order to allow the client to access the server system. It may not be necessary for the server to authenticate the server's credentials to the client. However, in some scenarios, such as peer-to-peer scenarios, it may be desirable for both nodes to authenticate to each other.

The method 400 further includes the second node 7 obtaining the second node's master private key (V_1S) and the generator value (GV) of the second node (V_2S) may include determining 470. Similar to step 330 performed by the first node 3, the second private key (V_2S) is the second node's master private key (V_1S) and generator values (GV): V_2S=V_1S+GV (Equation 13.1)V_2S=V_1S+SHA-256(M) (Equation 13.2)The second node 7 then uses the second private key (V_2S) and the second public key of the first node (P_2C), the common secret (CS) may be determined 480 based on the following formula: S=V_2S×P_2C (Equation 14) The common secret (CS) determined by the first node 3 is the same as the common secret (CS) determined by the second node 7. Here, we will provide a mathematical proof that Equation 11 and Equation 14 give the same common secret (CS).

Looking at the common secret (CS) determined by the first node 3, substituting equation 10.1 into equation 11 yields: S=V_2C×P_2S (Formula 11)S=V_2C×(V_2S×G)S=(V_2C×V_2S)×G (Equation 15) Looking at the common secret (CS) determined by the second node 7, substituting Equation 12.1 into Equation 14 gives: S=V_2S×P_2C (Formula 14)S=V_2S×(V_2C×G)S=(V_2S×V_2C)×G (Equation 16) Since the ECC algebra is commutative, Equations 15 and 16 are equivalent. Because:S=(V_2C×V_2S)×G=(V_2S×V_2C)×G (Equation 17)

The common secret (CS) can now be used as a secret key or as the basis of a secret key in a symmetric key algorithm for secure communication between the first node 3 and the second node 7. This communication may be used to convey a portion of the private key, a representation of the private key or an identifier for the private key, or a mnemonic for the private key. Thus, once the invention is used, for example, in setting up a digital wallet or other controlled resource, secure communications between the parties can be performed thereafter.

The common secret (CS) is the elliptic curve point (x_S,y_S). This may be converted to a standard key format using standard known operations agreed upon by nodes 3, 7. For example, x_SThe value is AES₂₅₆It can be a 256-bit integer that can be used as a key for encryption. It may also be converted to a 160-bit integer using RIPEMD160. This is for any application that requires a key of this length.

A common secret (CS) may be determined as needed. Importantly, the first node 3 does not need to store a common secret (CS). This is because the decision can be made again based on the message (M). In some examples, the messages used (M) are stored in datastores 13, 17, 19 (or other datastores) without the same level of security required for the master private key. Good too. In some examples, the message (M) may be publicly available.

However, for some applications, the common secret (CS) may be the first node's master private key (V_1C) can be stored in a first data store (X) attached to the first node.

The embodiments described above are illustrative rather than limiting, and those skilled in the art will appreciate that many alternative embodiments can be devised without departing from the scope of the invention as defined by the appended claims. It should be noted that it would be possible to design In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The words "comprising" and "having" do not exclude the presence of elements or steps other than those listed in any claim or in the specification as a whole. As used herein, "comprising" means "including or consisting of", and "having" means "including or consisting of". Reference to an element in the singular does not exclude reference to such element in the plural and vice versa. The invention can be implemented by hardware having several separate elements and by a suitably programmed computer. In the device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.