WO2021250129A1 - Computer implemented systems and methods for improved authentication of blockchain-based tokens - Google Patents
Computer implemented systems and methods for improved authentication of blockchain-based tokens Download PDFInfo
- Publication number
- WO2021250129A1 WO2021250129A1 PCT/EP2021/065529 EP2021065529W WO2021250129A1 WO 2021250129 A1 WO2021250129 A1 WO 2021250129A1 EP 2021065529 W EP2021065529 W EP 2021065529W WO 2021250129 A1 WO2021250129 A1 WO 2021250129A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- token
- transaction
- issuer
- blockchain
- tokens
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
Definitions
- Embodiments utilise, at least in part, a distributed ledger (blockchain) to facilitate the secure and efficient transfer of control of a tokenised resource from one party to another.
- the disclosure is generally suited, but not limited, to use in respect of the distribution of tokenised assets across a computing network. Verification of these tokenised assets is improved, enhancing security and reducing vulnerability to transfers and exploits by unauthorised parties.
- Embodiments enable the implementation of improved digital wallets which are able to exchange data in new and technically advantageous ways.
- a token transaction is a blockchain transaction that comprises one or more token outputs.
- Embodiments of the disclosure are particularly suited for use in relation to systems in which tokenised assets need to be verified to confirm their legitimacy and issuance by an authorised party.
- Embodiments provide numerous technical advantages including, but not limited to, improved efficiencies, reduced processing requirements and increased security of blockchain-based transfers.
- a blockchain transaction is a data structure formed in accordance with a blockchain protocol and comprises at least one input and at least one output. Control of the cryptocurrency that is digested/received by the input(s) is spent/transferred from the output(s) of the transaction to the input(s) of further transaction(s) that are added to the blockchain in subsequently mined block(s). Any portion of the cryptocurrency that is not transferred to a new receiving address/owner/receiver is sent back to the current address/owner/sender as "change”. Inputs and outputs are ordered and numbered within their respective transactions so that they can be referenced. In the case of outputs, they form a zero-indexed Vector (list) based on their position within the transaction's outputs.
- list zero-indexed Vector
- An output's index number is known as its "Vout” index.
- each input in a transaction is identifiable by the transaction identifier (TxlD) and the Vout of the output that it will spend.
- the inputs in a given transaction are also listed in a zero-indexed Vector, this time known as "Vin”.
- Vin zero-indexed Vector
- each input references an identifiable output in a previous transaction on the ledger, thus creating a chain so that the immutable transfer history of each cryptocurrency unit can be verified by traversing the blockchain back to the unit's originating source.
- blockchain platforms can provide the underlying mechanism that enables much more than just the transfer of cryptocurrency.
- blockchain transactions can be used to transfer other types of data in addition to digital money, thus driving technologies across a wide spectrum of industries and applications.
- This additional data is often referred to as "metadata" and could potentially comprise any type or format of data, such as text, media content, images, links to off-chain locations or resources, executable code, smart contracts, hashes of such data etc.
- a token is a digital object or item that is used to represent some other object or resource, physical or otherwise.
- Blockchain tokenisation technologies provide numerous technical advantages such as improved security, efficiency, ease of use and enhanced network privacy.
- known tokenisation approaches also face numerous technical challenges. These include, but are not limited to, the following problems.
- current token solutions require some type of third party infrastructure to handle authorisation of actions and verification of the token's authenticity.
- Such infrastructures can be costly in terms to develop and operate, both financially and in terms of required computing resources and time and, therefore, can be inefficient. They can also require the use of trusted third parties which, in turn, can lead to security concerns and increased potential for attacks, exploits and breaches.
- wallet integration can be a significant challenge as the process is often complex and time consuming.
- tokenisation protocols specify that the token validation rules are embedded within script inside the token transaction. These can be designed in such a way that the script proves the validity of a token all the way back through the chain of transaction until issuance. This is achieved by creating a hash puzzle that requires the previous transaction to be inserted as a solution (the transaction ID is the hash digest, and the transaction itself is the hash preimage).
- the transaction ID is the hash digest, and the transaction itself is the hash preimage.
- each token transaction necessarily contains all of the data of the previous transaction, by induction it must contain all previous transactions back to issuance. This means that the size of each token transaction increases cumulatively, meaning that the latest transaction in the chain may be very large. This increased transaction size therefore increases the resource demands relating to bandwidth and storage requirements and the cost of writing to the ledger.
- portions of cryptocurrency are included in blockchain transactions as part of the underlying transfer mechanism specified by the blockchain's protocol.
- blockchain transactions can also be used to transfer ownership or control of other, additional assets which are tokenised and represented on the ledger.
- Embodiments of the present disclosure relate to the processing of these additional tokens, rather than the protocol-level cryptocurrency required by the blockchain network's protocol.
- UTXO-based token systems share some advantageous features of the blockchain system in addition to the security such as in-script smart contracts for tokens. It also allows token issuers to peg their token value to the native blockchain token value.
- the issuer may choose to destroy the token or withdraw it from use in its current form and may re-issue it.
- This process can be re-referred to as a "melt and re-mint" operation as it is analogous to the concept of melting down a traditional coin in a fiat currency system when it has become compromised or damaged in some way over time.
- a newly minted replacement can be issued by the minting authority.
- the need to melt and remint incurs costs and requires resources for the issuing authority, and so it is disadvantageous to have to perform this operation on a frequent basis.
- a computer-implemented method which may be defined as, at least, a method of validating, certifying and/or endorsing/attesting the authenticity a blockchain-implemented token.
- “Certification” may be understood herein to include: a stamp of legitimacy or authenticity, a proof of origin or provenance, and/or a confirmation of authorship/creation by a specific entity.
- “Validating” may be understood to include: checking, testing and/or confirming the legitimacy, authenticity, origin, authorship, certification or provenance of a blockchain-implemented token.
- the token may be formed and/or processed in accordance with a protocol in which token validation rules are embedded within a script of the token transaction.
- Embodiments of the disclosure enable blockchain-based tokens to be validated quickly and efficiently, and without the need to trace the token's provenance back to its origin on the blockchain. This provides significantly enhanced efficiencies and the requirement of fewer resources on behalf of parties who process the tokens (e.g. senders, receivers, issuers) as they do not need to traverse and process extensive token histories. Fewer resources are also consumed due to a reduced need to replace such tokens, or at least a reduction in the frequency of doing so. Moreover, embodiments of the disclosure, by either melting-and-reminting or stamping the tokens, enable a reset of the size of the latest transaction in the token transaction chain. Therefore, very large savings of transaction size are achieved. This is turn leads to a reduced bandwidth requirement, storage requirement, and cost of writing to the ledger.
- parties e.g. senders, receivers, issuers
- the method comprises the step of adding a certification element to a token transaction that is an element in a chain of token transactions.
- token transaction may include a blockchain transaction which comprises at least one token, wherein the token represents a tokenised asset of any form and stored on or off chain, and the token is formed in accordance with a tokenisation protocol which is distinct from but implemented on top of the underlying blockchain protocol that is operated by the network nodes.
- the chain of token transactions originates from a minting transaction which is used by the issuer, or by an authorised party on behalf of the issuer, to generate the token.
- Each token transaction starting from the minting transaction onwards, passes the token on to the next element (token transaction) in the chain. Therefore, the token has a traceable and immutable, unbroken history on the blockchain ledger in the form of token transactions back to its mint transaction.
- Certain token transactions along that chain of history comprise a certification element.
- this removes or at least alleviates the need to trace the token's history all the way back to its originating (minting) transaction for verification/certification purposes as the verifier need only follow the history back to the last token transaction in the chain which contains a trusted certification element.
- At least one, some or all of the token transactions in the chain comprise a certification element which serves as a verifiable mark, certificate or stamp of authenticity associated directly or indirectly with an authorised entity e.g. the token issuer or some other party that is trusted as an authorised or approved certification entity that can attest to the origin and/or legitimacy of the token on the issuer's behalf.
- the certification element may be referred to as a stamp or confirmation of authenticity.
- the certification element may provide proof of knowledge of a secret that is known to be associated with or controlled by the issuer.
- one or some but not all of the token transactions in the chain may comprise a certification element. This provides the advantage of being more efficient because of the processing costs associated with provision of the certification element within the token transactions. (Hereafter, the term "issuer" may include other parties which are authorised by the issuer to act on their behalf).
- the same certification element may be provided in a plurality of token transactions within the chain. In other embodiments, however, a different certification element may be provided for each or some of the selected token transactions. Importantly, though, whether the same or different certification elements are used in the token transactions, the certification element(s) serve the purposes described above for facilitating attestation of the origin of the token.
- the certification element might take the form of cryptographic data such as a cryptographic element that can be provably associated with, or authorised by, the issuing entity. This could be, for example, a cryptographic key or a message signed using a key that is known to be associated by the issuer.
- the certification element can take any suitable form which enables a verifying entity to establish that it has been provided and/or authorised by the issuer and that its provision in the token transaction serves as proof or evidence of the token's provenance, legitimacy and/or authenticity.
- the certification element may be added to the token transaction in accordance with at least one predetermined rule or criteria such as, for example, when the token has been spent (transferred) a pre-determined number of times.
- the criteria or rule may be determined by the issuer, a token owner/receiver/controller, or some other party.
- the certification element may be added to a token transaction in the chain in response to a request, instruction or other signal. In this latter scenario, the insertion of the certification element may be performed on a more ad hoc basis rather than in a prescriptive manner.
- the certification element may be included in the chain at a predetermined interval such as every 100 transactions, or after a specified period of time such as each day or week (assuming, in this case, that the token will be involved in a sufficiently high frequency of transactional activity).
- a predetermined interval such as every 100 transactions, or after a specified period of time such as each day or week (assuming, in this case, that the token will be involved in a sufficiently high frequency of transactional activity).
- Other criteria and rules may be utilised, but in essence certain embodiments of the disclosure comprise the use of one or more predetermined metrics or which specify which elements of the chain (transactions) the certification element is to be added to.
- the certification element can be added to a token transaction in any suitable manner known in the art. For example, in some protocols this may be after an OP_RETURN while in others it may be in a script which includes OP_FALSE OP_RETURN commands. In other embodiments, the certification element may be provided in a locking script of an output in the token transaction, and/or provided as metadata. The skilled person will readily understand that the certification element can be provided in association with the token transaction in a variety of ways and at a variety of locations within the transaction to provide the same advantageous effect.
- an issuer may melt and re-mint one or more tokens provided in a token transaction, so that the token's prior history remains on-chain as a verifiable and auditable record of original provenance and authenticity, but the new mint transaction takes the place of the original mint transaction for verification purposes.
- this can be performed at periodic intervals so that the effort required to trace back to a minting transaction is reduced for the verifying party but the overheads associated with melting and reminting are also minimised for the issuer/certifying party.
- the frequency at which the melt and re-mint process is performed can be predetermined according to at least one rule, criteria or metric, which can be evaluated by an automated resource such as a bot, oracle or other software component.
- the tokens may be re-issued once a specified threshold, limit or measurable/quantifiable value has been reached. This may be the number of transactions written to the token's history chain on the blockchain since the original or last mint transaction, or every x number of token transactions written to the chain, or at periodic time intervals etc.. This provides the advantage of predictability for token users and/or owners.
- the melt and re-mint process can be performed on an ad hoc or random/pseudo random basis.
- an identifier associated with the token and used in previous token transactions in its history may be replaced by a new identifier.
- embodiments may comprise a blockchain-implemented method of issuing at least one token provided in a token transaction on a blockchain.
- the method may comprise the step of melting and reminting the token when a condition is met.
- This condition may, for example, comprise determining that pre-determined threshold, limit or specified value has been reached or identified.
- the token transaction is traceable on the blockchain back to at least one mint transaction issued by or on behalf of at least one issuer.
- Melting the at least one token may comprise providing an identification element, marker or other portion of data to indicate that the token is no longer valid.
- re-minting the token may comprise providing an identification element, marker or other portion of data to indicate that the token is valid.
- the identifier may provide an indication that the token has been re-minted, and is provided in a modified form relative to one or more previous versions.
- the identification element can take any suitable form such as, for example, an identifier and/or cryptographic data. It can be associated with the at least one issuer or a party authorised by the at least one issuer, and can be provided in a blockchain transaction, in the token transaction or in a storage resource provided off the blockchain.
- the step of assessing whether the pre-determined threshold, limit or specified value has been reached or encountered may comprise performing a comparison of a supplied or calculated value against the threshold, limit or specified value.
- the pre-determined threshold, limit or specified value may be determined by the at least one issuer or a party authorised by the at least one issuer, a user or a validating entity.
- Embodiments of the present disclosure may be implemented and used within the context of a wider tokenisation protocol that provides techniques, protocols and systems for creating, using, processing, and transferring tokenised assets or resources via a blockchain (ledger) that is associated with an underlying blockchain protocol and network.
- a blockchain (ledger) that is associated with an underlying blockchain protocol and network.
- This underlying blockchain protocol/network may be, for example, a version of the Bitcoin protocol and its associated network and platform but other blockchain protocols and implementations may be used and fall within the scope of the present disclosure.
- a token may, in the alternative, be considered as a "digital object" and may provide an on-blockchain representation of some tokenised resource or units thereof.
- the minting transaction comprises issuance data which testifies to the issuer's identity and/or authority to issue the tokens, and serves as a verification means during transfer and processing of the tokens in subsequent use.
- the minting transaction also comprises one or more outputs (UTXOs), each of which represents a token.
- each token represents a quantity of tokenised asset or resource of some type.
- the tokenised asset/resource may be expressed as a quantity of unit(s).
- the tokenised resource can take any form. For example, it can be a digital or virtual asset, an abstract entity or a physical entity.
- the token's pre-determined quantity of resource units is specified when the token is minted and during use the protocol requires that this quantity of tokenised resource units remains fixed i.e. immutable or unchanging in some respect despite their transfer over the blockchain.
- token value or “denomination” may be used interchangeably herein with “quantity of tokenised resource” or “token units”.
- the token is represented by a fixed quantity of cryptocurrency units (e.g. Satoshis or some other type of cryptocurrency) held in the locking script of a UTXO that has a linear history linking it to the token's creation in a minting transaction via the ledger.
- cryptocurrency units e.g. Satoshis or some other type of cryptocurrency
- a solution for the locking script plus a reference to the UTXO holding the token are used as an input in a new transaction which spends the token-holding UTXO to a new locking script specified by the receiving party.
- spending of a UTXO requires the transfer of control of a quantity of cryptocurrency from one address to another, and so transfer of the token is performed upon spending of an underlying portion of cryptocurrency.
- the issuance data and/or other data is also transferred along with the token and cryptocurrency.
- the UTXO holding the token is used as an input to the transaction and a quantity of cryptocurrency tokens must be spent into an output with the same index as the input for the token transfer to be valid. In this way, ownership of the token is passed to the new UTXO's controlling party.
- This method has the benefit of being easily traceable on the public ledger due to the matching indices of input and output (Vin and Vout) in each transaction, resulting in improved speed and efficiency when validating the provenance of the token.
- the transfer of the token can be performed through the linking of the input containing the token to an output of the transaction through other mechanisms such as, for example, a signature or identifier placed into the locking script of the new UTXO that holds the token.
- a token used and arranged in accordance with the illustrative tokenisation system can be described as having a linear transaction history when that token has a complete history of being transferred without there being any change to the originally ascribed token value applied in the minting transaction.
- This means that the token is always transferred wholly into a single, separate and unique UTXO without having its token value split, merged, duplicated or modified in any way.
- the transaction history of a token can be represented as a series of linear actions in which each action transfers the token in the same form in which it was created in the minting transaction. Because of this, the overhead required to manage token transfers is very low, and can be applied in a way that pushes the transfer governance process down onto the nodes of the Bitcoin network to manage as part of their role in transaction validation.
- Figure 1 is a flowchart illustrating steps in an illustrative tokenisation system/protocol which can incorporate a preferred embodiment of the disclosure.
- FIG. 2 and 3 shows illustrative tokenisation systems, some of which utilise an intermediary register and some which do not.
- FIG 4 shows the Inputs and Outputs of a Token transfer transaction (TTTx), in which tokens go into and out of the same VOUT index in the same blockchain transaction and retain their exact token; moreover, tokens that are sent into a wallet in respect of a given exchange or transaction may not (in fact, most likely will not) be the same tokens that will be sent for onward transfer to a recipient.
- TTTx Token transfer transaction
- FIG 5 further illustrates the TTTx of Figure 4, and how individual tokens having various token values can be transferred via numerous blockchain transactions but retain their exact same token units and are not split/recombined. This illustrates the fungible nature of tokens formed in accordance with the use of the illustrative tokenisation system.
- FIGS. 6 and 7 illustrate an illustrative tokenisation system in use.
- Figure 8 shows an overview of a validation process which may be used in accordance with an illustrative tokenisation system.
- Figure 9 illustrates a logical sub-ledger of associated tokens issued by the same issuer and implemented on a blockchain ledger e.g. the Bitcoin blockchain.
- a blockchain ledger e.g. the Bitcoin blockchain.
- Such a logical sub-ledger may be referred to as a Token Ledger.
- Figure 10 illustrates an arrangement in which a change component or service provides users with change for denominated tokens when needed . This enables users to exchange tokens for others with different token units.
- Figure 11 illustrates a Minting transaction where the source of the issuer authority is from public keys held in a UTXO not otherwise tied to the minting transaction. Validation is performed by checking that the signatures in the minting action validly use the public keys tied to the identities of the issuer authorities in the referenced transaction.
- Figure 12 illustrates a Minting transaction where the source of the issuer authority is derived from control of a token or Issuer Certificate.
- validation is performed by tracing the history of the issuer certificate back to the Token Ledger establishment transaction.
- Figure 13 illustrates a process that involves a sender and receiver creating a blockchain transaction, and comprises steps taken by the receiver to use a 3rd party service to validate the tokens.
- Figure 14 illustrates a multiparty group blockchain transaction of the type a third token processing party can use to obfuscate the parties to a transaction by grouping many smaller exchanges into one large transaction. This is done using SIGHASH_SINGLE
- Figure 15 illustrates two separate blockchain transactions being paid via a register and showing that the register holds the funds for the users, and the user only provides the register with a signature. Signatures are signed using SIGHASH_NONE
- Figure 16 illustrates a process by which physical tokens with specific details regarding their serial number and value can be destroyed and re-issued as digital items that carry the serial number and value of the original note into the token ledger.
- Figure 17 illustrates a process by which a digital token with a unique identifier e.g. serial number and token value can be locked into a script controlled by an issuer who can then create physical representations of the digital tokens. These can be verifiably linked to the digital token, and then destroyed by depositing them back into a register controlled by or associated with the issuer and removing the digital token from the locking script.
- a unique identifier e.g. serial number and token value
- Figure 18 illustrates the use of a blockchain transaction to melt i.e. destroy a token formed in accordance with atokenisation system.
- Figure 19 illustrates the use of a blockchain transaction to re-mint i.e. re-issue a token formed in accordance with a tokenisation system.
- Figure 20 shows an establishment transaction which spends a UTXO into an issuer certificate which contains the identities and digital signatures of the Issuer's authorised representative(s).
- Figure 21 shows an establishment transaction that generates a root node that contains the signatures and digital signatures of the Issuer's authorised representative(s).
- Figure 22 shows an illustration of an embodiment of an example use case which implements a voting process as described below.
- Figure 23 shows a sub-ledger which is formed as a subset of a token ledger in accordance with one or more illustrative tokenisation systems.
- Figure 24 provides an illustration of an embodiment of the present diclosure in use for certifying the authenticity of a token.
- ETx Establishment Transaction
- Figures 9 and 23 An example of an ETx in use is shown in Figures 9 and 23.
- the ETx's function is to provide the necessary authorisation data and record from which the issuer will derive their authority and which then enables issuer-performed actions such as minting to be carried out.
- a single ETx can be used in the creation of more than one Minting Transaction for a given token ledger.
- the Establishment transaction different from the minting transaction in that it is a single event that marks the first action within a Token Ledger whereas an MTx is subsequent to the ETx and represents the act of creating the tokens which will be transacted within the Token Ledger.
- the establishment transaction includes at least one input whose script is signed by all relevant, participating parties and comprises at least one output that becomes an issuer certificate for the Token Ledger.
- issuer certificates are each represented by a UTXO held in a script controlled by an authorised representative of the issuer which allows for the underlying cryptocurrency tokens to be transferred.
- issuer performs an action such as the minting of tokens the UTXO that holds the certificate is used as an input to the transaction that performs the action and the certificate is transferred into a new UTXO that is an output of that transaction. In this way the certificate can be re-used an unlimited number of times and retains a linear history back to the token ledger's establishment transaction.
- Another example comprises an Establishment Transaction which creates a root node using data carried in an output script (In the context of the present disclosure we are using the term 'node' as a way to describe a node in a graph or tree of blockchain transactions rather than computers within a network). Examples of root nodes being used can be seen in Figure 11, 18, 19 and 21.
- the root node contains details that can be used to establish the identity of the issuer, their representatives and the requirements that must be met for those representatives to generate valid issuer transactions within the token ledger.
- issuer actions such as the minting of tokens are performed by an issuer or their authorised representative (s) applying their digital signatures to the transactions in a way that can be both detected and verified by users of the token ledger.
- Yet another version of the example system establishes a root node using the Metanet Protocol as known in the art (see https://wiki.bitcoinsv.io/index.php/Metanet_Protocol) and uses Metanet children of the Root Node to mark issuer-related transactions such as minting transactions.
- the nature of the requirements can be agreed by participating parties and signed prior to publishing the establishment transaction to the network.
- data such as text of the agreement can be transcribed directly into the root node as ASCII or JSON formatted text, as an embedded file in an acceptable format (e.g. PDF), stored prior in a separate transaction that is referenced within the Root Node, or held in a document that is stored offline and validated by signing parties using a document hash or other knowledge proof which is stored in the Root Node.
- Other types of data and insertion mechanisms can also be used.
- the UTXO that is used as the input to the establishment transaction must be created and committed to the ledger before the agreement is signed. This action can be performed by one of the participating parties, or by a third party with knowledge of the requirements of the establishment transaction's input script.
- the establishment transaction input can be structured using Bitcoin script to enable the participants to choose a multiplicity of outcomes.
- This script allows for parties to negotiate on the outcome prior to accepting the agreement, and for either party to reject the agreement, ending the negotiation process.
- the selection of an outcome is provable on-chain.
- one or more blockchain-implemented tokens are created by an issuing source (“Issuer”) via a blockchain transaction which we will, for the sake of convenience, refer to as a “minting transaction” (MTx) or "issuance transaction” because its submission to the blockchain mints i.e. generates/issues/creates new tokens which can be subsequently transferred on-chain between parties.
- MTx mining transaction
- Figures 11 and 12 provide illustrations of how a Minting transaction can be used to generate tokens.
- these tokens can be provided to users for onward transfer. We may refer to this as putting the tokens into "circulation”, because they can be shared and exchanged between parties who have wallets that arranged to operate in accordance with the tokenisation protocol.
- token ledger As illustrated in Figure 9, and discussed in more detail below, once a minting transaction puts tokens into circulation, they form a sub-ledger on the underlying blockchain in that they reside and are recorded on the blockchain as per traditional UTXOs, and are transferred from one transaction to another in the usual way. However, the tokens carried by the UTXOs are logically linked or associated with each other due to their common issuer and/or minting transaction. It should be noted that an issuer may use more than one Minting Transaction to generate tokens of a particular type. Conversely, a single minting transaction can be used to generate tokens of different types.
- token ledger to refer to a set (sub-ledger) of tokens residing on the blockchain and logically linked or associated by virtue of their common minting source.
- the Minting Transaction comprises input(s) and output(s) as detailed below.
- a given blockchain e.g. Bitcoin SV
- Each token ledger may manage its own set of unique tokenised resources (digital objects).
- Each token ledger is spawned by and traceable on-chain to an establishment transaction or root node. This is advantageous because it enables an organisation to utilise the attributes (security etc) of an existing blockchain.
- an issuer is able to mint tokens onto a sub-ledger with minimal complexity or resource requirements, and then observe that transfers have been performed.
- privacy for parties to the transfer is preserved in the same way as per a fiat cash transaction.
- the minting transaction digests a quantity of cryptocurrency (C) and also a portion of issuance data (IData) via one or more transaction inputs.
- C cryptocurrency
- IData issuance data
- these are received into the Minting Transaction via the same input, while in others they are provided via separate inputs.
- the only input may be a transaction input that provides the cryptocurrency units required for the creation of the token(s).
- the Minting Transaction has issuance data in an output but not in an input.
- the issuance data comprises one or more portions of data that attests and/or relates to the Issuer (Tl) of the token(s), and/or the Issuer's authority to issue them.
- This issuance data could be referred to, in the alternative, as an "authority token” or "certificate”.
- the term “certificate” may be used herein for convenience.
- the certificate functions as a means for maintaining and controlling the flow of issued tokens into and subsequently over the token ledger.
- the incoming quantity of cryptocurrency (C) e.g. Bitcoin, is received into the Minting Transaction from a previous transaction on the blockchain. It is used by the Minting Transaction to generate the underlying, supporting transfer mechanism or vehicle which, after minting, enables control of the token(s) to be transferred from the sender to a receiver. If more than one token (T) is to be minted in a given minting transaction, the quantity of cryptocurrency will be split into sub-quantities at least some of which are allocated to respective Tokens.
- C e.g. Bitcoin
- the quantity of cryptocurrency may be thought of as analogous to a print media or coinage in the field of traditional minting techniques, in which a portion of raw material is supplied to a coin stamper for processing into smaller, individual portions (coins) each comprising a sub-portion of the original coinage material and thus its own associated, intrinsic value.
- the Issuer can impose any desired restrictions on the usage of the tokens via the minting transaction. This can be achieved via the use of a smart contract, for example.
- the Issuer's ownership rights and usage control can be managed and preserved via the underlying blockchain network and its protocol.
- the token ledger may be created via a transaction which comprises a (smart) contract or a pointer to a contract that is recorded on the blockchain and which is referenced when new tokens are minted.
- Authorised signatories related to the Issuer may cryptographically sign the certificate/issuance data/node to provide a verifiable record of authorisation.
- the minting transaction also comprises a plurality of unspent transaction outputs (UTXOs).
- UTXOs unspent transaction outputs
- At least one of the UTXOs provides, comprises or is associated with the certificate.
- the certificate is the means by which the Issuer's authorisation to issue the tokens is injected into the system. It is also the means by which authenticity of the tokens can be verified in subsequent use, after minting.
- the certificate can comprise any type, format or content of data that is required for the purposes of the particular implementation.
- the Certificate could be passed to an output from an input with the same VOUT/VIN indices.
- the Certificate exists in a UTXO which is not spent in the issuance transaction and identifying details (e.g. transaction ID, Vout index, public key or keys) are reproduced within the minting transactions and used in to create digital signatures to link the minting transaction to the token issuer (Tl).
- the certificate may be a public key or other knowledge proof which is provably linked to the issuer through means external to the blockchain database and which are used to generate digital signatures to link the minting transaction to the issuer.
- minting information is used in the minting and subsequent verification processes, but not for token transfer purposes.
- minting information is not attached to, or carried forward by, the transfer transactions a user is required to verify the authenticity of a particular token by tracing its history back to the minting transaction and checking the information from there. This provides the technical advantage that authenticity and verification of source can be assured, and security of tokens improved, because if minting/issuer related information was carried forward with the token on each exchange a malicious third party could exploit that to counterfeit the token.
- the need for this check is analogous to the sort of checks performed by merchants when they are handed a bank note from a customer. If, for example, a merchant chooses not to check that a customer's £50 note was genuinely issued by the Bank of England and not a forgery, they take the risk of receiving a counterfeit token. Therefore, most merchants would opt to make a small amount of effort to verify the authenticity of the bank note eg checking the note's serial number or holding it up to the light to look for a watermark etc.
- the same or at least one different UTXO provides, comprises or is associated with token generation data, which we may refer to herein as a "minting record" (MR).
- the minting record may comprise data that relates to the token(s) that are issued by the minting transaction. This may include a list of all tokens created by the minting transaction and/or any desired data relating to those new tokens such as details of the tokenised assets that they represent, the amount of cryptocurrency associated with each token, a unique identifier such as (but not limited to) a serial number, any related artwork or specific constraints on use.
- the minting record may be provided as a pointer, reference or representation of the list or token-related data, and may be provided within the locking script of the minting record's output(s). In some examples, it may be provided as metadata at a location within the token-holding output(s) e.g. within a locking script of the UTXO, possibly after an OP_RETURN opcode.
- T-UTXOs Token Outputs
- the plurality of outputs also comprises at least one (but typically a plurality of) token related UTXOs which we might refer to as T-UTXOs for convenience to distinguish a token-carrying output from an output that comprises a certificate and/or minting record.
- a T-UTXO is a UTXO which represents a token (and thus a tokenised resource) in accordance with embodiments of the present disclosure.
- the underlying, cryptocurrency value of the newly minted coins are a sub portion of the incoming quantity of cryptocurrency (C).
- C the incoming quantity of cryptocurrency
- the whole of the incoming quantity may be allocated to the newly minted coin. In all cases, whether one or more coins are minted, any remaining change will be returned as mentioned above.
- All of the tokens being minted by a given MTx represent token types and unit quantities that the issuing authority is permitted to issue under the conditions of the contract that established the token ledger.
- a token has two types of "value" or units/quantity of resource associated with it:
- token value or "token units (TU)) of the tokenised asset/resource being represented by the token; this can be any type of asset, entity, item or resource. (For ease of reference hereafter we will simply use “resource” as including all of these terms).
- resource could be:
- a legal right or obligation such as a licence to use some resource such as a car, or run some software or download some content (e.g. movie) for a specified period of time; or an obligation to perform conditions of a contract; a share of a patent right
- a virtual and/or digital asset such as a right to access a computer network or file, or cryptocurrency, or a digital ballot paper or selection in a voting system
- Tokens are spent by transferring the underlying cryptocurrency (e.g. Satoshis) into a new owner's address using a Bitcoin script.
- Control of the satoshis represents control of the token.
- Tokens minted in the same transaction can have different underlying satoshi values.
- Each token's token value (i.e. quantity of resource units) does not change after minting irrespective of the number of times it is transferred.
- a token cannot be split after minting, in that its value is fixed. Therefore, in a preferred system, the underlying quantity of cryptocurrency units associated with a given token cannot be changed after minting.
- the protocol may permit alteration of the number of cryptocurrency units in certain ways as long as the token's original token value specified by the minting transaction is not altered. For example, an issuer could issue a token with X underlying Satoshis and then create an output that contains X+Y Satoshis. This would enable a user to draw down on Y to pay transaction fees for transferring that token on condition that the number of Satoshis never reduces to below X as a balance. In this way, the token value can be supplemented but is retained.
- the tokens can be created such that the output scripts require any desired variation of signatories. This provides a significant benefit in terms of flexible script options for receiving tokens into, and enhanced functionality.
- Bitcoin-implemented examples include, but are not limited to:
- embodiments of our illustrative token system provide the ability of the issuer to establish secondary, self-contained Token Sub-Ledgers within their Token Ledger. This can be performed through the performance of an establishment transaction within the primary token ledger that uses the issuer's authority (depending on the implementation) of the main establishment transaction to create a sub-ledger to manage a particular set of tokens from the primary token ledger. Tokens transferred into the token sub-ledger can be given additional properties or different properties relative to those in the primary token ledger, or can be used as a reference or source for the minting of new tokens of different types. These additional or changed properties are defined in the establishment transaction in the same way as the primary Token Ledger's properties are defined.
- the token sub-ledger retains the same properties of the token ledger within which it was created.
- tokens When tokens are issued within a token sub-ledger, the use of those tokens is restricted to the bounds of that token sub ledger.
- Tokens created in a token sub-ledger cannot be transferred into the primary token ledger.
- tokens from within the primary token ledger can be used as inputs to a token sub-ledger minting transaction and broken down into smaller token sub-units or sub-types within the token sub ledger.
- a token after a token has been minted it can be transferred or "spent" from a sending party to a receiving party.
- the first transaction will spend the token from its T-UTXO in the Minting Transaction output list to an input in one or more further transactions. From there, the token can be spent to another recipient and so on, generating an evolving transactional history on the blockchain with each spend event.
- each token is generated as an unspent transaction (T-UTXO) that is included in a minting transaction (MTx) formed in accordance with the present disclosure
- each T-UTXO comprises a specified amount of cryptocurrency in compliance with the underlying blockchain protocol; in the Bitcoin protocol this would be zero or more Satoshis.
- This may be referred to herein as a quantity, amount or portion of token-related cryptocurrency (TRC) to distinguish it from the cryptocurrency (C) that is spent from a previous transaction into the Minting Transaction to enable the individual T-UTXOs to be created
- Each token represents a tokenised resource; therefore, it has an associated value arising from or associated with that resource. This may be referred to herein as the token's "face value”, “denomination”, “token units” or its “token value” to distinguish it from the value or quantity of the underlying cryptocurrency that carries the token for the purpose of enabling transfer over the blockchain in accordance with the underlying blockchain protocol
- each token is represented as a UTXO in a blockchain transaction; these transactions and UTXOs do not deviate in terms of formatting or appearance from conventional TXs and UTXOs.
- Embodiments of the example system do not require any deviation from, or alteration of, the underlying blockchain protocol
- Each user's tokens are stored using a script in accordance with, and specified by, the issuer's requirements. As the skilled person will appreciate, this can be achieved using known techniques such as multi-signature scripts or using accumulator scripting to capture different authorisations and structures.
- each token can be traced back, via its history on the blockchain, in a linear fashion to the Minting Transaction that created it; this enables authorisation and source to be verified to prevent counterfeiting and other unauthorised usage; however, embodiments of the present disclosure provide alternative and improved techniques for this trace-back-to-minting approach, as described in detail in the following section entitled "Detailed Description of Illustrative Embodiments” o
- Each token is transferred from a sender to a recipient by spending the UTXO that comprises it into an input in a subsequent blockchain transaction.
- the sender's digital wallet spends the UTXO to an address controlled by the recipient's digital wallet.
- the receiving wallet has been arranged and configured in accordance with the protocols and methods of the examples described herein. Therefore, the receiving wallet knows that it is expecting a token in accordance the system and must verify that this is the case.
- the receiving wallet knows the VOUT index of the UTXO that the token is contained in, so initiates a verification check of the token's history by checking that the cryptocurrency that was spent to that UTXO came from an input residing at the VIN index that matches the UTXO's VOUT index, and that this in turn came from a UTXO whose cryptocurrency came from an input residing at the VIN index that matches its VOUT index and so forth.
- the scanning process continues until a blockchain transaction is reached where the VOUT holding the token has no corresponding VIN. In other words, the linear transaction history terminates. If the transaction does not have a corresponding VIN, either the transaction is the minting transaction or the token is invalid. From here, the scanning process reads the Minting Record from the corresponding/designated output and validates that the token is genuine and was minted in a transaction that carries the signature of the issuing party's representative. Thus, in order to verify a token's history in accordance with this approach, the wallet uses the aggregate Merkle proofs of each transaction it has been used in on the blockchain since it was minted. This is illustrated in Figure 8.
- each token is created within a unique UTXO and is transacted without splits or combinations, its history is linear and can be quickly checked on the ledger.
- a token with a 1000 transaction history would carry approximately 1MB of history assuming 100 billion Txs/day on the Bitcoin blockchain.
- the Bitcoin ledger is publicly inspectable, wallets and third parties are able to verify tokens on behalf of other parties and users.
- a transfer transaction can also comprise one or more UTXOs and/or inputs that are not formed or used in accordance with the example token system.
- a service provider e.g. payment processor
- This also provides the advantage that tokens can be mixed and ownership obfuscated. This can provide security benefits because a malicious party cannot identify the owner of a particular token and thus target an attack. Therefore, a transaction can be used to take token inputs from multiple users and send different tokens to the desired receivers other than the ones signed by the spending party.
- an individual token has a token value. If a user wishes to transfer a given amount of token value, but no single token has been minted of sufficient token value or a particular user's wallet does not control a single token of that value, multiple tokens with smaller token values will need to be sent so that they add up to at least the desired overall token value. In such situations, the sending party's wallet selects tokens that it controls and (at least partially) signs multiple token UTXOs in a blockchain transaction (Tx) which add up to at least the required overall value.
- Tx blockchain transaction
- GTx group transaction
- transactions may be processed in a payment channel.
- a user's wallet receives new tokens they can be stored for onward payment at a later date. If the user needs to make a transfer for a certain overall token value, tokens can be selected from the wallet and added to the group transaction.
- the transaction may have a time lock mechanism (e.g. nLocktime) that prevents it from being mined by the blockchain network until a particular time, or until the subsequent block is found. Tokens are added to the payment channel.
- the wallet evaluates the TXID of the transaction that was included to check which version of the group transaction was recorded and begins building a new transaction for the payment channel.
- Figures 18 and 19 illustrate the use of transactions to perform melting and re-minting operations.
- Transactions that perform these re-stamping or re-minting actions must only be performed by the issuing authority to prevent users from fraudulently stamping them with incorrect information and so must also include a 'Minting Record' and either spend the issuer's certificate into a new output or include the signatures of the issuing authority as per the specifications of the particular token ledger.
- the tokens can be removed by the issuer by spending them out of the register into a Melting transaction, removing the tokens and the underlying cryptocurrency from the token register.
- the issuer creates the mint record as a spendable UTXO.
- the mint record can be spent into a new output that contains details of the expired tokens. In this way when a user does a validation check on the linear history of the token they can see if the token is still current.
- the issuer may have a contract with Bitcoin node operators who can remove the tokens from circulation by transferring them directly into a melting transaction, effectively transferring the tokens and the underlying currency from the user's wallets and back to the issuer.
- the issuer may publish information regarding the removal from circulation of tokens with certain properties and offer replacement tokens of the same value to users who transfer the obsolete tokens back to the issuer's control. This method allows the tokens to continue to circulate naturally, allowing people to hold the old versions as collectible items or simply as untouched savings without risk to the token value.
- one, some or all of the following three elements may be combined to form a network arranged to implement the protocols and methods disclosed herein:
- Trustholds are distributed threshold signature generators. They are networks of computers which provide users with threshold signature slices that can be combined to create an ECDSA signature. User wallets have access to the network, for example via an API, and include a software module to manage signature recombination.
- a Trusthold's function therefore, comprises relieving the user of the responsibility of key backup and management. They each validate the user's identity and provide signatures for their tokens. Users such as individuals merchants, banks or other entities are able to cryptographically sign their transactions via a trusthold. Advantages of using a trusthold include the use of secure, distributed network, and a reduced risk of losing access to controlled resources.
- the wallet's main functions may include:
- searching for and processing data stored via an associated tree or graph in order to monitor data relating to a computer-implemented transfer or other process (e.g. details of tokens sent/received, any alias associated with one or more parties and other data such as, for example, EDI records).
- data relating to a computer-implemented transfer or other process e.g. details of tokens sent/received, any alias associated with one or more parties and other data such as, for example, EDI records.
- a wallet user may request a trusthold sign message hash on demand. In other situations, the user can ask the trusthold(s) to pre-sign their tokens for spending.
- the trusthold(s) In systems where tokens are signed using 'SIGHASH_ANYONECANPAY
- These signed tokens can be held by the wallet to be handed to recipients.
- a recipient can store a pre-signed token and send it back to a receiver (e.g. a bank) for exchange with other tokens held within a pool or set of other minted tokens.
- Figure 7 illustrates a token systemusing a wallet to conduct a token transfer. With reference to Figure 7:
- Step 1 User 1 receives a token value transfer request and selects one or more Token UTXOs they control to a value equal or greater than the requested amount.
- User 1 may receive information regarding the receiver's identity, a receiving script/scripts generated by the receiver, or both.
- Step la Where User 1 has not been passed receiving scripts their wallet or a money handling service they subscribe to conducts alias lookups to discover the receiving scripts to send the funds to. If the user does not have exact change, this process can include a negotiation to receive change from the receiving party or an API connection to a change providing service.
- Step 2 Once User 1 has correct change, their wallet sends a signature request for each token selected in Step 1 to nodes in their trusthold network who create 'signature slices' needed for User l's wallet to build USERlsig for each selected token's ScriptSig.
- signatures can be signed using SIGHASH_ALL if the transaction is being handed directly to the receiver, or can use SIGHASH_SINGLE
- Step 3 Each of the fully signed tokens is passed to the receiver at the same time as they are broadcast to nodes on the blockchain network, completing the transfer.
- Figure 10 illustrates an example of a change service as mentioned in step la above. With reference to Figure 10:
- Step 1 a user wallet connects to a change server API to define transaction requirements and request receiving script.
- Step 2 The change service responds with receiving script / scripts.
- Step 3 The user sends signed tokens to the change service wallet.
- Step 4 The change service sends change back to the user's wallet.
- Figure 13 also shows a wallet in use in accordance with an example.
- Step 1 A Sender's wallet connects to a Receiver's wallet alias lookup/provision service to request a receiving script for a token delivery.
- Step 2 The Receiver wallet's alias service responds with receiving script / scripts.
- Step 3 The Sender signs and sends tokens to receiver wallet
- Step 4 The Receiver sends the token UTXO details to a validation service.
- Step 5 The validation service performs a Merkle proof lookup, tracing the linear transaction history back to the back to token's minting transaction.
- Step 6 The validation service validates the token's authenticity using the Minting authority provided via the MTx
- Step 7 If needed, the receiver makes an alias request to the Sender's wallet for receiving scripts to send tokens from its own wallet to provide change. These are applied to the transfer transaction before it is sent to nodes on the Bitcoin network to be processed.
- a register may be a computer- implemented resource which comprises a wallet arranged to process tokens that are minted and used in accordance with the present disclosure.
- the register may be a fully automated system component. The use or otherwise of a Register will be dictated by the requirements of a particular use case and its implementation.
- FIG. 2 shows illustrative embodiment(s) of the disclosure in which:
- token(s) for at least a required overal token amount or value are sent from a sender to a Register, and then tokens for at least the required overall amount are sent onwards from the register to a receiver; if tokens for more than the required overall amount are transferred, change is provided to the sender from the register or the receiver; performing the exchange via the register enabes a record of the transaction plus the transfer of ownership/control of the incoming and outgoing bills to be included in the Register.
- Tokens(s) for at least the required token amount are sent directly to the receiver without going via a register; if tokens for more than the required overall amount are sent, change is provided to the sender from the receiver or some other party.
- Figure 3 also show two possible tokenisation apporaches.
- an issuing entity creates and maintains a register of tokens.
- Each token that is issued is written to the register so that for each token that is put into circulation there may be a record comprising (at least) an identifier/serial number which uniquely identifies the respective token, and the token value associated with that token. If a token is withdrawn from circulation for some reason, it can be removed from the register using a melting action as illustrated in Figure 18.
- a user which receives a token from the register may then transfer tokens to other users via the register or directly from user to user without going via the register.
- Step 1 User 1 receives a token value transfer request and selects one or more Token UTXOs they control to a value equal to or greater than the requested amount.
- User 1 may receive information regarding the receiver's identity, a receiving script/scripts generated by the receiver, or both.
- Step 2 User 1 sends a signature request for each token selected in Step 1 to nodes in their trusthold network who create 'signature slices' needed for User l's wallet to build USERlsig in each selected token's ScriptSig using SIGHASH_NONE
- Step 3 User l's register operator receives the partially signed token or tokens into their register and receives the details of the value transfer which can include receiver identity or identities, receiving scripts and transfer amount. If scripts have not been supplied, the register operator conducts alias lookups to discover receiving scripts on behalf of the user.
- Step 4 The register operator selects appropriate tokens to make the full payment and any change payment from the partially signed tokens it has received for other transactions and holds in its register. It completes the signature process by signing each using SIGFIASFI_ANYONECANPAY
- the receiving script can represent any type of wallet used in the token ecosystem without restriction.
- FIG. 15 Possible implementations which make use of a register are also provided in Figure 15.
- User 1 signs tokens 1, 2 and 3 for transfer to User 2.
- User 1 signs tokens held in a multi-signature account, co-signed by the register, allowing the register to transfer them forwards into transactions to other receivers.
- User 3 is also shown signing tokens 4, 5 and 6 for transfer to the register.
- the Register creates outputs to a group transaction using other pre-signed tokens that it holds in its pool to complete transfers to users 2 and 4 in a single on-chain action
- wallets face the challenge of how to manage unspent transaction outputs (UTXOs) and any required change.
- UTXOs unspent transaction outputs
- the remaining change is sent back to the payer's digital wallet.
- fiat cash in which a buyer hands over ten dollars for payment of a $9.50 transaction. It may be that the $10 is provided as two $5 bills, a $10 bill, or a $5 bill plus 5 lots of $1 bills. In any event, the 50C change is handed back.
- implementations of the token system provide mechanisms for exchanging assets (eg cryptocurrencies, tokens, data etc) via a blockchain network which solve at least these technical challenges, including enhanced privacy and security for blockchain-enabled digital wallets.
- assets eg cryptocurrencies, tokens, data etc
- newly minted tokens may be assigned to or associated with a unique identifier. This may be performed via the Minting Transaction. This may be any type of identifier which can be used to refer to the token and distinguish it from other tokens that may be minted by the Issuer. We will refer to it as a "serial number" for convenience.
- a serial number is embedded in the output script (scriptSig) of the T-UTXO of a given token in the Minting Transaction. The serial number can then be carried forward with the token as it enters into circulation within the network.
- serial numbers may be a hash of the TX used to create the tokens. However, this is less preferred because of a reduced level of control.
- a particular embodiment might process the transaction identifier (TXID) through a hashing function to create a unique identifier for the first output, and process the unique identifier for the first output through the same hashing function to generate a second unique identifier for the second output and so on.
- the issuer is unable to determine the serial number of an issued token prior to the issuance action and the identifier is not recorded onto the blockchain as part of the minting record.
- the tracing of the bills back to the creation event can be done easily by tracking the usage of the bill back through the token's transaction graph.
- Serial numbers may be used to track or link the provenance of the tokens to the issuer and to index user transactions in a user's database/register.
- a Group transaction may spend all fully signed output tokens into new scripts assigning them to new owners. This can enable dynamic re-assignment of tokens up until a time specified in a time lock mechanism. It is also possible to withhold the outgoing tokens at a wallet's discretion.
- the medical practice has implemented a system which utilises tokens in accordance with the present disclosure.
- the medical practice owns some Bitcoin and uses it to generate a minting transaction that issues a set of tokens as described above. These tokens can be used to present pharmaceutical prescriptions.
- Each doctor within the medical practice has a digital wallet which controls a private key that can sign the unlocking scripts of the pharmacy's token T-UTXOs so as to authorise the transfer of tokens to a patient.
- the digital wallet is arranged to implement the protocol disclosed herein, so can accept, verify, transfer and process tokens as described above.
- the patient has also installed a digital wallet that can receive, send and process the practice's tokens in accordance with the protocol.
- the doctor After examining the patient, the doctor decides to prescribe some medication so she uses her wallet to generate a blockchain transaction which has a UTXO that comprises a locking script which can only be unlocked using a key controlled by the patient's wallet and also a key controlled by an authorised pharmacy.
- the doctor inserts a token comprising patient and prescription data into the UTXO's script.
- the token is then transferred from the doctor's wallet to the patient's wallet by spending the UTXO to an address owned by the patient's wallet.
- the customer When the customer arrives at the pharmacy, he presents the token he received from the doctor.
- the token must first be signed by the patient's own wallet and is then passed to the pharmacy's wallet for the pharmacist's authorisation.
- the pharmacist must be able to check that the prescription token is genuine and has not been forged. Therefore, the pharmacist's wallet traces the Token's transaction history on the blockchain to identify the minting transaction and checks the issuance data to verify the token. If verification is successful, redemption of the token can proceed. If not, the pharmacist declines to dispense the medication.
- the pharmacy wallet acts as its own trusthold and communicates with a network of pharmacies who each use their private cryptographic keys to sign the token. This gives the pharmacy network the ability to monitor prescriptions across groups of pharmacies to identify fraudulent activities. In this way, an improved monitoring and control solution is provided.
- redemption may require the patient's signature, the pharmacist's signature and the medical practice's signature. Other variations are also possible depending on the requirements of the use case.
- Game tokens Suppose that a gaming engine mints Tokens for game-related items. Items within the game are generated using vanity signatures that hash to item names. For example, a signature whose hash creates an ASCII string that begins with 'sword' can present that signature on a token to the game company. The signature hash defines the item's purpose in the gaming world, and the token's linear transaction history adds weight to its accumulated experience.
- in-game items can be issued by the game's creators as a sellable token which can be traded for cash or other in-game currency but where the traded item's ownership and usage history is tracked in a token ledger.
- each interaction with the environment can cause damage or add experience to the item's history, eventually leading to alteration of the item's functionality or usage over time.
- Such items could be customised by their owners, and retain their unique properties when they are exchanged.
- Further possibilities include the tokenisation of in-game reward systems or the creation of usable currency for an in-game environment.
- embodiments may allow for game developers to collaborate to allow items to be used by players in multiple games or to be carried forward into game sequels, allowing game items to accumulate status over many years and platform iterations.
- Figure 17 illustrates a process by which a digital token with a unique identifier e.g. serial number and token value can be locked into a script controlled by an issuer who can then create physical representations of the digital tokens. These can be verifiably linked to the digital token, and then destroyed by depositing them back into a register controlled by or associated with the issuer and removing the digital token from the locking script.
- a digital token with a unique identifier e.g. serial number and token value
- Step 1 Tokens are spent into a locking script that requires a knowledge proof provably linked to the issuer.
- Step 2 Physical tokens are created that represent the digital tokens being used, and contain details including the token value, serial number and the details of the UTXO the digital token is currently held in on the ledger.
- Step 3 Physical tokens can be exchanged between trading parties. Receivers validate the provenance of the token by checking that the digital token is locked in the transaction output shown on the physical token. Checking may be done via PC, point of sale device, or using a smartphone or tablet application. When the physical token is deposited, information it contains is used to build a transaction that moves the digital tokens, triggering a process in which the physical token is destroyed.
- Such an embodiment is suited for a wide range of possible use cases and applications. Once of these is provided as follow with regard to voting/selection processes.
- Example 4 is described with reference to figure 22.
- certain embodiments can be arranged such that the tokens can be used to implement choice-making functions (which we will call “ballot papers” for ease of reference) in a selection process.
- This may be referred to as a "voting" system as known in the technical field, which should not be construed or mistaken as meaning purely political in nature.
- the term "voting” is used herein to refer to a process by which a choice or selection can be made and recorded. However, for the following example we will use an election process as this is readily understandable due to familiarity.
- an electoral commission establishes a Token Ledger in accordance with the disclosure for the purposes of conducting an election.
- the commission mints enough tokens to cover the voting process in each electorate, allowing for an extra quantity (e.g. 10%).
- Each token represents a ballot paper.
- Each ballot paper is then reproduced as a physical token containing a unique code which can be used to spend the digital token as part of a voting action.
- voters arrive at the polling station their identity is processed through the normal means, in a way that is disconnected from the tokenised ballot paper. Once their identity and right to vote has been independently established, a physical ballot paper token is transferred to the voter.
- a physical token can be picked at random from a pool of tokens provided to the polling station staff. In this way, the voter's identity is not known or attached to the physical token in any way, but the voter is now in possession of a token that represents their right to vote in the election.
- the voter then presents themselves at a booth where a computer interface (e.g. touchscreen display) is provided and provides the terminal with the unique code provided by their physical token.
- the computer checks that the code represents an unspent ballot paper and presents the user with a voting process in accordance with the local rules of the electorate. This could be by being shown on screen, or could include other communication means e.g. audio means for use by blind users.
- a further embodiment may provide the user with a printed record of their vote to place into a ballot box as a backup to the electronic process, and a further embodiment may use the unique physical token as the print media.
- the computer interface spends the ballot paper into a group transaction which is held in a timelocked payment channel that closes when the ballot is finished. If the user retains a record of their unique ballot paper they can verify that their vote was correctly recorded once the transaction is finalized.
- the issuer creates a Root Node to establish the token ledger that records the election's votes and outcome
- the issuer uses the authority from the root node to generate enough ballot papers for the election process to take place using a minting transaction
- a knowledge proof needed to spend each ballot paper is produced as a physical token with a secure device that a voter must break into through an irreversible process in order to reveal (e.g. tearable perforated sheet/scratch panel)
- Ballot papers are randomized and delivered to voting locations where they are distributed to voters who have presented adequate identification to participate in the election process.
- Voters reveal their ballot paper's knowledge proof by conducting the irreversible process needed to access it and present the information to a secure voting terminal.
- the terminal checks that the knowledge proof represents a valid token and presents the voter with a set of guided voting options.
- the voter goes through the voting process using the secure terminal and once finished, indicates through an action that they have completed selecting their options.
- the terminal generates a new UTXO which it uses to transcribe the voter's selection and uses the knowledge proof to sign the digital ballot paper using SIGHASH_SINGLE
- SIGHASH_SINGLE SIGHASH_ANYONECANPAY.
- a token can be created that is intended to pass through a state machine with a linear processing framework. In this way, a token can be created, and pass through numerous transfer operations, changing state each time. Some tokens may be processed back into standard blockchain UTXOs at the finalization of a state transition. In this way, the disclosure can be used to implement DFAs and automated systems which can be used in a wide range of scenarios and for many different purposes.
- the first state is a ticket booking which includes data such as flight and date. Prior to the flight, the user may change the booking which would involve a transition into a different booking state. The user may also add other services such as meals and a specific seat selection to their booking, each of which modifies the state of the ticket.
- the user checks into their flight they are assigned their final seating and the ticket changes state into a boarding pass. If the flight is cancelled, the ticket's state may be changed back into a booking.
- all of the underlying cryptocurrency that held the tickets that were used by all of the passengers on that flight can be processed back into a Bitcoin UTXO which the airline can then recycle into new tickets.
- tokens as disclosed herein can be thought of analgous to the use of fiat currency bank notes or coins which are issued as tokens by a national reserve.
- a Little bank note is a promissory note issued by the Bank of England, having a serial number, watermark and/or other identifiying features (eg artwork) that enable them to be verified as being issued by an authorised issuer.
- a Little bank note is fungible and may be exchanged directly between users Alice and Bob without an intermediary (i.e. a peer-to-peer cash transfer as per Satoshi Nakamoto's 2008 whitepaper title) simply by Alice handing Bob a £5 note or five £1 coins. Alternatively, Alice may pay Bob via the issuing bank or another intermediary.
- Alice or Bob may also destroy their convinced note or five £1 coins if they so wish. They may burn their bank note or melt their coins. Alternatively, the Bank of England may withdraw a bank note or coin from circulation so it can no longer be transferred between users. Similarly, tokens minted in accordance with the present disclosure can be destroyed by users or withdrawn/cancelled from ongoing use by an issuer. Also in common with tokens of the present disclosure, a bank note or coin retains its token value regardless of the number of times that it is transacted - a £5 note is always worth five pounds Stirling, whether it is used once or 10,000 times.
- a banknote cannot be split or recombined. If a £5 note is cut into 5 individual pieces of paper/plastic, or a £1 coin is melted down into smaller pieces of metal they will retain some (probably very small) instrinsic value relating to the resale of the paper and/or metals, but the (probably larger) token value is lost. In the same way, if a token minted in accordance with the present disclosure is used in a manner that is incompatible with the protocol, the underlying cryptocurrency may still provide some value to the owner but the usage as a particular type of token may be rendered ineffective.
- banknotes and coins are a simple, quick, and private means of transferring a tokenised resource between users, they are inefficient in that their printing medium is physical.
- some use cases of the present disclosure may provide a peer- to-peer elecontric cash solution as per Satoshi Nakamoto's original white paper which offers the advantages of cash but provides a cryptographically secured and enforced alternative, that reduces the opportunity for exploitation by unauthorised parties (eg counterfeiters and fraudsters) and removes the wastage, expense and inefficiency of physical print media.
- embodiments of the disclosure provide simple, efficient and yet powerful blockchain-implemented solutions which are fully aligned with Satoshi Nakamoto's original, ground breaking design.
- the benefits of such solution extend well beyond the use of blockchain trechnology for simply digital cash or currency in the same way that the Internet's benefits extend well beyond the simple provision of an electronic message or web page.
- Embodiments provide potential for solutions which have not yet been explored on the blockchain. Any type of resource can be tokenised using the disclosed embodiments, giving rise to a versatile and advantageous blockchain-implemented data transfer mechanism.
- the recognition and conception of the present disclosure has been obfuscated to date by current blockchain rules which restrict the size of transaction outputs to "dust" levels, and which have resulted in efforts being focussed on a combine-and-split paradigm at the transaction and token levels.
- Embodiments of the disclosure are able to exploit and harness the benefits of existing functionalities within blockchain protocols, such as Bitcoin's SIGHASH flags and flags with the same or similar functionalities in alternative protocols.
- embodiments disclosed herein comprise the use of unqiue, fixed-value, denominated tokens which can be quickly and efficeintly verified and enable the creation of systems for uses beyond the capabilities of known approaches.
- improved blockchain networks and solutions are provided.
- the disclosure avoids or at least alleviates the problem of complex wallet integration so that development resources such as time, effort, computing power and costs are minimised.
- Wallets do not need to interface with the blockchain network other than to obtain block headers for validating SPV proofs for tokens that they receive.
- Wallets are simplified in that in some embodiments they do not need to build transactions, they can simply receive, sign and send the tokens in the usual way.
- embodiments of the disclosure provide the ability to construct hitherto unknown tokenisation systems and tools which store and transfer tokens using the simplest possible blockchain transaction outputs.
- embodiments of the disclosure do not require the Issuer to be party to each transfer transaction on the blockchain. This addresses problems faced by exsiting solutions with regard to privacy and scalability, as their resource and cost requirements can escalate relative to the number of users.
- token transaction is a blockchain transaction that has one or more token outputs
- a token output being an output that comprises or is in some way associated with at least one token, as shown in Figure 4.
- To check whether a blockchain transaction is a token transaction one can trace back to a mint transaction via the transaction chain. However, this may be difficult to do when the system is at scale because the increasing length of token's history chain over time results in a growth of required resources for the tracing and comparison operations.
- the following techniques can be used in addition or, preferably, as alternatives to the approach of tracing back to an original minting transaction in order to certify that the token(s) have been issued by an authorised party.
- embodiments of the disclosure provide mechanisms which avoid the need to trace all the way back to the minting transaction (MTX). Instead, at least one token verification/certification element (CE) is inserted into the token transaction chain at some point following the mint transaction(s), so that a verifying entity (VE) only needs to trace back from a given or current token transaction (which we may refer to as a "target token transaction") to an identifiable certification element.
- a Certification Element is shown inserted into a token transaction (TTx) in a chain of token transactions. The tracing process performed by the verifying entity can stop when the certification element is encountered in the chain, safe in the knowledge that the token has been issued by or on behalf of the issuer.
- each token transaction in the chain could be stamped by the issuer (or their authorised representative) to authenticate the token(s) it carries.
- this could require significant resources on behalf of the issuer and the verifying/using party.
- the chain is periodically stamped with a certification element so that the need to traverse the chain back to its origin is alleviated along with the need to stamp every transaction in the chain.
- Another advantage of periodic stamping is that it enables use of offline token transactions. This can be highly advantageous in circumstances where connectivity over the internet and other networks is not available. For example, transactions and transfers made on an aeroplane or in geographic locations where connectivity is not possible. Such offline transfers are not possible with prior art approaches where the issuer is required to stamp every transaction.
- the token certification element certifies that the at least one token provided in the token transaction was generated by or on behalf of the issuer.
- the token transaction comprises one token, while in other it may comprise more than one token. From hereon, we refer to a singular token for ease of reference.
- one or more than one certification element may be provided in a token transaction, and the token(s), token transaction and/or certification element(s) may be issued by one or more issuers using one or more mint transactions. We refer, though, for convenience, to these in the singular.
- the at least one token certification element is provided in the token transaction in response to a request or instruction.
- the request or instruction could originate from a token user, or an intended recipient of the token, or the issuer or their representative, or some other party.
- the certification element can be provided in the token transaction in accordance with at least one predetermined rule or criteria. Performance or evaluation of the rule/criteria can be automated and performed by a software-based component which may be executed by or on behalf of a validating entity.
- the at least one pre-determined rule or criteria could, for example, specify a threshold, interval or metric for identifying or selecting the transaction within the chain of token transactions so that the certification element can then be inserted into it by the issuer or an entity that is authorised to do so by the issuer.
- the certification element comprises some form of evidence that the token is genuine or authentic, in that it has been legitimately formed by the issuer(s). In this way, it legitimizes the token(s) in the token transaction and its presence in the transaction serves as a substitute for the mint transaction during a verification process.
- the certification element can take any suitable form that fulfils this role, such as, for example, proof of a secret known to or associated with the issuer; and/or cryptographic data.
- Cryptographic data could comprise a cryptographic key, a signature, a digitally signed message or other cryptographic element associated with the issuer or a party authorised by, representative of or associated with the issuer.
- the certification element provides evidence that can be trusted as belonging or known only to the issuer/authorised party.
- the certification element can be provided in the at least one token transaction in a variety of locations and/or formats. For example, it could be inserted into the transaction at a location following an instruction or code, for example after an OP_RETURN other instruction. It could be provided elsewhere in a script, and/or provided as metadata.
- the chain may comprise multiple certification elements which are provided in contiguous token transactions or, preferably, at spaced intervals.
- the interval between them may be defined by the afore-mentioned rule or criteria.
- a certification element may be provided every x number of token transactions on the ledger. Other metrics for determining the interval may be readily devised and implemented.
- the certification element may be inserted into the chain on a random or ad hoc basis, or (as previously mentioned) in response to a triggering even such as a request, instruction or monitored state.
- the monitored state may relate to an entity, resource or condition which is located on or off the blockchain.
- the certification element can be utilised by any entity or party that needs to validate or certify that the token(s) in a given token transaction were, indeed, issued by the issuer. This could, for example, be the validating entity or a user or a token client. Traditionally, such a party needs to establish the token's provenance by tracing the transaction chain back to the mint transaction to verify that it has, indeed, been generated by the issuing source, but embodiments of the disclosure enable the verifying party to traverse the chain of token transactions only from the token transaction to a previous token transaction that comprises a token certification element. This saves a significant amount of energy, time and processing resource.
- Embodiments of the disclosure may comprise features relating to melting and re-minting of the token. These features may be provided in addition to, or alongside and in conjunction with, the validation technique described above.
- the at least one token is provided in a token transaction on a blockchain and is generated in an original mint transaction by or on behalf of an issuing party.
- the token is melted and reminted. In some embodiments, this may be performed on an ad hoc random or pseudo-random basis, although in a preferred embodiment it is performed when a pre-determined threshold, limit or specified value has been reached.
- Melting in accordance with one form of wording, can be described as modifying the token or the token transaction, or performing some off-chain operation such that the token is no longer deemed valid or certified/authenticated by the issuer.
- Re-minting in accordance with one form of wording, can be described as modifying the token or the token transaction, or performing some off-chain operation such that the token remains valid or certified/authenticated by the issuer but performance of the modification or other operation can be verified.
- the token remains valid and approved by the issuer but its validity is re-incarnated in a different form. It is no longer valid in its previous form.
- Figure 19 shows a re-minting process.
- the melting operation can comprise providing an identification element, marker or other portion of data to indicate that the token is no longer valid.
- the specific mechanism used for melting and re minting will depend upon the implementation involved in the tokenisation system that is being used, but in one example embodiment, it can comprise providing an identification element, marker or other portion of data to indicate that the token is no longer valid.
- re-minting can be performed in a variety of ways, including providing an identification element, marker or other portion of data to indicate that the token is valid but in a modified form.
- the identification element can take a variety of forms, including an identifier e.g. serial number and/or cryptographic data such as, for example, a cryptographic key, signature, signed message etc.
- the identification element is associated with the at least one issuer or a party authorised by the at least one issuer, and serves as approval or issuance by the issuer.
- the identification element can be provided in a blockchain transaction, preferably in the token transaction (TTx), or in a storage resource provided off the blockchain.
- the pre-determined threshold, limit or specified value can be monitored by the issuer or some other party, to determine when it has been reached. This may involve comparing it against a supplied value. When the issuer or other party determines that the threshold has been reached or exceed, the melt and/or re-mint operations can be performed. This provides the advantage of reducing required resources and improving efficiency as explained above.
- the pre determined threshold, limit or specified value is determined by or on behalf of the issuer or a validating entity.
- Statement 2 The method of statement 1, wherein the at least one token certification element is provided in the token transaction: in response to a request or instruction; and/or in accordance with at least one predetermined rule or criteria.
- Statement 3 The method of Statement 2, wherein the at least one pre-determined rule or criteria specifies a threshold, interval or metric for identifying or selecting the transaction within the chain of token transactions.
- the at least one certification element comprises: proof of a secret known to or associated with the at least one issuer; and/or cryptographic data, preferably wherein the cryptographic data is or comprises a cryptographic key, signature, digitally signed message or other cryptographic element associated with the at least one issuer or a party authorised by the at least one issuer.
- Statement 6. The method of any preceding Statement wherein the at least one certification element is provided in the token transaction: following an instruction or code which renders the token transaction unspendable (e.g. an OP_RETURN statement in some blockchain protocols); or in a script of the transaction, wherein the script is associated with an output of the transaction.
- Statement 7 A method according to any preceding Statement and comprising the step of providing the same or a different certification element in at least one further token transaction in the chain of token transactions.
- a blockchain-implemented method of validating at least one token provided in a token transaction on a blockchain that is an element in a chain of token transactions originating from at least one minting transaction used by, or on behalf of, an issuer to generate the token; wherein the method comprises: inspecting the token transaction to determine whether it comprises at least one token certification element which certifies that the token was generated by or on behalf of the issuer; and/or traversing the chain of token transactions on the blockchain from the token transaction until a previous token transaction is identified in the chain which comprises at least one token certification element which certifies that the token was generated by or on behalf of the issuer.
- Statement 9 A method according to Statement 8 wherein the step of traversing the chain of token transactions is performed if, and only if, the token transaction does not comprise the at least one token certification element.
- a method according to Statement 8 or 9 wherein the step of traversing the chain of token transactions comprises: inspecting a token transaction in the chain to determine whether it comprises the at least one token certification element.
- Statement 11 A method according to Statements 8 to 10 wherein the at least one certification element comprises: proof of a secret known to, or associated with, the at least one issuer; and/or cryptographic data, preferably wherein the cryptographic data is or comprises a cryptographic key, signature, digitally signed message or other cryptographic element associated with the at least one issuer or a party authorised by the at least one issuer.
- Statement 13 A method according to Statement 12 wherein: the token transaction is traceable on the blockchain to at least one mint transaction issued by or on behalf of at least one issuer (702).
- a method according to Statement 12 or 13 wherein melting the at least one token comprises providing an identification element, marker or other portion of data to indicate that the token is no longer valid; and/or re-minting the token comprises providing an identification element, marker or other portion of data to indicate that the token is valid but in a modified form.
- Statement 15 A method according to Statement 14 wherein the identification element is: an identifier and/or cryptographic data; and/or associated with the at least one issuer or a party authorised by the at least one issuer; and/or provided in a blockchain transaction, in the token transaction or in a storage resource provided off the blockchain.
- Statement 16 A method according to Statements 12 to 15 and comprising: assessing whether the pre-determined threshold, limit or specified value has been reached by performing a comparison of a supplied value against the threshold, limit or specified value.
- Statement 17 A method according to Statements 12 to 16 wherein the pre-determined threshold, limit or specified value is determined by the at least one issuer or a party authorised by the at least one issuer (702), a user (703) or a validating entity (701).
- Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of Statements 1 to 17.
- Statement 19 A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of Statements 1 to 17.
- a blockchain-implemented token generation, transfer and/or verification method comprising: using, processing and/or generating a blockchain transaction (MTx) having: i) one or more token-related outputs (T-UTXOs), each of which represents a respective token (T) issued by a Token Issuer (Tl) and specifies a quantity of a) token units (TU) and b) token- related cryptocurrency (TRC) associated with the respective token (T); and ii) at least one Issuer-related output (l-UTXO) comprising issuance data (IData) associated with the Token Issuer (Tl).
- MTx blockchain transaction
- T-UTXOs token-related outputs
- T-UTXOs token-related outputs
- the TRC may be a variable amount of cryptocurrency in that the quantity of units e.g. may change.
- the transaction (MTx) further comprises: i) at least one input comprising a quantity of cryptocurrency (C); and/or ii) at least one input comprising the issuance data (IData).
- the Issuance data is provided in the same or a different input that comprises the quantity of cryptocurrency (C).
- the issuance data comprises, or references, a digital signature controlled by and/or associated with the Token Issuer (Tl).
- Tl Token Issuer
- at least one of the one or more token-related outputs comprises a unique token identifier (tokenID) associated with the token represented by the token-related output (T- UTXO).
- MTx further comprises: at least one input and/or output comprising token generation data (MR) relating to the one or more Token-related outputs (T-UTXOs).
- MR token generation data
- a method according to any preceding clause and further comprising the step of: using a token transfer transaction (TTTX) to transfer control, to a recipient, of a particular token represented by one of the one or more token-related outputs (T-UTXOs).
- TTTX token transfer transaction
- T-UTXOs token-related outputs
- a method according to clause 6 and further comprising the step of: using at least one further token transfer transaction (TTTXi) to transfer control of the particular token (T) to the same or a further recipient
- a method according to clause 6 or clause 7 and further comprising the step of: providing a solution in an unlocking script of an input in the token transfer transaction (TTTx) or at least one further token transfer transaction (TTTXi) to a locking script of the token-related output (T-UTXO) that represents the particular token.
- a method comprising the step of: providing a physical representation of at least one of the respective tokens represented by the one or more token-related outputs (T-UTXOs); preferably wherein the physical representation comprises means for identifying the at least one respective token.
- a method according to any preceding clause and further comprising the step of destroying the token by: removing it from a computer-based storage resources such as a token register; publishing data relating to the destruction of the token; and/or spending an unspent transaction output (UTXO) that comprises token generation data (MR) relating to the one or more Token-related outputs (T-UTXOs).
- UTXO unspent transaction output
- MR token generation data
- T-UTXOs Token-related outputs
- a blockchain-implemented token transfer and/or verification method comprising the step of using and/or generating a blockchain transaction (TokenTx) comprising an input which includes a token (T) and which: i) is linked in a linear transaction history on the blockchain to a token-issuing blockchain transaction (MTx) which comprises at least one Issuer-related output (l-UTXO) associated with issuance data (IData) relating to a Token Issuer (Tl) that Issued the token (T); and ii) comprises a quantity of: a) token units (TU) specified in a token-related output (T-UTXO) of the token issuing blockchain transaction (MTx); and b) token-related cryptocurrency (TRC).
- TokenTx comprising an input which includes a token (T) and which: i) is linked in a linear transaction history on the blockchain to a token-issuing blockchain transaction (MTx) which comprises at least one Issuer-related output (l-UTXO) associated with issuance data (IData)
- a method wherein: the blockchain transaction (TokenTx) is used and/or generated by a computing resource that is arranged to implement a tier-2 blockchain tokenisation protocol.
- a method according to any of clauses 12 to 14 and further comprising the step of transferring the token (T) from a Sender (S) to a receiver (R) by: spending the output (UTXO) of the blockchain transaction (TokenTx) to an input (I) in a receiving blockchain transaction (RTx), wherein an index or other identifier associated with the output (UTXO) corresponds to an index or other identifier associated with the Input.
- a digital wallet arranged and configured to use or process the method of any preceding clause.
- the wallet may be operative to communicate with a blockchain network. It may be operative to provide blockchain transactions to the network.
- the wallet is arranged to operate on a computing device such as, for example, a laptop or mobile device. 17.
- a computer implemented method comprising the step of: generating, storing, processing and/or maintaining a computer-based resource (R) of a plurality of token-related blockchain transaction outputs (T-UTXOs), wherein each of the outputs (T-UTXOs): i) provides a respective token (T) issued by a Token Issuer (Tl) and specifies a quantity of a) token units (TU) and b) token-related cryptocurrency (TRC) associated with the respective token (T); and ii) has a linear transaction history to a blockchain transaction (MTx) that comprises at least one
- Issuer-related output which includes issuance data (IData) associated with the Token Issuer (Tl).
- each token-related blockchain transaction output (T-UTXO) is generated and/or spent by a computing component arranged to implement a tier-2 blockchain tokenisation protocol and comprises at least one partially signed locking script.
- a method according to clauses 9 to 11 and further comprising the step of: receiving, at the computer-based resource (R) from a sending device (S), a token (T) provided by one of the plurality of token-related blockchain transaction outputs (T-UTXOs); storing at least one Token (T), received from a sending device, in the computer-based resource (R); and/or sending at least one Token (T) to a receiving device, wherein the token is provided by an output (T-UTXO) selected from the resource (R) of token-related blockchain transaction outputs (T-UTXOs)
- a computer network comprising a plurality of nodes, wherein each node in the blockchain network comprises: a processor; and memory including executable instructions that, as a result of execution by the processor, causes the system to perform the computer-implemented method of any preceding clause.
- the network may be, or comprise, a blockchain network.
- a non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by a processor of a computer system, cause the computer system to perform the computer-implemented method of any one of claims 1 to 20.
- Another aspect of the disclosure may provide a computer-implemented selection/voting method and corresponding system.
- the method/system may comprise steps and/or devices as recited in any of the preceding clauses.
- blockchain to include all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction-chain technologies, permissioned and un-permissioned ledgers, shared ledgers, public and private blockchains, and variations thereof.
- consensus-based blockchain and transaction-chain technologies include consensus-based blockchain and transaction-chain technologies, permissioned and un-permissioned ledgers, shared ledgers, public and private blockchains, and variations thereof.
- the term "Bitcoin” is intended herein to refer to any version or variation that derives from, or is based on, the Bitcoin protocol.
- other non-Bitcoin blockchain implementations have been proposed and developed and alternative blockchain implementations and protocols fall within the scope of the present disclosure.
- the term "user” may refer herein to a human or a processor-based resource.
- the skilled person will readily understand that in the art it is usual to refer to spending of cryptocurrency in terms of sending coins from one address/owner to another. However, in reality, no actual “coins” are transferred. Instead, control of ownership is transferred from one script to another.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Embodiments provide improved solutions for verifying one or more tokens provided via a token transaction on a blockchain. The token transaction is generated by an issuer and forms a link in a chain of token transactions which can be traced back to a minting transaction that was used by the issuer to generate the token(s). At least one certification element is provided in one or more token transactions within the chain, wherein the certification element certifies the authenticity of the token(s) by or on behalf of the issuer. A validating entity need only traverse the token's history chain back to a transaction which comprises a certification element rather than back to the mint transaction. Additionally, or alternatively, the disclosure provides improved solutions for melting and reminting the token when a pre-determined threshold, limit or specified value has been reached. Melting and reminting may comprise issuance on the blockchain of a new mint transaction subsequent to the original mint transaction in the token's chain of history, or replacement of an issuer-associated component such as an identifier which serves thereafter to identify the token, the issuer and/or the new or original mint transaction.
Description
Computer Implemented Systems And Methods For Improved Authentication of Blockchain-Based
Tokens
Field
This disclosure relates generally to methods and systems for electronic exchange between parties. Embodiments utilise, at least in part, a distributed ledger (blockchain) to facilitate the secure and efficient transfer of control of a tokenised resource from one party to another. The disclosure is generally suited, but not limited, to use in respect of the distribution of tokenised assets across a computing network. Verification of these tokenised assets is improved, enhancing security and reducing vulnerability to transfers and exploits by unauthorised parties. Embodiments enable the implementation of improved digital wallets which are able to exchange data in new and technically advantageous ways.
In particular, the present disclosure relates to methods and systems for validating, issuing, updating, replacing or otherwise processing blockchain-based tokens that are implemented using token transactions. A token transaction is a blockchain transaction that comprises one or more token outputs. Embodiments of the disclosure are particularly suited for use in relation to systems in which tokenised assets need to be verified to confirm their legitimacy and issuance by an authorised party. Embodiments provide numerous technical advantages including, but not limited to, improved efficiencies, reduced processing requirements and increased security of blockchain-based transfers.
Background
The Bitcoin blockchain ledger as introduced in 2008 by Satoshi Nakamoto's whitepaper (https://bitcoin.org/bitcoin.pdf) is the most widely known blockchain and associated network/platform in use today. Therefore, we will refer to Bitcoin in the examples used herein. However, embodiments of the disclosure are not limited in this regard and alternative blockchain protocols and implementations fall within the scope of the present disclosure.
A blockchain transaction is a data structure formed in accordance with a blockchain protocol and comprises at least one input and at least one output. Control of the cryptocurrency that is digested/received by the input(s) is spent/transferred from the output(s) of the transaction to the input(s) of further transaction(s) that are added to the blockchain in subsequently mined block(s). Any portion of the cryptocurrency that is not transferred to a new receiving address/owner/receiver is sent back to the current address/owner/sender as "change". Inputs and outputs are ordered and
numbered within their respective transactions so that they can be referenced. In the case of outputs, they form a zero-indexed Vector (list) based on their position within the transaction's outputs. An output's index number is known as its "Vout" index. With respect to inputs, each input in a transaction is identifiable by the transaction identifier (TxlD) and the Vout of the output that it will spend. The inputs in a given transaction are also listed in a zero-indexed Vector, this time known as "Vin". In this way, each input references an identifiable output in a previous transaction on the ledger, thus creating a chain so that the immutable transfer history of each cryptocurrency unit can be verified by traversing the blockchain back to the unit's originating source. In the Bitcoin protocol, this could be a coinbase transaction in which the cryptocurrency was created by a miner as a reward for Proof-of-Work effort, or the very first block of the ledger which is usually known as the Genesis block.
Although it has gained publicity as a means of transferring cryptocurrency, the wider applicability of blockchain technology is somewhat analogous to the way that the Internet provides an underpinning support layer for many distributed services, communications and data sharing technologies. In the same way as the Internet forms the backbone of many more computer-implemented solutions beyond just the provision of web pages, blockchain platforms can provide the underlying mechanism that enables much more than just the transfer of cryptocurrency. For example, blockchain transactions can be used to transfer other types of data in addition to digital money, thus driving technologies across a wide spectrum of industries and applications. This additional data is often referred to as "metadata" and could potentially comprise any type or format of data, such as text, media content, images, links to off-chain locations or resources, executable code, smart contracts, hashes of such data etc.. The ability to transfer data, plus blockchain-implemented technologies such as smart contracts, the Metanet, Simplified Payment Verification (SPV) and more, have resulted in the use of blockchain platforms as an underlying infrastructure or vehicle that other "layer 2" technologies can be built upon.
These include layer 2 tokenisation solutions which use the blockchain as an underlying transfer mechanism for communication of electronic tokens. A token is a digital object or item that is used to represent some other object or resource, physical or otherwise. Blockchain tokenisation technologies provide numerous technical advantages such as improved security, efficiency, ease of use and enhanced network privacy. However, known tokenisation approaches also face numerous technical challenges. These include, but are not limited to, the following problems. Firstly, current token solutions require some type of third party infrastructure to handle authorisation of actions
and verification of the token's authenticity. Such infrastructures can be costly in terms to develop and operate, both financially and in terms of required computing resources and time and, therefore, can be inefficient. They can also require the use of trusted third parties which, in turn, can lead to security concerns and increased potential for attacks, exploits and breaches. Moreover, wallet integration can be a significant challenge as the process is often complex and time consuming.
Other challenges include, but are not limited to, concerns over the scalability of tokenisation solutions, concerns surrounding privacy for users and therefore potential for targeted exploits, the need for off-chain token processing or transfer which means that such solutions are not fully cryptographically enforced and immutably verifiable on a public ledger, or require that the user inserts data into a script in order to process the tokens. Moreover, some tokenisation schemes lend themselves only to handling of certain types of tokens, which means they are restricted with regard to wider applicability and cannot be extended or adapted for use in a more diverse, potentially desirable implementations. These, and other challenges faced by current blockchain-implemented tokenisation schemes, are not trivial to address.
Moreover, as known in the art, some tokenisation protocols specify that the token validation rules are embedded within script inside the token transaction. These can be designed in such a way that the script proves the validity of a token all the way back through the chain of transaction until issuance. This is achieved by creating a hash puzzle that requires the previous transaction to be inserted as a solution (the transaction ID is the hash digest, and the transaction itself is the hash preimage). However, since each token transaction necessarily contains all of the data of the previous transaction, by induction it must contain all previous transactions back to issuance. This means that the size of each token transaction increases cumulatively, meaning that the latest transaction in the chain may be very large. This increased transaction size therefore increases the resource demands relating to bandwidth and storage requirements and the cost of writing to the ledger.
Therefore, for at least these reasons, it is desirable to provide enhanced efficiencies for validation and issuance of tokens on a blockchain, without compromising any of the security features implemented by the tokenisation protocol or the underlying blockchain protocol.
Summary Of The Disclosure
As explained above, portions of cryptocurrency (tokens) are included in blockchain transactions as part of the underlying transfer mechanism specified by the blockchain's protocol. However, blockchain transactions can also be used to transfer ownership or control of other, additional assets
which are tokenised and represented on the ledger. Embodiments of the present disclosure relate to the processing of these additional tokens, rather than the protocol-level cryptocurrency required by the blockchain network's protocol.
Using the blockchain to issue and spend tokens in of and itself is not novel. Known approaches have included the issuance of tokens using transaction outputs e.g. using an OP_RETURN or OP_FALSE OP_RETURN commands, in a UTXO-based approach in which tokens are coupled to transaction outpoints. Being more aligned with the native blockchain system, UTXO-based token systems share some advantageous features of the blockchain system in addition to the security such as in-script smart contracts for tokens. It also allows token issuers to peg their token value to the native blockchain token value.
Whichever tokenisation approach is adopted, however, there is a need to validate (or "authenticate") the tokens that have been issued to verify that they have been generated by an authorised issuing entity. The need to validate a given token can arise for various reasons. For example, receiving parties will wish to ensure that the token(s) they receive are genuine. This typically involves tracing a token's transactional history back to its originating (minting) transaction to be able to compare and validate a portion of minting data known to originate from the token issuer with data provided in the token transaction.
Flowever, a technical challenge arises in some situations where a token's chain of history has grown over time to such an extent that tracing its history on the blockchain back to a minting transaction becomes expensive in terms of time and also the amount of processing resources required. Inefficiencies can therefore build over a token's lifetime as a result of its usage to the point where, in certain conditions, a token's history can become so extensive that it renders continued use of the token impractical and too costly in terms of resources.
When this occurs, the issuer may choose to destroy the token or withdraw it from use in its current form and may re-issue it. This process can be re-referred to as a "melt and re-mint" operation as it is analogous to the concept of melting down a traditional coin in a fiat currency system when it has become compromised or damaged in some way over time. To keep a required number of coins in circulation, a newly minted replacement can be issued by the minting authority. Clearly, the need to melt and remint incurs costs and requires resources for the issuing authority, and so it is disadvantageous to have to perform this operation on a frequent basis.
In accordance with one aspect of the present disclosure, a computer-implemented method is provided which may be defined as, at least, a method of validating, certifying and/or endorsing/attesting the authenticity a blockchain-implemented token. "Certification" may be understood herein to include: a stamp of legitimacy or authenticity, a proof of origin or provenance, and/or a confirmation of authorship/creation by a specific entity. "Validating" may be understood to include: checking, testing and/or confirming the legitimacy, authenticity, origin, authorship, certification or provenance of a blockchain-implemented token. In some embodiments, the token may be formed and/or processed in accordance with a protocol in which token validation rules are embedded within a script of the token transaction.
Embodiments of the disclosure enable blockchain-based tokens to be validated quickly and efficiently, and without the need to trace the token's provenance back to its origin on the blockchain. This provides significantly enhanced efficiencies and the requirement of fewer resources on behalf of parties who process the tokens (e.g. senders, receivers, issuers) as they do not need to traverse and process extensive token histories. Fewer resources are also consumed due to a reduced need to replace such tokens, or at least a reduction in the frequency of doing so. Moreover, embodiments of the disclosure, by either melting-and-reminting or stamping the tokens, enable a reset of the size of the latest transaction in the token transaction chain. Therefore, very large savings of transaction size are achieved. This is turn leads to a reduced bandwidth requirement, storage requirement, and cost of writing to the ledger.
The method comprises the step of adding a certification element to a token transaction that is an element in a chain of token transactions. The term "token transaction" may include a blockchain transaction which comprises at least one token, wherein the token represents a tokenised asset of any form and stored on or off chain, and the token is formed in accordance with a tokenisation protocol which is distinct from but implemented on top of the underlying blockchain protocol that is operated by the network nodes.
The chain of token transactions originates from a minting transaction which is used by the issuer, or by an authorised party on behalf of the issuer, to generate the token. Each token transaction, starting from the minting transaction onwards, passes the token on to the next element (token transaction) in the chain. Therefore, the token has a traceable and immutable, unbroken history on the blockchain ledger in the form of token transactions back to its mint transaction. Certain token
transactions along that chain of history comprise a certification element. Advantageously, this removes or at least alleviates the need to trace the token's history all the way back to its originating (minting) transaction for verification/certification purposes as the verifier need only follow the history back to the last token transaction in the chain which contains a trusted certification element.
At least one, some or all of the token transactions in the chain comprise a certification element which serves as a verifiable mark, certificate or stamp of authenticity associated directly or indirectly with an authorised entity e.g. the token issuer or some other party that is trusted as an authorised or approved certification entity that can attest to the origin and/or legitimacy of the token on the issuer's behalf. In accordance with alternative wordings, the certification element may be referred to as a stamp or confirmation of authenticity.
The certification element may provide proof of knowledge of a secret that is known to be associated with or controlled by the issuer. In a preferred embodiment, one or some but not all of the token transactions in the chain may comprise a certification element. This provides the advantage of being more efficient because of the processing costs associated with provision of the certification element within the token transactions. (Hereafter, the term "issuer" may include other parties which are authorised by the issuer to act on their behalf).
In some embodiments, the same certification element may be provided in a plurality of token transactions within the chain. In other embodiments, however, a different certification element may be provided for each or some of the selected token transactions. Importantly, though, whether the same or different certification elements are used in the token transactions, the certification element(s) serve the purposes described above for facilitating attestation of the origin of the token.
In one or more embodiments, the certification element might take the form of cryptographic data such as a cryptographic element that can be provably associated with, or authorised by, the issuing entity. This could be, for example, a cryptographic key or a message signed using a key that is known to be associated by the issuer. The skilled person will readily understand that the certification element can take any suitable form which enables a verifying entity to establish that it has been provided and/or authorised by the issuer and that its provision in the token transaction serves as proof or evidence of the token's provenance, legitimacy and/or authenticity.
In one or more embodiments, the certification element may be added to the token transaction in accordance with at least one predetermined rule or criteria such as, for example, when the token has been spent (transferred) a pre-determined number of times. The criteria or rule may be determined by the issuer, a token owner/receiver/controller, or some other party. In other embodiments, the certification element may be added to a token transaction in the chain in response to a request, instruction or other signal. In this latter scenario, the insertion of the certification element may be performed on a more ad hoc basis rather than in a prescriptive manner.
In one or more embodiments where a predetermined rule or criteria is used to control or influence which token transaction(s) the certification element is added to within the chain, the certification element may be included in the chain at a predetermined interval such as every 100 transactions, or after a specified period of time such as each day or week (assuming, in this case, that the token will be involved in a sufficiently high frequency of transactional activity). Other criteria and rules may be utilised, but in essence certain embodiments of the disclosure comprise the use of one or more predetermined metrics or which specify which elements of the chain (transactions) the certification element is to be added to.
In one or more embodiments, the certification element can be added to a token transaction in any suitable manner known in the art. For example, in some protocols this may be after an OP_RETURN while in others it may be in a script which includes OP_FALSE OP_RETURN commands. In other embodiments, the certification element may be provided in a locking script of an output in the token transaction, and/or provided as metadata. The skilled person will readily understand that the certification element can be provided in association with the token transaction in a variety of ways and at a variety of locations within the transaction to provide the same advantageous effect.
In accordance with another aspect of the disclosure, there is provided a computer-implemented method of providing a blockchain-implemented token. In order to alleviate issues relating to lengthy history chains, an issuer may melt and re-mint one or more tokens provided in a token transaction, so that the token's prior history remains on-chain as a verifiable and auditable record of original provenance and authenticity, but the new mint transaction takes the place of the original mint transaction for verification purposes. To reduce the amount of processing resources required by the melt and re-mint process, this can be performed at periodic intervals so that the effort required to
trace back to a minting transaction is reduced for the verifying party but the overheads associated with melting and reminting are also minimised for the issuer/certifying party.
The frequency at which the melt and re-mint process is performed can be predetermined according to at least one rule, criteria or metric, which can be evaluated by an automated resource such as a bot, oracle or other software component. For example, the tokens may be re-issued once a specified threshold, limit or measurable/quantifiable value has been reached. This may be the number of transactions written to the token's history chain on the blockchain since the original or last mint transaction, or every x number of token transactions written to the chain, or at periodic time intervals etc.. This provides the advantage of predictability for token users and/or owners. Alternatively, the melt and re-mint process can be performed on an ad hoc or random/pseudo random basis.
The disclosure is not limited with regard to the particular mechanism used for melting and re minting the tokens. In one embodiment, for example, an identifier associated with the token and used in previous token transactions in its history may be replaced by a new identifier.
Additionally, or alternatively, embodiments may comprise a blockchain-implemented method of issuing at least one token provided in a token transaction on a blockchain. The method may comprise the step of melting and reminting the token when a condition is met. This condition may, for example, comprise determining that pre-determined threshold, limit or specified value has been reached or identified. This provides the advantage that a token's chain of history can be re-started under certain conditions, thus reducing the resources required for processing the lengthy history as mentioned above. Thus, such embodiments provide improved efficiency in terms of storage, processing and time during blockchain-implemented transfers, which retaining security and protection against fraud because the assurance of the token's authenticity is preserved.
In such embodiments, the token transaction is traceable on the blockchain back to at least one mint transaction issued by or on behalf of at least one issuer. Melting the at least one token may comprise providing an identification element, marker or other portion of data to indicate that the token is no longer valid. Additionally, or alternatively, re-minting the token may comprise providing an identification element, marker or other portion of data to indicate that the token is valid. The identifier may provide an indication that the token has been re-minted, and is provided in a modified form relative to one or more previous versions.
The identification element can take any suitable form such as, for example, an identifier and/or cryptographic data. It can be associated with the at least one issuer or a party authorised by the at least one issuer, and can be provided in a blockchain transaction, in the token transaction or in a storage resource provided off the blockchain.
The step of assessing whether the pre-determined threshold, limit or specified value has been reached or encountered may comprise performing a comparison of a supplied or calculated value against the threshold, limit or specified value. The pre-determined threshold, limit or specified value may be determined by the at least one issuer or a party authorised by the at least one issuer, a user or a validating entity.
Summary Of An Illustrative Tokenisation System Which Embodiments of the Present Disclosure May be Used With
Embodiments of the present disclosure may be implemented and used within the context of a wider tokenisation protocol that provides techniques, protocols and systems for creating, using, processing, and transferring tokenised assets or resources via a blockchain (ledger) that is associated with an underlying blockchain protocol and network. This underlying blockchain protocol/network may be, for example, a version of the Bitcoin protocol and its associated network and platform but other blockchain protocols and implementations may be used and fall within the scope of the present disclosure.
For purposes of illustration, we describe how embodiments of the disclosure can be used with an illustrative tokenisation system wherein one or more tokens are generated via the use of an issuing or "minting" transaction. A token may, in the alternative, be considered as a "digital object" and may provide an on-blockchain representation of some tokenised resource or units thereof. The minting transaction comprises issuance data which testifies to the issuer's identity and/or authority to issue the tokens, and serves as a verification means during transfer and processing of the tokens in subsequent use.
The minting transaction also comprises one or more outputs (UTXOs), each of which represents a token. In turn, each token represents a quantity of tokenised asset or resource of some type. In some cases, the tokenised asset/resource may be expressed as a quantity of unit(s). The tokenised resource can take any form. For example, it can be a digital or virtual asset, an abstract entity or a
physical entity. The token's pre-determined quantity of resource units is specified when the token is minted and during use the protocol requires that this quantity of tokenised resource units remains fixed i.e. immutable or unchanging in some respect despite their transfer over the blockchain. For the sake of convenience, the terms "token value" or "denomination" may be used interchangeably herein with "quantity of tokenised resource" or "token units". According to the illustrative tokenisation system,, the token is represented by a fixed quantity of cryptocurrency units (e.g. Satoshis or some other type of cryptocurrency) held in the locking script of a UTXO that has a linear history linking it to the token's creation in a minting transaction via the ledger.
When the token is to be transferred from one party to another, a solution for the locking script plus a reference to the UTXO holding the token are used as an input in a new transaction which spends the token-holding UTXO to a new locking script specified by the receiving party. As is known in the art, spending of a UTXO requires the transfer of control of a quantity of cryptocurrency from one address to another, and so transfer of the token is performed upon spending of an underlying portion of cryptocurrency. In some illustrative tokenisation systems, the issuance data and/or other data is also transferred along with the token and cryptocurrency.
When the token is transferred, the UTXO holding the token is used as an input to the transaction and a quantity of cryptocurrency tokens must be spent into an output with the same index as the input for the token transfer to be valid. In this way, ownership of the token is passed to the new UTXO's controlling party. This method has the benefit of being easily traceable on the public ledger due to the matching indices of input and output (Vin and Vout) in each transaction, resulting in improved speed and efficiency when validating the provenance of the token. However, in other illustrative tokenisation systems the transfer of the token can be performed through the linking of the input containing the token to an output of the transaction through other mechanisms such as, for example, a signature or identifier placed into the locking script of the new UTXO that holds the token.
Irrespective of the particular linking technique used, though, a token used and arranged in accordance with the illustrative tokenisation system can be described as having a linear transaction history when that token has a complete history of being transferred without there being any change to the originally ascribed token value applied in the minting transaction. This means that the token is always transferred wholly into a single, separate and unique UTXO without having its token value split, merged, duplicated or modified in any way. This means that the transaction history of a token
can be represented as a series of linear actions in which each action transfers the token in the same form in which it was created in the minting transaction. Because of this, the overhead required to manage token transfers is very low, and can be applied in a way that pushes the transfer governance process down onto the nodes of the Bitcoin network to manage as part of their role in transaction validation.
Each time a token is transferred, its identity and authenticity as a token in accordance with the protocol of the example system can be verified. As the token's transaction history is linear and the tokenised resource units (TU) represented by the token (T) is not split or altered during transfer, this can be performed quickly and efficiently. The blockchain record can be provably traversed until the minting transaction is reached, as illustrated in Figure 8. The issuance data and/or minting record associated with the minting transaction can be checked to ensure that the token is a genuine, authorised token. Known techniques and technologies such as Simplified Payment Verification (SPV), Metanet graphs etc can be used in conjunction with other techniques to further enhance efficiency and speed of verification or transfer, while preserving security. However, embodiments of the present disclosure can be used to avoid or minimise the need to trace back to an originating minting transaction, as described below.
Brief Description of the Drawings
Aspects and embodiments of the present disclosure, and illustrative computing environments with which it can be used, will now be described, by way of example only, and with reference to the accompany drawings, in which:
Figure 1 is a flowchart illustrating steps in an illustrative tokenisation system/protocol which can incorporate a preferred embodiment of the disclosure.
Figures 2 and 3 shows illustrative tokenisation systems, some of which utilise an intermediary register and some which do not.
Figure 4 shows the Inputs and Outputs of a Token transfer transaction (TTTx), in which tokens go into and out of the same VOUT index in the same blockchain transaction and retain their exact token; moreover, tokens that are sent into a wallet in respect of a given exchange or transaction may not (in fact, most likely will not) be the same tokens that will be sent for onward transfer to a recipient.
Figure 5 further illustrates the TTTx of Figure 4, and how individual tokens having various token values can be transferred via numerous blockchain transactions but retain their exact same token units and are not split/recombined. This illustrates the fungible nature of tokens formed in accordance with the use of the illustrative tokenisation system.
Figures 6 and 7 illustrate an illustrative tokenisation system in use.
Figure 8 shows an overview of a validation process which may be used in accordance with an illustrative tokenisation system.
Figure 9 illustrates a logical sub-ledger of associated tokens issued by the same issuer and implemented on a blockchain ledger e.g. the Bitcoin blockchain. Such a logical sub-ledger may be referred to as a Token Ledger.
Figure 10 illustrates an arrangement in which a change component or service provides users with change for denominated tokens when needed . This enables users to exchange tokens for others with different token units.
Figure 11 illustrates a Minting transaction where the source of the issuer authority is from public keys held in a UTXO not otherwise tied to the minting transaction. Validation is performed by checking that the signatures in the minting action validly use the public keys tied to the identities of the issuer authorities in the referenced transaction.
Figure 12 illustrates a Minting transaction where the source of the issuer authority is derived from control of a token or Issuer Certificate. In this example, validation is performed by tracing the history of the issuer certificate back to the Token Ledger establishment transaction.
Figure 13 illustrates a process that involves a sender and receiver creating a blockchain transaction, and comprises steps taken by the receiver to use a 3rd party service to validate the tokens.
Figure 14 illustrates a multiparty group blockchain transaction of the type a third token processing party can use to obfuscate the parties to a transaction by grouping many smaller exchanges into one large transaction. This is done using SIGHASH_SINGLE | SIGHASH_ANYONECANSPEND on all tokens
being spent, which locks each input/output pair but allows the processing party to have the freedom to stack them into a single large transaction, or even to break them out into multiple separate transactions.
Figure 15 illustrates two separate blockchain transactions being paid via a register and showing that the register holds the funds for the users, and the user only provides the register with a signature. Signatures are signed using SIGHASH_NONE | SIGHASH_ANYONECANPAY as the output destination is not determined at the time the tokens are signed. The register then takes other, separate tokens that have been pre-signed by other register users and spends them out to the fund recipients in a group transaction.
Figure 16 illustrates a process by which physical tokens with specific details regarding their serial number and value can be destroyed and re-issued as digital items that carry the serial number and value of the original note into the token ledger.
Figure 17 illustrates a process by which a digital token with a unique identifier e.g. serial number and token value can be locked into a script controlled by an issuer who can then create physical representations of the digital tokens. These can be verifiably linked to the digital token, and then destroyed by depositing them back into a register controlled by or associated with the issuer and removing the digital token from the locking script.
Figure 18 illustrates the use of a blockchain transaction to melt i.e. destroy a token formed in accordance with atokenisation system.
Figure 19 illustrates the use of a blockchain transaction to re-mint i.e. re-issue a token formed in accordance with a tokenisation system.
Figure 20 shows an establishment transaction which spends a UTXO into an issuer certificate which contains the identities and digital signatures of the Issuer's authorised representative(s).
Figure 21 shows an establishment transaction that generates a root node that contains the signatures and digital signatures of the Issuer's authorised representative(s).
Figure 22 shows an illustration of an embodiment of an example use case which implements a voting process as described below.
Figure 23 shows a sub-ledger which is formed as a subset of a token ledger in acordance with one or more illustrative tokenisation systems.
Figure 24 provides an illustration of an embodiment of the present diclosure in use for certifying the authenticity of a token.
Detailed Description of An Illustrative Tokenisation System
Examples of some possible illustrative tokenisation systemsand use cases are now provided for the purpose of illustration, without limitation. As explained above, for the sake of convenience only, we will refer herein to "Bitcoin" for our examples as it is the most well-known and widely used blockchain protocol. Preferred embodiments of the disclosure may be implemented on the Bitcoin protocol, platform and ledger, although this and the references to Bitcoin are not intended to be limiting and the scope of embodiments of the present disclosure is not thus restricted.
The Establishment Transaction
Consider a tokenisation system which involves the use of an Establishment Transaction (ETx). An example of an ETx in use is shown in Figures 9 and 23. The ETx's function is to provide the necessary authorisation data and record from which the issuer will derive their authority and which then enables issuer-performed actions such as minting to be carried out. As illustrated in Figure 9, a single ETx can be used in the creation of more than one Minting Transaction for a given token ledger. The Establishment transaction different from the minting transaction in that it is a single event that marks the first action within a Token Ledger whereas an MTx is subsequent to the ETx and represents the act of creating the tokens which will be transacted within the Token Ledger. It is the linear history that can link every token in the token ledger back to a specific Minting Transaction and every minting transaction back to the authority created in the Establishment Transaction that gives the disclosure some of its most important properties including low overhead, simple traceability and unique yet fungible tokens.
The establishment transaction includes at least one input whose script is signed by all relevant, participating parties and comprises at least one output that becomes an issuer certificate for the Token Ledger. This is shown in Figure 20. In this example, issuer certificates are each represented
by a UTXO held in a script controlled by an authorised representative of the issuer which allows for the underlying cryptocurrency tokens to be transferred. Each time the issuer performs an action such as the minting of tokens the UTXO that holds the certificate is used as an input to the transaction that performs the action and the certificate is transferred into a new UTXO that is an output of that transaction. In this way the certificate can be re-used an unlimited number of times and retains a linear history back to the token ledger's establishment transaction.
Another example comprises an Establishment Transaction which creates a root node using data carried in an output script (In the context of the present disclosure we are using the term 'node' as a way to describe a node in a graph or tree of blockchain transactions rather than computers within a network). Examples of root nodes being used can be seen in Figure 11, 18, 19 and 21. In this version, the root node contains details that can be used to establish the identity of the issuer, their representatives and the requirements that must be met for those representatives to generate valid issuer transactions within the token ledger. In this version, issuer actions such as the minting of tokens are performed by an issuer or their authorised representative (s) applying their digital signatures to the transactions in a way that can be both detected and verified by users of the token ledger.
Yet another version of the example system establishes a root node using the Metanet Protocol as known in the art (see https://wiki.bitcoinsv.io/index.php/Metanet_Protocol) and uses Metanet children of the Root Node to mark issuer-related transactions such as minting transactions.
The nature of the requirements can be agreed by participating parties and signed prior to publishing the establishment transaction to the network. In a different version, data such as text of the agreement can be transcribed directly into the root node as ASCII or JSON formatted text, as an embedded file in an acceptable format (e.g. PDF), stored prior in a separate transaction that is referenced within the Root Node, or held in a document that is stored offline and validated by signing parties using a document hash or other knowledge proof which is stored in the Root Node. Other types of data and insertion mechanisms can also be used.
In one or more tokenisation systems, the UTXO that is used as the input to the establishment transaction must be created and committed to the ledger before the agreement is signed. This action can be performed by one of the participating parties, or by a third party with knowledge of the requirements of the establishment transaction's input script.
The establishment transaction input can be structured using Bitcoin script to enable the participants to choose a multiplicity of outcomes.
Example: Simple contract DEPTH 2 EQUAL IF
2 <customer_pubkey> <contractor_pubkey> 2 CHECKMULTISIG RETURN <accepted>
ELSE
DUP <customer_pubkey> CHECKSIG IF
TRUE RETURN <rejected_by_customer>
ELSE
<contractor_pubkey> CHECKSIG RETURN <rejected_by_contractor>
ENDIF
ENDIF
This script allows for parties to negotiate on the outcome prior to accepting the agreement, and for either party to reject the agreement, ending the negotiation process. The selection of an outcome is provable on-chain.
The Issuing (Minting) Transaction
In accordance with one example system, one or more blockchain-implemented tokens (Ts) are created by an issuing source ("Issuer") via a blockchain transaction which we will, for the sake of convenience, refer to as a "minting transaction" (MTx) or "issuance transaction" because its submission to the blockchain mints i.e. generates/issues/creates new tokens which can be subsequently transferred on-chain between parties. Figures 11 and 12 provide illustrations of how a Minting transaction can be used to generate tokens.
Once minted, these tokens can be provided to users for onward transfer. We may refer to this as putting the tokens into "circulation", because they can be shared and exchanged between parties who have wallets that arranged to operate in accordance with the tokenisation protocol.
As illustrated in Figure 9, and discussed in more detail below, once a minting transaction puts tokens into circulation, they form a sub-ledger on the underlying blockchain in that they reside and are recorded on the blockchain as per traditional UTXOs, and are transferred from one transaction to another in the usual way. However, the tokens carried by the UTXOs are logically linked or associated with each other due to their common issuer and/or minting transaction. It should be
noted that an issuer may use more than one Minting Transaction to generate tokens of a particular type. Conversely, a single minting transaction can be used to generate tokens of different types. Herein we will use the term "token ledger" to refer to a set (sub-ledger) of tokens residing on the blockchain and logically linked or associated by virtue of their common minting source.
As per traditional blockchain transactions, the Minting Transaction comprises input(s) and output(s) as detailed below. In this way, a given blockchain (e.g. Bitcoin SV) may provide the foundation layer for one or more token ledgers. Each token ledger may manage its own set of unique tokenised resources (digital objects). Each token ledger is spawned by and traceable on-chain to an establishment transaction or root node. This is advantageous because it enables an organisation to utilise the attributes (security etc) of an existing blockchain. By creating such a layer on top of an underlying, public blockchain, an issuer is able to mint tokens onto a sub-ledger with minimal complexity or resource requirements, and then observe that transfers have been performed. However, privacy for parties to the transfer is preserved in the same way as per a fiat cash transaction.
Minting Transaction MTx Inputs:
In accordance with certain illustrative tokenisation systems, the minting transaction digests a quantity of cryptocurrency (C) and also a portion of issuance data (IData) via one or more transaction inputs. In one or more systems, these are received into the Minting Transaction via the same input, while in others they are provided via separate inputs. In some examples, however, the only input may be a transaction input that provides the cryptocurrency units required for the creation of the token(s). In such an example, the Minting Transaction has issuance data in an output but not in an input.
The issuance data comprises one or more portions of data that attests and/or relates to the Issuer (Tl) of the token(s), and/or the Issuer's authority to issue them. This issuance data could be referred to, in the alternative, as an "authority token" or "certificate". The term "certificate" may be used herein for convenience. The certificate functions as a means for maintaining and controlling the flow of issued tokens into and subsequently over the token ledger.
The incoming quantity of cryptocurrency (C) e.g. Bitcoin, is received into the Minting Transaction from a previous transaction on the blockchain. It is used by the Minting Transaction to generate the underlying, supporting transfer mechanism or vehicle which, after minting, enables control of the
token(s) to be transferred from the sender to a receiver. If more than one token (T) is to be minted in a given minting transaction, the quantity of cryptocurrency will be split into sub-quantities at least some of which are allocated to respective Tokens. In this way, the quantity of cryptocurrency may be thought of as analogous to a print media or coinage in the field of traditional minting techniques, in which a portion of raw material is supplied to a coin stamper for processing into smaller, individual portions (coins) each comprising a sub-portion of the original coinage material and thus its own associated, intrinsic value.
The Issuer can impose any desired restrictions on the usage of the tokens via the minting transaction. This can be achieved via the use of a smart contract, for example. Advantageously, the Issuer's ownership rights and usage control can be managed and preserved via the underlying blockchain network and its protocol. The token ledger may be created via a transaction which comprises a (smart) contract or a pointer to a contract that is recorded on the blockchain and which is referenced when new tokens are minted. Authorised signatories related to the Issuer may cryptographically sign the certificate/issuance data/node to provide a verifiable record of authorisation.
Minting Transaction (MTx) Outputs:
The minting transaction also comprises a plurality of unspent transaction outputs (UTXOs).
In a preferred embodiment, at least one of the UTXOs provides, comprises or is associated with the certificate. The certificate is the means by which the Issuer's authorisation to issue the tokens is injected into the system. It is also the means by which authenticity of the tokens can be verified in subsequent use, after minting.
The certificate can comprise any type, format or content of data that is required for the purposes of the particular implementation.
In some examples, the Certificate could be passed to an output from an input with the same VOUT/VIN indices. In some examples the Certificate exists in a UTXO which is not spent in the issuance transaction and identifying details (e.g. transaction ID, Vout index, public key or keys) are reproduced within the minting transactions and used in to create digital signatures to link the minting transaction to the token issuer (Tl).
In some examples the certificate may be a public key or other knowledge proof which is provably linked to the issuer through means external to the blockchain database and which are used to generate digital signatures to link the minting transaction to the issuer.
However, in one example, neither the certificate (IData) or minting record (MR) are used in the token transfer itself, and there is no authorisation certificate required for subsequent transfers once tokens are minted. Thus, the minting information is used in the minting and subsequent verification processes, but not for token transfer purposes. As minting information is not attached to, or carried forward by, the transfer transactions a user is required to verify the authenticity of a particular token by tracing its history back to the minting transaction and checking the information from there. This provides the technical advantage that authenticity and verification of source can be assured, and security of tokens improved, because if minting/issuer related information was carried forward with the token on each exchange a malicious third party could exploit that to counterfeit the token. Although this requires the user's wallet to expend some resources to perform the check, the linear transaction history and techniques such as SPV keep that overhead to a minimum. In some ways, the need for this check is analogous to the sort of checks performed by merchants when they are handed a bank note from a customer. If, for example, a merchant chooses not to check that a customer's £50 note was genuinely issued by the Bank of England and not a forgery, they take the risk of receiving a counterfeit token. Therefore, most merchants would opt to make a small amount of effort to verify the authenticity of the bank note eg checking the note's serial number or holding it up to the light to look for a watermark etc.
In the following section where we provide a detailed description of embodiments of the disclosure, we provide techniques which can be used additionally or alternatively to such an approach in order to reduce the overheads mentioned above in respect of checking the authenticity of the token.
Additionally, in some examples, the same or at least one different UTXO provides, comprises or is associated with token generation data, which we may refer to herein as a "minting record" (MR). In such examples, the minting record may comprise data that relates to the token(s) that are issued by the minting transaction. This may include a list of all tokens created by the minting transaction and/or any desired data relating to those new tokens such as details of the tokenised assets that they represent, the amount of cryptocurrency associated with each token, a unique identifier such as (but not limited to) a serial number, any related artwork or specific constraints on use. The minting record may be provided as a pointer, reference or representation of the list or token-related
data, and may be provided within the locking script of the minting record's output(s). In some examples, it may be provided as metadata at a location within the token-holding output(s) e.g. within a locking script of the UTXO, possibly after an OP_RETURN opcode.
Token Outputs (T-UTXOs):
The plurality of outputs also comprises at least one (but typically a plurality of) token related UTXOs which we might refer to as T-UTXOs for convenience to distinguish a token-carrying output from an output that comprises a certificate and/or minting record. A T-UTXO is a UTXO which represents a token (and thus a tokenised resource) in accordance with embodiments of the present disclosure. We may refer to an output that comprises the certificate (IData) as an l-UTXO.
In respect of one particular illustrative system, in which the Minting Transaction generates more than one new token, the underlying, cryptocurrency value of the newly minted coins are a sub portion of the incoming quantity of cryptocurrency (C). However, in an example where only one coin is to be minted by the issuing transaction, the whole of the incoming quantity may be allocated to the newly minted coin. In all cases, whether one or more coins are minted, any remaining change will be returned as mentioned above.
All of the tokens being minted by a given MTx represent token types and unit quantities that the issuing authority is permitted to issue under the conditions of the contract that established the token ledger. A token has two types of "value" or units/quantity of resource associated with it:
1. The quantity of units ("token value" or "token units (TU)) of the tokenised asset/resource being represented by the token; this can be any type of asset, entity, item or resource. (For ease of reference hereafter we will simply use "resource" as including all of these terms). For example, but without limitation, the resource could be:
• a physical resource such as car, house, racehorse, cinema ticket etc
• a legal right or obligation such as a licence to use some resource such as a car, or run some software or download some content (e.g. movie) for a specified period of time; or an obligation to perform conditions of a contract; a share of a patent right
• a virtual and/or digital asset such as a right to access a computer network or file, or cryptocurrency, or a digital ballot paper or selection in a voting system
• Financially or corporate-oriented assets such as fiat currency, commodities, stocks and shares etc
2. the non-negative portion of underlying cryptocurrency that has to be transferred as an essential mechanism of blockchain transactions; blockchain protocols operate via the transfer of some Satoshi (or other form of cryptocurrency) from an output in one transaction to an input in another transaction; therefore, the skilled person will readily understand that while this is the underlying mechanism or vehicle that makes the disclosed blockchain-embodiments work in practice, the known art of cryptocurrency transfer is not the novel or inventive aspect of the disclosure; instead, the innovation lies in the disclosed tokenisation techniques, systems and protocols which utilise those known blockchain mechanics.
Tokens are spent by transferring the underlying cryptocurrency (e.g. Satoshis) into a new owner's address using a Bitcoin script. Control of the satoshis represents control of the token. It should be noted that, in our example system:
• Tokens minted in the same transaction can have different underlying satoshi values.
• Each token's token value (i.e. quantity of resource units) does not change after minting irrespective of the number of times it is transferred.
• A token cannot be split after minting, in that its value is fixed. Therefore, in a preferred system, the underlying quantity of cryptocurrency units associated with a given token cannot be changed after minting. However, in other examples the protocol may permit alteration of the number of cryptocurrency units in certain ways as long as the token's original token value specified by the minting transaction is not altered. For example, an issuer could issue a token with X underlying Satoshis and then create an output that contains X+Y Satoshis. This would enable a user to draw down on Y to pay transaction fees for transferring that token on condition that the number of Satoshis never reduces to below X as a balance. In this way, the token value can be supplemented but is retained.
The tokens can be created such that the output scripts require any desired variation of signatories. This provides a significant benefit in terms of flexible script options for receiving tokens into, and enhanced functionality. Bitcoin-implemented examples include, but are not limited to:
■ Example 1: Simple cash output
■ <pubkey> CHECKSIG
■ This is one of the most simple scripts in Bitcoin - a single signature check against a public key can transfer ownership/control of the tokens
Example 2: Joint Account
■ 1 <husband_pubkey> <wife_pubkey> 2 CHECKMULTISIG
■ This script allows either the husband or the wife to transfer ownership/control of the tokens
■ Example 3: Corporate Account
■ <department_VP_pubkey> CHECKSIGVERIFY 1 <engineer_l_pubkey> <engineer_2_pubkey> <engineer_3_pubkey> 3 CHECKMULTISIG
■ This script allows 1 of 3 engineers to sign before passing to their department VP for countersignature to transfer ownership/control of the tokens
Token sub-Ledgers:
With reference to Figure 9, embodiments of our illustrative token system provide the ability of the issuer to establish secondary, self-contained Token Sub-Ledgers within their Token Ledger. This can be performed through the performance of an establishment transaction within the primary token ledger that uses the issuer's authority (depending on the implementation) of the main establishment transaction to create a sub-ledger to manage a particular set of tokens from the primary token ledger. Tokens transferred into the token sub-ledger can be given additional properties or different properties relative to those in the primary token ledger, or can be used as a reference or source for the minting of new tokens of different types. These additional or changed properties are defined in the establishment transaction in the same way as the primary Token Ledger's properties are defined.
Where no additional or changed properties are defined, the token sub-ledger retains the same properties of the token ledger within which it was created. When tokens are issued within a token sub-ledger, the use of those tokens is restricted to the bounds of that token sub ledger. Tokens created in a token sub-ledger cannot be transferred into the primary token ledger. However tokens from within the primary token ledger can be used as inputs to a token sub-ledger minting transaction and broken down into smaller token sub-units or sub-types within the token sub ledger.
For example, consider a scenario in which a company creates software. The company can build a token which represents a license to install a particular piece of software. Each time a user purchases a license, one of the license tokens is used as an input to a new token sub ledger. Each time that customer uses the software in such a way that a record is created, that record is created within their own private sub-ledger which exists within the company's primary token ledger. Records can represent events and actions such as additional in-app purchases, the performance of software updates or the creation of files and other information.
Transferring & Validating Tokens On A Blockchain
As shown in Figure 1, after a token has been minted it can be transferred or "spent" from a sending party to a receiving party. The first transaction will spend the token from its T-UTXO in the Minting Transaction output list to an input in one or more further transactions. From there, the token can be spent to another recipient and so on, generating an evolving transactional history on the blockchain with each spend event.
While variations of aspects and embodiments will be readily apparent to the skilled person, all tokens minted in accordance with the example token system share certain features:
• each token is generated as an unspent transaction (T-UTXO) that is included in a minting transaction (MTx) formed in accordance with the present disclosure
• each T-UTXO comprises a specified amount of cryptocurrency in compliance with the underlying blockchain protocol; in the Bitcoin protocol this would be zero or more Satoshis. This may be referred to herein as a quantity, amount or portion of token-related cryptocurrency (TRC) to distinguish it from the cryptocurrency (C) that is spent from a previous transaction into the Minting Transaction to enable the individual T-UTXOs to be created
• Each token represents a tokenised resource; therefore, it has an associated value arising from or associated with that resource. This may be referred to herein as the token's "face value", "denomination", "token units" or its "token value" to distinguish it from the value or quantity of the underlying cryptocurrency that carries the token for the purpose of enabling transfer over the blockchain in accordance with the underlying blockchain protocol
• in use after minting:
• each token is represented as a UTXO in a blockchain transaction; these transactions and UTXOs do not deviate in terms of formatting or appearance from conventional TXs and UTXOs. Embodiments of the example system do not require any deviation from, or alteration of, the underlying blockchain protocol
• Each user's tokens are stored using a script in accordance with, and specified by, the issuer's requirements. As the skilled person will appreciate, this can be achieved using known techniques such as multi-signature scripts or using accumulator scripting to capture different authorisations and structures. o each token can be traced back, via its history on the blockchain, in a linear fashion to the Minting Transaction that created it; this enables authorisation and source to be
verified to prevent counterfeiting and other unauthorised usage; however, embodiments of the present disclosure provide alternative and improved techniques for this trace-back-to-minting approach, as described in detail in the following section entitled "Detailed Description of Illustrative Embodiments" o Each token is transferred from a sender to a recipient by spending the UTXO that comprises it into an input in a subsequent blockchain transaction. Each time a token is transferred over the blockchain, a linear transfer is performed in that transaction graph of the token does not contain any splits or re-combinations o In order to ensure that the token is a genuine, authorised token for the purpose and of the source expected by the recipient, the transactional history of the token can be verified easily, quickly and efficiently by tracing it back to the Minting Transaction which issued it and checking it against the Minting Record and/or certificate; again, we refer to the section below where embodiments of the present disclosure provide techniques for verifying the authenticity of token(s) without tracing all the way back to the original minting transaction.
When a token is to be sent to a receiver (which would initially be the Issuer, and subsequently a different owner) the sender's digital wallet spends the UTXO to an address controlled by the recipient's digital wallet. In a preferred token system, the receiving wallet has been arranged and configured in accordance with the protocols and methods of the examples described herein. Therefore, the receiving wallet knows that it is expecting a token in accordance the system and must verify that this is the case. The receiving wallet knows the VOUT index of the UTXO that the token is contained in, so initiates a verification check of the token's history by checking that the cryptocurrency that was spent to that UTXO came from an input residing at the VIN index that matches the UTXO's VOUT index, and that this in turn came from a UTXO whose cryptocurrency came from an input residing at the VIN index that matches its VOUT index and so forth.
The scanning process continues until a blockchain transaction is reached where the VOUT holding the token has no corresponding VIN. In other words, the linear transaction history terminates. If the transaction does not have a corresponding VIN, either the transaction is the minting transaction or the token is invalid. From here, the scanning process reads the Minting Record from the corresponding/designated output and validates that the token is genuine and was minted in a transaction that carries the signature of the issuing party's representative.
Thus, in order to verify a token's history in accordance with this approach, the wallet uses the aggregate Merkle proofs of each transaction it has been used in on the blockchain since it was minted. This is illustrated in Figure 8. As each token is created within a unique UTXO and is transacted without splits or combinations, its history is linear and can be quickly checked on the ledger. A token with a 1000 transaction history would carry approximately 1MB of history assuming 100 billion Txs/day on the Bitcoin blockchain. As the Bitcoin ledger is publicly inspectable, wallets and third parties are able to verify tokens on behalf of other parties and users.
It should be noted that the described system does not preclude the use of conventional UTXOs as inputs, nor the creation of conventional UTXOs as outputs in transactions that include the transfer of tokens. Therefore, a transfer transaction can also comprise one or more UTXOs and/or inputs that are not formed or used in accordance with the example token system.
Group Transactions
In some situations, more than one token may need to be transferred. Additionally, or alternatively, a service provider (e.g. payment processor) may elect to take transactions from several parties and merge them into a single transaction for the sake of efficiency and resource management. This also provides the advantage that tokens can be mixed and ownership obfuscated. This can provide security benefits because a malicious party cannot identify the owner of a particular token and thus target an attack. Therefore, a transaction can be used to take token inputs from multiple users and send different tokens to the desired receivers other than the ones signed by the spending party.
For example, as explained above, an individual token has a token value. If a user wishes to transfer a given amount of token value, but no single token has been minted of sufficient token value or a particular user's wallet does not control a single token of that value, multiple tokens with smaller token values will need to be sent so that they add up to at least the desired overall token value. In such situations, the sending party's wallet selects tokens that it controls and (at least partially) signs multiple token UTXOs in a blockchain transaction (Tx) which add up to at least the required overall value. We may refer to this transaction as a "group transaction" (GTx) because it groups or clusters token outputs together into one blockchain transaction. Thus, there may be a need to generate blockchain transactions which mix tokens, and tokens transferred to a given receiver may not be the same ones that were received from the sender. This gives the advantage of enhanced privacy (as token distribution is obfuscated) and improved efficiency.
If required, a sender can cryptographically sign tokens that add up to a higher value than required. Depending on the implementation required, such scenarios will result in change being sent back to the sender. In embodiments which are implemented on a Bitcoin blockchain, the user's signature uses SIGHASH_ANYONECANPAY and SIGHASH NONE. This effectively creates a signature that can be applied to any signed UTXO that can be applied to any input in any transaction. Other flags, instructions or OPCODES may be used to provide the same technical result in accordance with alternative blockchain protocols.
In some embodiments, transactions may be processed in a payment channel. When a user's wallet receives new tokens they can be stored for onward payment at a later date. If the user needs to make a transfer for a certain overall token value, tokens can be selected from the wallet and added to the group transaction. The transaction may have a time lock mechanism (e.g. nLocktime) that prevents it from being mined by the blockchain network until a particular time, or until the subsequent block is found. Tokens are added to the payment channel. When a group transaction is being updated in a node's public mempool, the wallet evaluates the TXID of the transaction that was included to check which version of the group transaction was recorded and begins building a new transaction for the payment channel.
The GTx process is illustrated with reference to Figures 14 and 15 in which, solely for the sake of convenience and ease of understanding, tokens are shown which represent fiat currency banknotes and coins. We use fiat currency for the examples in Figures 14 and 15 because cash bills and coins are readily understood and familiar. Figure 5 also illustrates how tokens retain their token value regardless of the number of times they are transferred.
Re-stamping Or Destroying tokens
Under some circumstances token issuers may wish to remove tokens from circulation. Figures 18 and 19 illustrate the use of transactions to perform melting and re-minting operations.
Transactions that perform these re-stamping or re-minting actions must only be performed by the issuing authority to prevent users from fraudulently stamping them with incorrect information and so must also include a 'Minting Record' and either spend the issuer's certificate into a new output or include the signatures of the issuing authority as per the specifications of the particular token ledger.
In embodiments of the system where the issuer controls the tokens directly by holding them in a single register, the tokens can be removed by the issuer by spending them out of the register into a
Melting transaction, removing the tokens and the underlying cryptocurrency from the token register.
In another embodiment where the issuer may not have the ability to move the tokens, the issuer creates the mint record as a spendable UTXO. When tokens need to be removed from circulation, the mint record can be spent into a new output that contains details of the expired tokens. In this way when a user does a validation check on the linear history of the token they can see if the token is still current.
In another embodiment the issuer may have a contract with Bitcoin node operators who can remove the tokens from circulation by transferring them directly into a melting transaction, effectively transferring the tokens and the underlying currency from the user's wallets and back to the issuer.
In yet another embodiment, the issuer may publish information regarding the removal from circulation of tokens with certain properties and offer replacement tokens of the same value to users who transfer the obsolete tokens back to the issuer's control. This method allows the tokens to continue to circulate naturally, allowing people to hold the old versions as collectible items or simply as untouched savings without risk to the token value.
Concepts and embodiments relating to melting and re-minting of tokens, and/or stamping them, are further described in more detail in the following section entitled "detailed description of illustrative embodiments".
Nodes and Network Topology
In some examples, one, some or all of the following three elements may be combined to form a network arranged to implement the protocols and methods disclosed herein:
1. Trustholds
2. User wallets
3. Registers
Trustholds:
Trustholds are distributed threshold signature generators. They are networks of computers which provide users with threshold signature slices that can be combined to create an ECDSA signature. User wallets have access to the network, for example via an API, and include a software module to
manage signature recombination. A Trusthold's function, therefore, comprises relieving the user of the responsibility of key backup and management. They each validate the user's identity and provide signatures for their tokens. Users such as individuals merchants, banks or other entities are able to cryptographically sign their transactions via a trusthold. Advantages of using a trusthold include the use of secure, distributed network, and a reduced risk of losing access to controlled resources.
Wallet:
The wallet's main functions may include:
1. Tracking the public keys being used to receive tokens from senders and, where necessary, ensure that any relevant trustholds have knowledge of them
2. Giving public keys to other authorised parties (e.g. Registers, collaborating or participating entities in a scheme or network) so that they can process tokens received from the wallet
3. Monitoring an index of tokens held by the wallet and formed in accordance with the tokenisation protocol, including various types and form of data relating to tokens and the UTXOs that they are embedded in
4. Where necessary, providing an interface between a user's trusthold network for the purposes of requesting and receiving signatures
5. Communicating with other users to send and receive tokens, and send other data (e.g. EDI)
6. Participating in collaborative transaction (Tx) and signature processes for creating and spending multi-signature tokens
7. In some systems, searching for and processing data stored via an associated tree or graph in order to monitor data relating to a computer-implemented transfer or other process (e.g. details of tokens sent/received, any alias associated with one or more parties and other data such as, for example, EDI records). This is seen in Figure 13
Depending on how the tokens are to be used, a wallet user may request a trusthold sign message hash on demand. In other situations, the user can ask the trusthold(s) to pre-sign their tokens for spending. In systems where tokens are signed using 'SIGHASH_ANYONECANPAY | SIGHASH_NONE', this makes them easy, simple and efficient to transfer. These signed tokens can be held by the wallet to be handed to recipients. A recipient can store a pre-signed token and send it back to a receiver (e.g. a bank) for exchange with other tokens held within a pool or set of other minted tokens.
Figure 7 illustrates a token systemusing a wallet to conduct a token transfer. With reference to Figure 7:
Step 1: User 1 receives a token value transfer request and selects one or more Token UTXOs they control to a value equal or greater than the requested amount. In this example, User 1 may receive information regarding the receiver's identity, a receiving script/scripts generated by the receiver, or both.
Step la: Where User 1 has not been passed receiving scripts their wallet or a money handling service they subscribe to conducts alias lookups to discover the receiving scripts to send the funds to. If the user does not have exact change, this process can include a negotiation to receive change from the receiving party or an API connection to a change providing service.
Step 2: Once User 1 has correct change, their wallet sends a signature request for each token selected in Step 1 to nodes in their trusthold network who create 'signature slices' needed for User l's wallet to build USERlsig for each selected token's ScriptSig. In this embodiment signatures can be signed using SIGHASH_ALL if the transaction is being handed directly to the receiver, or can use SIGHASH_SINGLE | SIGHASH_ANYONECANPAY if the transaction is being spent into a Group Transaction via a payment processor.
Step 3: Each of the fully signed tokens is passed to the receiver at the same time as they are broadcast to nodes on the blockchain network, completing the transfer.
Figure 10 illustrates an example of a change service as mentioned in step la above. With reference to Figure 10:
Step 1: a user wallet connects to a change server API to define transaction requirements and request receiving script.
Step 2: The change service responds with receiving script / scripts.
Step 3: The user sends signed tokens to the change service wallet.
Step 4: The change service sends change back to the user's wallet.
Figure 13 also shows a wallet in use in accordance with an example. With reference to Figure 13: Step 1: A Sender's wallet connects to a Receiver's wallet alias lookup/provision service to request a receiving script for a token delivery.
Step 2: The Receiver wallet's alias service responds with receiving script / scripts.
Step 3: The Sender signs and sends tokens to receiver wallet
Step 4: The Receiver sends the token UTXO details to a validation service.
Step 5: The validation service performs a Merkle proof lookup, tracing the linear transaction history back to the back to token's minting transaction.
Step 6: The validation service validates the token's authenticity using the Minting authority provided via the MTx
Step 7: If needed, the receiver makes an alias request to the Sender's wallet for receiving scripts to send tokens from its own wallet to provide change. These are applied to the transfer transaction before it is sent to nodes on the Bitcoin network to be processed.
Registers:
As shown in figures 2, 3, 6 and 15, certain (but not all) example systems may utilise a system component which we will refer to for convenience as a "register". A register may be a computer- implemented resource which comprises a wallet arranged to process tokens that are minted and used in accordance with the present disclosure. The register may be a fully automated system component. The use or otherwise of a Register will be dictated by the requirements of a particular use case and its implementation.
Figure 2 shows illustrative embodiment(s) of the disclosure in which:
1. token(s) for at least a required overal token amount or value are sent from a sender to a Register, and then tokens for at least the required overall amount are sent onwards from the register to a receiver; if tokens for more than the required overall amount are transferred, change is provided to the sender from the register or the receiver; performing the exchange via the register enabes a record of the transaction plus the transfer of ownership/control of the incoming and outgoing bills to be included in the Register.
2. Tokens(s) for at least the required token amount are sent directly to the receiver without going via a register; if tokens for more than the required overall amount are sent, change is provided to the sender from the receiver or some other party.
Figure 3 also show two possible tokenisation apporaches. In the first, an issuing entity creates and maintains a register of tokens. Each token that is issued is written to the register so that for each token that is put into circulation there may be a record comprising (at least) an identifier/serial number which uniquely identifies the respective token, and the token value associated with that token. If a token is withdrawn from circulation for some reason, it can be removed from the register
using a melting action as illustrated in Figure 18. A user which receives a token from the register may then transfer tokens to other users via the register or directly from user to user without going via the register.
With reference to Figure 6:
Step 1: User 1 receives a token value transfer request and selects one or more Token UTXOs they control to a value equal to or greater than the requested amount. In this example, User 1 may receive information regarding the receiver's identity, a receiving script/scripts generated by the receiver, or both.
Step 2: User 1 sends a signature request for each token selected in Step 1 to nodes in their trusthold network who create 'signature slices' needed for User l's wallet to build USERlsig in each selected token's ScriptSig using SIGHASH_NONE | SIGHASH_ANYONECANPAY
Step 3: User l's register operator receives the partially signed token or tokens into their register and receives the details of the value transfer which can include receiver identity or identities, receiving scripts and transfer amount. If scripts have not been supplied, the register operator conducts alias lookups to discover receiving scripts on behalf of the user.
Step 4: The register operator selects appropriate tokens to make the full payment and any change payment from the partially signed tokens it has received for other transactions and holds in its register. It completes the signature process by signing each using SIGFIASFI_ANYONECANPAY | SIGHASH_SINGLE and adds the signed outputs to a group transaction. The receiving script can represent any type of wallet used in the token ecosystem without restriction.
Possible implementations which make use of a register are also provided in Figure 15. In Figure 15, User 1 signs tokens 1, 2 and 3 for transfer to User 2. User 1 signs tokens held in a multi-signature account, co-signed by the register, allowing the register to transfer them forwards into transactions to other receivers. User 3 is also shown signing tokens 4, 5 and 6 for transfer to the register. The Register creates outputs to a group transaction using other pre-signed tokens that it holds in its pool to complete transfers to users 2 and 4 in a single on-chain action
Although versions of the token system can be implemented without the use of a register, there are techncial advantages which flow from such an arrangement where an implementation lends itself to
the use of a register. Although the title of the Satoshi Nakamoto whitepaper referred to a "peer-to- peer electronic cash system", cryptocurrencies still face numerous technical challenges regarding adoption and implementation. One of these challenges is that the wallets used to control a party's coins typically use a seed for back-up and recovery purposes. The seed is typically a more user- friendly mnemonic such as a phrase or group of words that are associated with an address or series of addresses that enable the wallet to be replenished. However, this requires a wallet owner to memorise or somehow record the seed. There are numerous known instances in which the seed has been lost or forgotten, leading to non-recoverable loss of the wallet contents. Moreover, the use of a seed prevents or at least hinders certain custodial applications of cryptocurrencies.
In addition to the "Seed Word" problem, wallets face the challenge of how to manage unspent transaction outputs (UTXOs) and any required change. In Bitcoin, coins are received into a wallet as UTXOs. Typically, the wallet will combine more than one unspent coins (received via >=1 inputs) to create one or more outputs. As the combined UTXO coins often amount to more than the required payment amount, the remaining change is sent back to the payer's digital wallet. This is analogous to the use of fiat cash, in which a buyer hands over ten dollars for payment of a $9.50 transaction. It may be that the $10 is provided as two $5 bills, a $10 bill, or a $5 bill plus 5 lots of $1 bills. In any event, the 50C change is handed back.
In the digital cash paradigm, this gives rise to technical challenges including:
1) the wallet needs to manage its UTXO set; this set can become complex which in turn may result in security risks for both users and developers
2) security can be compromised as it is often easier to identify ownership of coins through their transaction history; if coins can be traced to a source via a wallet, attacks may be more successful
Thus, implementations of the token system provide mechanisms for exchanging assets (eg cryptocurrencies, tokens, data etc) via a blockchain network which solve at least these technical challenges, including enhanced privacy and security for blockchain-enabled digital wallets.
Serial Numbers
In accordance with a preferred (but not every) example, newly minted tokens may be assigned to or associated with a unique identifier. This may be performed via the Minting Transaction. This may be any type of identifier which can be used to refer to the token and distinguish it from other tokens
that may be minted by the Issuer. We will refer to it as a "serial number" for convenience. A serial number is embedded in the output script (scriptSig) of the T-UTXO of a given token in the Minting Transaction. The serial number can then be carried forward with the token as it enters into circulation within the network.
In one or more other versions, though, serial numbers may be a hash of the TX used to create the tokens. However, this is less preferred because of a reduced level of control. A particular embodiment might process the transaction identifier (TXID) through a hashing function to create a unique identifier for the first output, and process the unique identifier for the first output through the same hashing function to generate a second unique identifier for the second output and so on.
In this implementation, the issuer is unable to determine the serial number of an issued token prior to the issuance action and the identifier is not recorded onto the blockchain as part of the minting record.
As the tokens are always spent into and out of the same index in any transaction they are used in, the tracing of the bills back to the creation event can be done easily by tracking the usage of the bill back through the token's transaction graph. In some embodiments, it may be desirable to periodically mark, flag or identify tokens with their serial number to make verification and tracking more efficient.
Serial numbers may be used to track or link the provenance of the tokens to the issuer and to index user transactions in a user's database/register. In one or more embodiments, a Group transaction may spend all fully signed output tokens into new scripts assigning them to new owners. This can enable dynamic re-assignment of tokens up until a time specified in a time lock mechanism. It is also possible to withhold the outgoing tokens at a wallet's discretion.
Example Use Cases
The following examples are provided as illustration of a small sample of the applications in which embodiments of the token system may be implemented. Many other applications and uses can, of course, be devised.
Use Case Example 1: Prescriptions
Suppose a patient visits a medical practice because of back pain. The medical practice has implemented a system which utilises tokens in accordance with the present disclosure. The medical
practice owns some Bitcoin and uses it to generate a minting transaction that issues a set of tokens as described above. These tokens can be used to present pharmaceutical prescriptions. Each doctor within the medical practice has a digital wallet which controls a private key that can sign the unlocking scripts of the pharmacy's token T-UTXOs so as to authorise the transfer of tokens to a patient. The digital wallet is arranged to implement the protocol disclosed herein, so can accept, verify, transfer and process tokens as described above. The patient has also installed a digital wallet that can receive, send and process the practice's tokens in accordance with the protocol.
After examining the patient, the doctor decides to prescribe some medication so she uses her wallet to generate a blockchain transaction which has a UTXO that comprises a locking script which can only be unlocked using a key controlled by the patient's wallet and also a key controlled by an authorised pharmacy. The doctor inserts a token comprising patient and prescription data into the UTXO's script. The token is then transferred from the doctor's wallet to the patient's wallet by spending the UTXO to an address owned by the patient's wallet.
When the customer arrives at the pharmacy, he presents the token he received from the doctor. The token must first be signed by the patient's own wallet and is then passed to the pharmacy's wallet for the pharmacist's authorisation. The pharmacist must be able to check that the prescription token is genuine and has not been forged. Therefore, the pharmacist's wallet traces the Token's transaction history on the blockchain to identify the minting transaction and checks the issuance data to verify the token. If verification is successful, redemption of the token can proceed. If not, the pharmacist declines to dispense the medication.
According to one example, to create the second signature needed to redeem the prescription, the pharmacy wallet acts as its own trusthold and communicates with a network of pharmacies who each use their private cryptographic keys to sign the token. This gives the pharmacy network the ability to monitor prescriptions across groups of pharmacies to identify fraudulent activities. In this way, an improved monitoring and control solution is provided. In other examples, redemption may require the patient's signature, the pharmacist's signature and the medical practice's signature. Other variations are also possible depending on the requirements of the use case.
Use Case Example 2: Game tokens Suppose that a gaming engine mints Tokens for game-related items. Items within the game are generated using vanity signatures that hash to item names. For example, a signature whose hash
creates an ASCII string that begins with 'sword' can present that signature on a token to the game company. The signature hash defines the item's purpose in the gaming world, and the token's linear transaction history adds weight to its accumulated experience.
Thus, in-game items can be issued by the game's creators as a sellable token which can be traded for cash or other in-game currency but where the traded item's ownership and usage history is tracked in a token ledger. As the item is used, each interaction with the environment can cause damage or add experience to the item's history, eventually leading to alteration of the item's functionality or usage over time. Such items could be customised by their owners, and retain their unique properties when they are exchanged. Further possibilities include the tokenisation of in-game reward systems or the creation of usable currency for an in-game environment. Further still, embodiments may allow for game developers to collaborate to allow items to be used by players in multiple games or to be carried forward into game sequels, allowing game items to accumulate status over many years and platform iterations.
Example Use case 3: Physical tokens
Figure 17 illustrates a process by which a digital token with a unique identifier e.g. serial number and token value can be locked into a script controlled by an issuer who can then create physical representations of the digital tokens. These can be verifiably linked to the digital token, and then destroyed by depositing them back into a register controlled by or associated with the issuer and removing the digital token from the locking script. With reference to Figure 17:
Step 1: Tokens are spent into a locking script that requires a knowledge proof provably linked to the issuer.
Step 2: Physical tokens are created that represent the digital tokens being used, and contain details including the token value, serial number and the details of the UTXO the digital token is currently held in on the ledger.
Step 3: Physical tokens can be exchanged between trading parties. Receivers validate the provenance of the token by checking that the digital token is locked in the transaction output shown on the physical token. Checking may be done via PC, point of sale device, or using a smartphone or tablet application. When the physical token is deposited, information it contains is used to build a
transaction that moves the digital tokens, triggering a process in which the physical token is destroyed.
Such an embodiment is suited for a wide range of possible use cases and applications. Once of these is provided as follow with regard to voting/selection processes.
Example Use case 4: Voting Systems
Example 4 is described with reference to figure 22. In this illustrative use case, certain embodiments can be arranged such that the tokens can be used to implement choice-making functions (which we will call "ballot papers" for ease of reference) in a selection process. This may be referred to as a "voting" system as known in the technical field, which should not be construed or mistaken as meaning purely political in nature. The term "voting" is used herein to refer to a process by which a choice or selection can be made and recorded. However, for the following example we will use an election process as this is readily understandable due to familiarity.
For example, consider a scenario in which an electoral commission establishes a Token Ledger in accordance with the disclosure for the purposes of conducting an election. Once the token ledger is established, the commission mints enough tokens to cover the voting process in each electorate, allowing for an extra quantity (e.g. 10%). Each token represents a ballot paper. Each ballot paper is then reproduced as a physical token containing a unique code which can be used to spend the digital token as part of a voting action. When voters arrive at the polling station their identity is processed through the normal means, in a way that is disconnected from the tokenised ballot paper. Once their identity and right to vote has been independently established, a physical ballot paper token is transferred to the voter. This could be, for example, a piece of paper with a bar code on it, or a plastic token or smart card with a chip or tag provided in or on it. A physical token can be picked at random from a pool of tokens provided to the polling station staff. In this way, the voter's identity is not known or attached to the physical token in any way, but the voter is now in possession of a token that represents their right to vote in the election.
The voter then presents themselves at a booth where a computer interface (e.g. touchscreen display) is provided and provides the terminal with the unique code provided by their physical token. The computer checks that the code represents an unspent ballot paper and presents the user with a voting process in accordance with the local rules of the electorate. This could be by being shown on screen, or could include other communication means e.g. audio means for use by blind users.
A further embodiment may provide the user with a printed record of their vote to place into a ballot box as a backup to the electronic process, and a further embodiment may use the unique physical token as the print media. Once the user's vote is concluded, the computer interface spends the ballot paper into a group transaction which is held in a timelocked payment channel that closes when the ballot is finished. If the user retains a record of their unique ballot paper they can verify that their vote was correctly recorded once the transaction is finalized.
This process is illustrated in Figure 22 which comprises the following steps:
1. The issuer creates a Root Node to establish the token ledger that records the election's votes and outcome
2. The issuer uses the authority from the root node to generate enough ballot papers for the election process to take place using a minting transaction
3. A knowledge proof needed to spend each ballot paper is produced as a physical token with a secure device that a voter must break into through an irreversible process in order to reveal (e.g. tearable perforated sheet/scratch panel)
4. Ballot papers are randomized and delivered to voting locations where they are distributed to voters who have presented adequate identification to participate in the election process.
5. Voters reveal their ballot paper's knowledge proof by conducting the irreversible process needed to access it and present the information to a secure voting terminal. The terminal checks that the knowledge proof represents a valid token and presents the voter with a set of guided voting options.
6. 6.The voter goes through the voting process using the secure terminal and once finished, indicates through an action that they have completed selecting their options. The terminal generates a new UTXO which it uses to transcribe the voter's selection and uses the knowledge proof to sign the digital ballot paper using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY. At the end of the voting process, the signed ballot papers are all spent together in one transaction to finalise the voting process. A user who retains access to their ballot paper can easily check that their vote was recorded correctly.
Example Use case 5: State Machines
In one embodiment of the disclosure, a token can be created that is intended to pass through a state machine with a linear processing framework. In this way, a token can be created, and pass through numerous transfer operations, changing state each time. Some tokens may be processed back into standard blockchain UTXOs at the finalization of a state transition. In this way, the disclosure can be
used to implement DFAs and automated systems which can be used in a wide range of scenarios and for many different purposes.
For example, consider a scenario in which a user purchases an airline ticket on a particular flight. The first state is a ticket booking which includes data such as flight and date. Prior to the flight, the user may change the booking which would involve a transition into a different booking state. The user may also add other services such as meals and a specific seat selection to their booking, each of which modifies the state of the ticket. When the user checks into their flight, they are assigned their final seating and the ticket changes state into a boarding pass. If the flight is cancelled, the ticket's state may be changed back into a booking. Once the passenger has arrived at their destination, all of the underlying cryptocurrency that held the tickets that were used by all of the passengers on that flight can be processed back into a Bitcoin UTXO which the airline can then recycle into new tickets.
Peer-To-Peer Electronic Token Transfer
In some ways, the creation and use of tokens as disclosed herein can be thought of analgous to the use of fiat currency bank notes or coins which are issued as tokens by a national reserve. A £5 bank note is a promissory note issued by the Bank of England, having a serial number, watermark and/or other identifiying features (eg artwork) that enable them to be verified as being issued by an authorised issuer. A £5 bank note is fungible and may be exchanged directly between users Alice and Bob without an intermediary (i.e. a peer-to-peer cash transfer as per Satoshi Nakamoto's 2008 whitepaper title) simply by Alice handing Bob a £5 note or five £1 coins. Alternatively, Alice may pay Bob via the issuing bank or another intermediary. Suppose that Alice wishes to pay Bob £5 via her bank. The £5 that Bob subsequently withdraws from his bank's ATM is unlikely to (although theoretically may) be the same £5 note that Alice paid into her bank. If he withdraws it in person from a bank teller he may be given five individual £1 coins. In either case, Bob's concern is that he receives his £5 worth of Bank of England tokens into his wallet.
Although it is unlikely that they would wish to do so, Alice or Bob may also destroy their £5 note or five £1 coins if they so wish. They may burn their bank note or melt their coins. Alternatively, the Bank of England may withdraw a bank note or coin from circulation so it can no longer be transferred between users. Similarly, tokens minted in accordance with the present disclosure can be destroyed by users or withdrawn/cancelled from ongoing use by an issuer.
Also in common with tokens of the present disclosure, a bank note or coin retains its token value regardless of the number of times that it is transacted - a £5 note is always worth five pounds Stirling, whether it is used once or 10,000 times.
Moreover, a banknote cannot be split or recombined. If a £5 note is cut into 5 individual pieces of paper/plastic, or a £1 coin is melted down into smaller pieces of metal they will retain some (probably very small) instrinsic value relating to the resale of the paper and/or metals, but the (probably larger) token value is lost. In the same way, if a token minted in accordance with the present disclosure is used in a manner that is incompatible with the protocol, the underlying cryptocurrency may still provide some value to the owner but the usage as a particular type of token may be rendered ineffective.
However, while banknotes and coins are a simple, quick, and private means of transferring a tokenised resource between users, they are inefficient in that their printing medium is physical. By providing a digital version of a token, some use cases of the present disclosure may provide a peer- to-peer elecontric cash solution as per Satoshi Nakamoto's original white paper which offers the advantages of cash but provides a cryptographically secured and enforced alternative, that reduces the opportunity for exploitation by unauthorised parties (eg counterfeiters and fraudsters) and removes the wastage, expense and inefficiency of physical print media.
In some ways, therefore, embodiments of the disclosure provide simple, efficient and yet powerful blockchain-implemented solutions which are fully aligned with Satoshi Nakamoto's original, ground breaking design. However, the benefits of such solution extend well beyond the use of blockchain trechnology for simply digital cash or currency in the same way that the Internet's benefits extend well beyond the simple provision of an electronic message or web page. Embodiments provide potential for solutions which have not yet been explored on the blockchain. Any type of resource can be tokenised using the disclosed embodiments, giving rise to a versatile and advantageous blockchain-implemented data transfer mechanism.
In some respects, the recognition and conception of the present disclosure has been obfuscated to date by current blockchain rules which restrict the size of transaction outputs to "dust" levels, and which have resulted in efforts being focussed on a combine-and-split paradigm at the transaction and token levels. Embodiments of the disclosure, however, are able to exploit and harness the benefits of existing functionalities within blockchain protocols, such as Bitcoin's SIGHASH flags and
flags with the same or similar functionalities in alternative protocols. Instead of following conventional tokenisation approaches which break up tokens and recombine them into different token amounts during the transfer process, embodiments disclosed herein comprise the use of unqiue, fixed-value, denominated tokens which can be quickly and efficeintly verified and enable the creation of systems for uses beyond the capabilities of known approaches. Thus, improved blockchain networks and solutions are provided.
Moreover, once the tokens disclosed herein are issued, there is no requirement for the token Issuer to build or maintain additional infrastructure for token exchange/transfer/verification, providing a highly efficient and secure improvement over known technqiues. The capacilities and benefits of the blockchain network are leveraged by simply specifying the way in which the transactions are built in script. All token transfers are conducted on-chain and so the cryptographic enforcement, consensus mechanisms and security of the blockchain network are harnessed, plus the immutable, inspectable, timestamped record of events is secured on-chain. There is no requirement for a user to insert data into a script, while having the ability to lock tokens using scripts that are suited to their individual requirements without changing the value of the token. As there is no additional overhead in terms of scripting, this again gives rise to efficiency benefits in terms of ledger use.
With regard to digital wallets, the disclosure avoids or at least alleviates the problem of complex wallet integration so that development resources such as time, effort, computing power and costs are minimised. Wallets do not need to interface with the blockchain network other than to obtain block headers for validating SPV proofs for tokens that they receive. Wallets are simplified in that in some embodiments they do not need to build transactions, they can simply receive, sign and send the tokens in the usual way. Thus, embodiments of the disclosure provide the ability to construct hitherto unknown tokenisation systems and tools which store and transfer tokens using the simplest possible blockchain transaction outputs.
Further still, embodiments of the disclosure do not require the Issuer to be party to each transfer transaction on the blockchain. This addresses problems faced by exsiting solutions with regard to privacy and scalability, as their resource and cost requirements can escalate relative to the number of users.
Thus, the present disclosure provides technical solutions to a variety of technical problems, including, but not limited to, those mentioned above.
Detailed Description of Illustrative Embodiments of the Disclosure
Above, we have described a tokenisation sytstem and protocol that the presently disclsoed embodiments can be used with. However, the present invention is not limited to use with just this example system; it provides a more generalised solution for certification of blockchain tokens, and the invention is not limited with regard to the type of tokenisation method, system or protocol that is used to generate and/or process the token.
We now provide a detailed description of how embodiments of the present disclosure can be used with a tokenisation system such as the example described above.
Hereafter, we may refer to a "token transaction" as being a blockchain transaction that has one or more token outputs, a token output being an output that comprises or is in some way associated with at least one token, as shown in Figure 4. As explained above, to check whether a blockchain transaction is a token transaction one can trace back to a mint transaction via the transaction chain. However, this may be difficult to do when the system is at scale because the increasing length of token's history chain over time results in a growth of required resources for the tracing and comparison operations. The following techniques can be used in addition or, preferably, as alternatives to the approach of tracing back to an original minting transaction in order to certify that the token(s) have been issued by an authorised party.
Thus, as shown in Figure 24, embodiments of the disclosure provide mechanisms which avoid the need to trace all the way back to the minting transaction (MTX). Instead, at least one token verification/certification element (CE) is inserted into the token transaction chain at some point following the mint transaction(s), so that a verifying entity (VE) only needs to trace back from a given or current token transaction (which we may refer to as a "target token transaction") to an identifiable certification element. In Figure 24, a Certification Element is shown inserted into a token transaction (TTx) in a chain of token transactions. The tracing process performed by the verifying entity can stop when the certification element is encountered in the chain, safe in the knowledge that the token has been issued by or on behalf of the issuer.
In accordance with one approach, each token transaction in the chain could be stamped by the issuer (or their authorised representative) to authenticate the token(s) it carries. However, this could require significant resources on behalf of the issuer and the verifying/using party. In a
preferred embodiment, therefore, the chain is periodically stamped with a certification element so that the need to traverse the chain back to its origin is alleviated along with the need to stamp every transaction in the chain. Another advantage of periodic stamping is that it enables use of offline token transactions. This can be highly advantageous in circumstances where connectivity over the internet and other networks is not available. For example, transactions and transfers made on an aeroplane or in geographic locations where connectivity is not possible. Such offline transfers are not possible with prior art approaches where the issuer is required to stamp every transaction.
The token certification element certifies that the at least one token provided in the token transaction was generated by or on behalf of the issuer. In some embodiments, the token transaction comprises one token, while in other it may comprise more than one token. From hereon, we refer to a singular token for ease of reference. Similarly, one or more than one certification element may be provided in a token transaction, and the token(s), token transaction and/or certification element(s) may be issued by one or more issuers using one or more mint transactions. We refer, though, for convenience, to these in the singular.
In some embodiments, the at least one token certification element is provided in the token transaction in response to a request or instruction. The request or instruction could originate from a token user, or an intended recipient of the token, or the issuer or their representative, or some other party. Additionally, or alternatively, the certification element can be provided in the token transaction in accordance with at least one predetermined rule or criteria. Performance or evaluation of the rule/criteria can be automated and performed by a software-based component which may be executed by or on behalf of a validating entity. The at least one pre-determined rule or criteria could, for example, specify a threshold, interval or metric for identifying or selecting the transaction within the chain of token transactions so that the certification element can then be inserted into it by the issuer or an entity that is authorised to do so by the issuer.
The certification element comprises some form of evidence that the token is genuine or authentic, in that it has been legitimately formed by the issuer(s). In this way, it legitimizes the token(s) in the token transaction and its presence in the transaction serves as a substitute for the mint transaction during a verification process. Thus, the certification element can take any suitable form that fulfils this role, such as, for example, proof of a secret known to or associated with the issuer; and/or cryptographic data. Cryptographic data could comprise a cryptographic key, a signature, a digitally signed message or other cryptographic element associated with the issuer or a party authorised by,
representative of or associated with the issuer. Essentially, the certification element provides evidence that can be trusted as belonging or known only to the issuer/authorised party.
The certification element can be provided in the at least one token transaction in a variety of locations and/or formats. For example, it could be inserted into the transaction at a location following an instruction or code, for example after an OP_RETURN other instruction. It could be provided elsewhere in a script, and/or provided as metadata.
As the chain of token transactions grows over time through usage and transmission of the token(s), the same or a different certification element is provided in a new token transaction when it is added to the ledger. Thus, the chain may comprise multiple certification elements which are provided in contiguous token transactions or, preferably, at spaced intervals. When the certified token transactions are spaced apart, the interval between them may be defined by the afore-mentioned rule or criteria. For example, a certification element may be provided every x number of token transactions on the ledger. Other metrics for determining the interval may be readily devised and implemented. Alternatively, the certification element may be inserted into the chain on a random or ad hoc basis, or (as previously mentioned) in response to a triggering even such as a request, instruction or monitored state. The monitored state may relate to an entity, resource or condition which is located on or off the blockchain.
The certification element can be utilised by any entity or party that needs to validate or certify that the token(s) in a given token transaction were, indeed, issued by the issuer. This could, for example, be the validating entity or a user or a token client. Traditionally, such a party needs to establish the token's provenance by tracing the transaction chain back to the mint transaction to verify that it has, indeed, been generated by the issuing source, but embodiments of the disclosure enable the verifying party to traverse the chain of token transactions only from the token transaction to a previous token transaction that comprises a token certification element. This saves a significant amount of energy, time and processing resource.
Embodiments of the disclosure may comprise features relating to melting and re-minting of the token. These features may be provided in addition to, or alongside and in conjunction with, the validation technique described above. In accordance with such embodiments, and as above, the at least one token is provided in a token transaction on a blockchain and is generated in an original mint transaction by or on behalf of an issuing party. Advantageously, the token is melted and
reminted. In some embodiments, this may be performed on an ad hoc random or pseudo-random basis, although in a preferred embodiment it is performed when a pre-determined threshold, limit or specified value has been reached. Melting, in accordance with one form of wording, can be described as modifying the token or the token transaction, or performing some off-chain operation such that the token is no longer deemed valid or certified/authenticated by the issuer. Re-minting, in accordance with one form of wording, can be described as modifying the token or the token transaction, or performing some off-chain operation such that the token remains valid or certified/authenticated by the issuer but performance of the modification or other operation can be verified. The token remains valid and approved by the issuer but its validity is re-incarnated in a different form. It is no longer valid in its previous form. Figure 19 shows a re-minting process.
The melting operation can comprise providing an identification element, marker or other portion of data to indicate that the token is no longer valid. The specific mechanism used for melting and re minting will depend upon the implementation involved in the tokenisation system that is being used, but in one example embodiment, it can comprise providing an identification element, marker or other portion of data to indicate that the token is no longer valid. Similarly, re-minting can be performed in a variety of ways, including providing an identification element, marker or other portion of data to indicate that the token is valid but in a modified form.
The identification element can take a variety of forms, including an identifier e.g. serial number and/or cryptographic data such as, for example, a cryptographic key, signature, signed message etc. Preferably, the identification element is associated with the at least one issuer or a party authorised by the at least one issuer, and serves as approval or issuance by the issuer. The identification element can be provided in a blockchain transaction, preferably in the token transaction (TTx), or in a storage resource provided off the blockchain.
The pre-determined threshold, limit or specified value can be monitored by the issuer or some other party, to determine when it has been reached. This may involve comparing it against a supplied value. When the issuer or other party determines that the threshold has been reached or exceed, the melt and/or re-mint operations can be performed. This provides the advantage of reducing required resources and improving efficiency as explained above. In some embodiments, the pre determined threshold, limit or specified value is determined by or on behalf of the issuer or a validating entity.
Enumerated Clauses:
Some illustrative embodiments of the present disclosure are provided in the following enumerated clauses.
Statement 1. A blockchain-implemented method of endorsing or attesting the authenticity of at least one token provided in a token transaction that is an element in a chain of token transactions originating from at least one minting transaction used by or on behalf of at least one issuer to generate the at least one token; wherein the method comprises: providing, in the token transaction, at least one token certification element which certifies that the at least one token was generated by or on behalf of the at least one issuer.
Statement 2. The method of statement 1, wherein the at least one token certification element is provided in the token transaction: in response to a request or instruction; and/or in accordance with at least one predetermined rule or criteria.
Statement 3. The method of Statement 2, wherein the at least one pre-determined rule or criteria specifies a threshold, interval or metric for identifying or selecting the transaction within the chain of token transactions.
Statement 4. The method of any preceding Statement wherein the at least one certification element is provided in the token transaction by the at least one issuer or a party authorised by the at least one issuer.
Statement 5. The method of any preceding Statement wherein the at least one certification element comprises: proof of a secret known to or associated with the at least one issuer; and/or cryptographic data, preferably wherein the cryptographic data is or comprises a cryptographic key, signature, digitally signed message or other cryptographic element associated with the at least one issuer or a party authorised by the at least one issuer.
Statement 6. The method of any preceding Statement wherein the at least one certification element is provided in the token transaction: following an instruction or code which renders the token transaction unspendable (e.g. an OP_RETURN statement in some blockchain protocols); or in a script of the transaction, wherein the script is associated with an output of the transaction.
Statement 7. A method according to any preceding Statement and comprising the step of providing the same or a different certification element in at least one further token transaction in the chain of token transactions.
Statement 8. A blockchain-implemented method of validating at least one token provided in a token transaction on a blockchain that is an element in a chain of token transactions originating from at least one minting transaction used by, or on behalf of, an issuer to generate the token; wherein the method comprises: inspecting the token transaction to determine whether it comprises at least one token certification element which certifies that the token was generated by or on behalf of the issuer; and/or traversing the chain of token transactions on the blockchain from the token transaction until a previous token transaction is identified in the chain which comprises at least one token certification element which certifies that the token was generated by or on behalf of the issuer.
Statement 9. A method according to Statement 8 wherein the step of traversing the chain of token transactions is performed if, and only if, the token transaction does not comprise the at least one token certification element.
Statement 10. A method according to Statement 8 or 9 wherein the step of traversing the chain of token transactions comprises: inspecting a token transaction in the chain to determine whether it comprises the at least one token certification element.
Statement 11. A method according to Statements 8 to 10 wherein the at least one certification element comprises: proof of a secret known to, or associated with, the at least one issuer; and/or cryptographic data, preferably wherein the cryptographic data is or comprises a cryptographic key, signature, digitally signed message or other cryptographic element associated with the at least one issuer or a party authorised by the at least one issuer.
Statement 12. A blockchain-implemented method of issuing at least one token provided in a token transaction on a blockchain (150), comprising: melting and reminting the token when a pre-determined threshold, limit or specified value has been reached.
Statement 13. A method according to Statement 12 wherein: the token transaction is traceable on the blockchain to at least one mint transaction issued by or on behalf of at least one issuer (702).
Statement 14. A method according to Statement 12 or 13 wherein melting the at least one token comprises providing an identification element, marker or other portion of data to indicate that the token is no longer valid; and/or re-minting the token comprises providing an identification element, marker or other portion of data to indicate that the token is valid but in a modified form.
Statement 15. A method according to Statement 14 wherein the identification element is: an identifier and/or cryptographic data; and/or associated with the at least one issuer or a party authorised by the at least one issuer; and/or provided in a blockchain transaction, in the token transaction or in a storage resource provided off the blockchain.
Statement 16. A method according to Statements 12 to 15 and comprising: assessing whether the pre-determined threshold, limit or specified value has been reached by performing a comparison of a supplied value against the threshold, limit or specified value.
Statement 17. A method according to Statements 12 to 16 wherein
the pre-determined threshold, limit or specified value is determined by the at least one issuer or a party authorised by the at least one issuer (702), a user (703) or a validating entity (701).
Statement 18. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of Statements 1 to 17.
Statement 19. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of Statements 1 to 17.
Other illustrative embodiments of the present disclosure are also provided in the following enumerated clauses.
1. A blockchain-implemented token generation, transfer and/or verification method comprising: using, processing and/or generating a blockchain transaction (MTx) having: i) one or more token-related outputs (T-UTXOs), each of which represents a respective token (T) issued by a Token Issuer (Tl) and specifies a quantity of a) token units (TU) and b) token- related cryptocurrency (TRC) associated with the respective token (T); and ii) at least one Issuer-related output (l-UTXO) comprising issuance data (IData) associated with the Token Issuer (Tl).
The TRC may be a variable amount of cryptocurrency in that the quantity of units e.g. may change.
2. A method according to clause 1, wherein the transaction (MTx) further comprises: i) at least one input comprising a quantity of cryptocurrency (C); and/or ii) at least one input comprising the issuance data (IData).
Preferably, the Issuance data is provided in the same or a different input that comprises the quantity of cryptocurrency (C).
3. A method according to clause lor 2 wherein: the issuance data (IData) comprises, or references, a digital signature controlled by and/or associated with the Token Issuer (Tl).
4. A method according to any preceding clause wherein: at least one of the one or more token-related outputs (T-UTXO) comprises a unique token identifier (tokenID) associated with the token represented by the token-related output (T- UTXO).
5. A method according to any preceding clause wherein the blockchain transaction (MTx) further comprises: at least one input and/or output comprising token generation data (MR) relating to the one or more Token-related outputs (T-UTXOs).
6. A method according to any preceding clause and further comprising the step of: using a token transfer transaction (TTTX) to transfer control, to a recipient, of a particular token represented by one of the one or more token-related outputs (T-UTXOs).
7. A method according to clause 6 and further comprising the step of: using at least one further token transfer transaction (TTTXi) to transfer control of the particular token (T) to the same or a further recipient
8. A method according to clause 6 or clause 7 and further comprising the step of: providing a solution in an unlocking script of an input in the token transfer transaction (TTTx) or at least one further token transfer transaction (TTTXi) to a locking script of the token-related output (T-UTXO) that represents the particular token.
9. A method according to any preceding clause and further comprising the step of: providing a physical representation of at least one of the respective tokens represented by the one or more token-related outputs (T-UTXOs); preferably wherein the physical representation comprises means for identifying the at least one respective token.
10. A method according to any preceding clause and further comprising the step of destroying the token by: removing it from a computer-based storage resources such as a token register; publishing data relating to the destruction of the token; and/or spending an unspent transaction output (UTXO) that comprises token generation data (MR) relating to the one or more Token-related outputs (T-UTXOs).
11. A method according to any preceding clause and further comprising the step of: submitting the blockchain transaction (MTx) to a blockchain network.
12. A blockchain-implemented token transfer and/or verification method comprising the step of using and/or generating a blockchain transaction (TokenTx) comprising an input which includes a token (T) and which: i) is linked in a linear transaction history on the blockchain to a token-issuing blockchain transaction (MTx) which comprises at least one Issuer-related output (l-UTXO) associated with issuance data (IData) relating to a Token Issuer (Tl) that Issued the token (T); and ii) comprises a quantity of: a) token units (TU) specified in a token-related output (T-UTXO) of the token issuing blockchain transaction (MTx); and b) token-related cryptocurrency (TRC).
13. A method according to clause 12 wherein: the blockchain transaction (TokenTx) is used and/or generated by a computing resource that is arranged to implement a tier-2 blockchain tokenisation protocol.
14. A method according to clause 12 or 13 wherein the quantity of token units (TU) is fixed such that it remains the same upon spending the input to an output (UTXO).
15. A method according to any of clauses 12 to 14 and further comprising the step of transferring the token (T) from a Sender (S) to a receiver (R) by: spending the output (UTXO) of the blockchain transaction (TokenTx) to an input (I) in a receiving blockchain transaction (RTx), wherein an index or other identifier associated with the output (UTXO) corresponds to an index or other identifier associated with the Input.
16. A digital wallet arranged and configured to use or process the method of any preceding clause.
The wallet may be operative to communicate with a blockchain network. It may be operative to provide blockchain transactions to the network. The wallet is arranged to operate on a computing device such as, for example, a laptop or mobile device.
17. A computer implemented method comprising the step of: generating, storing, processing and/or maintaining a computer-based resource (R) of a plurality of token-related blockchain transaction outputs (T-UTXOs), wherein each of the outputs (T-UTXOs): i) provides a respective token (T) issued by a Token Issuer (Tl) and specifies a quantity of a) token units (TU) and b) token-related cryptocurrency (TRC) associated with the respective token (T); and ii) has a linear transaction history to a blockchain transaction (MTx) that comprises at least one
Issuer-related output (l-UTXO) which includes issuance data (IData) associated with the Token Issuer (Tl).
18. A method according to clause 17 wherein the computer-based resource (R) is generated, stored, processed and/or maintained off-chain.
19. A method according to clause 17 or 18 wherein each token-related blockchain transaction output (T-UTXO) is generated and/or spent by a computing component arranged to implement a tier-2 blockchain tokenisation protocol and comprises at least one partially signed locking script.
20. A method according to clauses 9 to 11 and further comprising the step of: receiving, at the computer-based resource (R) from a sending device (S), a token (T) provided by one of the plurality of token-related blockchain transaction outputs (T-UTXOs); storing at least one Token (T), received from a sending device, in the computer-based resource (R); and/or sending at least one Token (T) to a receiving device, wherein the token is provided by an output (T-UTXO) selected from the resource (R) of token-related blockchain transaction outputs (T-UTXOs)
21. A computer network comprising a plurality of nodes, wherein each node in the blockchain network comprises: a processor; and memory including executable instructions that, as a result of execution by the processor, causes the system to perform the computer-implemented method of any preceding clause. The network may be, or comprise, a blockchain network.
22. A non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by a processor of a computer system, cause the computer system to perform the computer-implemented method of any one of claims 1 to 20.
Another aspect of the disclosure may provide a computer-implemented selection/voting method and corresponding system. The method/system may comprise steps and/or devices as recited in any of the preceding clauses.
It should be noted that the above-mentioned embodiments illustrate rather than limit the disclosure, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the disclosure as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The word "comprising" and "comprises", and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In the present specification, "comprises" means "includes or consists of" and "comprising" means "including or consisting of". Throughout this specification the word "comprise", or variations such as "includes", "comprises" or "comprising", will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps. The singular reference of an element does not exclude the plural reference of such elements and vice-versa. The disclosure may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.
In this document we use the term 'blockchain' to include all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction-chain technologies, permissioned and un-permissioned ledgers, shared ledgers, public and private blockchains, and variations thereof. As the Bitcoin ledger is the most widely known application of blockchain technology it will be used herein for ease of reference, although it should be noted that the term "Bitcoin" is intended herein to refer to any version or variation that derives from, or is based on, the Bitcoin protocol. Moreover, other non-Bitcoin blockchain implementations have been proposed and
developed and alternative blockchain implementations and protocols fall within the scope of the present disclosure.
The term "user" may refer herein to a human or a processor-based resource. The skilled person will readily understand that in the art it is usual to refer to spending of cryptocurrency in terms of sending coins from one address/owner to another. However, in reality, no actual "coins" are transferred. Instead, control of ownership is transferred from one script to another. As used herein, phrases "quantity/amount/portion of cryptocurrency", "non-negative quantity etc of cryptocurrency" and the like are intended to mean zero or more units of a cryptocurrency e.g. >= 0 Satoshi in relation to Bitcoin.
Claims
1. A blockchain-implemented method of endorsing or attesting the authenticity of at least one token provided in a token transaction that is an element in a chain of token transactions originating from at least one minting transaction used by or on behalf of at least one issuer to generate the at least one token; wherein the method comprises: providing, in the token transaction, at least one token certification element which certifies that the at least one token was generated by or on behalf of the at least one issuer.
2. The method of claim 1, wherein the at least one token certification element is provided in the token transaction: in response to a request or instruction; and/or in accordance with at least one predetermined rule or criteria.
3. The method of claim 2, wherein the at least one pre-determined rule or criteria specifies a threshold, interval or metric for identifying or selecting the transaction within the chain of token transactions.
4. The method of any preceding claim wherein the at least one certification element is provided in the token transaction by the at least one issuer or a party authorised by the at least one issuer.
5. The method of any preceding claim wherein the at least one certification element comprises: proof of a secret known to or associated with the at least one issuer; and/or cryptographic data, preferably wherein the cryptographic data is or comprises a cryptographic key, signature, digitally signed message or other cryptographic element associated with the at least one issuer or a party authorised by the at least one issuer.
6. The method of any preceding claim wherein the at least one certification element is provided in the token transaction:
in a script of the transaction, wherein the script is associated with an output of the transaction; or as metadata in a script of an output; or following an instruction or code which renders the token transaction unspendable.
7. A method according to any preceding claim and comprising the step of providing the same or a different certification element in at least one further token transaction in the chain of token transactions.
8. A blockchain-implemented method of validating at least one token provided in a token transaction on a blockchain that is an element in a chain of token transactions originating from at least one minting transaction used by, or on behalf of, an issuer to generate the token; wherein the method comprises: inspecting the token transaction to determine whether it comprises at least one token certification element which certifies that the token was generated by or on behalf of the issuer; and/or traversing the chain of token transactions on the blockchain from the token transaction until a previous token transaction is identified in the chain which comprises at least one token certification element which certifies that the token was generated by or on behalf of the issuer.
9. A method according to claim 8 wherein the step of traversing the chain of token transactions is performed if, and only if, the token transaction does not comprise the at least one token certification element.
10. A method according to claim 8 or 9 wherein the step of traversing the chain of token transactions comprises: inspecting a token transaction in the chain to determine whether it comprises the at least one token certification element.
11. A method according to claims 8 to 10 wherein the at least one certification element comprises:
proof of a secret known to, or associated with, the at least one issuer; and/or cryptographic data, preferably wherein the cryptographic data is or comprises a cryptographic key, signature, digitally signed message or other cryptographic element associated with the at least one issuer or a party authorised by the at least one issuer.
12. A blockchain-implemented method of issuing at least one token provided in a token transaction on a blockchain, comprising: melting and reminting the token when a pre-determined threshold, limit or specified value has been reached.
13. A method according to claim 12 wherein: the token transaction is traceable on the blockchain to at least one mint transaction issued by or on behalf of at least one issuer .
14. A method according to claim 12 or 13 wherein melting the at least one token comprises providing an identification element, marker or other portion of data to indicate that the token is no longer valid; and/or re-minting the token comprises providing an identification element, marker or other portion of data to indicate that the token is valid but in a modified form.
15. A method according to claim 14 wherein the identification element is: an identifier and/or cryptographic data; and/or associated with the at least one issuer or a party authorised by the at least one issuer; and/or provided in a blockchain transaction, in the token transaction or in a storage resource provided off the blockchain.
16. A method according to claims 12 to 15 and comprising: assessing whether the pre-determined threshold, limit or specified value has been reached by performing a comparison of a supplied value against the threshold, limit or specified value.
17. A method according to claims 12 to 16 wherein the pre-determined threshold, limit or specified value is determined by the at least one issuer or a party authorised by the at least one issuer, a user or a validating entity.
18. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of claims 1 to 17.
19. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of claims 1 to 17.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GBGB2008790.4A GB202008790D0 (en) | 2020-06-10 | 2020-06-10 | Computer-implemented methods and systems |
GB2008790.4 | 2020-06-10 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2021250129A1 true WO2021250129A1 (en) | 2021-12-16 |
Family
ID=71615942
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2021/065368 WO2021250046A1 (en) | 2020-06-10 | 2021-06-08 | Computer implemented methods and systems |
PCT/EP2021/065529 WO2021250129A1 (en) | 2020-06-10 | 2021-06-09 | Computer implemented systems and methods for improved authentication of blockchain-based tokens |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2021/065368 WO2021250046A1 (en) | 2020-06-10 | 2021-06-08 | Computer implemented methods and systems |
Country Status (2)
Country | Link |
---|---|
GB (1) | GB202008790D0 (en) |
WO (2) | WO2021250046A1 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2024052047A1 (en) * | 2022-09-08 | 2024-03-14 | Nchain Licensing Ag | Blockchain-based token protocol |
GB2622358A (en) * | 2022-09-08 | 2024-03-20 | Nchain Licensing Ag | Blockchain-based token protocol |
WO2024126027A1 (en) * | 2022-12-14 | 2024-06-20 | Nchain Licensing Ag | Computer-implemented methods and systems |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2607618A (en) * | 2021-06-09 | 2022-12-14 | Nchain Licensing Ag | Computer-implemented method and system |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20190130391A1 (en) * | 2016-04-11 | 2019-05-02 | nChain Holdings Limited | Computer-implemented methods and systems for validating tokens for blockchain-based cryptocurrencies |
US20190228407A1 (en) * | 2016-07-25 | 2019-07-25 | Tbcasoft, Inc. | Digital property management on a distributed transaction consensus network |
-
2020
- 2020-06-10 GB GBGB2008790.4A patent/GB202008790D0/en not_active Ceased
-
2021
- 2021-06-08 WO PCT/EP2021/065368 patent/WO2021250046A1/en active Application Filing
- 2021-06-09 WO PCT/EP2021/065529 patent/WO2021250129A1/en active Application Filing
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20190130391A1 (en) * | 2016-04-11 | 2019-05-02 | nChain Holdings Limited | Computer-implemented methods and systems for validating tokens for blockchain-based cryptocurrencies |
US20190228407A1 (en) * | 2016-07-25 | 2019-07-25 | Tbcasoft, Inc. | Digital property management on a distributed transaction consensus network |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2024052047A1 (en) * | 2022-09-08 | 2024-03-14 | Nchain Licensing Ag | Blockchain-based token protocol |
GB2622358A (en) * | 2022-09-08 | 2024-03-20 | Nchain Licensing Ag | Blockchain-based token protocol |
WO2024126027A1 (en) * | 2022-12-14 | 2024-06-20 | Nchain Licensing Ag | Computer-implemented methods and systems |
Also Published As
Publication number | Publication date |
---|---|
GB202008790D0 (en) | 2020-07-22 |
WO2021250046A1 (en) | 2021-12-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20230214792A1 (en) | Computer implemented systems and methods | |
US20240005304A1 (en) | Computer-implemented methods and systems for validating tokens for blockchain-based cryptocurrencies | |
US11133943B2 (en) | Issuing virtual documents in a block chain | |
CN108885746B (en) | Method and system for recording multiple transactions on a blockchain | |
WO2021250129A1 (en) | Computer implemented systems and methods for improved authentication of blockchain-based tokens | |
CN113412602A (en) | Method and system for anchoring physical objects based on tokens in a distributed ledger environment | |
US20220253813A1 (en) | Cryptographicaly secured hybrid (on and off blockchain) cryptocurrency system | |
US20030226028A1 (en) | Article, method, system and apparatus for decentralized creation, distribution, verification and transfer of valuable documents | |
CN116057554A (en) | Method for managing transaction data sets, participant unit, transaction register and payment system | |
CN111062717B (en) | Data transfer processing method, device and computer readable storage medium | |
Shope | The bill of lading on the blockchain: an analysis of its compatibility with international rules on commercial transactions | |
US20230214830A1 (en) | Blockchain supported banknote | |
Haga et al. | Blockchain-based autonomous notarization system using national eid card | |
CN109889343A (en) | Electronic invoice circulation control method and device | |
US20230259901A1 (en) | Issuing entity and method for issuing electronic coin data sets, and payment system | |
US20230084651A1 (en) | Method, terminal, monitoring entity, and payment system for managing electronic coin datasets | |
Jain et al. | Plasma chain and blockchain security model | |
JP2022089542A (en) | Processing system, processing device, processing method, and processing program | |
Gupta et al. | Blockchain-Based Electronic Voting System | |
US20240127233A1 (en) | Blockchain locking mechanism using paper share certificate | |
US20230267790A1 (en) | Banknote with processor | |
US20150206125A1 (en) | Method, system, and computer-readable medium for providing a near field secure electronic token transaction | |
Panduro-Ramirez et al. | Blockchain Implementation in Financial Sector and Cyber Security System | |
CN117730514A (en) | Revocation of keys by blockchain-based tickets | |
Koscina | Security and optimization of blockchains and associated algorithms |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 21733082 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 21733082 Country of ref document: EP Kind code of ref document: A1 |