Systems and methods implemented by blockchain
The method employs encryption and time locks in blockchain transactions to facilitate secure asset exchange between untrusted parties, ensuring asset integrity and timely return, addressing the lack of trust in existing systems.
Patent Information
- Application Number
- JP2023184336
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2016-07-29
- Filing Date
- 2023-10-27
- Publication Date
- 2025-07-17
- Estimated Expiration
- 2037-07-21
AI Technical Summary
Existing blockchain technologies lack a secure mechanism for asset exchange between untrusted parties, lacking trust and requiring additional security measures to ensure asset transfer integrity and immutability.
A method utilizing encryption techniques and time locks to generate interdependent blockchain transactions, ensuring secure exchange and return of assets between users, with unlock data and signatures controlling the transfer process.
Enables secure, immutable record of asset transfers between untrusted parties, preventing losses and ensuring timely asset return, thereby enhancing security and user trust.
Smart Images

Figure 0007709806000007 
Figure 0007709806000008 
Figure 0007709806000009
Abstract
Description
Technical Field
[0001] The present invention generally relates to distributed ledger technologies (such as blockchain-related technologies), and particularly relates to a solution for secure transfer (and / or exchange) of assets between entities. It can provide a secure peer-to-peer exchange method and / or system implemented via a blockchain platform or protocol. The present invention is particularly suitable for securely transmitting assets such as digital or electronic assets between entities where no prior relationship or trust exists.
Background Art
[0002] In this document, for the sake of convenience of reference and ease, the term "blockchain" is used as it is currently the most widely known term in this context. Here, the term is used to include all forms of electronic computer-based distributed ledgers, including consensus-based blockchains, orthochains, sidechains, and transaction chain technologies, permissioned and non-permissioned ledgers, private or public ledgers, shared ledgers, and their variations.
[0003] A blockchain is an electronic ledger realized as a computer-based decentralized distributed system composed of blocks consisting of transactions. Each transaction (Tx) includes at least one input and at least one output. Each block includes the hash of the previous block of the chained blocks to create a permanent and immutable record of all the transactions written to the blockchain since its inception. Transactions include a small program known as a script embedded in the inputs and outputs that specify how and by whom the output of the transaction can be accessed. On the Bitcoin platform, these scripts are described using a stack-based scripting language.
[0004] For a transaction to be written to the blockchain, it must be verified by the first node that receives the transaction, and if the transaction is verified, the node relays it to other nodes in the network. ii) Added to a new block constructed by the miner. iii) It needs to be mined, that is, added to the public ledger of past transactions.
[0005] The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. Bitcoin may be referenced here for purposes of convenience and explanation, but it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and other blockchain implementations fall within the scope of the present invention.
[0006] Blockchain technology is most widely known for its use in virtual currency implementations. However, more recently, digital entrepreneurs have begun to implement new systems using both the cryptographic security system underlying Bitcoin and the data that can be stored on the blockchain.
[0007] One area of current interest and research is the use of blockchain for the implementation of "smart contracts". These are computer programs designed to automate the execution of the terms of a contract or agreement. Unlike traditional contracts written in natural language, smart contracts are machine-executable programs that contain rules that can process inputs to produce results and can execute actions in response to these results.
[0008] Another area of interest related to blockchain is the use of "tokens" (or "colored tokens") to represent and transfer real-world entities via the blockchain. Potentially confidential or secret items can be represented by tokens that have no distinguishable meaning or value. Thus, the tokens function as identifiers that enable real-world items to be referenced.
[0009] The present invention is defined by the appended claims.
[0010] The present invention can provide a method implemented by a computer and a corresponding system. It can be described as a method for realizing or executing processing via the blockchain. It can be described as a method for executing the exchange or transfer of assets via the blockchain. One or both of the assets may be part of a virtual currency. Additionally or alternatively, one or both of the assets may be non-virtual currency, but may be any other type of asset, such as a physical, electronic, or digital asset. It may be a tokenized asset.
[0011] The method can provide a method implemented by a computer for controlling the transfer and / or exchange of at least one asset between a first user and a second user via the blockchain. The method can control how and when the asset is transferred. The method Generating a first blockchain transaction including at least one first output representing at least one first asset that is redeemable by providing either (i) unlock data, or (ii) an encrypted signature of a first user and an encrypted signature of a second user, wherein the at least one first asset is exchanged for at least one second asset represented by at least one second output of a second blockchain transaction, and the at least one second output is redeemable by providing either (i) unlock data, or (ii) an encrypted signature of a first user and an encrypted signature of a second user.
[0012] The redemption of at least one second output by providing first unlock data may make the first unlock data available for redeeming at least one first output.
[0013] The term "redeem" may mean using (i.e., redeeming or exchanging) an output included within a blockchain transaction.
[0014] Mutually guaranteed transfer of assets via a blockchain is made possible by the above method, thereby providing the effect of enabling secure transfer of these assets and creation and maintenance of an immutable record of the transfer.
[0015] Accordingly, the present invention may provide a mechanism enabling two parties to perform a secure exchange of assets via a blockchain even if no trust has been established between them. The present invention utilizes encryption techniques in addition to the concept of "publicable" data for implementing this, in addition to a time lock mechanism that controls the point in time at which transaction mining can be performed. An interdependence between transactions is generated that means that control of asset transfers is implemented by application of the blockchain protocol invention. Accordingly, the present invention provides a more secure means of asset exchange for effective use between untrusted parties.
[0016] The repayment of the first blockchain transaction by providing the encrypted signature of the first user and the encrypted signature of the second user may return at least one first output to the first user.
[0017] This enables the first asset to be returned to the first user when the signatures of both the first and second users are provided, thereby providing an effect of preventing losses to the first user.
[0018] The method may further include the step of generating a third blockchain transaction configured to enable the repayment of at least one first output by providing the encrypted signature of the first user and the encrypted signature of the second user in response to the elapse of a first lock time.
[0019] This provides a period that prevents the first user from repaying the first output, thereby providing an effect of preventing the first user from claiming the first output in addition to the second output within that period.
[0020] The third blockchain transaction may include an unlock script including the encrypted signature of the first user and the encrypted signature of the second user.
[0021] This prevents a third party from claiming the first output, thereby providing an effect of increasing the security of the method.
[0022] The step of generating the third blockchain transaction may include the step of sending the third blockchain transaction in an incomplete state to the second user, and the incomplete third blockchain transaction is configured to receive the encrypted signature of the second user before being returned to the first user in a complete state.
[0023] This provides the effect of providing a simple and secure mechanism for collecting encrypted signatures.
[0024] The first lock time may be greater than the second lock time associated with the fourth blockchain transaction, and the fourth blockchain transaction is configured to enable the repayment of at least one second output by providing the encrypted signature of the first user and the encrypted signature of the second user in response to the elapse of the second lock time.
[0025] This provides a buffering period equal to the difference between the first lock time and the second lock time, within which the second user may repay the first output, but the first user does not send a third blockchain transaction to the blockchain for repaying the first output, thereby making it impossible for the first user to repay both the first output and the second output.
[0026] The unlock data may include publicly available data selected by the first user, and the publicly available data is unknown to the second user until the repayment of the third blockchain transaction. The publicly available data may be data that is initially a secret known only to the first user (preferably) until the third blockchain transaction is used. The publicly available data may be made available or "published" on the blockchain by providing it in an unlock script. This may be for unlocking the lock script of the third transaction. Thereafter, the second user may view and utilize the publicly available data and provide it to other lock scripts.
[0027] This provides an effect that enables mutual trust to be generated between a first user and a second user, and the disclosure of publicly available data provides a further effect that enables the first and second users to regain their respective assets represented by their respective first and second transactions while the first user repays the second output and the second user repays the first output.
[0028] The unlock data may further include an encrypted signature of the second user.
[0029] This guarantees that the repayment of the first output requires the encrypted signature of the second user, thereby providing an effect of increasing the security of the method.
[0030] According to a second aspect of the present invention, a method implemented by a computer for transferring an asset between a first user and a second user, comprising the step of generating a second blockchain transaction including at least one second output representing at least one second asset that is redeemable by providing either (i) unlock data, or (ii) an encrypted signature of the first user and an encrypted signature of the second user, wherein at least one second asset is exchanged for at least one first asset represented by at least one first output of a first blockchain transaction, and at least one first output is redeemable by providing either (i) first unlock data, or (ii) an encrypted signature of the first user and an encrypted signature of the second user, and providing a method for making the first unlock data available for redeeming the first output for the repayment of the second output.
[0031] The repayment of the second blockchain transaction by providing the encrypted signature of the first user and the encrypted signature of the second user may refund the second output to the second user.
[0032] Providing the signatures of both the first and second users enables the second asset to be returned to the second user, thereby providing the effect of preventing losses to the second user.
[0033] The method may further include generating a fourth blockchain transaction configured to enable repayment of at least one second output by providing the encrypted signature of the first user and the encrypted signature of the second user in response to the expiration of a second lock time.
[0034] This provides a period during which the second user is prevented from repaying the second output, thereby providing the effect of preventing the second user from claiming the second output in addition to the first output during this period.
[0035] The fourth blockchain transaction may include an unlock script that includes the encrypted signature of the first user and the encrypted signature of the second user.
[0036] The step of generating the fourth blockchain transaction may include sending an incomplete fourth blockchain transaction to the first user, and the incomplete fourth blockchain transaction is configured to receive the encrypted signature of the first user before being returned to the second user in a complete state.
[0037] The method may further include monitoring a third blockchain transaction on the blockchain.
[0038] This provides the effect of enabling the second user to repay the first output in a timely manner.
[0039] The method may further include generating a fifth blockchain transaction that is redeemable by providing an encrypted signature of a first user, thereby including at least one third output that returns at least one first output to the first user.
[0040] This enables a refund mechanism to be implemented on the blockchain, provides the effect of returning the first asset to the first user, and increases the user-friendliness of the method.
[0041] The method may further include broadcasting the fifth blockchain transaction to the blockchain in response to a determination that the asset was not provided to the first user.
[0042] This provides the effect of further reducing the probability of loss to the first user.
[0043] The fifth blockchain transaction may be sent to a third party, and the determination and broadcast may be executed by the third party.
[0044] This provides a further effect of increasing the automation of the method.
Brief Description of the Drawings
[0045]
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
DETAILED DESCRIPTION OF THE INVENTION
[0046] Here, for illustrative purposes only, an example of an embodiment of the present invention will be provided. In this exemplary scenario, a method of transferring a second asset in the form of an event ticket in return for a first asset in the form of a payment via a blockchain is described. The use of the blockchain provides the inherent effects provided by the technology. These effects include a record of tamper-resistant events and increased security for currency exchange. Although this description pertains to tickets, other types of assets may be transferred and still fall within the scope of the present invention. The present invention is not limited with respect to the type of asset being targeted.
[0047] Alice is considering purchasing tickets for an event to be held at some point in the future. Bob is offering tickets for sale for the event in the form of tokenized blockchain transactions.
[0048] Referring to FIGS. 1 and 6, Alice generates a first blockchain transaction (S100) that represents payment for the number of tickets she wishes to purchase from Bob (in this exemplary embodiment, the payment is 2-bitcoins or 2 BTC as shown in the Value cell of FIG. 1). From here, the first blockchain transaction may be referred to as a payment transaction for simplicity.
[0049] The payment transaction has an output that includes the following lock script.
[0050] [Table 1] The payment transaction can be unlocked by presenting any of the following unlock scripts against the lock script of the payment transaction.
[0051] [Table 2] Here, X is selected by Alice and contains data in a form that can be used in the blockchain transaction to secure the payment transaction. X may be a digitized version of biometric information such as a fingerprint or iris. X may contain data generated randomly or pseudorandomly. The above unlock script containing X
[0052] [Table 3] The content of can be referred to as "unlock data". The unlock data may include Bob's signature and Bob's public key, or it may include only the data X, or it may include any suitable combination of these. In this exemplary embodiment, the unlock data includes Bob's signature, Bob's public key, and X which is a password selected by Alice. From here, X can be referred to as "revealable data".
[0053] 2 BTC can be redeemed by providing either Bob's encrypted signature, Bob's public key, and X, or Alice's encrypted signature and Bob's encrypted signature. (Note that the first data element (OP_0, OP_1) selects which stage is being used. If the top stack value is not 0, the IF statement is executed and the top stack value is removed.) Alice sends the payment transaction for verification and broadcast to the blockchain. Bob may monitor the blockchain for the payment transaction and read the hash of X from the payment transaction (S102). Alice may further communicate the hash of X and / or other information regarding the payment transaction to Bob by any suitable means, such as via email or text message (S102).
[0054] Referring to FIGS. 2 and 6, Bob generates a second blockchain transaction representing the ticket that Alice desires to purchase and that is transferred to Alice by the payment (S104). The number and type of tickets that Alice desires to purchase may be communicated to Bob by any suitable means, such as via email, an app on a mobile device or PC, an online store, or transaction metadata embedded in a previous blockchain transaction, before Bob generates the second blockchain transaction representing these tickets. Hereinafter, this second blockchain transaction may be referred to as a "ticket transaction" for simplicity.
[0055] The ticket transaction has an output that includes the following lock script.
[0056] [Table 4] In the above lock script, the redeem script is
[0057] [Table 5] as follows.
[0058] The ticket transaction has the following unlock script
[0059] [Table 6] can be unlocked by presenting to the lock script of any of the ticket transactions
[0060] Here, X is a password selected by Alice that is provided by Alice to the lock script of the ticket transaction to redeem the ticket and is kept secret by Alice until the redeem script is given. That is, the ticket may be redeemed by providing either Alice's encrypted signature, the redeem script (including Alice's public key) and X, or Alice's encrypted signature and Bob's encrypted signature.
[0061] Bob sends the ticket transaction for verification and broadcast to the blockchain. Alice may monitor the blockchain for the ticket transaction. Bob may further communicate information regarding the ticket transaction to Alice by any suitable means, such as via email or text message.
[0062] Referring to FIGS. 3 and 6, Alice also generates a third blockchain transaction (hereinafter referred to as the payment return transaction) configured to enable the redemption of 2 BTC of the payment transaction by providing both Alice's signature and Bob's signature to the lock script of the payment transaction (S200). Alice configures the transaction to have a lock time of 48 hours. This means that the transaction is verifiable by the first node that receives it and can be added to the memory pool. However, until the time specified by the lock time (in this exemplary embodiment, 48 hours) has elapsed, the transaction is not mineable by the miner and thus cannot be added to the blockchain.
[0063] To generate a payment return transaction, Bob must provide his signature to create the unlock script for the transaction. To do this, Alice may generate an incomplete version of the payment return transaction that does not include Bob's signature and send it to Bob, who then provides his signature to the lock script of the incomplete transaction (S204) and returns a complete version of the payment return transaction to Alice.
[0064] Referring to FIGS. 4 and 6, Bob also generates a fourth blockchain transaction (hereinafter, the transaction may be referred to as a "ticket return transaction") configured to enable redemption of the tokenized output of the ticket transaction by providing both Alice's signature and Bob's signature to the lock script of the ticket transaction (S202). Bob configures the transaction to have a 24-hour lock time. This means that the transaction is verifiable by the first node that receives it and can be added to the memory pool. However, the transaction is non-mineable by miners and thus not addable to the blockchain until the time specified by the lock time (in this exemplary embodiment, 24 hours) has elapsed. Although it is effective for the lock time of the payment return transaction to be longer than the lock time of the ticket return transaction for reasons to be explained later in the present application, it should be understood that the lock times of 48 hours and 24 hours are selected, but any appropriate lock time may be selected.
[0065] To generate a payment return transaction, Alice must provide her signature to create the unlock script for the transaction. To do this, Bob may generate an incomplete version of the ticket return transaction that does not include Alice's signature and send it to Alice, who may then provide her signature to the lock script of the incomplete transaction (S204) and return a complete version of the payment return transaction to Bob.
[0066] Once the payment transaction and the ticket transaction are added to the blockchain, Alice has the option to provide her signature, public key, and X to the lock script of the ticket transaction to redeem the ticket. In doing so, Alice needs to disclose X, which is disclosed on the blockchain as a requirement to unlock the ticket transaction. When Bob knows X, Bob can provide his signature, his public key, and X to the lock script of the payment transaction to redeem the payment for the ticket.
[0067] Alice needs to provide X until the lock time of the ticket return transaction has elapsed. After that time, Bob can provide his signature to the lock script of the ticket return transaction and make it possible to add the ticket return transaction to the blockchain, which causes Alice's signature and Bob's signature to be provided to the lock script of the ticket transaction, thereby returning the tokenized output of the ticket transaction to Bob.
[0068] After that, Alice may provide her signature to the lock script of the payment return transaction until the lock time of the payment return transaction elapses, and wait for the payment return transaction to be added to the blockchain, which causes the lock script of the payment transaction to be provided with Alice's signature and Bob's signature, thereby returning 2 BTC of the payment transaction to Alice.
[0069] If Alice provides X before the lock time of the ticket return transaction elapses, Bob must provide X to the lock script of the payment transaction in order to claim his 2 BTC payment for the ticket redeemed by Alice until the lock time of the payment return transaction elapses. If Bob does not claim the 2 BTC before the lock time elapses, upon the expiration of the lock time, Alice can sign the payment return transaction and retrieve her 2 BTC.
[0070] The lock time of the payment return transaction is selected to be greater than the lock time of the ticket return transaction in order to give Bob a reasonable minimum time to claim his payment from the time Alice claims the ticket. This minimum time is equal to the difference between the two lock times. In this exemplary specific example, therefore, the minimum time is 24 hours.
[0071] Referring to FIG. 5, Bob generates a fifth blockchain transaction, hereinafter referred to as a refund transaction, representing a refund of 2 BTC from Alice to Alice. Bob executes this if the event for which the ticket was purchased is cancelled, or if Alice decides to return the ticket for a refund or any other appropriate reason. Bob sends the refund transaction to a third party, such as an independent service provider offering this type of mediation service or a third user of the blockchain. The third party may monitor the exchange and / or the event situation and determine whether the event was carried out as planned or not, a specific example of the latter including the cancellation of the event, and if the event is determined to have been cancelled, returns 2 BTC to Alice.
[0072] The third party may be instructed or set to execute the refund (by publishing the refund transaction on the blockchain) for any other appropriate reason. The legitimate reasons, i.e., those that satisfy Bob and / or the third party as legitimate criteria for refunding 2 BTC to Alice, may be defined in the terms and conditions of the exchange, which may be communicated between Alice, Bob, and the third party prior to the exchange, and the terms and conditions will probably be stored on the blockchain in the form of a tokenized contract, or on an internet-connected resource.
Claims
1. A method implemented by a computer for transferring an asset between a first user and a second user via a blockchain, comprising: generating a first payment transaction including at least one first output representing at least one payment, wherein the first payment transaction is repayable by providing either (i) unlock data, or (ii) an encrypted signature of the first user and an encrypted signature of the second user; the step of being; including the step of, wherein the at least one payment is exchanged for at least one ticket for an event represented by at least one second output of a ticket transaction, and the at least one second output is repayable by providing either (i) the unlock data, or (ii) an encrypted signature of the first user and an encrypted signature of the second user; the step of being; repayment of at least one second output by providing first unlock data makes the first unlock data available for repaying at least one first output, and the method further comprises generating a refund blockchain transaction including at least one third output, repayable by providing the encrypted signature of the first user, thereby returning at least one first output to the first user, and broadcasting the refund blockchain transaction to the blockchain, wherein the refund blockchain transaction is sent to a third party, and the broadcast is executed by the third party; including the step of, method.
2. Repayment of the first payment transaction by providing the encrypted signature of the first user and the encrypted signature of the second user returns at least one first output to the first user; The method according to claim 1.
3. The method further comprises generating a payment return transaction configured to enable repayment of at least one first output by providing the encrypted signature of the first user and the encrypted signature of the second user in response to the expiration of a first lock time; including the step of, The method according to claim 1 or 2.
4. The payment return transaction includes an unlock script including the encrypted signature of the first user and the encrypted signature of the second user. The method according to claim 3.
5. The step of generating the payment return transaction includes the step of sending the payment return transaction to the second user in an incomplete state, and the incomplete payment return transaction is configured to receive the encrypted signature of the second user before being returned to the first user in a complete state. The method according to claim 4.
6. The first lock time is greater than a second lock time associated with a ticket return transaction, and the ticket return transaction is configured to enable the repayment of at least one second output by providing the encrypted signature of the first user and the encrypted signature of the second user in response to the elapse of the second lock time. The method according to any one of claims 3 to 5.
7. The unlock data includes publicly available data selected by the first user, and the publicly available data is unknown to the second user until the repayment of the payment return transaction. The method according to any one of claims 1 to 6.
8. The unlock data further includes the encrypted signature of the second user. The method according to claim 7.