Universal tokenisation system for blockchain-based cryptocurrencies

Universal token system based on blockchain cryptocurrency

Universal Tokenisation System for Blockchain-based Cryptocurrencies

The present invention relates to a solution for the control and/or transfer of assets or the transfer of asset ownership, and particularly relates to methods of creating, transferring ownership and redeeming tokens representing assets. The present invention discloses a special application that creates tokens associated with transactions on a peer-to-peer distributed ledger, such as the Bitcoin blockchain, which can represent contract rights, smart contracts, or other forms of assets.

Commercial transactions may involve the transfer of property rights, and these rights may include real property or personal property (including tangible and intangible property). In addition, the contract between the two parties may also include the contractual rights that bind the parties. In the digital economy, it may be expected to conduct transactions over a reasonable period of time and over long distances. This expectation and practical limitations mean that traditional forms of transfer of property transfer, such as the actual delivery of hard copies of files representing contracts or negotiable bills, etc. , Or tangible property itself is not desirable. Recently, blockchain is used to transfer digital assets.

Blockchain is an electronic ledger, which is implemented as a computer-based decentralised, distributed, and peer-to-peer system. It is composed of blocks composed of transactions, and each transaction (Tx) is a data structure , Which encodes the transmission of control of digital assets between participants in the blockchain system, and includes at least one input and at least one output. Each block contains the hash value of the previous block, which links the blocks together to create a permanent and unchangeable record of all transactions that have been written to the blockchain since its establishment. Transactions include scripts embedded in their inputs and outputs, i.e. small programs, which specify who can access the output of the transaction and how. On the Bitcoin platform, these scripts are written in a stack-based scripting language.

Writing transactions into the block must be "verified". The network nodes (miners) perform this work to ensure that each transaction is valid and reject invalid transactions from the network. The software client installed on the node performs this verification on an unspent transaction (UTXO) by executing its lock and unlock script. If the calculation result of the execution of the lock and unlock script is TRUE, the transaction is valid and the transaction is written into the blockchain. Therefore, in order to write a transaction to the blockchain, it must i) be verified by the first node that receives the transaction if the transaction is verified, the node will relay it to other nodes in the network; and ii) add it to the miner In a new block constructed; and iii) Mining, that is, adding to the public ledger of past transactions.

Although blockchain technology is most widely used in cryptocurrency execution, digital entrepreneurs have begun to explore the use of bitcoin-based cryptocurrency security systems and data that can be stored on the blockchain to implement new systems. If blockchain can be used for automated tasks and processes that are not limited to the field of cryptocurrency, it will be very beneficial. This solution will be able to take advantage of the blockchain's advantages (such as permanent, tamper-proof event recording, decentralized processing, etc.), while being more versatile in its applications.

The current research area is the use of blockchain to implement "smart contracts", which are computer programs designed to automatically execute machine-readable contracts or agreement terms. Unlike traditional contracts written in natural language, smart contracts are machine executable programs that include rules that can process inputs to produce results, and then perform actions based on these results.

Another area of interest associated with blockchain is the use of "tokens" (or "colored coins") to represent and transmit real world or virtual entities through the blockchain. Represents a potentially sensitive or secret item, which has no discernible meaning or value. Therefore, the token is used as an identifier that allows the resource to be referenced from the blockchain.

Any discussion about archives, behaviors, materials, devices, articles, etc. that have been included in this specification should not be considered as an admission that any or all of these matters form part of the prior art basis, or as the priority of each claim of the present invention The common knowledge in the field related to the disclosure of the present invention that existed before the right date.

In this invention, we use the term "blockchain" to include all forms of electronic, computer-based peer-to-peer distributed ledgers. These include, but are not limited to, consensus-based blockchain and transaction chain technologies, permissioned and unallocated ledgers, shared ledgers and their variants. Although other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. Although Bitcoin is used in the present invention for the convenience of description, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and agreements fall within the scope of the present invention.

In this specification, the word "include" or "include" represents or implies the state of including elements, integers, steps, or groups of steps, elements or integers, but does not include the exclusion of any other elements, integers or steps, or elements , Integer, or group of steps.

The following provides inventions as defined in the scope of the appended application.

The present invention can provide a solution for the security control and/or transfer of assets or rights through the blockchain. Additionally or alternatively, it can realize the control and/or transfer of ownership of assets or rights. This may be a digital or virtual asset, such as a smart contract or a real world/physical asset. The present invention can use tokenization technology to facilitate such control or transfer. The invention combines the use of encrypted currency keys to perform transmission in a safe manner, without any changes to the underlying blockchain protocol.

The present invention particularly provides: the use of hash technology to enhance the optimization of the use of electronic transmission memory, improve security and data integrity, improve security by eliminating the need for a trusted third party, and enhance the anonymity of data. The advantages listed above are not limiting or exhaustive.

The present invention may require the interaction and intercommunication of various and independent computer-based resources, such as one or more user devices and a distributed computer system (blockchain), which includes software for executing blockchain-related software and The compute node of the agreement.

The present invention may provide a method including the following steps: Generate a blockchain transaction (Tx), which includes a hash of an output (TxO) associated with a digital asset and a redeem script, including: The plural metadata includes a token, a tokenized entity for representing or reference; and at least one public key (preferably two or more).

The digital asset (B1) can be a quantity of cryptocurrency, such as Bitcoin. The redemption script is provided in one of the lock scripts of the transaction output TxO. The metadata can provide the location of the encryption key in the location specified in the blockchain protocol in the redemption script.

The method further includes submitting the transaction Tx to a blockchain. In fact, the encrypted currency (B1) can therefore be locked on the blockchain associated with the token. When providing an unlocking script that meets the requirements of the locking script for outputting TxO, only the amount of (redeemed) cryptocurrency (B1) can be used. In particular, redemption must be provided when the hash matches the hash value provided in the locking script of TxO script. Since the lock script used to output the TxO includes the hash value of the redemption script, which in turn includes the token (in the metadata), the encrypted currency (B1) is associated with the token. When the correct unlocking (redemption) script is presented, the ownership of the encrypted currency (B1) can be transmitted to the redeeming party or user, for example, to be spent.

The terms "expenditure", "transfer", "redemption" or "transfer of ownership/control" are used interchangeably in the present invention. In addition, the term "user" can be used to refer to human users or machine-based resources.

The public key can be associated with the corresponding private key to form an encryption key pair, and the corresponding private key may be required to unlock the transaction output (TxO) so that the digital asset and/or its ownership can be transmitted. The tokenized entity can be stored in or off the blockchain, and it can be a digital asset, such as a (smart) contract or some other form/type of asset or entity. The token can be provided in the redemption script to be interpreted as an encryption key for the blockchain protocol. Therefore, the underlying blockchain agreement may have nothing to do with the existence of the token and/or other metadata provided in the redemption script. However, as a user of the method of the present invention, the metadata can be interpreted and used as a token.

Therefore, the present invention may include embodiments that enable cryptocurrency to be executed via a blockchain and issue a digital token to a user in a secure manner, provide a corresponding system for implementing the method of any of the above embodiments, and Including the blockchain network and associated nodes.

Now providing subsidiary features or embodiments of the present invention, at least one feature described in the embodiments of the present invention may relate to one or more other aspects or embodiments.

The present invention provides a computer-based method for creating a first token (T1) using an issuer (I), wherein the first token (T1) is associated with a first amount of digital asset (B1), which is encrypted And can be transmitted electronically.

The above method further includes at least one step: receiving a request for a first token (T1) from a first user (A) through a communication network; determining a first user public key (P1A), wherein the first user (P1A) The user public key (P1A) and a first user private key (V1A) form an encrypted pair; allocate the first amount of digital assets (B1) associated with the first token (T1); determine a first A first hash (H1) of a redemption script (RS1), the first redemption script (RS1) is based on: at least one first metadata (MD1), which includes information related to the first token (T1) Linked information; the first user public key (P1A); and a first publisher public key (P1I) associated with the publisher (I), which is formed with a first publisher private key (V1I) An encrypted pair; sending a first data output (O1) to a peer to peer distributed ledger through the communication network, including: an instruction to trade the first amount of the digital asset (B1) To the first user (A); and the first hash (H1), which is associated with the first amount of the digital asset (B1), and provides the first user (A) and the publisher ( I) The associated first token (T1).

Determine a first hash (H1) of a first redemption script (RS1), the first redemption script (RS1) is based on at least one first metadata (MD1), which includes the first token (T1) ) Associated information, the first user public key (P1A), and a first publisher public key (P1I) associated with the publisher (I); a first data output (O1 ). First, because the information about the token is securely embedded in the public edge such as the blockchain, it provides the security of data transmission while avoiding the need for trusted third parties, because the transaction party can rely on the public The verification method locks the details of the associated transaction. In addition, the anonymity of the transaction is preserved, and since the first redemption script is hashed, it is impractical to change the metadata value without causing the corresponding hash value of the redemption script to change. It also provides the advantage that the first metadata can be embedded in the available one or more locations of the public key of the redemption script, so that nodes that are not suitable for processing metadata can easily transfer the redemption script to another node. Stop its progress. This in turn improves the computational efficiency of associated transactions. A further advantage is that metadata can contain indicators pointing to the terms and conditions of the contract, so that the information can be stored in an off-block library (off-block In the repository), since the transaction processing does not need to transmit its physical transaction history, it can reduce the processing volume and the amount of memory resources, and at the same time enable the detailed information of the associated transaction to be reliably verified. Another advantage is that control data can be incorporated into metadata, for example, an access code of a barrier can be expressed as a token of a ticket such as a venue, travel ticket, or voucher. Another advantage is that the tokens can be divided to achieve two or more transaction outputs, each of which can be associated with a tokenized or non-tokenized digital asset.

The first data output (O1) can easily record payment to script hash transactions.

In this method, the step of receiving a request from the first user (A) of the token (T) may include receiving an offer or accepting a contract. The step of receiving a request from the first user (A) of the token (T) may also include receiving at least one or more terms and conditions of the contract.

The method may also include sending at least one or more terms and conditions of the contract to the first user (A).

The information in the first metadata (MD1) contains a hash of a contract with at least one or more conditions and clauses. The information in the first metadata (MD1) includes one or more information: a contract type; one or more conditions and clauses of a contract; an indicator pointing to the terms and conditions of a contract; and how to implement the Transaction information.

The method further includes storing the first redemption script (RS1) in a data store.

In this method, the format of the first redemption script (RS1) includes: <NumSigs MD1...P1A P1I...NumKeys OP_CHECKMULTISIG> where NumSigs is the number of signatures required to redeem the first token (T1); NumKeys is the redemption The total number of public key slots in the script, including the metadata and the public keys; and OP_CHECKMULTISIG is the operation of performing signature comparison in the order of the public key slots.

The method further includes determining whether the first user (A) has an account (ACA) of the issuer (I) to execute the transaction associated with the first token (T1), if the first user (A) does not have the account, the method further includes: sending a request to the first user (A) to open an account (ACA) through a communication network, wherein the account (ACA) is related to the first user (A) The encrypted pair of the user (A) is associated, and the encrypted pair includes the first user private key (V1A) and the first user public key (P1A).

In the method, the step of allocating the first amount of the digital asset (B1) associated with the first token (T1) includes: determining a first token value (TV1) of the first token (T1) ); Determine a fixed price rate (PR1) (pegging rate) of the first token (T1); and determine the value of the digital asset (B1) based on the fixed price rate and the first token value (TV1) The first quantity.

In an alternative solution, the step of allocating the first amount of the digital asset (B1) associated with the first token (T1) includes: determining the value of the digital asset (MT1) of the first token (T1) A minimum threshold; and determining a first amount of the digital asset (B1), the first amount equals or exceeds the minimum threshold of the digital asset (MT1).

A computerized method for redeeming a first token (T1) associated with a first amount of digital asset (B1) according to the method of creating a first token (T1), the method including the issuer : Receive a redemption request for the first token (T1) from a first user (A) through the communication network; determine the first redemption script associated with the first token (T1) (RS1); receive the first user private key (V1A); use the first user private key (V1A) and the first publisher private key (V1I) to sign the first redemption script (RS1) , To unlock the first amount of the digital asset (B1) associated with the first token (T1); and send a second data output (O2) to the point-to-point distributed ledger through the communication network, It includes an instruction to the issuer (I) to trade the first amount of the digital asset (B1).

In the method of redeeming a first token (T1), the first token (T1) has a token value of the first part (R1) and the second part (R2), wherein the first user (A) The request for redeeming the first token (T1) includes a request for redeeming a value of the first part (R1), and the method further includes: determining the first user public key (P1A) ; Allocate a second amount of the digital asset (B2) associated with a second token (T2), wherein the second token has a second token value (TV2) based on the second part (R2) ). The method further includes determining a second hash (H2) of a second redemption script (RS2), wherein the second redemption script (RS2) is based on: at least one second metadata (MD2) based on the The first metadata (MD1) at least partially associated with the first token (T1); the first user public key (P1A); and a first issuer public key associated with the issuer (I) (P1I). In this method, the second data output (O2) to the public ledger further includes: an instruction to trade at least one second amount of the digital asset (B2) to the first user ( A); and the second hash (H2), which is associated with the second amount of the digital asset (B2), and provides the first user (A) and the publisher (I) associated with the first Two tokens (T2).

A computer-implemented method that uses an issuer (I) to create a third token (T3), wherein the third token is associated with a value transmitted by a first token (T1), and a first token (T1) is created according to the above A token (T1) method, the method includes: receiving a request from the first user (A) and/or the second user (B) through the communication network to create the third token (T3) ); determine the first redemption script (RS1) associated with the first token (T1); receive the first user private key (V1A); use the first user private key (V1A) and the The first issuer private key (V1I) signs the first redemption script (RS1) to unlock the first amount of the digital asset (B1) associated with the first token (T1). The method further includes determining a second user public key (P1B), which forms an encryption pair with a second user private key (V1B); assigning a third amount of the digits associated with the third token Assets (B3). The method further includes determining a third hash (H3) of a third redemption script (RS3), the third redemption script is based on: at least one third metadata (MD3), at least a part of which is established with the first A token (T1) is associated with the first metadata (MD1); the second user public key (P1B); and the first issuer public key (P1I). The method also includes outputting a third data (O3) through the communication network The transmission to the peer-to-peer distributed ledger includes: an instruction to trade at least one of the third amount of the digital asset (B3) to the second user (B); and the third hash (H3) with the A third amount of the digital asset (B3) is associated, and the third token (T3) associated with the second user (B) and the issuer (I) is provided.

In the method of creating a third token (T3), the first token (T1) has a token value of the first part (R1) and the second part (R2), and the third token is created The request of (T3) includes a request to create the third token (T3) with a third token value (TV3) based on the first part (R1). The method further includes: judging the public of the first user Key (P1A); allocate a second amount of the digital asset (B2) associated with a second token (T2), wherein the second token (T2) has a second part (R2) based The second token value (TV2). The method further includes determining a second hash (H2) of a second redemption script (RS2), wherein the second redemption script (RS2) is based on: at least one second metadata (MD2) based on the The first metadata (MD1) at least partially associated with the first token (T1); the first user public key (P1A); and a first issuer public key associated with the issuer (I) (P1I). In this method, the third data output (O3) to the peer-to-peer distributed ledger further includes: an instruction to trade at least one second amount of the digital asset (B2) to the first user (A); And the second hash (H2), which is associated with the second amount of the digital asset (B2), and provides the second token associated with the first user (A) and the issuer (I) (T2).

In the method of creating a third token (T3), the step of allocating a second amount of the digital asset (B2) includes: judging a predetermined price rate (PR2) of the second token (T2) ( pegging rate); and judging the second amount of the digital asset (B2) based on the predetermined price rate (PR2) and the second token value (TV2).

In the method of creating a third token (T3), the step of allocating a second amount of the digital asset (B2) includes: judging a minimum threshold of the digital asset (MT2) of the second token (T2) Value; and determine the second quantity of the digital asset (B2), the second quantity is equal to or exceeds the minimum threshold of the digital asset (MT2) of the second token (T2).

In the method of creating a third token (T3), the second quantity of the digital asset (B2) and/or the third quantity of the digital asset (B3) at least partly includes the first quantity of the digital asset (B1).

In the method of creating a third token (T3), it further includes: judging a fourth amount of the digital asset (B4) as a transaction fee; wherein the first data output to the peer-to-peer distributed ledger ( O1), the second data output (O2) and the third data output (O3) further include: an instruction to use a transaction of the fourth amount of the digital asset as a transaction fee.

In the above method, the peer-to-peer distributed ledger includes the Bitcoin blockchain.

A computer-implemented method for redeeming a first token (T1) associated with a first amount of digital asset (B1) as defined above, the method includes the issuer: through the communication network, from a first token (T1) A user (A) receives a request for redemption of the first token (T1); determines the first redemption script (RS1) associated with the first token (T1); transmits the redemption script (RS1) through the communication network The first redemption script (RS1) signed by the first user (A); a first redemption signed by the first user (RS1A) using the first user's private key (V1A) is received via the communication network Back to the script; using the first issuer's private key (V1I) to sign, the first redemption script signed by the first user (RS1A) will be associated with the first token (T1) of the first amount of the number The asset (B1) is unlocked; and a second data output (O2) is sent to the peer-to-peer distributed ledger through the communication network, including the transaction of the first amount of the digital asset (B1) to the publisher (I) One instruction.

A computer execution method for an issuer (I) to create a third token (T3), which is based on the above-mentioned method for creating a first token (T1), wherein the third token and a first token (T1) The method includes the following steps: through the communication network, receiving a request from the first user (A) and/or the second user (B) to create the third token (T3). ); determine the first redemption script (RS1) associated with the first token (T1); transmit the first redemption script (RS1) signed by the first user (A) through the communication network ; Receive a first redemption script signed by the first user (RS1A) using the first user's private key (V1A) through the communication network; use the first publisher's private key (V1I) to sign, and the first redemption script is signed by the first user (RS1A) A first redemption script signed by a user (RS1A) unlocks the first amount of the digital asset (B1) associated with the first token (T1); and determines a second user public key (P1B) , Which forms an encryption pair with a second user private key (V1B); allocates a third amount of the digital asset (B3) associated with the third token; determines a third redemption script (RS3) A third hash (H3) of, the third redemption script is based on: at least one third metadata (MD3), at least part of which is based on the first metadata associated with the first token (T1) (MD1) on; the second user public key (P1B); and the first publisher public key (P1I); a third data output (O3) is sent to the point-to-point distributed ledger through the communication network, Including: an instruction to trade at least one third amount of the digital asset (B3) to the second user (B); and the third hash (H3), which is combined with the third amount of the digital asset (B3) ) Is associated to provide the third token (T3) associated with the second user (B) and the issuer (I).

The present invention can also provide a tokenization method, which can be implemented using a decentralized peer-to-peer network (such as a blockchain). Therefore, the present invention can take advantage of all the known advantages of blockchain technology. The present invention can provide an improved solution for securely transferring data items via a blockchain platform, which can be described as a solution for effectively and securely transferring tokens on, for example, a blockchain.

The method can provide a solution for representing a contract for the supply of at least one asset and/or service. The contract may be a negotiable contract.

The present invention does not limit the nature, type, quantity, etc. of the assets and/or services transferred by the contract. This method can provide a coding scheme for any type of transferable contract for tokenization.

The method may include the step of generating a blockchain transaction, and the transaction may include three parameters or data items. This information may indicate: i) the number of shares available under the contract (this may be referred to as "NumShares" in the present invention); ii) the number of transfer units to be transmitted from the sender to at least one receiver (this can be It is called "ShareVal" in the invention); and iii) the factor used to calculate the value of the number of transfer units (this may be called a "pegging rate" in the present invention).

One of the advantages of the present invention is that the contract can be encapsulated or expressed on the blockchain as a token, which can only be achieved by using the above three parameters. In fact, the minimum of these three data items can be used to specify the contract. Since the present invention provides a solution that can be used for any type of transferable contract, common algorithms can be designed and applied.

These three data items can be provided as metadata in the transaction. Advantageously, only a small amount of metadata (in bits) is required to represent any type of contract, so the present invention provides an efficient and effective method for transferring tokens on a peer-to-peer distributed system such as a blockchain. Effective and powerful mechanism.

The information may also include instructions for the availability of assets, that is, the goods and/or services provided under the contract. Additionally or alternatively, it may include instructions for the type and/or quantity of assets or services provided under the contract.

The transaction may actually include a fourth parameter or data item, which represents the specific asset being transferred, such as a house or horse race associated with the transaction.

The method may also include the step of sending the transaction to at least one recipient (or an address associated with the at least one recipient).

Transactions may include contracts; and/or access to contracts or access to information about files containing contracts. This provides the facility to transfer the contract or information corresponding to the file location of the contract through the block link.

The transaction can include a hash of the contract, which provides the advantage of a means to verify the authenticity of the contract.

The transaction may include at least one cryptographic signature, which provides the advantage of determining the source of the transaction.

The transaction may include at least one locking script and at least one public key, providing the advantage of preventing the contract from being redeemed by persons other than the intended recipient of the transaction.

The transfer unit may be associated with cryptocurrency, but may or may not be associated with Bitcoin. The transfer unit can be the amount of Bitcoin, and the blockchain can be the Bitcoin blockchain, which provides the advantage that this method can be implemented on the existing infrastructure.

Therefore, the present invention provides a simple and effective solution for safely transferring contracts on the blockchain.

A computer program includes a plurality of machine-readable instructions so that a processing device can implement the above method.

A device includes a processing device that executes a method according to any of the above methods.

<b>System Overview</b>

The present invention provides a system and method for creating, redeeming and transferring tokens. The system 1 shown in Figure 1 includes an issuer (I) 3, a first user (A) 5, and a second user (B)7. The issuer (I)3 generates a token, which can be, for example, a bank, another financial institution, a mint, a company, etc. The publisher (I) 3 is associated with the first processing device 12 and communicates with a communication network 8 to execute the methods 100, 200, and 300. Although the first processing device 13 is described as a single node, the methods 100, 200, In 300, it can also be executed by more than one processing device 13 or a plurality of nodes associated with the publisher (I) 3, and at least one step can be executed on a different node. The publisher (I) also has an associated data store 11.

The first user (A) 5 is associated with a second processing device 15 and communicates with the first processing device 13 of the publisher (I) 3 through a communication network 8. The first user (A) 5 can request The issuer (I) 3 creates a token, redeems the token from the issuer (I) 3, or requests to transmit part or all of the token value to the second user (B) 7.

The second user (B) 7 is associated with a third processing device 17 and communicates with the first processing device 13 through a communication network 8. In some embodiments, the second processing device 15 and the third processing device 17 may be computers, mobile communication devices, or other electronic devices used by the first and second users 5 and 7 respectively. In other embodiments, the second processing device 15 and the third processing device 17 are virtual machines, and the first and second users access through terminals or other interfaces.

The point-to-point distributed ledger 9 is also described to record transactions. This point-to-point distributed ledger 9 is associated with at least one processing device 19 to receive and record transactions. For example, the point-to-point distributed ledger includes a blockchain. It is a distributed database of transactions based on the Bitcoin protocol, so the ledger associated with the processing device 19 can be a processing device used by "miners".

<b>Overview of transactions involving tokens</b>

In a non-limiting embodiment, the token has three general types of transactions, as shown in Figure 2. In this embodiment, the issuer (I) also manages the first user (A) 5 and the second user. (B)7 is the financial institution of the electronic wallet.

The first type of transaction is shown in Figure 2(a), which is used to create a first token (T1), in which the first user (A) transfers legal currency (for example, 1,000 Australian dollars) to the issuer (I )3. In order to exchange currency, the issuer (I) "tokenizes" the first amount of cryptocurrency (B1) so that it has a token value, and transmits the first amount of cryptocurrency (B1) to The first user (A)5. The first token (T1) may represent a contract, such as a contract in which the issuer (I) agrees to redeem the holder of the first token (T1) with a specific monetary amount (for example, 1,000 Australian dollars). Therefore, the first token (T1) can be similar to a negotiable ticket. "Cryptocurrency" refers to encrypted, electronically transmittable digital assets, such as but not limited to Bitcoin.

The second type of transaction, as shown in Figure 2(b), is that the first user (A) 5 and the issuer (I) 3 redeem the first token (T1) 3. In this transaction, the first user (A)5 sends the first amount of cryptocurrency (B1) to the publisher (I)3 in return, and the publisher (I)3 redeems the value in the form of legal tender sent to the first user (a) 5, transfer to the publisher (I) of a first quantity of money encryption 3 (B1) may be used in other subsequent transactions. Whether the first amount of cryptocurrency (B) with the issuer (I)3 remains "tokenized" or converted to "untokenized" cryptocurrency may be the issuer (I)3's choice.

The third type of transaction is shown in Figure 2(c), where the first user (A) 5 transmits the value of the first token (T1) to the second user (B). In this embodiment, the encrypted currency (B1) representing the first amount of the first token (T1) is transferred from the first user (A) 5 to the second user (B) 7. When the publisher (I) needs to sign a redemption script (detailed later), the publisher (I) 3 authorizes the transaction. The result of this transaction is that the second user (B)7 with the first amount of cryptocurrency (B1) has a token value, which can be "consumed" with the issuer (I)3 (similar to the above Way) or transfer to another user.

In some cases, only a part of the value of the first token (T1) can be consumed by the first user (A)5, which will be described in the fourth type of Figure 3(a) and Figure 3(b) And the fifth type of transaction, this is the change of the above-mentioned second and third types of transaction. In these embodiments, the first token (T1) has a total token value consisting of the first part (R1) plus the second part (R2), and the first user (A) 5 wants to "spend" The first part (R1), and the second part (R2) is returned as a change.

The fourth transaction type is shown in Figure 3(a). The first user (A) 5 has a first amount of cryptocurrency (B1), which represents the first token (T1) of the previous transaction. The first user (A) then sends a certain amount of cryptocurrency through the token value of the first part (R1) to redeem the first part (R1) of the token (T1), and returns to represent the first part (R1) Value. Since only the first part (R1) is redeemed, the remaining second part (R2) stays at the first user (A) 5, displaying the second amount of cryptocurrency (B2) as a token with one value Representing the second part (R2), in one embodiment, the second amount of cryptocurrency (B2) is the first amount of cryptocurrency (B1) that reduces the amount transmitted to the issuer (I)3.

The fifth transaction type is shown in Figure 3(b). The first user also has a cryptocurrency (B1) representing the first amount of the first token (T1) from the previous transaction. Next, the first user (A) sends a third amount of encrypted currency (B3) with the value of the first part (R1) as a token to send the first part (R1) of the token (T1) to The second user (B) 7 only transmits the first part (R1), so the remaining second part (R2) is consistent with the first user (A) 5. The second amount of cryptocurrency (B2) is displayed as a token with one value, representing the second part (R2). In an embodiment, the second amount of encrypted currency (B2) and the third amount of encrypted currency (B3) can be derived from the first amount of encrypted currency (B1).

Next, embodiments of the above-mentioned transaction types will be described.

<b>The first transaction type-the issuer generates a first token (T1) to the first user (A)</b>

One of the non-limiting embodiments of the method of the present invention application includes a first user (A) 5 who deposits a legal currency amount (for example, 1,000 Australian dollars) to the issuer (I) (for example, a financial institution), and the issuer ( I) Create the first token (T1) to the first user (A) 5. The first token (T1) represents the value of the deposited currency. According to specific terms and conditions, the first user (A) 5 can redeem the value associated with the stored currency in the first token (T1) at a future date, and the terms and conditions may also allow the first user (A) 5 has at least a part of the token value transferred to the second user (B). These terms and conditions may be token-specific, or may be general terms and conditions between the user 5, 7 and the issuer (I) 3.

<b>Outline the method of creating a token</b>

Next, please refer to FIGS. 2(a) and 4, which describe an embodiment of the method 100 for creating the first token (T1) by the first processing device 13 at the issuer (I)3. The method 100 includes receiving 110 a request for a first token (T1) from a first user (A) 5 through a communication network 8. The method further includes determining 120 the first user public key (P1A) that forms an encrypted pair with the first user private key (V1A).

The method 100 includes step 130, allocating a first amount of cryptocurrency (B1) associated with the first token (T1), and the method 100 further includes step 140, determining the first hash (H1) of the first redemption script (RS1) ), where the first redemption script (RS1) is based on: at least the first metadata (MD1), which includes information associated with the first token (T1); the first user public key (P1A); and the release A first issuer public key (P1I) associated with the person (I), wherein the first issuer public key (P1I) and the first issuer private key (V1I) form an encryption pair.

The method 100 further includes step 150 of sending a first data output (O1) to the peer-to-peer distributed ledger 9 through the communication network 8. The first data output (O1) includes: an instruction, a transaction of a first amount of cryptocurrency (B1) To the first user (A) 5; and the first hash (H1), wherein the first hash (H1) is associated with the first amount of cryptocurrency (B1) to provide the first user (A) 5 The first token (T1) associated with the issuer (I).

Therefore, the method 100 allows the creation of a token, and the record of the token will be sent to the peer-to-peer distributed ledger 9. The advantage of recording transactions on the peer-to-peer distributed ledger 9 is that it allows the recipient (such as the first user (A) 5) to verify the existence of the token (T1). In addition, since at least the first metadata (MD1) including the information associated with the first token (T1) is hashed, the transaction (on the public record) can be verified based on the information associated with the token, in an implementation In an example, the message associated with the first token (T1) may be the terms and conditions of the contract. Therefore, including the terms and conditions in the first redemption script to be hashed can advantageously provide comfort for the first user (A)5 (or any other user), and the terms and conditions cannot be changed because any changes will Change the first hash (H1). Since the first hash (H1) is sent and recorded on the peer-to-peer distributed ledger 9 when the first token (T1) is created, it is impossible (or difficult) to change the terms and conditions at a later time, and The same first hash (H1) will be provided.

Next, a detailed embodiment of the issuer (1) 3 creating a token to the first user (A) 5 will be described, including the initial registration process 400.

<b>Registration method 400</b>

FIG. 5 shows the registration method 400. The method 100 may include step 312 of determining whether the first user (A) 5 has an account with the publisher (I). In particular, this may include determining whether the first user (A) 5 has an account suitable for facilitating transactions associated with the first token (T1).

If the first user (A) 5 does not have an account, the method may further include step 314 of sending a request through the communication network 8 to open the account of the first user (A). The request to open an account may include sending general details of the terms and conditions of the publisher's (I) account to the first user (A) 5, and requesting the first user (A) 5 to accept the terms and conditions. It also includes sending a request for details about the first user (A) 5.

In addition, sending a request to open an account may also include sending a request to generate an encryption pair, the encryption pair including the first user key (V1A) of the first user (A)5 and the first user public key (P1A) . In some embodiments, it may include sending a request to another node associated with the issuer (I) to generate a first user key (V1A) and a first user public key (P1A), and another node generates The first user key (V1A) and the first user public key (P1A) are then sent to the first user (A) 5. In other embodiments, it may include sending a request to the first user (A) 5 to generate the first user private key (V1A) at the second processing device 15 associated with the first user (A) 5 ) And the first user public key (P1A). It should be understood that these keys associated with the first user (A) 5 can be generated by the above-mentioned methods or other methods, as long as the first user key (V1A) remains secure and only in the first user (A) 5 Just go on.

The first user (A) 5 can receive the request to open an account in step 714, and send the account opening information to the publisher (I) 3 in step 716.

The registration method 400 may also include creating 316 an electronic wallet associated with the account of the first user (A) 5, and storing information associated with the electronic wallet and the account in the data storage 11.

In some embodiments, the first user private key (V1A) can be stored in an electronic wallet, and the first user private key (V1A) can only be accessed by the first user (A) 5 after authorization. For example, the electronic wallet may include a plurality of private keys associated with the first user (A)5, when the first user successfully and securely logs in to the publisher (I)3 (such as a virtual machine environment or a terminal) , The first user's private key can be activated. Then, the first user (A) 5 can selectively authorize the publisher (3) to retrieve and use these private keys from the data storage 11 for transactions. In some embodiments, the user private key is not stored in the electronic wallet, but can be recreated by the issuer (I) 3 with authorization from the visible user. In yet another embodiment, the user's private key may be a separate key, the electronic wallet has a part, and the user has the remaining part, so that they can be combined to recreate the private key.

In other embodiments, the first user key (V1A) can be kept separate from the issuer (I), the first processing device 13 and the data storage 11, for example, the first user (A) 5 can The hard copy of the user's private key (V1A) is stored in the safe or secure part of the personal electronic device, computer or storage device.

It should be understood that the steps in the method 400 may be performed during the method 100, for example after the step of receiving the request 110 for the first token (T1) from the first user (A) 5. In other embodiments, the method or registration 400 may be performed in advance.

<b>The detailed method of creating token 100</b>

The method 100 for creating the first token (T1) is shown in Figures 2(a), 4, and 6 (which respectively show the method 100 and the method performed by the issuer (I) 3 and the first user (A) 5 500). In this embodiment, the creation of a token will be discussed in the context of the first user (A) 5, and the first user (A) 5 deposits a token representing cash to the issuer (I) 3. However, it should be understood that this is a non-limiting embodiment, and the token can be created in the context of other transactions. For example, the token can represent any other contract, negotiable instrument, tangible property, etc., and can represent a barrier. The transferable attribute of the access code is, for example, a token that can represent a venue or travel ticket or coupon.

<b>Agree to the terms and conditions of the token</b>

After or before the registration method 400, the first user (A) 5 may send a request for the first token (T1) in step 510. In one embodiment, the first user (A) 5 makes a request by depositing legal currency (for example, $1000 Australian dollars), and requires the amount of token (T1).

In one embodiment, the request sent by the first user (A) 5 may include a contract offer, and the discount may include one or more terms and conditions of the contract. For example, the first user (A) 5 may include a token associated with a deposit of 1000 Australian dollars in the request, and its cryptocurrency should have a fixed fixed price rate, for example, the fixed price rate is 1000 satoshi / cent (Australian dollar) request. It should be noted that other terms and conditions may be included in the quotation, such as account retention fees, transaction fees, how to redeem tokens, etc.

As shown in Figure 6, the first processing device 13 of the issuer (1) receives a request for the first token (T1) from the first user (A) 5 through the communication network 8, and in some cases, Receive at least some terms and conditions. The issuer (I) can then determine whether to accept the request in step 112, submit a request including the modification of the requested terms and conditions, or reject the request. The method 100 then includes a step 112 of sending the result of the determination in step 112 on the communication network 8.

Then in step 520, the first user (A) 5 can receive the judgment result of step 112 through the communication network 8, which includes acceptance, counter offer, and rejection request.

In an alternative embodiment, the request sent to the issuer (I) in step 510 may simply include a request for the first token (T1). In this case, the publisher (I) may send an offer including terms and conditions to the first user (A) 5. The first user (A) 5 can conversely determine whether to accept the offer, make a counter offer, or reject the offer, and then send it to the publisher (I).

It should be understood that steps 510, 520 and 110, 112, 114 can be modified to send and receive multiple rounds of proposals and counter quotations between the publisher (I) and the first user (A) 5 until the two are consistent. .

In some alternatives, the terms and conditions can be standardized, whereby the user accepts the terms and conditions by performing the steps in the methods 100 and 500. In an embodiment, the issuer (I) may provide their customers (including the first user (A) 5) with standardized quotations for tokens. Such token offers can be publicly listed, for example on public exchanges or on the publishers website. Private publishers (I) can also provide permanent discounts privately by email, by applying or logging on to a secure website.

The terms and conditions associated with the token can be stored in the data storage 11 and sent to a third party for storage or activation.

<b>Determine the public key of the first user 120</b>

The method 100 includes step 120, determining the first user public key (P1A). In one embodiment, the first user public key (P1A) can be transmitted from the first user (A) 5 to the publisher (I) through the communication network 8. In another embodiment, the first user public key (P1A) may be associated and stored in the data storage 11 (for example, it may be received and stored during the registration of the first user (A) 5). Therefore, the step 120 of determining the first user public key (P1A) includes retrieving the key from the data storage 11. In another embodiment, the first user public key (P1A) may be received from a third party through the communication network 8. The third party may include, for example, a trusted third party used as a public directory, such as a certificate authority.

<b>Allocate the first amount of cryptocurrency to associate with the token 130</b>

The method 100 includes a step 130 of allocating a first amount of cryptocurrency (B1) associated with a first token (T1). In order to record the transaction of the first token (T1) in a peer-to-peer distributed ledger (blockchain in this embodiment), the token must be associated with a certain amount of cryptocurrency. Conversely, this amount of cryptocurrency is used as a transaction record from the issuer (I) 3 to the first user (A) 5 on the peer-to-peer distributed ledger. In other words, the blockchain transaction Tx is submitted to the blockchain network to be included in the ledger. Tx includes an output that can be used to transfer the cryptocurrency (or its ownership/control) from a party (such as the issuer) The quantity is sent to the other party (for example, the first user).

The allocation for the first amount of cryptocurrency (B1) associated with the first token (T1) may be based on a ratio of token values. For example, a pegging rate (PR1) can be specified for the first token (T1). Therefore, the step of distributing 130 the first amount of encrypted currency (B1) may include determining the first amount of encrypted currency (B1) based on the predetermined price rate (PR1) and the first token value (TV1). Taking a practical example to illustrate, the fixed price rate (PR1) can be 1000 satoshis/cent Australian dollars, and the first token value (TV1) is $1000 Australian dollars. Therefore, the first amount of cryptocurrency (B1) can be 10,000,000 .

The amount of cryptocurrency to be allocated for the token may be affected by the following considerations. First, the allocated cryptocurrency quota ideally has a market value (which means the market value of the cryptocurrency itself, assuming that it has a value and does not refer to the token value) is less than the value of the token (token value). This is desirable, so there is no incentive to use the base value of the encrypted currency as a token. It can be similar to a cash coin. It is expected that the face value of the coin is higher than the metal minted by the coin, and the value of the metal can be obtained without melting the coin. In some embodiments, the token value is several times greater than the underlying value of the cryptocurrency amount. However, it should be understood that some tokens may not have a fixed or easily judged token value. For example, the token may represent a contract to perform work, and thus the value may change day by day. In other examples, the contract may only be worth judging on the day of redemption.

Another consideration is that the amount of cryptocurrency allocated should not be too large relative to the value of the token or the value of the transaction, because transactions that record the amount of cryptocurrency on a peer-to-peer distributed ledger may have a cost, such as transactions. cost. In some embodiments, the transaction fee is based on the amount of cryptocurrency in the transaction, so it is advisable to keep the amount of cryptocurrency of the token to a minimum.

On the other hand, the number of passwords allocated for association with the token cannot be infinitely small. First, cryptocurrency may have the smallest denomination. For example, Bitcoin has a minimum amount of one satoshi (where 1 Bitcoin (BTC) = 10,000,000 satoshi); secondly, cryptocurrency transactions may be restricted to the smallest amount, otherwise it will not be recorded (Or the cost of the transaction will approach or exceed the cost of executing the transaction). In some embodiments, this minimum amount is a "dust" limit. Therefore, in some embodiments, a certain amount of cryptocurrency allocated to the token must be higher than the minimum threshold of cryptocurrency (MT1). Therefore, the method 100 may include determining a minimum threshold (MT1) of cryptocurrency suitable for the first token (T1), and determining a first amount of cryptocurrency (B1) that is equal to or higher than the minimum threshold (MT1) of cryptocurrency. In one embodiment, the minimum threshold (MT1) of the cryptocurrency in "Bitcoin" is 546 satoshis.

Another consideration for the number of cryptocurrencies for allocating tokens is the divisibility of the number of cryptocurrencies for subsequent tokens. For example, the first token (T1) may have a token value (TV1) of $1000 Australian dollars, and the first user (A) 5 may wish to transmit the token value of $800 Australian dollars to the second user (B) 7, And reserve the remaining $200 Australian dollar tokens. Such a transaction will involve a transaction with the first token (T1). The transaction of the first token (T1) generates a second token (T2) representing $200 Australian dollars. User (A) 5 keeps the same, and then creates a third token (T3) representing $800 Australian dollars and transfers it to the second user (B) 7. Therefore, the result of this transmission is two tokens, the second token (T2) and the third token (T3), each of which must also be allocated a certain amount of encrypted currency, if the first amount of encrypted currency Currency (B1) is the smallest, such as the "dust" limit, you need to withdraw a larger amount of cryptocurrency in order to create a sufficient amount of cryptocurrency to meet the minimum threshold for each new token. Therefore, allocating a sufficient amount of cryptocurrency (B1) to the first token (T1) has the advantage that the amount is sufficient to be divided for the expected number of subsequent tokens.

In one embodiment, the terms and conditions may specify the amount of cryptocurrency or the minimum or denomination of the token. For example, the terms and conditions can set the minimum face value of the token value to $10 Australian dollars. Therefore, allocating the first amount of encrypted currency (B1) to the first token (T1) with a token value of $1000 Australian dollars (TV1) may include: judging the first amount to determine if it is divided into the smallest denomination, the entire order The card value (TV1) has enough cryptocurrency. In this embodiment, the token value (TV1) can be divided into 100 subsequent tokens (calculated by $1000 / $10). Therefore, the appropriate first amount of cryptocurrency (B1) is 100 times the "dust" limit.

<b>Determine the first hash (H1) 140 in the first redemption script (RS1)</b>

The method further includes determining 140 the first hash (H1) of the first redemption script (RS1). In one embodiment, the hash of the redemption script can be used to provide a fee to the script hash (P2SH) address for the paid script hash transaction. This embodiment includes the hash function used by the P2SH script in the Bitcoin protocol, which may include a combination of SHA 256 and RIPEMD160.

The first redemption script (RS1) is a script that can be used to unlock the first token (T1). As described later, it includes a transaction of the first amount of encrypted currency (B1). When unlocking the first token (T1), certain conditions of the first redemption script (RS1) must be met to unlock the transaction. In particular, the signatures of the first user (A) 5 and the publisher (I) are required. One embodiment of the first redemption script (RS1) will now be described.

<b>The first redemption script (RS1)</b>

The first redemption script (RS1) is based on: at least one first metadata (MD1), including those associated with the first token, the first user public key (P1A), and the first issuer public key (P1I) News.

<b>(i)</b><b>Generally redeem scripts in P2SH</b>

As a background, in the payment script hash method, the redemption script may take the following form: &lt;NumSigs PubK1 PubK2... PubK15 NumKeys OP_CHECKMULTISIG&gt; where NumSigs - the number of valid signatures required to satisfy the redemption script to unlock the transaction "m" PubK1, PubK2 ... PubK15-is the public key, corresponding to the signature to unlock the transaction (up to 15 public keys) NumKeys-is the number of public keys "n" (must be 15 or less)

To unlock the above redemption script, at least "m" signatures corresponding to the public key are required. In some embodiments, the order of the public keys is important, and the number "m" in the "n" signatures used for signing must be done in order. For example, if there are two "m" and the number of public keys "n" is fifteen, two signatures can be used, such as Sig1 (corresponding to PubK1) and Sig 15 (corresponding to PubK15). The redemption script must Signed by Sig1 first, then Sig15.

<b>(ii)</b><b>Use P2SH's first redemption script (RS1)</b>

Returning to this embodiment, the first redemption script (RS1) using P2SH may include at least the first metadata (MD1) in the redemption script. In particular, at least the first metadata (MD1) can be embedded in one or more of the 15 locations available for the public key in the redemption script.

Therefore, in an embodiment, the first redemption script (RS1) can take the following form: &lt;NumSigs Metadata1 Metadata2 ... PubK1 PubK2 ... NumKeys OP_CHECKMULTISIG&gt; where NumSigs is required to satisfy the redemption script to unlock the transaction The number of valid signatures "m" Metadata 1 and Metadata 2-including the metadata PubK1 and PubK2 that replace the public key-are the actual public keys. In one embodiment, PubK1 can be the public key of the first user (P1A), and PubK2 can be the public key of the publisher (P1I) NumKeys-the total number of bits occupied by the metadata and the public key (must be 15 or less )

The advantage of this approach is that the metadata will be included in the first redemption script (RS1), and this script will be hashed, and its records will be included in the peer-to-peer distributed ledger 9. Therefore, if not impossible, it will be difficult to change the value of the metadata without changing the corresponding hash of the first redemption script hash (RS1).

The actual advantages can be illustrated by the following examples. The first user (A)5 and the issuer (I)3 may wish to sign a contract with specific terms and conditions. The contract may include the issuer (I) creating a token, where specific terms and conditions are included in the redemption Metadata in the script. Then, the hash of the redemption script is recorded on the peer-to-peer distributed ledger 9, which becomes a transaction record that is difficult or unchangeable. Say that the publisher (I) tries to deceive the first user (A)5, for example, tries to modify a term and claims that the modified term is in the original contract, then the first user (A)5 can modify The term of is placed in the metadata of the redemption script and hashed, and then it is shown that this does not match the redemption script recorded on the peer-to-peer distributed ledger. Therefore, it may be useful to include information associated with the token in at least the first metadata to ensure the integrity of the token.

It should be understood that the metadata in the redemption script itself may include a hash of other information. For example, if the terms and conditions are lengthy, a hash of terms and conditions can be used to provide shorter metadata.

The first redemption script (RS1) can be stored as a record in the data storage 11 and used to redeem the first token (T1). In some alternative embodiments, the first redemption script may be sent to the first user (A) 5 or a third party.

<b>Metadata</b>

In this embodiment, the first redemption script (RS1) takes the following form: &lt;2 Metadata1 Metadata2 P1A P1I 4 OP_CHECKMULTISIG&gt;

Therefore, at least the first metadata (MD1) includes metadata 1 and metadata 2 occupying two positions in the redemption script, followed by two public keys, including the first user public key (P1A) and the first publisher public key. Key (P1I). NumSigs is 2, which means that two signatures are required to unlock the transaction.

Metadata can include information about the token in a variety of ways. As discussed, in one embodiment, terms and conditions can be included in the metadata; in another embodiment, a hash of terms and conditions can be included in the metadata. In the data; in another embodiment, the metadata may include pointers to files containing the terms and conditions of the contract; in another embodiment, a combination including one or more of the above may be included in the metadata .

<b>(i)</b><b>Has metadata pointing to terms and conditions</b>

Table 1 below is a specific example of the first metadata (MD1)<tables><table><img wi="758" he="200" file="tw201732705a_d0001.tif" img-content="drawing" img-format="jpg" orientation="portrait" inline="no" /></table></tables>Table I

This embodiment includes the minimum amount of information associated with tokens and transactions, including providing an indicator that points to the contract, which may be useful if the size of the contract excludes details included in the metadata. In addition, since the metadata can be made public or transmitted through an insecure network, it is advisable to cover up or hide the specific details of the token for reasons of privacy.

The first 4 bits of metadata indicate the type of contract. For example, the type of contract may be "legal currency"; the next 16 bits are the IP address of the location where the actual electronic contract file is stored, and IPv6 addresses are allowed. It should be noted that in some embodiments, the value can point to the seed file, so that the contract file can be distributed on the cloud instead of being centralized. The next 12 bits contain data specific to the type of contract.

The first 20 bits of metadata 2 are a hash of the actual contract file using RIPEMD160 on the SHA256 applied to the file. Since the actual contract file is searchable, it allows transaction verification based on the contract. Please note that, depending on the requirements of specific embodiments, the contract file itself may be completely public (unencrypted and human-readable) or may be encrypted for privacy. The remaining 12 bits of metadata 2 can be used according to the type of contract.

<b>(ii)</b><b>Metadata with key parameters of the token</b>

The following table two is another specific embodiment of the first metadata (MD1)<tables><table><img wi="732" he="298" file="tw201732705a_d0002.tif" img-content="drawing" img-format="jpg" orientation="portrait" inline="no" /></table></tables>Table II

In this embodiment, some key parameters of the token included in the metadata can include information associated with the token itself or information that can assist in processing transactions. In particular, the bits allocated to the sub-field "ContractTypeData1" in Table 1 above have been used to order: par value, set price rate, and transaction type.

Importantly, the key parameters included in the metadata can help improve processing efficiency, because in some cases, the issuer (I)3 can process the tokens in the transaction without retrieving what is needed to process the transaction The contract file for the key information of.

In addition to the above information, it may also include other information about the history of the token or the token before the token. For example, if the first user (A) 5 wishes to redeem part of the first token (T1), and the issuer (I) creates a second token (T2) to represent the value of the remaining part, the issuer can The information is embedded in the metadata to associate the second token (T2) with the first token (T1). This may help the issuer (I) consider and track tokens without the cost of tracking transaction history, which is an intensive task for issuers (I) such as banks.

In Table 2 above, the metadata includes a 2-bit field, representing fiat currency (FiatDenomination), and a 1-bit field, called PeggingRate. The fixed price rate is set by the publisher (I), the same currency It can be set to different interest rates, but different tokens (different contracts) will be required for each different interest rate. The issuer (I) can decide the choice of interest rate by himself, but for the distribution of the number of cryptocurrencies of the token, who can take considerations similar to the set price rate is as described above.

In one embodiment, PeggingRate is an 8-bit coded value, as shown below: The leftmost bit is used as a sign: 1 = interest rate expressed in satoshis / cent ("cent" refers to one-hundredth of legal tender, That is, the lowest average) 0 = The rightmost seven digits of the ratio expressed in centimeters/satoshi represent the tens digits of the binary system, for example: 10000010 USD means 100 percentages/percentage (the sign is on) PHP 00000000 means 1 centavo / satoshi (Flag closed) IDR 00000001 means 10 rupees/satoshi (Flag closed)

In one embodiment, TransactionType is a 1-bit field, which represents whether the transaction is an "issuance" (where the token is created from a cryptocurrency); a payment (where at least part of the token value is from a The user transfers to another user); or a redemption (where the token is transferred to the issuer (I) and converted into conventional hidden currency).

In some embodiments, "Padding" in metadata 1 and metadata 2 may include a randomly generated value for each transaction. The result is that Metadata 1 and Metadata 2 will change between transactions. This advantage is that it can reduce the risk and motivation of unscrupulous people trying to determine the private key. One or both of metadata 1 or metadata 2 is used as an encryption pair, and the private key will match it (the purpose is to use the private key To sign the redemption script). It may be important that most of the remaining tokens in Metadata 1 or Metadata 2 are the same standardized tokens.

<b>Public key</b>

The first user public key (P1A) and the publisher public key (P1I) are respectively paired with the corresponding first user private key (V1A) and the publisher private key (P1I). It should be understood that the public key may be widely disclosed, and in other embodiments, it may be desirable to transmit the public key on demand. In any case, only the public key needs the redemption script, because the corresponding private key is only required when signing and unlocking the redemption script (for example, when redeeming a token).

As mentioned above, in some alternatives, the first user 5 and the second user 7 can access their electronic wallets through a virtual machine environment or terminal. )3 The associated server) is hosted, where the private key of the corresponding user is stored in the data storage 11, but it can only be accessed (or recreated) by the publisher (I)3 authorized by the user. In this case, the first user 5 and the second user 7 may authorize the provision of their private keys to the issuer (I) 3 to unlock the redemption script, which may include authorized users private keys to be sent to the issuer ( I) The first processing device 13 of 3. The first processing device 13 can unlock the redemption script and the first issuer public key (P1I) with the user's private key (such as P1A, P1B).

<b>Output the first data</b><b>(O1)</b><b>Send to a peer-to-peer distributed ledger</b><b>150</b>

The method 100 further includes a step 150 of sending a first data output (O1) to the peer-to-peer distributed ledger transmitter via the communication network 8. The first data output (O1) may include an instruction to the first user (A) 5 of the first amount of encrypted currency (B1) transaction, in other words, record the underlying data associated with the first token (T1) The encrypted currency (B1) has been sent to the first user (A)5. The first data output (O1) also includes the above-mentioned first hash (H1). The first hash (H1) is associated with the first amount of cryptocurrency (B1) to provide a connection with the first user (A) 5 and the publisher (I) The record of the associated first token (T1).

Importantly, the first hash (H1) is on the peer-to-peer distributed ledger 9, which can be used to prove or verify the existence of the token (T1), the relationship between the issuer (I) and the first user (A) 5 , And/or the terms and conditions of the token.

The method may further include step 160, storing the first redemption script (RS1) in the data storage 11 for later use.

Then please refer to the specific embodiment of the transaction for creating the first token (T1) described in Figure 2(a).

<b>First user</b><b>(A)5</b><b>To the publisher</b><b>(I)</b><b>Deposit</b><b>1000</b><b>Australian dollar, used for the equivalent value in the token</b>

In this embodiment, the first user (A) 5 wants to deposit $1000 Australian dollars to the issuer (I), and the issuer (I) creates a first token (T1), which has a token value of 1000 Australian dollars. (TV1), which is associated with the first amount of cryptocurrency (B1) of 10,000,000.

In order to create a token, the issuer (I) needs to have an encryption mechanism, which can come from a previous transaction, or from a request from the first user (A) 5 for the first token (T1), as shown in Figure 2(a) "The first amount (undeveloped) cryptocurrency" shown on the left side of .).

Table 3 below is an original transaction output, displayed in the form of transaction ID / Satoshis number / locked script. The original transaction output represents the cryptocurrency obtained by the issuer (I) from the previous exchange, and using at least some of the cryptocurrency will be used in the encryption mechanism associated with the first token.<tables><table><img wi="230" he="118" file="tw201732705a_d0003.tif" img-content="drawing" img-format="jpg" orientation="portrait" inline="no" /></table></tables>Table Three

The first line "ID-201" is the transaction identification code used to identify this transaction. The next line is the number of satoshis in this transaction, which is 50,000,000. The third line is the lock script (output script) of this transaction. The redemption script in this output &lt;PubK-Issuer hash&gt; shows that the output has been locked by the public key of the first issuer (P1I), and the corresponding issuer can be used The first issuer's private key (V1I) to unlock the transaction.

As described above, the method 100 includes allocating a first amount of cryptocurrency (B1) suitable for the first token (T1). However, the number of cryptocurrencies owned by the publisher (I) may not exactly match the first number of cryptocurrencies (B1). In this embodiment, the required first amount of cryptocurrency (B1) is 10,000,000, which is much lower than the 50,000,000 in transaction ID-201.

Therefore, the transaction to create the first token (T1) will include the provision of the change of the cryptocurrency to the issuer (I), and the change of the amount of excess cryptocurrency not needed by the token.

In addition, the token creation 100 may be a transaction that requires payment of transaction fees to miners. Please refer to Table 4 below to describe the transaction used to create the token.<tables><table><img wi="400" he="382" file="tw201732705a_d0004.tif" img-content="drawing" img-format="jpg" orientation="portrait" inline="no" /></table></tables>Table Four

The first line "ID-210" is the transaction identification code used to identify this transaction. The second line indicates the "version number" of the Bitcoin protocol version used. The third line represents the number of inputs for this transaction, which represents a single input.

The fourth to seventh rows in Table 4 above are related to "input", that is, the transaction of the previous transaction ID-201 (that is, the current transaction fund ID-210). The fourth line is the transaction identification code of the previous transaction. The fifth line "IDX-00" is the index of the output of the previous transaction, ID-201 (in this case, the reference to the first output using the previous transaction ID-201). The sixth line "ScriptSig" is the unlocking script of the previous transaction ID-201. As mentioned above, the previous transaction was locked by the first issuer's public key (P1I), represented by PubK-Issuer. Therefore, the corresponding first issuer private key (V1I) of the issuer represented by Sig-Issuer can be used to unlock the previous transaction. The seventh line is the serial number associated with the input.

In Bitcoin transactions, every 4-digit field that contains a "serial number" will no longer be used by Bitcoin Core. According to the publisher's implementation, you can choose to use this field to assign transaction inputs to outputs. The serial number can be represented by a 1-bit token string, so starting from the rightmost bit, the position of each mark represents a part of the invested part of the funds for the output of the token. In this embodiment, the serial number "000000000000000000000000000000011" indicates that the input will be delivered to the outputs 1 and 2, which will be described below.

Row 8 in Table 4 shows the output quantity of this transaction, which is two in this embodiment. Lines 9 to 11 represent the first output, and lines 12 to 14 represent the second output.

The first output reflects the first amount of cryptocurrency (B1) associated with the first token (T1). Line 9 is the output value of the first amount of cryptocurrency (B1), which is 10,000,000 satoshis. Line 10 represents the length of the output script. The 11th line is the output script, that is, the lock script to lock the first amount of cryptocurrency (B1), including the first hash (H1) of the first redemption script (RS1), which is expressed as follows: OP_HASH160 &lt;redeem script hash&gt; OP_EQUAL

"OP_HASH160" is a hash function in which the input is hashed twice-with SHA-256 followed by RIPEMD-160. The redemption script hash is a hash of the first redemption script (RS1), which is in the above form, for this example: 2 metadata1 metadata2 P1A P1I 4 OP_CHECKMULTISIG

This includes the first user public key (P1A) and the first publisher public key (P1I) as described above. Metadata 1 and Metadata 2 may include the metadata as described above, including this is an instruction to "publish" a transaction. OP_EQUAL provides a Boolean result to verify the output.

The second output reflects the transaction changes of the publisher. Since the input as the previous transaction ID-201 contains 50,000,000 satoshis, the publisher (I) can expect to receive the remaining satoshis. The 12th line is the output value of the second output, which is 39,999,000. Line 13 is the length of the output script, and line 14 is the output script of the second output. Since the second output is a change returned to the publisher (I), the publisher should be free to use the second output. Therefore, the output script (ie, the lock script) only includes the first issuer public key (P1I) represented by &lt;PubK-Issuer hash&gt;.

Generally speaking, the output value of the transaction must be equal to or less than the input. In the above example, the input is 50,000,000 and the output is 49,999,000 (based on the first output of 10,000,000 and the second output of 39,999,000). Therefore, there is a deficit of 1,000 satoshis. In this example, 1,000 satoshis are transaction fees (for example, miner fees).

<b>Second category</b><b>type</b><b>trade</b><b>-</b><b>First user</b><b>(A)</b><b>Towards</b><b>announcer</b><b>(I)</b><b>redemption</b><b>Token</b>

<b>Overview of redemption tokens</b>

In this embodiment, the issuer (I) is a service provider that provides electronic wallets for users 5 and 7, where the user's private key is securely maintained in the data storage 11 associated with the issuer (I) 3. middle. Therefore, in this embodiment, the users 5, 7 (or their respective processing devices 15, 17) do not sign the redemption script. On the contrary, the redemption script is signed by the publisher (I) 3 through the authorization of the users 5 and 7, as shown in the methods 200 and 600 in Fig. 7, where the first user (A) 5 issues the redemption script to the publisher (I) ) 3 Send 610 to request to redeem the first token. Implicitly or explicitly, the request to redeem the first token also includes the first user (A) 5 using the first user private key (P1A) for the issuer (I) 3 to redeem the first order Licensing.

The method 200 includes receiving a request 610 to redeem the first token (T1) from the first user (A) 5 through the communication network 8. The method 200 includes determining 220 the first redemption script (RS1) associated with the first token (T1).

The method also includes the issuer (I) 3 receiving the first user private key (V1A) 235. In one embodiment, this includes retrieving the first user private key (V1A) from the data storage 11. It is understood that the user private key contained in the electronic wallet managed by the issuer (I) should be kept safe. In another alternative, the issuer (I) 3 may receive the first user private key (V1A) from another entity or node.

Then, the publisher can sign the first redemption script 245 with the first user private key (P1A) and the first publisher private key (P1I). This may be advantageous because the publisher (I) 3, who is the service provider of the first user (A) 5, can safely perform these steps on the first processing device 13 and does not send the first user (A) 5 through the communication network 8. A redemption script (RS1), signed or unsigned.

The method 200 also includes sending 260 a second data output (O2) to the peer-to-peer distributed ledger 9 via the communication network 8, including sending a transaction instruction of the first amount of cryptocurrency (B1) to the issuer (I).

Therefore, the method 200 returns the first amount of cryptocurrency (B1) associated with the first token (T1) to the issuer (I). In an embodiment, since the first redemption script (RS1) is simultaneously signed by the private keys of the first user (A) 5 and the issuer (I), the first amount of cryptocurrency (B1) in the transaction The recipient of is the issuer (I)3, who can pay the first amount of cryptocurrency (B1) for other transactions, whether it is a separate cryptocurrency or a token associated with another.

Next, a specific embodiment of the transaction to redeem the first token (T1) will be described.

<b>First user</b><b>(A)5</b><b>From the publisher</b><b>(I)</b><b>redemption</b><b>1000</b><b>The first token of Australian dollars</b><b>(T1)</b>

In this embodiment, as shown in Figure 2(b), the first user (A) 5 wants to use the token value to redeem the first token (T1) from the issuer (I). The transaction of the first amount of cryptocurrency (B1) from the user (A) 5 to the issuer (I) is referred to as transaction ID-510 below. In contrast, the publisher (I) provided the first user (A) with 1,000 Australian dollars of legal tender.

In this embodiment, the first token is redeemed by unlocking the first amount of cryptocurrency (B1) and transferring it to the issuer (I)3, and the first amount of cryptocurrency (B1) is transferred back to the issuer (I), the issuer (I)3 is allowed to use the first amount of cryptocurrency (B1) for future transactions. The issuer (I) 3 can also send the first amount of cryptocurrency (B1) (which may include transmitting the first amount of cryptocurrency (B1) back to the issuer (I) by removing one or more transactions of metadata 3 redemption transaction) "detokenize". The issuer (I) can further pay for this encryption mechanism without the restriction of authorization (such as signature) from the first user (A) 5 or other users.

Before describing the transaction to redeem the first token ID-510, we will briefly introduce the original transaction output (from transaction ID-210 and ID-610) that is the input of the current redemption transaction ID-510. These two inputs usually include A first amount of cryptocurrency (B1) associated with the first token (T1), and another amount of cryptocurrency used at least in part to pay transaction fees (eg, miner fees).

From the above embodiment, the first user (A) 5 receives the first amount of encrypted currency (B1) in the transaction ID-210. The output to the first user (A)5 in transaction ID-210 can be summarized in Table 5 below:<tables><table><img wi="230" he="86" file="tw201732705a_d0005.tif" img-content="drawing" img-format="jpg" orientation="portrait" inline="no" /></table></tables>Table 5

The second row in Table 5 above represents the first amount of cryptocurrency (B1) associated with the first token (T1), and the amount is in 10,000,000 satoshis. The third line represents the output script, which is equivalent to line 11 in Table 4 above. From the foregoing example, the transaction ID-210 that created the first token (T1) has two outputs, but only the first output corresponding to the first amount of cryptocurrency (B1) is related to the redemption transaction ID-510 United. The second output in transaction ID-210 has been changed to the issuer (I) shown in Table 4.

The issuer (I) also needs to pay transaction fees for redemption of transaction ID-510 (such as miner fees), which is paid for the amount of cryptocurrency received from the previous transaction ID-610. This amount of cryptocurrency can be summarized in the following table six:<tables><table><img wi="230" he="118" file="tw201732705a_d0006.tif" img-content="drawing" img-format="jpg" orientation="portrait" inline="no" /></table></tables>Table 6

The second row of Table 6 represents the number of cryptocurrencies previously traded at 9,999,000. The third row of Table 6 is the output script of the previous transaction. Since the cryptocurrency of this transaction ID-610 is not associated with the token (or the user associated with the token), the redemption script hash is only the hash value of the first issuer's public key (P1I), which is displayed as PubK-Issuer. In other words, the output of the payment transaction ID-610 only needs to be signed with the first issuer's private key (V1I).

Please refer to the transaction ID-510 for redemption of the first token (T1) discussed in Table 7 below.<tables><table><img wi="400" he="546" file="tw201732705a_d0007.tif" img-content="drawing" img-format="jpg" orientation="portrait" inline="no" /></table></tables>Table Seven

The third row of Table 7 indicates that there are two inputs, and the 14th row indicates that there are two output ID-510 in this transaction.

The first input is displayed on lines 4 to 8, and is the input of the first amount of cryptocurrency (B1) to be redeemed, which comes from the previous transaction ID-210. The fifth line is the output index of the previous transaction. The token is "IDX-00", which represents the first output of transaction ID-210 as the first amount of encrypted currency (B1). Line 7 shows that ScripSig represents the first amount of cryptocurrency (B1) allowed to be paid. This indicates that the first redemption script (RS1) requires two of the four signatures, especially the first user private key (V1A) and the first publisher private key (V1I) for signing.

The second input shown in lines 9 to 13 is shown in the previous transaction ID-610 used to fund the current transaction ID-510. The ScriptSig on line 12 needs to be signed with the first publisher's private key (V1I) of the previous output script containing the first publisher's public key (P1I).

Lines 15 to 17 show the first output, which has an output of 10,000,000 satoshis, corresponding to the first amount of cryptocurrency (B1) of the first token (T1). The output script is located on line 17, and the corresponding redemption script is: 1 metadata1 metadata2 PubK-Issuer 3 OP_CHECKMULTISIG

The redemption script includes metadata from the first token and the issuer public key (P1I) shown as PubK-Issuer. This redemption script requires one of three signatures to pay 10,000,000 satoshis. In fact, the first issuer's private key (V1I) can be used to sign and spend the cryptocurrency for subsequent transactions. It is worth noting that the first user public key (P1A) is not included in this redemption script, because this amount of cryptocurrency has been redeemed by the issuer (I), so it may be considered as the first user (A). ) 5 spent. Therefore, the publisher (I) should be free to spend this amount of encrypted currency without authorization (for example, implicit authorization by the signature of the first user (A) 5).

Then, the publisher 3 can use the publisher's public key (P1I) to perform another transaction from the output script (line 17) to redeem the redemption script, so that further transactions generate an output script without metadata.

Although the above first output retains the metadata of the first token (T1) in the redemption script, it should be understood that in some alternatives, when the first token (T1) has been redeemed, the metadata The data does not need to be included in the first output and is therefore "untokenized". In other words, by removing the corresponding first and/or second metadata (MD1/MD2), the first token (T1) can be used to disassociate the first amount of encrypted currency (B1) during a redemption transaction. In addition, it should be understood that the output script may be in other forms specified by the publisher (I).

Lines 18 to 20 show the second output, which has 9,998,000 satoshis outputs. This is the opposite of the input corresponding to transaction ID-610 with 9,999,000 satoshis. The difference of 1,000 satoshis reflects the miner fee for this transaction.

<b>The fourth category</b><b>type</b><b>trade</b><b>-</b><b>First user</b><b>(A)</b><b>Towards</b><b>announcer</b><b>(I)</b><b>Redeem the first part</b>

<b>Redeem the first token</b><b>(T1)</b><b>Part of the value</b>

In the above embodiment, the first user (A) 5 redeems the entire value of the first token (T1). However, in some embodiments, the first user (A) 5 may wish to redeem only part of the value of the first token (T1).

Please refer to Figure 3(a) and Figure 8. The first token (T1) has a token value that can include the sum of the first part (R1) and the second part (R2). Therefore, the first user (A) 5 A request to redeem the value of the first part (R1) of the first token (T1) can be sent 610 through the communication network 8. The issuer (I) 3 receives a request 210 from the first user (A) 5 to redeem the first token (T1) through the communication network 8. Then, the issuer can perform the redemption for the first token (T1) as described above. Steps 220, 230, 240, and 250 of the token (T1).

However, since the first user (A) 5 has requested to redeem the value of the first part (R1) of the total token value (T1), the remaining value of the second part (R2) will need to be allocated to the second order The card (T1) is returned to the first user (A) 5. Please refer to the second token described in Figure 8.

The first user (A) 5 can send the first user public key (P1A) to the issuer (I) 3 through the communication network 8 to create a second token (T2). Next, the method 200 includes the issuer (I) determining the first user public key (P1A) 255 from the first user (A) 5. It should be understood that the issuer (I) may already have the first user public key (P1A) from a previous transaction (or electronic wallet), and in this case, it may not be necessary to have the first user (A) 5 again Send the first user public key (P1A). Otherwise, the first user public key (P1A) can be received from the data storage 11 and/or a third party.

In another alternative, the first user (A) 5 may wish to use a different encryption pair for the second token (T2). Therefore, the step of sending 645 and determining 255 the first users public key may include the first The user public key is different from the first user public key associated with the first token (T1).

Next, the method 200 includes allocating 265 a second amount of cryptocurrency (B2) associated with a second token (T2), wherein the second token has a second token value (TV2) based on the second part (R2) . The step of distributing 265 the second amount of cryptocurrency (B2) may include considerations similar to those of distributing the first amount of cryptocurrency (B1) described above.

In some embodiments, the fixed price rate (PR2) of the second token (T2) is the same as the fixed price rate (PR1) of the first token (T1), which may be the first user (A)5 It is expected that the terms and conditions of the first token (T1) and the second token (T2) remain unchanged, except for the quality of the token value.

In other embodiments, the second amount of cryptocurrency (B2) may need to be equal to or higher than the minimum threshold (MT2) of a cryptocurrency, which is different from the minimum threshold (MT1) of the cryptocurrency of the first token (T1) . Therefore, allocating 265 the second amount of cryptocurrency (B2) may include determining the minimum threshold (MT2) of the cryptocurrency of the second token (T2), and determining that the second amount of cryptocurrency (B2) is equal to or higher than the first The minimum threshold (MT2) of the cryptocurrency of two tokens (T2).

The method 200 further includes determining a second hash (H2) 275 of the second redemption script (RS2), wherein the second redemption script (RS2) is based on: at least one second metadata, at least partly based on the first token (T1) The associated first metadata (MD2); the first user public key (P1A); and the first publisher public key (P1I) associated with the publisher (I).

The at least one second metadata (MD2) may include, for example, an association with one or more terms and conditions of the first token (T1). Therefore, although the second token (T2) has a different token value from the first token (T1), it may have the same or similar characteristics as the first token (T1). In some specific embodiments, the at least one second metadata (MD2) of the second token (T2) is the same as at least the first metadata (MD1) of the first token. In this embodiment, the second redemption script (RS2) of the second token (T2) is the same as the first redemption script (RS1) of the first token (T1). Therefore, the second hash (H2) associated with the second token (T2) is also the same as the first hash (H1) associated with the first token (T1). This may be advantageous because by comparing it with the first hash (H1) of the first token (T1), the second hash (H2) of the second token (T2) can be easily verified. This can also reduce the storage space associated with storing the second hash (H2) (or subsequent hashes) because they will be the same.

As mentioned above, in some alternatives, the first user public key (P1A) used for the second token (T2) may be different from the first user public key associated with the first token (T1), and Similarly, the first issuer public key (P1I) of the second token (T2) associated with the issuer (I) may also be different. For example, for security reasons, the publisher (I) and/or the first user (A) 5 may wish to use different encryption pairs.

In this embodiment, the step 260 of sending a second data output (O2) to the peer-to-peer distributed ledger via the communication network may also include sending a second amount of encrypted currency (B2) instruction to the first user ( A) 5 and the second hash (H2), where the second hash (H2) is associated with a second amount of cryptocurrency (B2) to provide a correlation with the first user (A) 5 and the publisher (I) The second token of the union (T2). Therefore, the first user (A) 5 is provided with a second token (T2) based on the value of the second part (R2), and in some embodiments has similar characteristics to the first token (T1).

Figure 3(a) shows an example of the first part of the redemption. The first user (A) 5 redeems the first token (T1) to the issuer (I), including a request to redeem the first part (R1) of the first token (T1), where the first part is equivalent to A currency of $500 Australian dollars. As a reply, the issuer (I) 3 provides 500 Australian dollars of legal currency and a second amount of encrypted currency (B2) to provide the first user (A) 5 with a second token (T2). The second amount of cryptocurrency (B2) is associated with a second token that can represent the value of the second part (R2) of 500 Australian dollars.

<b>The third type of transaction</b><b>-</b><b>First user</b><b>(A)</b><b>Transfer value to second user</b><b>(B)</b>

<b>from</b><b>First user</b><b>(A)</b><b>arrive</b><b>Second user</b><b>(B)</b><b>of</b><b>Value transfer</b><b>Summary of</b>

The present invention also includes a method 300 for creating one or more additional tokens by the issuer, as shown in FIG. 9. These additional tokens can be created to transmit the first token (T1) to the second user (B), such as the value of the first token (T1) desired by the first user (A) 5 or a part thereof. This can be achieved by creating a third token (T3) associated with the second user (B) 7 and the issuer (I) 3.

This may advantageously allow the first user (A) 5, in fact, to transmit the same or similar rights associated with the first token (T1) to the second user (B). Although the new token is created in the form of the third token (T3), the third token (T3) has many similarities with the first token (T1). For example, different tokens may have the same or similar associated metadata. This may be useful, for example, if the same or similar terms and the conditions that apply between the first user (A)5 and the publisher (I)3 should also apply to the second user (B)7 and the publisher (I) Between 3.

In some cases, as shown in Figure 2(c), the first user (A) 5 may wish to transmit at least a part of the value of the first token (T1) to the second user (B). In one embodiment, this is through a transaction of a first amount of cryptocurrency (B1) associated with the first token (T1) from the first user (A) 5 to the second user (B) 7 accomplish. In the transaction where the entire value of the first token (T1) is transferred to the second user (B) 8, this may involve the third token (T3) created with the first amount of cryptocurrency (B1), The third token is transmitted to the second user (B) 7. The third token (T3) can effectively transmit the first token (T1) and the authority associated with the first token (T1) to the second user (B) 7.

In this embodiment, the value transfer from the first user (A) 5 to the second user (B) involves the publisher (I) 3 as an intermediary to promote the transfer, which is the same as the transfer from the first user (A) 5 The direct transaction of the first amount of cryptocurrency (B1) to the second user (B) 7 is different. For many reasons, value transfer involving the issuer (I) may be advantageous. First of all, compared with using the first amount of cryptocurrency (B1), the issuer (I) reduces the transmission and consumption of the first user (A) 5 of the first amount of cryptocurrency (B1) as an ordinary cryptocurrency Risk, the token is prevented by requiring the issuer (I) to sign a redemption script. Second, the issuer (I) may allow the issuer (I)3 to track tokens and specific rights and/or responsibilities related to specific users. This may be useful for accounting, financial reporting, and/or regulatory purposes.

Please refer to the example of sending this value as described in Figures 2(c) and 9, where the methods are 300, 700, and 800 respectively by the publisher (I) 3, the first user (A) 5 and the second user (B)7 execution. The first user (A) 5 can send 710 a request to create a third token (T3) through the communication network 8, wherein the third token (T3) is associated with the first token (T1). In combination or alternatively, the second user (B) 7 can send 810 a request to create a third token (T3) through the communication network 8. These requests are sent by one or both of the first user (A) 5 and/or the second user (B) 7, depending on the terms and conditions of the first token (T1).

Next, the issuer (I) receives a request to create a third token (T3) through the communication network 8. It should be understood that the requests from the first user (A) 5 and the second user (B) can be sent via the other party in the communication network 8. In addition, the requests can be scattered, with some requests coming from the first user (A)5 and the other part coming from the second user (B)7.

The method 300 includes determining 320 a first redemption script (RS1) associated with the first token (T1).

The method 300 also includes receiving 335 the first user private key (V1A). In one embodiment, this includes retrieving the first user private key (V1A) from the data storage 11. The method also includes the issuer (I)3 signature 345, wherein the user private key (P1A) and the first issuer private key (P1I) are in the first redeem script (redeem script). Steps 335 and 345 are similar to steps 235 and 245 in the method 200 for redeeming the first token (T1) described above, and similar considerations are also applicable.

The creation of the third token (T3) requires the second user public key (P1B), this second user public key (P1B) and the second user private key (V1B) form an encrypted pair, the issuer (I)3 The 360 second user public key (P1B) can be determined in a variety of ways. First, the publisher (I) 3 can be the service provider of the second user (B) 7, and the second user public key (P1B) can be stored in the data storage 11 of the publisher (I). Alternatively, the second user public key (P1B) can be received by the issuer (I) during the earlier transaction processing. Therefore, in some cases, the second user public key (P1B) can be received from the issuer (I). ) Is obtained from the data storage 11. In some other alternatives, the second user public key (P1B) can be received via a third party in the communication network 8. In another alternative, the second user (B) 7 can send 820 the second user public key (P1B) to the publisher (I) 3 through the communication network 8.

The method 300 further includes allocating 370 a third amount of cryptocurrency (B3), which is associated with a third token (T3). In some embodiments where the total value of the first token (T1) is transmitted to the second user (B), it may be suitable to distribute a third amount of cryptocurrency (B3) from the first amount of cryptocurrency (B1) , Which is the same as the first amount of cryptocurrency (B1). In other alternatives (such as the fifth type of transaction will be discussed in further detail below), only a part of the total value of the first token (T1) is transmitted to the second user (B), and it can be the third The amount of cryptocurrency (B3) is allocated to the corresponding ratio. In another example, the third amount of encrypted currency (B3) may be allocated from other encrypted currencies that are not associated with the first amount of encrypted currency (B1). It should be understood that when the first amount of cryptocurrency (B1) is allocated 130 in method 100 and the second amount of cryptocurrency (B2) is allocated 265 in method 200, considerations for allocating 370 third amount of cryptocurrency (B3) Can be the same or similar to those.

The method also includes determining 380 a third hash (H3) of the third redemption script (RS3), wherein the third redemption script (RS3) is based on: at least the third metadata (MD3), which is based at least in part on the first order The first metadata (MD1) associated with the card; the second user public key (P1B); and the first issuer public key (P1I). This may include the first hash (H1) of the first redemption script (RS1) in the method 100 or the second hash (H2) of the second redemption script (RS2) in the method 200. Considerations.

The method 300 also includes sending 390 a third data output (O3) to the peer-to-peer distributed ledger via the communication network, including: sending an instruction to a second user (B) to trade at least a third amount of cryptocurrency (B3); and third Hash (H3), where the third hash (H3) is associated with a third amount of cryptocurrency (B3) to provide a third token ( T3). This is similar to steps 150 and 260 and similar changes described above and alternatives may apply.

<b>NS</b><b>Fives</b><b>Types of transactions</b><b>-</b><b>First user</b><b>(A)</b><b>will</b><b>The first part of the transmission</b><b>To the second user</b><b>(B)</b>

In another embodiment, only the first part (R1) of the total value of the first token (T1) is transmitted to the second user (B) 7, and in this case, the remaining second part of the total value ( R2) may be included in the second token (T2), which is returned to the first user (A)5. This may be similar to returning the second part (R2) of the above value in method 200. Therefore, the request to create the third token (T3) may explicitly or implicitly include a request to create the third token (T3) based on the third token value (TV3) of the first part (R1).

Figures 3(b) and 10 show that the refund is returned to the first user (A) in the form of a second token (T2). In order to create a second token (T2), the method 300 includes a judgment 355 The first user public key (P1A), which can be implemented in multiple ways as described above, and may include receiving the first user public key (P1A) sent from the first user (A) 5 via the communication network 8 .

The method also includes allocating 365 a second amount of cryptocurrency (B2) associated with a second token (T2), wherein the second token has a second token value (TV2) based on the second part (R2). The method 300 also includes determining 375a a second hash (H2) of the second redemption script (RS2) based on: a second hash (H2) based at least in part on the first metadata (MD1) associated with the first token (T1) Metadata (MD2); the first user public key (P1A); and the first publisher public key (P1I) associated with the publisher (I)3. Therefore, the step of sending 390 the third data output (O3) to the peer-to-peer distributed ledger further includes: sending to the first user (A) 5 an instruction to trade at least the second amount of cryptocurrency (B2); and second Hash (H2), where the second hash (H2) is associated with a second amount of cryptocurrency (B2) to provide a second token associated with the first user (A) 5 and the issuer (I) 3 (T2).

<b>Example of sending a value from the first user (A) 5 to the second user (B)</b>

Next, a specific example of the transaction ID-110 shown in Figure 3(b) will be described. The total value of the first user (A) 5 is 10.00 Australian dollars, and the first user (A) 5 wishes to send the first part (R1) of $7.30 Australian dollars as the third token (T3) to the second user (B) ), and return the remaining second part (R2) $2.70 as a variation of the second token (T2) to the first user (A) 5.

In this embodiment, the first token (T1) includes two token blocks, and each block represents a value of $5.00 Australian dollars. This can mean that the standardized value of the two blocks has been obtained from different transactions (for example, the block of $5.00) or the code of the first user (A)5. Each of these blocks contains 50,000 satoshis, which is equivalent to $5.00 at a fixed price rate of 100 satoshis/cent. This is the transaction ID-101 and ID-102 in Table 8 below, which are the transaction to create the first token (T1).<tables><table><img wi="230" he="64" file="tw201732705a_d0008.tif" img-content="drawing" img-format="jpg" orientation="portrait" inline="no" /></table></tables><tables><table><img wi="230" he="64" file="tw201732705a_d0009.tif" img-content="drawing" img-format="jpg" orientation="portrait" inline="no" /></table></tables><tables><table><img wi="230" he="96" file="tw201732705a_d0010.tif" img-content="drawing" img-format="jpg" orientation="portrait" inline="no" /></table></tables>Table 8

Line 3 of both D-101 and ID-102 represents the output script of the corresponding transaction, which is similar to line 11 in Table 4 above.

The publisher (I) also needs to pay transaction fees (miner fees). The transaction fee may partly come from the amount of encrypted currency received by the previous transaction ID-103. As shown in Table 8, it means that the previous 10,000,000 satoshis transaction will partially be used for fund transactions. This is similar to the previous transaction ID-610 described in Table 6 above.

Table 9 below shows the value of transaction ID-110 sent to the second user (B).<tables><table><img wi="400" he="770" file="tw201732705a_d0011.tif" img-content="drawing" img-format="jpg" orientation="portrait" inline="no" /></table></tables>Table 9

The third row of Table 9 above represents three inputs, and the 19th row represents three outputs. Two inputs represent the first token (T1), and the third input is used to pay transaction fees. The first output represents the transfer of value to the second user (B) 7, the second output represents the token change back to the first user (A) 5, and the third output is the cryptocurrency conversion of the issuer (I).

The first input based on the previous transaction ID-101 is shown in lines 4 to 8. It is the input of the first block of 50,000,000 satoshis, half of the first amount of cryptocurrency (B1), and represents the value of $5.00 Australian dollars. Line 7 shows ScriptSig to allow this amount of cryptocurrency to be spent, which means that the first redemption script (RS1) requires two of the four signatures, especially the use of the first user private key (V1A) and the first publisher private Key (V1I) for signing. Line 8 represents the sequence number, where the first input is tokenized as the first output.

Lines 9 to 13 are based on the second input of the previous transaction ID-102, which is the input of the second block of 50,000,000 satoshis, the second half of the first amount of cryptocurrency (B1), and represents the value of $5.00 Australian dollars. Line 12 shows a ScriptSig similar to line 7 above, which represents the serial number, where the second input is tokenized as output to the first output and the second output. This is because the second batch of 50,000,000 satoshis will be split, of which 23,000 satoshis to the first output and 27,000 satoshis to the second output.

Lines 14 to 18 show the third input, which is based on the previous transaction ID-103 used to fund the current transaction ID-110. The ScriptSig on line 17 needs to be signed with the first publisher's private key (V1I) of the previous output script containing the first publisher's public key (P1I).

Lines 20 to 22 show the first output and have an output of 73,000 satoshis, which is the third token (T3) of the third amount of cryptocurrency (B3). In this embodiment, the fixed price rate of the third token (T3) is 100 satoshis/cent (the same fixed price rate as the first token (T1)), so the third amount of cryptocurrency (B3) The third token value (TV3) is $7.30 Australian dollars, based on the first part (R1) is 7.30 Australian dollars.

The 22nd line is the output script, and the corresponding redemption script in this embodiment is: 2 metadata1 metadata2 P1B P1I 4 OP_CHECKMULTISIG

As mentioned above, the second user public key (P1B) and the first publisher public key (P1I) are included. What is important is that since the third token (T3) is redeemed by the second user (B) 7, the second user public key (P1B) is used. Metadata 1 and Metadata 2 may include metadata as described above, including instructions for "payment" or "transfer" transactions between users. Therefore, the first output provides a third token (T3), and the third token (T3) can be redeemed by the second user (B) 7 with a value of $7.30 Australian dollars to the issuer (I) 3.

Lines 23 to 24 show two outputs and have an output of 27,000 satoshis, which is the second amount of cryptocurrency (B2) that the second token (T2) returns to the first user (A) 5. In this example, the same fixed price rate is 100 satoshis / cent, so the second amount of cryptocurrency (B2) has a second token value (TV3) of $2.70 Australian dollars, which is based on the remaining second part (R2 ) Is 2.70 Australian dollars. Line 25 is the output script. The corresponding redemption script in this embodiment is: 2 metadata1 metadata2 P1A P1I 4 OP_CHECKMULTISIG

It includes the first user public key (P1A) and the first publisher public key (P1I). What is important is that since the second token (T2) is redeemed by the first user (A) 5, the first user public key (P1A) is used. Metadata may also include instructions for part of a "payment" or "transfer" transaction between users.

The third output is shown in lines 26 to 28, which reflects the publisher's changes to the transaction. In this transaction, the transaction fee is one thousandth, therefore, the publisher (I) is expected to reach the third output of 10,000,000 satoshis. The output value of the third output in line 26 is 9,999,000. Since the third output is the change of the publisher (I), the publisher should be free to pay for the third output. The output script on line 28 only includes the first publisher's public key (P1I) represented by it, which is &lt;PubK- Issuer hash&gt;.

The above embodiments show that a single transaction can have a mixture of "tokenized" and "non-tokenized" cryptocurrencies. In an embodiment, it may be important to verify that the input token value is equal to the output token value, so the issuer (I) can verify that the first token value (TV1) of the first token (T1) is equal to the second token The sum of the value (TV2) and the third token value (TV3).

In the above embodiment, the transaction fees are paid by the publisher (I), and they can pass on these fees in other ways. It should be understood that in some alternatives, the transaction fee may be paid directly by the first user and/or the second user. For example, the first user may be required to provide cryptocurrency for payment of transaction fees. In another embodiment, a portion of the first, second, or third amount of cryptocurrency may be used in each transaction to pay for transaction fees. In another alternative, each transaction may include an additional output, which is an additional token for the miner to create a convenient transaction to redeem with the issuer (I)3.

<b>Variety</b><b>–</b><b>User use</b><b>Corresponding private key pair</b><b>redemption</b><b>Script signature</b>

In the above embodiment, the publisher (I) is the service provider of the first user (A) 5 and the second user (B) 7, and manages their respective electronic wallets. Therefore, the issuer (I) 3 can access the private key of the corresponding user under the authorization of the user. This includes retrieving the user's private key from the data storage 11.

In some alternative embodiments, the slave user may desire to maintain the private key itself, and this separation may allow the user to better control his private key. This may be more secure, because a user has the right to access all the information in the publisher (I)3s data storage 11, including the first publishers private key (V1I). If they dont have the corresponding users private key, then Unable to unlock the redemption script.

Therefore, a variant of this method may include sending the redemption script to the users 5, 7 for signing with their respective private keys. In this embodiment, the issuer (I) 3 does not need to possess the user's private key.

Please refer to Figure 11, which is a description of the variations of the methods 200 and 600 for redeeming the first token (T1).

The first user (A) 5 can send 610 a request to redeem the first token (T1) through the communication network 8. First, the publisher (I) 3 receives the request from the first user (A) 5 through the communication network 8. A request 210 to redeem the first token (T1), and then the method 200 includes determining 220 the first redemption script (RS1) associated with the first token (T1). Retrieve the first redemption script (RS1) in 11; in another embodiment, it may include reconstructing the first redemption script (RS1) with data from one or more sources. For example, this may include 11 Retrieve at least the first metadata (MD1) and the first issuer public key (P1I), and receive the first user public key (P1A) through the communication network 8. The information can then be combined to recreate the first redemption script (RS1).

Next, the method 200 includes sending 230 the first redemption script (RS1) via the communication network 8 to the first user (A) to sign, in other words, the first user (A) 5 receives 620 the first redemption script (RS1). It should be understood that in some alternative embodiments, the step of sending the first redemption script (RS1) to the first user (A) 5 may be performed at other times, such as creating the first order in the publisher (I) 3 During or after the card (T1), the first redemption script (RS1) can be sent to the first user (A) 5. In another option, the first user (A) 5 can retrieve the first redemption script (RS1) in the data storage. In other alternatives, the first user (A) 5 can independently determine the first redemption script (RS1) associated with the first token (T1), for example, the first user (A) 5 can download from a Or multiple sources retrieve the first metadata (MD1), the first issuer public key (P1I), and the first user public key (P1A) to determine the first redemption script (RS1).

Next, the first user (A) 5 uses the first user private key (V1A) to sign 630 on the first redemption script (RS1) to provide the first redemption script (RS1A) signed by the first user . Then, the first redemption script (RS1A) signed by the first user is sent from the first user (A) 5 to the publisher (I) 3 via the communication network 8.

Conversely, the method 200 includes receiving the first redemption script (RS1A) signed by the first user via the communication network 8. The method 200 further includes that the first user signs 250 (RS1A) on the first redemption script using the first issuer private key (V1I), so as to associate the first token (T1) with the first amount of cryptocurrency. (B1) Unlock.

The method 200 further includes the step of sending 260 a second data output (O2) to the peer-to-peer distributed ledger via the communication network 8. The second data output (O2) includes the first amount of cryptocurrency (B1) to the publisher (I) The order of the transaction. In one embodiment, since the first token (T1) has been redeemed, the first amount of cryptocurrency (B1) is transferred back to the issuer (I), and may no longer be associated with the first token (T1) Associated. In some cases, the metadata associated with the first amount of cryptocurrency (B1) can be removed to "hide" the cryptocurrency. This can be done in the same transaction or a subsequent transaction, possibly the issuer (I)3 s Choice.

The above method 200 requires both the first user (A) 5 and the issuer (I) to sign the first redemption script (RS1), which may be beneficial to prevent or reduce tokens exceeding expectations by the first user (A) 5 The risk of spending the first amount of cryptocurrency (B1) accidentally or unintentionally. For example, if the first user (A) 5 tries to pay the first amount of cryptocurrency (B1) to another user (other than the issuer (I)), because the first issuer's private key (V1I) is required To unlock the first amount of cryptocurrency (B1), so this transaction will not proceed. On the other hand, the first user (A) 5 is required to sign the first redemption script (RS1) to provide a certain degree of security in order to redeem the first amount of cryptocurrency (B1), because the first user (A) 5 The first user private key (V1A) can be controlled and used to authorize transactions selectively.

In addition, having the publisher (I) finally sign the redemption script can improve security because it can avoid sending a fully signed redemption script on a potentially insecure communication network. For example, when the first token (T1) is redeemed, the public sequence key can instruct the first user (A) 5 to sign the first redemption script (RS1), and then send it to the issuer (I) for Make the final signature. Since the issuer (I) provides the unlocked final signature, this reduces the possibility that one person intercepting the communication between the issuer (I) and the first user (A) 5 may fraudulently access the token (T1) and/or the first The risk of the number of cryptocurrencies (B1).

Please refer to Figure 12, the method 300', 700', 800' can also be used to transfer the value of the first token (T1) from the first user (A) 5 to the second user (7). step. The methods 300', 700', and 800' are similar to the methods 300, 700, and 800 shown in Figure 9 with the following exceptions. The first user (A) 5 replaces the publisher (I) 3 to receive 335 first use The private key (V1A) and use it to sign the first redemption script (RS1), therefore, the method 300' includes the issuer (I) 3 sending 330 via the communication network 8 for signing to the first user (A) 5 The first redemption script (RS1).

The first user (A) 5 receives 720 the first redemption script, and signs 730 the first redemption script with the first user's private key (V1A), which provides that it is signed by the first user and then passes through the communication network 8 Send 740 the first redemption script (RS1A) to the publisher (I)3.

Next, the method 300' includes receiving 340 the first redemption script (RS1A) signed by the first user via the communication network 8. Then use the first issuer's private key (V1I) to sign 350, and the first redemption script (RS1A) signed by the first user is used to associate the first token (T1) with the first amount of encrypted currency ( B1) Unlock.

The method 300' may further include completing the steps 360, 370, 380, and 390 of creating the third token (T3) in a similar manner to the method 300 described above.

<b>Token and contract program</b>

If its defined rights are granted to the holder or owner of the contract, the contract is transferable. An example of a non-transferable contract is an example where participants are named, that is, rights are given to a specific named entity rather than the holder of the contract. This invention only discusses assignable contracts.

The token represents a specific contract conferred by a specific or defined contract. The actual contract can be a file stored in the form of distribution. Such as storing in the cloud. In a preferred embodiment, the token represents the contract in the form of a Bitcoin transaction.

Dividable tokens are tokens that can subdivide the value on the transaction output into smaller numbers distributed across multiple tokens (ie, distributed across multiple transactions). The prototype is a tokenized fiat currency. A divisible contract is defined as a contract that specifies a fixed price rate (PeggingRate) that is not zero. For a divisible contract, the value of the token transferred in the transaction output is related to the underlying Bitcoin (BTC) value through a fixed price rate. In other words, the contract stipulates the holder's right to set the price rate. For indivisible tokens, there is no fixed price rate. The contract stipulates the holders right in terms of fixed value (for example, bearer bonds: "This contract is redeemable for $1,000" or a voucher "This contract can be redeemed for one haircut "). For indivisible contracts, the basic transaction BTC value has nothing to do with the contract value.

The term "base BTC value" refers to the amount of Bitcoin (BTC) attached to the transaction output. In the Bitcoin protocol, each transaction output must have a non-zero amount of BTC to be considered valid. In fact, the BTC amount must be greater than the set minimum value (called "dust"). At the time of writing, it is currently set to 546 satosis. One bitcoin is defined as equal to 100 million satoshis. Since Bitcoin transactions are only used here as a means of facilitating the exchange of ownership, the actual basic BTC amount is arbitrary: the real value lies in the contract specifications. In theory, every token can be carried by dust.

In the protocol of the present invention, specifically for the divisible token, the underlying BTC value has the following meaning: it is associated with the contract value through a fixed price rate (PeggingRate). The set price rate itself is arbitrary and is chosen to keep the underlying BTC volume small. The reason for using a fixed price rate instead of simply doing the bottom layer for each token transaction with dust is because the protocol of the present invention facilitates severability: when the token is split into a smaller number of multiple transaction outputs , No need to adjust the original contract. On the contrary, the value of each contract is simply calculated based on the subdivided tokens of the set price rate and the underlying BTC value.

A limited token is a kind of total issuance value fixed (or "restricted") by a fixed non-zero number of shares, called the number of NumShares, so no more shares can be issued in a limited contract. For example, the partial ownership contract for horse racing is limited to 100% of the race (for example, 1% per 100 shares or 10% per 10 shares, etc.). An unlimited contract means that the issuer can underwrite further issuance of shares, for example, adding the required amount of fiat currency to its reserve account. NumShares must be clearly stated in all contracts. The limited contract must have NumShares&gt; 0; the unlimited contract is set to NumShares = 0.

A typical example is currency reserves (similar to gold reserves), so that the total value in the reserve bank account matches the total value in the existing promissory notes (ie, unredeemed tokens). This concept goes beyond currency reserves, including inventory counting. For example, the issuer of the token that is permitted to print T-shirts can start from the inventory of 10,000 T-shirts, and can issue a divisible token to represent these 10,000 T-shirts (each share = 1 T-shirt). The original token can be subdivided according to the underlying BTC value of the transaction output defined by the set price rate, and each subdivision token can be redeemed for multiple T-shirts. However, if demand increases, the publisher may decide to issue more shares (that is, increase the number of outstanding shares) (additional 10,000 shares). In this case, the publisher is obliged to deposit another 10,000 T-shirts in its reserve account (ie, inventory warehouse) to underwrite further issuance. Therefore, the total number of T-shirts of stocks (stocks as a "reserve account") at any time = the total number of outstanding shares.

The fixed price rate is only applicable to divisible contracts, where the value of the shares (indicated by the number named ShareVal) is linked to the potential BTC amount. For example, the contract may stipulate that the issuer promises to redeem tokens for $10,000 for each bottom layer of 1 BTC. That would mean that (for example) a transaction with a tokenized potential output value of 15,400 satoshis would be redeemed at $1.54. A value of 0 for the fixed price rate indicates that the contract is indivisible (that is, it can only be completely transferred, like a bearer bond). When the fixed price rate is set to 0 (meaning non-dividable tokens), the underlying BTC value has nothing to do with the contract value and can be set to any number. Generally in this case, it is desirable to keep the amount of the underlying BTC as small as possible (that is, set as dust) to minimize the operating cost.

NumShares is the total number of (fixed) shares available under the (limited) contract. For limited contracts, NumShares must be an integer greater than zero. For unlimited contracts, NumShares is not fixed because it means that by setting the value to 0, more shares can be issued at any time (as long as they are underwritten).

A share is defined as a transfer unit, and ShareVal is the value of the unit. For example, for legal tender, the transfer unit can be set to 1 point. For example, it can be set to 50 cents. In this case, the transfer can only be executed at "a lot" of 50 cents. ShareVal can also be expressed as a percentage: for example, if a breeder wants to sell racehorses for 10 equal parts, then ShareVal = 10%. ShareVal must be&gt; 0 and must be defined in the contract.

The total amount is the total amount of issued shares. This value is only related to limited contracts. For unlimited contracts, the issuance is not fixed and more shares can be issued.

If the shares are expressed as a percentage, then TotalIssuance = 100% is defined.

For limited contracts, NumShares, ShareVal and TotalIssuance are related to the following way: NumShares x ShareVal = TotalIssuance.

A value of 0 for TotalIssuance means that it is an unlimited contract. An example of an unlimited contract is legal tender (so TotalIssuance is set to 0); an example of a limited contract is: (i) Limited commemorative coins (1000 minted, 1 share = 1 coin): TotalIssuance = 1000 x 1 = 1000 Coins; and (ii) seats at the ticket office, where TotalIssuance = the total number of seats available.

Circulation is defined as the total value of unused tokens (e.g. judged in unused transaction output). The complete set of all unsold transactions is stored in all bitcoin nodes in the available list. For example, if the issuer initially issued $10,000 as a fiat currency type token and a token with a settlement time of $5500 is redeemed, then circulation = $4500 (as an unredeemed value token), this value should be compared with the relevant reserve account Balance adjustment.

It should be noted that in certain (non-typical) situations, circulation may be lower than the reserve account balance, although the opposite has never been the case. For example, breeders consider the issue of 10 shares of stallion (by definition TotalIssuance = 100%). Buyers can redeem their tokens by sending them back to the breeder. If she cancels, there will be only 9 shares in circulation = 90% of the horses, although of course 100% of the horses are in reserve (=stable). In this case, the reserve excess (that is, the 10% ownership is unknown) implicitly belongs to the publisher.

Although this situation is benign and falls within the scope of the present invention, 100% of the shares in the executable agreement must be explicitly considered (that is, the breeder in this illustrative situation is not allowed to remove the token from the token (Detokenise)).

Example 1-Firewood weight. In this example, the contract is: "The holder has the right to get firewood at a rate of 20kg for 600 satoshi per bottom layer." Metadata is defined to represent the following key parameters: NumShares = 0; ShareVal = 20kg; and PeggingRate = 600 satoshis/share. These parameters define an infinitely divisible contract, where one share in the contract is 20 kilograms of firewood, where each multiple of the 600 quarters in the transaction corresponds to a share in the contract. In this example, TotalIssuance is not fixed.

Example 2-Firewood bag. In this example, the content of the contract is as follows: "The holder has the right to use a 20 kg firewood." Metadata is defined to represent the following key parameters: NumShares = 0; ShareVal = 1 package; PeggingRate = 0. These parameters define an unrestricted and indivisible contract, where the share value in the contract is 20 kilograms of firewood, where any amount of underlying bitcoin in the transaction corresponds to a share in the contract. In this example, TotalIssuance is not fixed.

Example 3-$1000 notes. In this example, the content of the contract is as follows: "The holder is entitled to USD 1,000." Metadata is defined to represent the following key parameters: NumShares = 0; ShareVal = USD 1,000; PeggingRate = 0. These parameters define an infinite and indivisible contract, where the share in the contract is $1,000, where any amount of underlying bitcoin in the transaction corresponds to a share in the contract. In this example, TotalIssuance is not fixed.

Example 4-Commemorative coin #1. In this example, the content of the contract is as follows: "The holder is entitled to a limited edition (1,000 coins) of the 2000 Olympic silver coins (maximum one per customer)." Metadata is defined to represent the following key parameters: NumShares = 1000; ShareVal = 1 coin; PeggingRate = 0. These parameters define an indivisible contract, limited to 1000 shares, where the share in the contract is 1 coin, and any number of underlying bitcoin transactions corresponds to one share in the contract. In this example, TotalIssuance is 1000 coins.

Example 5-Commemorative coin #2. In this example, the content of the contract is as follows: "The holder is entitled to a limited edition (10,000 coins) of the 2000 Olympic bronze coins, and each bottom coin is 1 600 satoshis." Metadata is defined to represent the following key parameters: NumShares = 10,000; ShareVal = 1 coin; PeggingRate = 600 satoshis / share. These parameters define a divisible contract with a limit of 10,000 shares, where the share in the contract is 1 coin, and each multiple of the 600 satoshis in the transaction corresponds to a share in the contract. In this example, TotalIssuance is 10,000 coins.

Example 6-Legal tender #1. In this example, the content of the contract is as follows: "The holder is entitled to Canadian dollars, and the cost of each underlying bitcoin is 10,000 US dollars. The transfer unit is 50 cents." Metadata is defined to represent the following key parameters: NumShares = 0; ShareVal = 50 points; PeggingRate = 5000 satoshis / share. These parameters define an infinite and divisible contract, where one share in the contract is worth 50 Canadian cents, and each multiple of the 5000 thousands in the transaction corresponds to a share in the contract. In this example, TotalIssuance is not fixed.

Example 7-Legal tender #2. In this example, the content of the contract is as follows: "The holder has the right to receive Australian dollars, 10,000 US dollars for each potential Bitcoin. The transfer unit is 1 point." Metadata is defined to represent the following key parameters: NumShares = 0; ShareVal = 1 point; PeggingRate = 100 satoshis / share. These parameters define an infinite and divisible contract, where the value of the share in the contract is 1 Australian dollar, where each multiple of 100 satoshis in the transaction corresponds to a share in the contract. In this example, TotalIssuance is not fixed. It can be seen that the lowest Australian dollar that can actually be transferred in this example is 6 cents. The disadvantages will result in the underlying BTC value being lower than the current minimum required for valid transactions.

Example 8-Shared housing. In this example, the content of the contract is as follows: "The holder has the right to partly own the property by (address), and the proportion of each potential 600 satoshis is 10%." Metadata is defined as representing the following key parameters : NumShares = 10; ShareVal = 10%; PeggingRate = 600 satoshis / share. These parameters define a divisible contract limited to 10 shares, where the value of one share in the contract is 10%, and each multiple of the 600 proceeds in the transaction corresponds to a share in the contract. In this example, TotalIssuance is 100% ownership of the house.

Example 9-Horse racing. In this example, the content of the contract is as follows: "The holder is entitled to partial ownership of Naka's Delight, and the proportion of 600 satoshis per bottom layer is 1%." Metadata is defined to represent the following key parameters: NumShares = 100; ShareVal = 1%; PeggingRate = 600 satoshis / share. These parameters define a divisible contract limited to one hundred shares, where one share in the contract is worth 1%, and each multiple of the 600 proceeds in the transaction corresponds to one share in the contract. In this example, TotalIssuance is 100% ownership of a horse.

Example 10-Allocate seat tickets. In this example, the content of the contract is as follows: "The holder has the right to seat B54 at the "Dead Lizard" concert at the Central Concert Hall on February 14, 2016. "Metadata is defined to represent the following key parameters: NumShares = 1; ShareVal = 1 vote; PeggingRate = 0. These parameters define an indivisible contract limited to one share, where the value of the share in the contract is 1 vote, and any number of underlying bitcoins in the transaction corresponds to one share in the contract. In this example, TotalIssuance is 1 ticket. Tickets may include access codes for obstacles entering the event venue, thereby providing rewards that the tickets have been redeemed.

Example 11-Credentials of celebrity dates. In this example, the content of the contract is as follows: "The holder is entitled to a one-time dinner time on March 31, 2016, George Kludgy at the Spiffy Hotel in central Sydney, including a taxi home." Metadata is defined to represent the following key parameters: NumShares = 1; ShareVal = 1 date; PeggingRate = 0. These parameters define an indivisible contract that is restricted to a shared contract, where a shared value in the contract is 1, and any number of underlying bitcoins in the transaction corresponds to a share in the contract. In this example, TotalIssuance is a certain day.

Example 12-Haircut coupons. In this example, the content of the contract is as follows: "Except for public holidays, the holder is entitled to a haircut and hair dryer, valid on any weekday." Metadata is defined to represent the following key parameters: NumShares = 0; ShareVal = 1 voucher; PeggingRate = 0. These parameters define an unrestricted and indivisible contract, where the share value in the contract is a voucher, and any amount in the underlying bitcoin in the transaction corresponds to a share in the contract. In this example, TotalIssuance is not fixed.

Example 13-T-shirt. In this example, the content of the contract is as follows: "The holder is entitled to the "Dead Lizard" commemorative T-shirt for the 2016 World Tour, at a rate of 1 T-shirt for every 1,000 satoshis. Metadata is defined to represent the following key parameters: NumShares = 0; ShareVal = 1 t-shirt; PeggingRate = 1000. These parameters define an infinitely divisible contract, where the share value in the contract is 1 T-shirt, and where each multiple of 1000 kilobytes in the transaction corresponds to a share in the contract. In this example, TotalIssuance is not fixed.

Example 14-Unallocated seat tickets. In this example, the content of the contract is as follows: "The holder has the right to enter the Jazz Jivers concert at Sadie's Pub on April 29, 2016. The ratio of each potential 1,000 satoshis admission ticket is 1. There are only 137 spaces. Available". Metadata is defined to represent the following key parameters: NumShares = 137; ShareVal = 1 vote; PeggingRate = 1000. These parameters define a divisible contract with a limit of 137 shares, where the value of the shares in the contract is 1 vote, and each multiple of 1,000 satoshis in the transaction is equivalent to one share.

Example 15-Music files. In this example, the content of the contract is as follows: "The holder has the right to obtain a copy of the dead lizard album "Chameleon Rising"." Metadata is defined to represent the following key parameters: NumShares = 0; ShareVal = 1 album; PeggingRate = 0. These parameters define an unrestricted and indivisible contract, where one share in the contract corresponds to or contains an album, and where any number of underlying bitcoins in the transaction corresponds to a share in the contract. In this example, TotalIssuance is not fixed.

Example 16-Furniture items in the catalog. In this example, the content of the contract is as follows: "Under excellent conditions, the holder is entitled to this amazing and unique classical Georgian style." Metadata is defined to represent the following key parameters: NumShares = 1; ShareVal = 1 item; PeggingRate = 0. These parameters define an indivisible contract, limited to one sharing, where a common value in the contract is 1 item, and any number of underlying bitcoins in the transaction corresponds to a share in the contract. In this example, TotalIssuance is 1 item.

Example 17-Batch of golf balls. In this example, the content of the contract is as follows: "The holder is entitled to high-quality Tigger Wodes" Class A "Golf, 600 satoshis per bottom layer is 12 balls." Metadata is defined as representing the following key parameters: NumShares = 0; ShareVal = 12 golf balls; PeggingRate = 600. These parameters define an infinitely divisible contract, where the share in the contract has the value of 12 golf balls, and where each multiple of 600 satoshis in the transaction corresponds to a share in the contract. In this example, TotalIssuance is not fixed.

<b>Processing device</b>

As mentioned above, the publisher (I) 3, the first user (A) 5, and the second user (B) 7 can be associated with the first processing device 13, the second processing device 15, and the third processing device 17. The point-to-point distributed ledger 9 may also be associated with multiple processing devices 19.

The processing device can be a part of an electronic device, such as a computer, a tablet computer, a mobile communication device, a computer server, and so on. In addition to the processing device, the electronic device may include a data storage 11 and a user interface.

Figure 13 shows embodiments of processing devices 13, 15, 17, 19. The processing devices 13, 15, 17, and 19 include a processor 1510, a memory 1520 and a user interface device 1540 that communicate with each other via a bus 1530. The memory 1520 stores instructions and data used to implement the above methods 100, 200, 300, 400, 500, 600, 700, 800, and the processor 1510 executes instructions from the memory 1520 to implement the method. The user interface device 1540 may include a communication module that facilitates communication with the communication network 5, and in some embodiments, serves as a user interface and peripheral devices such as the data storage 11. It should be noted that although the processing device 1501 may be an independent network element, the processing device may also be part of another network element. In addition, some functions performed by the processing device may be distributed among multiple network elements. For example, the publisher 3 may have multiple processing devices 23 to execute the method 100 in a secure local area network associated with the publisher (I)3. , 200, 300, 400.

The present invention describes that users, publishers, merchants, providers, or other entities perform specific actions (including signing, issuing, determining, calculating, sending, receiving, creating, etc.), and this wording is used for clear presentation. It should be understood that these actions are performed by computing devices operated by these entities.

Signing can include performing encryption functions. The encryption function has input for plain text and input of key such as private key. The processor can perform this function to calculate the number or string that can be used as a signature, and then provide the signature together with the plaintext to provide the signature text. If the message text or key changes by one bit, the signature will be completely changed. When computing a signature requires very little computing power, it is practically impossible to recreate a message with a given signature. The plaintext can only be changed when the private key is available, with a valid signature attached. In addition, other entities can easily use publicly available public keys to verify signatures.

In most cases, encryption and decryption include the processor performing encryption functions to calculate an output string representing the encrypted message, or to display the plaintext message separately.

Data memory stores keys, tokens, metadata, transactions, proposals, contracts, signatures, scripts, metadata invitations, and quotes data represented by numbers, text or strings, such as "string" or "int" type or other Type or text of the variable file in the program code.

An example of a peer-to-peer ledger is the Bitcoin blockchain. Transferring funds or paying fees in Bitcoin currency includes creating transactions on the Bitcoin blockchain. Funds or fees are generated by the transaction. Bitcoin transactions can include input transaction hashes, transaction volume, one or more destinations, payee or payee's public key, and signature created by using the input transaction as the input message, and the payer's private key calculation The signature can be verified by checking that the input transaction hash exists in a copy of the Bitcoin blockchain and the public key signature is correct. To ensure that the same input transaction hash has not been used elsewhere, the transaction is broadcast to the network of computing nodes ("miners"). Only when the input transaction hash is not connected and the signature is valid, the miner accepts and records the transaction on the blockchain. If the input transaction hash has been linked to a different transaction, the miner will reject the transaction.

Assigning cryptocurrency to the token includes using the assigned cryptocurrency and token shown in the metadata field of the transaction to create a transaction.

When two projects are related, it means that there is a logical connection between these projects. For example, the identification codes of two items in the database can be stored in the same record to correlate the two items. In the transaction, the identification codes of the two items can be included in the transaction string to associate the two items with each other.

When using the Bitcoin protocol, redeeming a script and/or unlocking a token includes using a private key to calculate a script and/or a signature string of a transaction. The script may require more than one signature from different private keys or other conditions. The output of the transaction is then provided to the miner.

Authorizing another entity may include using the private key to calculate the signature string of the transaction and providing the signature string to the entity to allow the entity to use the signature to verify the transaction.

A user with an account with another entity can include entities that store information about the user, such as email addresses, names, and possibly public keys. For example, the entity can maintain a database such as SQL, OrientDB, MongoDB Or other databases. In some embodiments, the entity may also store the private keys of one or more users.

Only the above are only preferred embodiments of the present invention and are not used to limit the scope of implementation of the present invention. Therefore, all equivalent changes or modifications made in accordance with the characteristics and spirit of the application scope of the present invention should be included in the patent application scope of the present invention.

<p>3Publisher</p><p>5First user</p><p>7Second User</p><p>8Communication network</p><p>9Point-to-point distributed ledger</p><p>11Data Storage</p><p>13First processing device</p><p>15Second processing device</p><p>17Third processing device</p><p>19Processing device</p><p>1510Processor</p><p>1520Memory</p><p>1522Data</p><p>1524Command</p><p>1530Bus</p><p>1540User Interface</p>

Figure 1 is a schematic diagram of an embodiment of the system for creating and redeeming tokens. Figure 2(a) is a schematic diagram of an embodiment of the first transaction mode in which a token is generated between the first user and the issuer. Figure 2(b) is a schematic diagram of an embodiment of the second transaction mode of redeeming tokens between the first user and the issuer. Figure 2(c) is a schematic diagram of an embodiment of the third transaction mode between the first user and the second user. The issuer facilitates the transfer of part of the token value from the first user to the second user. Two users. Figure 3(a) is a schematic diagram of an embodiment of the fourth transaction pattern for redeeming a portion of the token value between the first user and the issuer. Figure 3(b) is a schematic diagram of an embodiment of the fifth transaction mode between the first user and the second user. The issuer facilitates the transfer of part of the token value from the first user to the second user. Two users. Figure 4 is a flowchart of the computer execution method of creating a token. Figure 5 is a flowchart of the computer execution method for registered users. Figure 6 is a flowchart of another embodiment of the computer execution method for creating a token. Figure 7 is a flowchart of the computer execution method of redeeming tokens. Figure 8 is a detailed flowchart of the computer execution method in Figure 7. Figure 9 is a flowchart of a computer execution method for transferring token values from a first user to a second user facilitated by the issuer. Figure 10 is a detailed flowchart of the computer execution method in Figure 9. Figure 11 is a flowchart of a variant of the computer-executed method for redeeming tokens, in which the redemption script is sent to the first user for signature. Figure 12 is a flowchart of a variant of the computer-executed method for transferring the token value from the first user to the second user facilitated by the issuer, in which the redemption script is sent to the first user for signature. Figure 13 is a block diagram of an embodiment of the processing device.

<bio-deposit></bio-deposit>

<sequence-list-text></sequence-list-text>