Blockchain Implemented Method and System
Patent Information
- Authority / Receiving Office
- TW · TW
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2017-07-28
- Publication Date
- 2022-09-01
- Estimated Expiration
- Not applicable · inactive patent
Smart Images
Figure TWG2TA000873763_001 
Figure TWG2TA000873763_002 
Figure TWG2TA000873763_003
Abstract
Description
[Technical Field]
[0001] This invention relates to a computer-implemented method for transferring assets (such as digital assets) between a first user and a second user. In particular (but not exclusively), this invention relates to a computer-implemented control mechanism for determining how to execute an asset transfer process via multiple transactions on a blockchain platform. This invention may include the use of micropayment channels. [Previous Technology]
[0002] In this document, for convenience and ease of reference, we use the term "blockchain" because it is the most widely known term in this context. The term is used herein to encompass all forms of computer-based electronic distributed ledgers, including consensus-based blockchains, alt-chains, sidechains, and transaction-chain technologies, permissioned and permissionless ledgers, private and public ledgers, shared ledgers, and variations thereof.
[0003] Blockchain is an electronic ledger implemented using a computer-based decentralized distributed system composed of blocks, which in turn consist of transactions. Each transaction includes at least one input and at least one output. Each block contains the hash of previous blocks, making these blocks linked together to create a permanent and immutable record of all transactions written to the blockchain from the beginning. Transactions contain small programs called instructions embedded in their inputs and outputs, which specify how and by whom the transaction's outputs can be accessed. For example, instructions embedded in the outputs can specify which cryptographic signatures are required to access the transaction's outputs. On the Bitcoin platform, these instructions are written using a stack-based instruction processing language.
[0004] In order to write a transaction to the blockchain, the transaction must i) be verified by the first node that receives the transaction—if the transaction is verified, the node will relay the transaction to other nodes in the network; and ii) be added to a new block built by the miner; and iii) be mined, that is, added to the public ledger of past transactions.
[0005] Although other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. While Bitcoin is mentioned herein for convenience and illustrative purposes, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations fall within the scope of this invention.
[0006] Blockchain technology is most widely known for its use in implementing cryptocurrencies. However, recently, several entrepreneurs have begun exploring the use of both the cryptographic security system upon which Bitcoin is based and the data that can be stored on the blockchain to implement new systems.
[0007] One area of current interest and research is the use of blockchain for implementing "smart contracts." These smart contracts 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 process input to produce results, and then can perform actions based on those results.
[0008] Another area related to blockchain is the use of "tokens" (or "colored coins") to represent and transmit real-world entities via blockchain. Potentially sensitive or secret items can be represented by tokens, which do not have a discernible meaning or value. Tokens thus act as identifiers that allow reference to real-world items.
[0009] Another application of blockchain technology relates to "micropayment channels." This is illustrated by the description of micropayment channels provided on the Internet at https: / / bitcoinj.github.io / working-with-micropayments. These channels allow consumers to make regular payments to merchants, for example, for time-related online services such as internet access. These micropayment channels operate by generating a first funding blockchain transaction, which has an output representing a deposit that can be paid by the consumer to the merchant and is refundable to the consumer after a specified lock-up period. This first funding blockchain transaction is then committed to the blockchain. In previous technologies, this funding transaction could also be referred to as a "refund transaction." A second "fungible" blockchain transaction is generated, which has an output representing a payment to the merchant. The fungible transaction is a copy of the previous transaction, but with a smaller refund to the consumer. This process can be repeated, allowing the fungible transaction to be periodically updated to increase the amount paid to the merchant. Merchants remain on the fungible transaction until the final transaction is submitted to the blockchain to fulfill the payment, thereby minimizing unnecessary data processing and unnecessary memory usage on the blockchain. The name "fungible transaction" comes from the fact that it replaces a previous transaction provided by the user. Funds and fungible transactions are normal blockchain transactions as known in previous technologies, allowing the blockchain to be used normally.
[0010] An example of this known one-way micropayment channel is shown in Figure 1.
[0011] Referring to Figure 1, initially in step S1, a micropayment channel is established between consumers and merchants who have reached an agreement on an implicit or explicit contract. This channel allows consumers to make payments to merchants for online time-dependent digital assets (such as internet access). The implicit or explicit contract defines the details of how the contract is executed, such as the deposit amount, payment amount, and payment frequency. The micropayment channel is unidirectional in that the asset (in the form of payment) is transferred from the consumer to the merchant via the blockchain, but not from the merchant to the consumer. Next, in step S2, a first funds blockchain transaction is generated. This transaction has a first input representing the consumer's funds deposit and a first output. With the aid of the first output, the entire deposit is paid to a command code that can be redeemed by the signatures of both the consumer and the merchant, or by the consumer's signature alone after a lock-up period N. In step S3, the consumer signs the funds transaction and submits it to the blockchain.
[0012] Next, in step S4, a fungible blockchain transaction is generated so that the consumer can make a payment to the merchant. The fungible blockchain transaction has a single input from the deposit spent on the fund transaction and a pair of outputs: one output pays the due amount to the merchant, and the other output returns the remaining balance to the consumer. The fungible transaction can be unlocked using the signatures of both the consumer and the merchant (time N has not yet passed, therefore signatures from both the consumer and the merchant are required). In step S5, the consumer signs the fungible transaction and then sends it to the merchant (the fungible Tx still requires the merchant's signature to be complete).
[0013] Since the time a merchant supplies to a consumer depends on the amount of online assets, such as internet access or content, which increases over time, in step S6, the replaceable transaction is updated to increment the amount of the first output that can be paid to the merchant and decrement the amount of the second output that can be returned to the consumer (it should be noted that in an untrusted system, the total payment to the merchant must be monotonically incremented. In this way, merchants are incentivized to submit the latest replaceable transaction to the blockchain to obtain the maximum total payment). To cash out the payment, in step S7, the merchant signs the final replaceable transaction and submits the signed transaction to the blockchain. On the other hand, if a replaceable transaction has not been received before time N, the consumer can cash out the output of the refund transaction by providing the consumer's signature in step S8 (after time N, only the consumer's signature is required). The refund transaction has a single input of the deposit spent on the funds transaction and a single output of paying the full deposit to the address specified by the consumer. In step S9, the consumer signs the refund transaction and submits it to the blockchain.
[0014] This configuration has the following drawbacks: Although it indicates that the funds transaction for deposit payments ensures the security of payments to merchants, the assets transferred from consumers to merchants via blockchain are decoupled from the agreement between consumers and merchants. As a result, in the event of a lack of agreement between merchants and consumers, merchants may find it difficult to prove the necessary relevance between the agreement and the relevant blockchain transactions, or impose conditions on the supply of online services, or take action without the consumer's authorization except by terminating the micropayment channel by redeeming the latest replaceable transaction. [Summary of the Invention]
[0015] The preferred embodiments of the present invention attempt to overcome one or more of the above-mentioned disadvantages of the prior art.
[0016] The present invention can provide a computer implementation method and corresponding system as defined in the appended claims.
[0017] This invention can be described as a symbolization method and system. It may include contracts that use symbols or colored coins to represent assets to be transferred from one party to another via blockchain, or to define the transfer of assets. This asset may be referred to as a "transfer asset". The asset transfer may be defined or detailed in a machine-executable smart contract.
[0018] Alternatively or concurrently, the present invention may be described as a method and system for implementing or executing micropayment channels via blockchain.
[0019] Alternatively or alternatively, the present invention may be described as a control method and system. It controls the provision of transferred assets from one party (user) to another. Alternatively or alternatively, it controls the transfer or exchange of assets between users according to the present invention. Users may be referred to as "party" or "participant." They may be referred to as "asset recipient" or "acceptor" and correspondingly, "asset provider."
[0020] Transferable assets may be any type of digital, physical, electronic, or abstract asset. They may be services or goods.
[0021] The method of the present invention may include the step of transferring (transferring) assets between a first user and a second user.
[0022] The method described may facilitate or enable the transfer of assets using blockchain technology. This blockchain may or may not be the Bitcoin blockchain.
[0023] According to one form of wording, the present invention may provide a computer-implemented method. The method may be a method of implementing or executing micropayment channels on a blockchain. Alternatively or additionally, the method may be a method of performing an exchange or transaction via a blockchain. The method may be a method of controlling the submission of transactions to the blockchain.
[0024] The method may include the following steps: submitting a fund transaction to a blockchain network, wherein the fund transaction: i) includes a symbolic contract related to assets transferred from a second user to a first user; and ii) is signed by the first user; sending one or more subsequent transactions from the first user to the second user, wherein each of the subsequent transactions consumes the output of the fund transaction and is signed by the first user; submitting one of the subsequent transactions to the blockchain network, wherein the submitted transaction has been signed by the second user.
[0025] Multiple subsequent transactions may be generated. These transactions may be generated consecutively (one after another). Fund transactions or subsequent transactions may include the transfer of some value, asset, or fund (e.g., BTC) to the output (TxO) of the first user. Each subsequent transaction may return a smaller value, fund, or asset to the first user.
[0026] A "symbolized contract" can be a symbol representing a contract or its location (which may be called colored coin). The contract can be a machine-executable smart contract. Smart contracts can be generated by asset providers. Symbols can be provided within the command code. Symbols can be provided within the metadata following the command code. Command codes can be provided in the locking command code of a blockchain transaction.
[0027] The contract may be generated by a second user (asset provider). Therefore, in one or more embodiments, the present invention can provide a novel combination of several technologies including smart contracts, tokens, and micropayment channels.
[0028] According to alternative wording, the method may include the following steps: generating a first blockchain transaction, the first blockchain transaction including at least one first input representing an individual first asset transferable from a second user to a first user and at least one first output representing an individual second asset, the second asset being redeemable by providing a cryptographic signature of the first user and a cryptographic signature of the second user; generating a second blockchain transaction, the second blockchain transaction having at least one second input representing an individual second asset and at least one second output representing an individual third asset transferable from a first user to a second user, wherein the third asset is replaced by an individual first asset, and wherein the second output is redeemable by providing a cryptographic signature of the first user and a cryptographic signature of the second user; and repeatedly generating the second blockchain transaction to update the value of the third asset.
[0029] By generating a first blockchain transaction that includes at least one first input (representing an individual first asset), this provides the advantage that information related to the first asset can be included in the first transaction. For example, the first blockchain transaction can provide an immutable record of an agreement between a first user and a second user, and may include a date that can cause action to be taken in certain circumstances, such as a smart contract or control data that causes certain actions (e.g., making a payment to a designated party) in the event of an activity not authorized by the first user.
[0030] The second blockchain transaction may have at least one third output representing an individual first asset.
[0031] This provides the following advantages: it allows the first asset to be transferred to another party after use, for example, returned to a second user for reuse, thereby preventing the first asset from unnecessarily occupying memory or taking up processing power in the blockchain.
[0032] At least one of the first inputs may contain control data for generating third blockchain transactions.
[0033] This provides the advantage of enabling automatic actions to be taken, for example, in situations where the activity is not authorized by the first user.
[0034] At least one of the second assets may be redeemable by providing a cryptographic signature of the first user due to the failure to redeem the third asset.
[0035] At least one of the second assets can be cashed out after the first lock-up period expires by providing a cryptographic signature to the first user.
[0036] According to another aspect of the present invention, a computer-implemented method for transferring at least one asset between a first user and a second user via blockchain is provided, the method comprising: generating a fourth blockchain transaction having at least one fourth output representing a particular first asset transferable from the second user to the first user and corresponding to a particular first input of the first blockchain transaction; receiving a first blockchain transaction including at least one first input representing a particular first asset and at least one first output representing a particular second asset, the second asset being redeemable by providing a cryptographic signature of the first user and a cryptographic signature of the second user; submitting the first blockchain transaction to the blockchain; receiving a plurality of second blockchain transactions, each second blockchain transaction including at least one particular second input representing a particular second asset and at least one particular second output representing a particular third asset transferable from the first user to the second user, wherein the third asset is replaced by a particular first asset, wherein the third asset is redeemable by providing a cryptographic signature of the first user and a cryptographic signature of the second user; and submitting the second blockchain transactions to the blockchain.
[0037] The first blockchain transaction may include at least one fifth output, which represents an individual fourth asset that can be cashed out by providing a cryptographically compiled signature to a second user.
[0038] The fourth asset can be cashed out by providing a second user with a cryptographically compiled signature since the third asset has not been cashed out.
[0039] The fourth asset can be cashed out after the second lock-up period expires by providing a second user with a cryptographically compiled signature.
[0040] At least one of the first or second assets may include machine-executable code.
[0041] The various “modes” described above are not intended to limit the invention. Any feature mentioned in relation to one mode or terminology of the invention may also be applied to one or more modes or terms provided above.
[0042] The present invention can provide methods and systems substantially as described in the following illustrative embodiments or the use cases provided below.
Implementation Method
[0044] Referring to the figures, the following illustrates illustrative use cases related to purchasing services. However, it is worth noting that the invention is not limited thereto. Embodiments of the invention can be configured to facilitate the exchange of any asset. This asset may be referred to as a "transfer asset." The transfer asset may be a digital asset and may represent any type, such as a physical, electronic, digital, or abstract entity. In the following description, references to the first, second, third, and fourth blockchain transactions and to the first, second, third, and fourth assets may have the same meaning as in the claims.
[0045] It is also worth noting that the examples provided herein pertain to scenarios involving purchases. Therefore, the terms "consumer" and "merchant" can be used to refer to participants in an exchange. However, this invention is not intended to be limited to retail applications. In fact, this invention is equally applicable to applications where goods or services are not purchased. The transfer of digital assets (funds) via blockchain transactions can only be used to facilitate blockchain-related implementations, as all blockchain transactions (Tx) must have inputs and outputs.
[0046] Referring to Figure 2, a micropayment channel embodying the present invention is illustrated. The micropayment channel may be referred to as a "unidirectional payment channel." The micropayment channel is configured to enable a participant (hereinafter, "consumer") to make payments to another participant (hereinafter, "merchant") by updating one or more payment transactions for online time-dependent digital assets (such as internet access). This allows the output of the micropayment channel, representing payments made for time-dependent assets, to be updated as more assets are transferred over time. This may be referred to as "transferred assets" because it is an asset being provided from one user to another. Therefore, the present invention provides a technical mechanism for controlling how transferred assets are transferred. Blockchain transactions provide a technical means (vehicle) for determining whether assets can be transferred between parties and how and when such transfer will be carried out.
[0047] A key advantage of this invention is that the exchange process can be fully automated, thus eliminating the need for manual intervention once the process has begun. The system can be configured such that a computational agent can determine how and when a transaction should be generated and / or submitted to the blockchain.
[0048] Initially, in step S101, the merchant establishes C contracts for the service or asset. Preferably, the contracts are machine-executable smart contracts that define certain details such as deposit amount, payment amount, and payment frequency. Therefore, by utilizing smart contracts, the present invention allows asset providers (e.g., merchants) to have some input into the micropayment process. This is an advantage over prior art configurations, and the present invention provides an alternative technical mechanism for controlling how micropayment channels are executed. Greater granularity or conditions are introduced into the execution via smart contracts. For example, asset providers can also use smart contracts to physically control access to assets (e.g., internet access).
[0049] In step S102, the merchant then generates a fourth blockchain transaction in the form of a minting blockchain transaction ("minting Tx"). This fourth blockchain transaction has an input representing funds provided by the merchant and a series of C outputs, each of which pays funds to a command code or symbol representing an individual first asset forming part of the contract between the merchant and the consumer. Those skilled in the art will understand that the party generating the minting transaction ("minter") need not be the merchant. For example, the merchant may choose to contract with a third party to generate the minting transaction or use software provided by a third party for this purpose.
[0050] A token can represent a smart contract that can be stored on a computer-based resource (e.g., a server). Smart contracts are written in a machine-executable form and therefore can be read, executed, or performed by automated agents (which may be called "bots"). For example, a contract can be stored in a distributed hash table (DHT) provided outside of a block. Tokens can be minted or melted by a minter at any time.
[0051] A symbol (or "colored coin") representing a contract may be provided as post-data in the instruction code. The symbol enables access to the contract. For example, the symbol may provide the location or URI where the smart contract is stored, or a hash of the location.
[0052] In step S103, the merchant then submits the minting transaction to the blockchain. Details of the minting transaction are shown in Figure 4A, and details of the transaction's inputs and outputs, as well as the instructions for the minting transaction's output to pay the funds, are shown in Figure 4B. It should be noted that the merchant can perform steps 1 to 4 of Figure 2 at any time and add the new token to its list.
[0053] The details of the transaction inputs and outputs, and the instructions for paying funds to the minting transaction output, are as follows: Input 1 – Funds used by the merchant to mint the token. The amount of funds and the unlocking instruction are arbitrary. Output 1 – Payment of funds to the <script_hash_token> whose Hash160 is the following instruction: Instruction code OP_1 <Metadata1> <Metadata2> <PubKey_Merchant> OP_3 OP_CHECKMULTISIG metadata1 and metadata2 are hypothetical compressed public keys containing information about the contract.
[0054] After the minting transaction has been submitted to the blockchain in step S103, in step S104, the merchant publicly discloses the symbol's instruction code and contract details on a platform accessible to consumers. Steps S101 to S104 can be performed at any time, allowing the merchant to add new symbols to the list, and the symbols can be melted (i.e., deleted or reused) by the merchant at any time.
[0055] Figure 3 illustrates examples of token minting transactions and token transfer transactions. A token minting transaction can be the minting transaction of step S102 in Figure 2, and a token transfer transaction can be the transfer transaction that forms the output of the replaceable transaction in step S108 of Figure 2. A minting transaction is generated by the token minter in step S201 and has an input representing funds provided by the minter and a single output representing payment to a hash of the instruction code. The instruction code hash is a hash containing a multi-signature instruction code pointing to the post-data of the electronic certificate (funds / token value is usually a small amount). The instruction code has the following form: Instruction Code <NumSigs Metadata1 Metadata2... PubKey1 PubKey2... NumKeys OP_CHECKMULTISIG> where Metadata1... etc. are hypothetical compressed public keys (32 bytes). Examples of post-data formats are shown below: column Sub-column byte value annotation Metadata1 ContractType 4 The written code value indicates the type of contract. ContractPointer 16 IPv6 address of the actual contract file location ContractTypeData1 12 The format depends on the value of ContractType. Padding with zeros. Metadata2 ContractHash 20 RIPEMD-160 (SHA256 (the actual contract file addressed by ContractPointer)) ContractTypeData2 12 The format depends on the ContractType value. Padding with zeros. PubK1 is a real public key.
[0056] The token can be redeemed by a command code containing the minter's public key, as shown in Figure 2. The minter's public key is not necessary, but it allows the minter to control how Party A uses the token (e.g., to prevent Party A from melting the token).
[0057] The token transfer transaction is generated in step S202 and has inputs for spending tokens and their associated funds and outputs for paying funds to a hash of an instruction code representing a token owned by Party A (the instruction code reuses the same meta data to "retain" the token).
[0058] Referring back to Figure 2, when the consumer browses the contract in step S105 and establishes a first blockchain transaction in the form of a fund transaction for the contract they wish to conclude, a micropayment channel is initially established. The fund transaction has: a first input representing the consumer's fund deposit; and a second input representing a first asset represented by the second input containing an instruction code, the instruction code including a token provided by the merchant. The fund transaction has: an output of a second asset by paying the consumer an amount X, which can be redeemed by providing the consumer's signature and the merchant's signature or by providing the consumer's signature only after the lock-up period N expires; and an output of a third asset by paying the merchant an amount Y, which can be redeemed by providing the consumer's signature and the merchant's signature or by providing the merchant's signature only after the lock-up period N expires. The amount X can typically be the full deposit amount, representing a full refund of the deposit to the consumer, and Y can represent a full refund of the token value to the merchant. However, X can also be set to a smaller value and Y to a larger value, representing a non-refundable deposit payment to the merchant. X + Y = Deposit + Symbol Value, where X can be the consumer's entire deposit (i.e., if Tx does not occur, the entire deposit will be refunded to the consumer after time N). Other options are possible, such as mandating a minimum fee when entering into the contract.
[0059] In step S106, the consumer then signs the fund transaction and sends it to the merchant. In step S107, the merchant signs the fund transaction and submits it to the blockchain. Details of the fund transaction are shown in Figure 5A, and details of the inputs and outputs of the fund transaction, as well as the instruction codes used to unlock the inputs and outputs of the fund transaction, are shown in Figure 5B.
[0060] Details of the input and output of fund transactions, and the instruction codes used to unlock fund transactions, are as follows: Input 1 – The consumer's deposit amount and unlocking method are arbitrary, as required by the contract. Input 2 – The merchant's token, which the consumer copies from the platform where the merchant's publicly disclosed contract and token instruction code are located. <script_serialized_token> is the serialized token instruction code: Instruction code OP_1 <Metadata1> <Metadata2> <PubKey_Merchant> OP_3 OP_CHECKMULTISIG Metadata and metadata2 contain information about the contract. Output 1 – Pay amount X to <script_hash_customer> whose Hash160 is the following instruction code: Instruction code OP_IF <now + time N> OP_CHECKLOCKTIMEVERIFY OP_DROP <PubKey_Customer> OP_CHECKSIGVERIFY OP_ELSE <PubKey_Customer> <PubKey_Merchant> OP_2 OP_CHECKMULTISIGVERIFY OP_ENDIF The `<script_hash_customer>` can be unlocked by: OP_1 `<Sig_Customer> <serialized script customer>` with a lock time N; or OP_0 `<Sig_Customer> <Sig Merchant> <serialized script customer>`. The amount paid, X (450,000 in this case), may be adjusted depending on the contract terms. That is, if no replacement transaction is submitted to the blockchain before time N, how much is refunded to the consumer? Output 2 – the amount Y paid to the `<script_hash_merchant>` with the following Hash160 instruction code: Instruction code OP_IF <now + time N> OP_CHECKLOCKTIMEVERIFY OP_DROP <PubKey_Merchant> OP_CHECKSIGVERIFY OP_ELSE <PubKey_Customer> <PubKey_Merchant> OP_2 OP_CHECKMULTISIGVERIFY OP_ENDIF The `<script_hash_merchant>` can be unlocked by: an OP_1 `<Sig_Merchant> <serialized script merchant>` with a lock time N; or an OP_0 `<Sig_Customer> <Sig Merchant> <serialized script merchant>`. The amount paid, Y (here, 50,000), can be adjusted depending on the contract terms. That is, how much is paid to the merchant if no replacement transaction is submitted to the blockchain before time N.
[0061] Referring again to Figure 2, in step S108, when making a payment, the consumer generates a second blockchain transaction in the form of a fungible blockchain transaction. The fungible transaction has inputs of the transaction spending amounts X and Y, respectively, and outputs of paying the symbol value to the symbol's instruction code, representing a third asset by paying the due amount to the merchant, and paying the remaining funds to the consumer. In step S109, the consumer signs the fungible transaction and sends it to the merchant. It should be noted that the fungible transaction is not submitted to the blockchain. In fact, the fungible transaction is sent to the merchant by the consumer's signature; the merchant can choose which fungible transaction to sign and submit to the blockchain, and when to sign and submit it (time N has not yet passed, therefore the signatures of both the consumer and the merchant are required).
[0062] To redeem each output of the replaceable transaction, the consumer's signature and the merchant's signature are required. When subsequent payments are due, steps S108 and S109 are repeated, increasing the due amount paid to the merchant and decreasing the amount due to be returned to the consumer.
[0063] Finally, in step S110, the merchant signs the two inputs of the latest replaceable transaction and submits the transaction to the blockchain to realize the due amount paid to the merchant. Details of the replaceable transaction are shown in Figure 6A, and details of the transaction inputs and outputs, as well as the instruction codes used to unlock the replaceable transaction inputs and outputs, are shown in Figure 6B (it should be noted that in an untrusted system, the total payment to the merchant must be monotonically increased. In this way, the merchant is incentivized to submit the latest replaceable transaction to the blockchain to obtain the maximum total payment).
[0064] Details of the transaction inputs and outputs, and the instruction codes used to unlock the replaceable transaction inputs and outputs, are as follows: Input 1—Output 1 using the consumer and merchant signatures to spend funds Tx to unlock <serialized script customer>: Instruction code OP_IF <now + time N> OP_CHECKLOCKTIMEVERIFY OP_DROP <PubKey_Customer> OP_CHECKSIGVERIFY OP_ELSE <PubKey_Customer> <PubKey_Merchant> OP_2 OP_CHECKMULTISIGVERIFY OP_ENDIF Input 2 – Output 2: Using consumer and merchant signatures to spend funds Tx to unlock <serialized script merchant>: Instruction code OP_IF <now + time N> OP_CHECKLOCKTIMEVERIFY OP_DROP <PubKey_Merchant> OP_CHECKSIGVERIFY OP_ELSE <PubKey_Customer> <PubKey_Merchant> OP_2 OP_CHECKMULTISIGVERIFY OP_ENDIF Output 1 – Pay funds to the <script_hash_token> whose Hash160 is the following instruction code: Instruction code OP_1 <Metadata1> <Metadata2> <PubKey_Merchant> OP_3 OP_CHECKMULTISIG metadata1 and metadata2 are hypothetical compressed public keys containing information about the contract. This sends the token back to the merchant. Output 2 – Pay the amount owed to the merchant. This amount should monotonically increase with each new replaceable Tx. Output 3 – Pay the remaining deposit to the consumer.
[0065] If no replacement transaction is received before the lock-up period N expires, a consumer and merchant refund blockchain transaction is executed. Specifically, the consumer refund transaction generated in step S111 has a single input of the funds X spent in the funds transaction from step S105 and pays the amount X to the address specified by the consumer. The output of the consumer refund transaction only requires the consumer's signature (only the consumer's signature is required after time N). In step S112, the consumer signs the transaction and submits it to the blockchain.
[0066] Details of the consumer refund transaction are shown in Figure 7A, and details of the inputs and outputs of the consumer refund transaction and the instruction codes used to unlock the inputs and outputs of the consumer refund transaction are shown in Figure 7B.
[0067] Similarly, the merchant refund transaction generated in step S113 has a single input of the funds Y spent in the fund transaction since step S105 and pays the amount Y to the address specified by the consumer. The output of the merchant refund transaction only requires the merchant's signature (only the merchant's signature is required after time N). In step S114, the merchant signs the transaction and submits it to the blockchain. Details of the merchant refund transaction are shown in Figure 8A, and details of the inputs and outputs of the merchant refund transaction, as well as the instruction codes used to unlock the inputs and outputs of the merchant refund transaction, are shown in Figure 8B.
[0068] The details of the inputs and outputs of the consumer refund transaction, as well as the instruction codes used to unlock the inputs and outputs of the consumer refund transaction, are as follows: Input 1 – Output 1 using the consumer signature to spend funds Tx to unlock <serialized script customer>: Instruction code OP_IF <now + time N> OP_CHECKLOCKTIMEVERIFY OP_DROP <PubKey_Customer> OP_CHECKSIGVERIFY OP_ELSE <PubKey_Customer> <PubKey Merchant> OP_2 OP_CHECKMULTISIGVERIFY OP_ENDIF Note that the sequence number is not for the lock time N to be checked. Output 1 (0xFFFFFFFF) – selects the amount in output 1 from the payment funds Tx specified in the output 1, regardless of the address, to be paid to the consumer.
[0069] The details of the inputs and outputs of the merchant refund transaction, as well as the instruction codes used to unlock the inputs and outputs of the merchant refund transaction, are as follows: Input 1 — Use the merchant signature to unlock the <serialized script merchant> to spend funds Tx Output 1: Instruction code OP_IF <now + time N> OP_CHECKLOCKTIMEVERIFY OP_DROP <PubKey_Merchant> OP_CHECKSIGVERIFY OP_ELSE <PubKey Customer> <PubKey_Merchant> OP_2 OP_CHECKMULTISIGVERIFY OP_ENDIF Note that the sequence number is not for the lock time N to be checked. Output 1 – Selects the amount in Output 2 (regardless of address) to pay the specified funds to the merchant. The merchant can choose to use one of these outputs to recast the symbol. Example 1
[0070] In the following example, the merchant is a hotel that provides Internet access, and the consumer is a hotel guest who wishes to purchase Internet access.
[0071] The hotel has router management software that allows it to set bandwidth, download, and time limits for different IP / MAC addresses. To profit from internet access, the hotel provides the following services to its guests: Service Number Bandwidth limitations Download restrictions Time limit Locked deposit* Minimum payment* rate* 1 30 Mbps 2 GB 24 hours 4,500,000 (~$18) 2,250,000 (~$9) 1,125 / MB (~$0.0045) 2 30 Mbps 1 GB 24 hours 2,500,000 (~$10) 1,250,000 (~$5) 1,250 / MB (~$0.005) 3 10 Mbps Unrestricted 2 hours 6,000,000 (~$24) 3,000,000 (~$12) 25,000 / minute (~$0.1) 4 10 Mbps Unrestricted 1 hour 3,750,000 (~$15) 1,875,000 (~$7.5) 31,250 / minute (~$0.125) *The unit is Satoshi. The USD value is estimated at $400 / BTC. Other setup details: The hotel has a private or public key H with 1 BTC (100,000,000 Satoshi). Guests have a private or public key G with 0.06 BTC (6,000,000 Satoshi). The hotel has its own server where its stored tokens or contracts reside. It also has its own intranet website used to display available tokens or contracts. Steps: 1. The hotel creates a contract for each of its four services. The hotel saves the contract as a PDF and stores it on its server. 2. The hotel creates metadata1 and metadata2 for each of its four contracts. The format is as follows: Field Name Number of bytes describe metadata1 Contract Link 32 32-character link to the contract metadata2* Contract Hash 20 RIPEMD (SHA256 (Contract File)) The remaining 12 bytes of metadata2 are only zeros. 3. The hotel establishes a minting transaction that tokenizes 5 contracts. a. Note that for simplicity, only 4 tokens are created here. In practice, multiples of each service or token could be created.
[0072] Details of the casting transaction are shown in Figure 9A, and details of the transaction inputs and outputs, as well as the instructions for the casting transaction outputs to pay funds, are shown in Figure 9B.
[0073] The details of the input and output of the transaction, and the output of the minting transaction, regarding the instruction code that pays the funds, are as follows: Output 1 – P2PKH. Pay the remaining funds back to the hotel's address H. Output 2 – P2SH (Token 1). Pay 1,000 Satoshi to the hash <script_hash_token3> of the instruction code. Instruction code OP_1 <Metadata1> <Metadata2> <PubKey H> OP_3 OP_CHECKMULTISIG metadata1 and metadata2 are hypothetical compressed public keys containing information about contract 1. Outputs 3 through 5 – P2SH. Same as output 2, but the postfix data points to a different contract. 4. The hotel submits the minting transaction to the blockchain. 5. The hotel displays the token and contract on its intranet website for guests to view. 6. The hotel's guests browse the intranet to view internet access options and decide to choose service 3. The guests use token 3 and establish a financial transaction according to the associated contract 3.
[0074] Details of the fund transaction are shown in Figure 10A, and details of the input and output of the fund transaction and the instruction codes used to unlock the input and output of the fund transaction are shown in Figure 10B.
[0075] The details of the inputs and outputs of the funds transaction, and the instruction codes used to unlock the inputs and outputs of the funds transaction, are as follows: Input 2—A copy of the token details on the hotel's corporate intranet website. Requires a complete hotel signature. Output 1—P2SH. Pay 3,000,000 to the hash of the instruction code <script_hash_guest>: Instruction code OP_IF <now + 48hrs> OP_CHECKLOCKTIMEVERIFY OP_DROP <PubKey G> OP_CHECKSIGVERIFY OP_ELSE <PubKey G> <PubKey H> OP_2 OP_CHECKMULTISIGVERIFY OP_ENDIF The locked funds can be claimed by the guest within 48 hours if unspent. Output 2 – P2SH. Pay 3,001,000 to the hash of the instruction code <script_hash_hotel>: Instruction code OP_IF <now + 48hrs> OP_CHECKLOCKTIMEVERIFY OP_DROP <PubKey H> OP_CHECKSIGVERIFY OP_ELSE <PubKey G> <PubKey H> OP_2 OP_CHECKMULTISIGVERIFY OP_ENDIF
[0076] The locked funds can be reclaimed by the hotel within 48 hours. This is the minimum due payment according to Contract 3 and the value of the token itself. 7. The guest sends the fund transaction to the hotel via a form on the company's intranet website. 8. The hotel checks the fund transaction, approves it by signature, and submits it to the blockchain. 9. The hotel provides the guest with details of internet access. Alternatively, the token may contain machine-executable instructions for automatically enabling and terminating internet access. 10. The guest begins using the internet. Connection time and downloads are tracked by the router management software. 11. The router management software detects that the connection has been in use for 1 minute. The router management software sends a payment request to the guest. The guest creates an alternative transaction sent to the hotel:
[0077] Details of the replaceable transaction are shown in Figure 11A, and details of the transaction inputs and outputs, as well as the instruction codes used to unlock the replaceable transaction inputs and outputs, are shown in Figure 11B.
[0078] The details of the transaction inputs and outputs, and the command codes used to unlock the replaceable transaction inputs and outputs, are as follows: Inputs 1 to 2 – Spending Funds Transaction Outputs. Requires a complete hotel signature Output 1 – P2SH. Send the token back to the hotel. Pay 1,000 to the hash <script_hash_token3> of the command code Output 2 – P2PKH. 3,000,000 owed to the hotel + 25,000 / minute × 1 minute Output 3 – P2PKH. 6,000,000 (payment to the hotel) change given to the guest 12. While the guest is connected to the internet, the router management software continuously increments the connection timer and sends a payment request every minute. The guest simply updates the replaceable transaction outputs 2 and 3 to the latest amount and sends them to the hotel. 13. At the end of the 2 hours according to Contract 3, the hotel signs the latest replaceable transaction and commits it to the blockchain. The guests have used a total of 70 minutes, so output 2 is 4,750,000 and output 3 is 1,250,000.
[0079] Those skilled in the art will understand that the above embodiments are for illustrative purposes only and have no limiting meaning, and various changes and modifications can be made without departing from the scope of the invention as defined in the appended claims. [Simplified Explanation of the Diagram]
[0043] Figure 1 is a schematic diagram illustrating the operation of a known one-way micropayment channel; Figure 2 is a schematic diagram illustrating the operation of a one-way micropayment channel embodying the present invention; Figure 3 illustrates the blockchain symbolization process in the method of Figure 2; Figures 4A to 8B illustrate blockchain transactions in the micropayment channel of Figure 2; and Figures 9A to 11B illustrate blockchain transactions in Example 1.
Claims
1. A computer-implemented method for performing an exchange or executing a contract via a blockchain, the method comprising the steps of: submitting a funds transaction to the blockchain network, wherein the funds transaction: i) contains a symbolic (smart) contract relating to an asset transferred from a second user to a first user; and ii) is signed by the first user; sending one or more subsequent transactions from the first user to the second user, wherein each subsequent transaction consumes an output of the funds transaction and is signed by the first user; submitting one of the subsequent transactions to the blockchain network, the submitted transaction being signed by the second user.
2. The computer implementation method for performing an exchange or executing a contract via a blockchain as described in claim 1, wherein the method is a method for implementing or executing a micropayment channel on a blockchain.
3. A computer-implemented method for performing exchanges or executing contracts via a blockchain as described in claim 1 or 2, wherein the plurality of subsequent transactions are generated sequentially.
4. A computer-implemented method for performing an exchange or executing a contract via a blockchain as described in claim 1 or 3, wherein the financial transaction or subsequent transaction includes transferring some value, asset, or funds to the output (TxO) of the first user.
5. A computer-implemented method for performing exchanges or executing contracts via a blockchain as described in claim 4, wherein each subsequent transaction returns a smaller value, funds, or assets to the first user.
6. A computer-implemented method for exchanging or executing contracts via a blockchain as described in claim 1, wherein the symbolic (smart) contract is a symbol representing the contract or its location.
7. A computer-implemented method for exchanging or executing contracts via a blockchain as described in claim 6, wherein the symbolic (smart) contract is a machine-executable smart contract.
8. A computer-implemented method for performing an exchange or executing a contract via a blockchain as described in claim 1, wherein the symbolic (smart) contract is generated by an asset provider.
9. A computer implementation method for exchanging or executing contracts via a blockchain as described in claim 1, wherein the symbolic (smart) contract is provided in data following the instruction code.
10. A computer-implemented method for performing an exchange or executing a contract via a blockchain as described in claim 9, wherein the symbolic (smart) contract is provided in the locking instruction code of the blockchain transaction.
11. A computer-implemented system configured to perform a computer-implemented method for performing an exchange or executing a contract via a blockchain as described in any one of claims 1 to 10, the system comprising: A blockchain network; And at least one computer-based resource configured to generate a blockchain transaction or submit a blockchain transaction to a blockchain network.