Computer-implemented system and method for implementing transfer over blockchain network

Abstract

To provide an improve simple payment verification method and system for transfer implemented on a blockchain, and a storage medium.SOLUTION: A transferor transmits a payment transaction template to a transferee and requests complete transaction data for input transaction including at least one output that the transferee wants to spend as input to be transferred, Merkle paths for all input transactions, and complete transaction. The transferee provides their signature, in addition to the above information, and a change address optionally. The transferor uses the input transactions, Markle paths for them, and a local list of transferors of block headers, to execute local SPV check on the input transactions. The transferor broadcasts the transfer transaction to a P2P network.SELECTED DRAWING: Figure 10

Description

[Technical field]

[0001] The present invention relates generally to communication and transfer of resources over networks, and more specifically to transfers made over blockchain networks, and also to digital wallets. The present invention is particularly suited, but not limited to, to wallets for processing transfers of cryptocurrencies, tokens, and other resources implemented on or communicated over a blockchain. The present invention provides apparatus and techniques that provide numerous technical advantages, including, but not limited to, increasing the security, versatility, resilience, and efficiency of digital wallets and blockchain-based communications. [Background technology]

[0002] In this document, the term "blockchain" is used to include all forms of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The best-known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. For convenience and for purposes of explanation, Bitcoin may be referred to herein, but it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention. The term "Bitcoin" is used herein to include all variations of protocols or implementations derived from or implementing any variation of the Bitcoin protocol. The term "user" may refer to a person or a processor-based resource in this specification.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized system of blocks, which are made up of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system and includes at least one input and at least one output. Each block contains a hash of the previous block, so that blocks become strung together to create a permanent, immutable record of all transactions that have been written to the blockchain since its inception. The header of each block contains a field that provides the Merkle root of that block. The Merkle root is generated by repeatedly hashing together pairs of transaction IDs from the block until a single hash is arrived at. This Merkle root provides an efficient mechanism for verifying that a transaction is part of a block, as it allows users to verify a particular transaction without downloading the entire blockchain.

[0004] Transactions have small programs, known as scripts, embedded in their inputs and outputs that specify how and who can access the transaction's outputs. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0005] For a transaction to be written to the blockchain, it must be "validated." Network nodes (miners) perform work to ensure that each transaction is valid, and invalid transactions are rejected from the network. A software client installed on the node performs this validation work on unspent transactions (UTXOs) by executing locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to TRUE, the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, the transaction must i) be validated by the first node that receives the transaction, and if the transaction is validated, the node relays it to other nodes in the network, ii) be added to a new block constructed by miners, and iii) be mined, i.e., added to the public ledger of past transactions. (Note: validation as described above should not be confused with "verification," which is used herein to mean establishing or confirming whether a particular transaction is included in a block on the blockchain).

[0006] Once stored on the blockchain as a UTXO, a user can transfer control of the associated cryptocurrency to another address that is associated with the input in another transaction. This is often done using a digital wallet that stores a public and private key pair associated with the user's cryptocurrency. There are various forms of known cryptocurrency wallets, including SPV wallets (Simple Payment Verification).

[0007] In an SPV-based cryptocurrency exchange between Alice and Bob, both use the same type of SPV wallet. The SPV wallet stores the user's private and public keys, unspent transactions, and block headers. It also has the ability to connect to a blockchain network. The term "block header" is known in the art and is used to refer to the data provided at the top of a block of blockchain transactions. The block header uniquely identifies the block so that the block can be located on the blockchain. The block header comprises fields of data that provide a unique summary or fingerprint of the entire contents of the block. The block header contains a Merkle root, which is a hash of all of the transactions in that block. A user can then search the Merkle tree with that root to see (i.e., verify) whether a particular transaction was included in a particular block on the blockchain without having to download the entire blockchain.

[0008] The advantage of SPV wallets is that they allow devices with limited processing power and storage, such as phones and laptops, to operate within the Bitcoin ecosystem, since they only need to verify that a transaction has been verified (hence the name "simple payment verification"), rather than performing a full blockchain verification as other forms of wallets do. Because SPV wallets only download block headers without needing to contain any of the transactions, this reduces the storage space required from 159GB (as of November 2018) to 43MB, and storage requirements will only grow by a constant amount of 4.2MB per year as Bitcoin continues to expand.

[0009] Assume Alice wants to send some cryptocurrency or tokenized asset / resource to Bob. When using a traditional SPV wallet, the communication flow between Alice and Bob is as follows: 1. Alice creates a blockchain transaction (TX), specifying Bob's address in the output and providing a signature for the input (from a previously unspent transaction to Alice). 2. Alice broadcasts the transaction to the blockchain network. 3. Bob queries the network to verify that the transaction was accepted. [Prior art documents] [Patent documents]

[0010] [Patent Document 1] International Publication No. 2017145016 [Non-patent literature]

[0011] [Non-Patent Document 1] “Bitcoin: A Peer-to-Peer Electronic Cash System”, Satoshi Nakamoto, 2008, www.bicoin.org / bitcoin.pdf Summary of the Invention [Problem to be solved by the invention]

[0012] Essentially, the blockchain network acts as an intermediary between Alice's wallet and Bob's wallet. However, this is not only a resource intensive process, but also requires network connectivity. If the device on which Alice's wallet is running is offline for any reason, the transfer cannot be completed. Thus, technical challenges exist, including but not limited to, how to provide methods, systems, and devices for implementing more reliable and efficient mechanisms for electronic transfers from one entity (e.g., computing resource / node / digital wallet) to another.

[0013] It is therefore desirable to provide a solution that solves at least these technical problems. Such an improved solution is now conceived. Thus, according to embodiments of the present disclosure, there is provided a system and method as defined in the appended claims. [Means for solving the problem]

[0014] According to the present disclosure, a computer- and / or blockchain-implemented method and corresponding system may be provided. The system may comprise one or more computer-implemented resources. These may be hardware and / or software-implemented resources.

[0015] Embodiments of the present disclosure may provide a computer-implemented resource that may be operable to facilitate or enable the transfer of assets (between a transferor and a transferee) on or through a blockchain network. The transferor (the one sending the assets) may be referred to as Alice and the transferee (the one receiving the assets) may be referred to as Bob. The assets may be or comprise any type of asset, for example, a portion of a cryptocurrency or token, or anything else that may be transferred digitally in some manner via a blockchain transaction.

[0016] Additionally or alternatively, the system may be operable to facilitate or enable validation of blockchain transactions. This may be SPV validation. The system may be described as an SPV system. The term "operable to" is used herein to include the terms "made to" and "configured to."

[0017]

[0010] An embodiment of the present disclosure may provide a system operable to facilitate a transfer of assets on a blockchain between a transferor and a transferee, the system comprising: completed transaction data relating to at least one blockchain transaction; The completed Merkle path of at least one blockchain transaction and a first verification resource comprising: Receive and / or request completed transaction data for the at least one blockchain transaction and a Merkle path for the at least one blockchain transaction from a first validation resource. and a second verification resource operable to:

[0018] The transaction data may be complete, in the sense that it is sufficient to form a valid blockchain transaction according to the blockchain protocol. It may be referred to as "complete" transaction data. The first and / or second validation resource may additionally or alternatively be referred to as a "transfer resource" or simply a "computer-based resource."

[0019] The first validation resource may be substantially as disclosed herein with respect to Alice and / or in the section entitled "Offline SPV Wallet" and associated drawings. For convenience, the first validation resource may hereinafter be referred to as Alice and the second validation resource may hereinafter be referred to as Bob. The second validation resource may be substantially as described herein with respect to Bob or in the section entitled "PoS SPV Wallet" provided herein.

[0020] The second validation resource may be further operable to use the Merkle path to validate the Merkle proof for the at least one transaction.

[0021] Advantageously, the Merkle path can be provided to Bob by Alice, rather than having to be obtained from a peer on the blockchain network, which allows Bob to perform local SPV confirmation of at least one transaction without needing to access or communicate with the blockchain or network.

[0022] Moreover, data, requests, and responses may be sent (directly) between Bob and Alice using off-chain communication. The term "off-chain communication" is intended to mean that the communication does not go through, query, or interact with the blockchain or blockchain network. Alice and / or Bob may not be nodes or peers on the network.

[0023] The second validating resource may further be operable to send a transaction to the blockchain upon successful validation of the Merkle proof, which may be Tx3 as described and disclosed herein and with reference to Figures 8 and 10. It may be a blockchain transaction with an input that spends at least one blockchain transaction output (UTXO).

[0024] The first and / or second validation resource may be or may comprise a smart card, a digital wallet, a light and / or an SPV wallet.

[0025] The second validating resource may be operable to receive and / or request the complete transaction data and Merkle path from the first validating resource using off-chain communication, where "off-chain" may mean that the communication does not involve, go through, or interrogate a blockchain network and / or blockchain.

[0026] The system may further be operable to use the Merkle path to verify the Merkle proof for at least one transaction and, upon successful verification, transmit the transaction to the blockchain. The verification may be performed (locally) at or by a second verifying resource. It may be performed "off-chain", meaning that it is not performed by querying or using a blockchain network or blockchain.

[0027] The system may further comprise a plurality of second validation resources and a coordinating component operable to communicate with the plurality of validation resources, which may be substantially as disclosed herein as a "splitter wallet."

[0028] The first verification resource may be the transferor of the asset and the second verification resource may be the transferee of the asset.

[0029] A signature to spend the output of at least one blockchain transaction, Transfer value, and / or Public Key Address The second verification resource may be operable to receive and / or request from the first verification resource, or the first verification resource may also be operable to transmit to the second verification resource at least one of.

[0030] The transfer value may be an amount of cryptocurrency or other resource. It may be an asset or the value of an asset to be transferred. It may be the amount of a payment.

[0031]

[0013] Embodiments of the present disclosure also provide a blockchain implemented method, which may be a simplified payment verification method, that may be adapted to facilitate the transfer of assets on a blockchain between a transferor and a transferee, In the second verification resource, completed transaction data relating to at least one blockchain transaction; The completed Merkle path of at least one blockchain transaction and receiving a signal from the The transaction data and the Merkle path are received from a first validation resource that stores the transaction data and the Merkle path.

[0032] The method may further comprise using a Merkle path to verify the Merkle proof for the at least one transaction.

[0033] The method may further comprise the step of transmitting the transaction to a blockchain upon successful verification of the Merkle proof.

[0034] The following steps may be performed off-chain: i) verifying Merkle proofs; and / or ii) Receiving or requesting the completed transaction data and Merkle path from the first validating resource.

[0035] The first verification resource may be a transferor of the asset and the second verification resource may be a transferee of the asset. The second verification resource may be operable to send the transaction to the blockchain upon successful verification of the Merkle proof. The first and / or second verification resource may be or comprise a smart card, a digital wallet, or a lightweight and / or SPV wallet.

[0036] The present disclosure also provides a non-transitory computer-readable storage medium having stored thereon executable instructions which, when executed by a processor of a computer system, cause the computer system to at least perform an embodiment of a method or system as claimed or disclosed herein.

[0037] Any features described herein with respect to systems or resources are equally applicable to the methods of the present disclosure, and vice versa.

[0038] These and other aspects of the present disclosure will be apparent from and elucidated with reference to the embodiments described hereinafter, in which embodiments of the present disclosure will be described, by way of example only, with reference to the accompanying drawings. [Brief description of the drawings]

[0039] [Figure 1] FIG. 2 illustrates an “offline SPV wallet” according to an embodiment of the present disclosure. [Diagram 2] FIG. 2 illustrates an “Online and Offline SPV Wallet” according to an embodiment of the present disclosure. [Diagram 3] FIG. 2 illustrates a “PoS SPV Wallet” according to an embodiment of the present disclosure. [Figure 4] FIG. 1 illustrates a partial and completed template transaction and associated Merkle proofs according to an embodiment of the present disclosure. [Diagram 5] A diagram illustrating the flow of data and interactions between Alice and Bob when conducting a transaction using a split SPV wallet according to an embodiment of the present disclosure. [Figure 6] FIG. 1 is a schematic diagram of an embodiment of the present disclosure in use. [Figure 7] FIG. 1 is a schematic diagram illustrating a computing environment in which various embodiments may be implemented. [Figure 8] FIG. 1 is a schematic diagram showing three transactions and a Merkle path that may be used to associate them with a block (header). [Figure 9] FIG. 1 illustrates a conventional SPV payment method. [Figure 10] FIG. 1 illustrates a method according to an embodiment of the present disclosure. [Figure 11]FIG. 1 shows an example of a binary Merkle tree as known in the prior art. [Figure 12] FIG. 2 illustrates a Merkle existence proof of a data block D1 in a tree represented by root R using a Merkle path according to the prior art. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0040] Prior Art: Merkle Trees Embodiments of the present disclosure utilize and benefit from the concept of Merkle trees, and are therefore described for background purposes only.

[0041] A Merkle tree is a hierarchical data structure that allows for secure verification of a collection of data. In a Merkle tree, each node in the tree is given an index pair (i, j), denoted as N(i, j). The indices i, j are simply numerical labels that relate to a particular position in the tree. An important feature of a Merkle tree is that the construction of each of its nodes is governed by the following (simple) formula:

[0042]

number

[0043] where k=(i+j-1) / 2 and H is a cryptographic hash function.

[0044] The labeled binary Merkle tree constructed according to these formulas is shown in Fig. 11, from which it can be seen that the case i=j corresponds to a leaf node, which is simply the data D i We can see that j is the hash of the i-th packet of j. If i ≠ j, it corresponds to an internal or parent node, which is generated by recursively hashing and concatenating the child nodes until a single parent (the Merkle root) is found.

[0045] For example, node N(1, 4) receives four data packets D1...D4 as follows: N(1,4) = H(N(1,2) || N(3,4)) = [H(N(1,1) || N(2,2)) || H(N(3,3) || N(4,4))] = [H(H(D1) || H(D2)) || H(H(D3) || H(D4))] It is constructed as.

[0046] The tree depth M is defined as the lowest level of a node in the tree, and the depth m of a node is the level at which it resides. For example, in Figure 11, root = 0 and m leaf =M and M=3.

[0047] Merkle Proof The main feature of a Merkle tree is that any data packet D1 can be expressed as a list or set D∈{ D1, ... , D N The goal of the proof is to verify that a data packet D1, ..., D is an element of {\displaystyle \mathbb {D1, ... , D}}. The mechanism for verification is known as a Merkle proof, and consists of obtaining a set of hashes known as a Merkle path for a given data packet D1 and a Merkle root R. A Merkle path for a data packet is simply the minimal list of hashes required to reconstruct the root R by repeated hashing and concatenation, sometimes called an "authentication path". A proof of existence is a proof that a data packet D1, ..., D N is known to the prover. However, this requires a much larger storage overhead than a Merkle path, and also requires that the entire data set is available to the prover. A comparison of using a Merkle path versus using the entire list is shown in the table below, where we used a binary Merkle tree and assumed that the number of data blocks N is strictly equal to an integer power of 2. If this were not the case, the number of hashes required for a Merkle proof would differ by ±1 in each case.

[0048] [Table 1]

[0049] In this simplified scenario, where the number of data packets is equal to the number of leaf nodes, we can see that the number of hash values ​​required to compute a Merkle proof scales logarithmically. Rather than storing N data hashes and computing a trivial proof, it takes only log k It is obviously much more efficient and practical to compute a Merkle proof involving N hashes.

[0050] method Given a Merkle root R, let D∈{D1, ... , D1} be a set D∈{D1, ... , D1} such that D1 is represented by R. N}, one can perform a Merkle proof as follows: i. Obtain the Merkle root R from a trusted source. ii. Obtain a Merkle path Γ from the source, where Γ is a set of hashes. Γ = {N (2, 2), N(3, 4), N(5, 8)} iii. Compute the Merkle proof using D1 and Γ as follows: a. Hash the data block to get: N(1, 1) = H(D1) b. Concatenate with N(2, 2) and hash to get: N(1, 2) = H(N(1, 1) || N(2, 2)) c. Concatenate with N(3, 4) and hash to get: N(1, 4) = H(N(1, 2) || N(3, 4)) d. Concatenate with N(5, 8) and hash to get the root. N(1, 8) = H(N(1, 4) || N(5, 8)) R' = N(1, 8) e. Compare the root R obtained in (i) with the calculated root R'. I. If R'=R, then the existence of D1 in the tree, and therefore the data set D, is confirmed. II. If R' ≠ R, then the proof fails and D1 is not established to be an element of D.

[0051] This is an efficient mechanism for providing a proof of existence of some data as part of a data set represented by a Merkle tree and its root. For example, if the data D1 corresponds to a blockchain transaction and the root R is publicly available as part of the block header, then it can be immediately proven that the transaction was included in that block.

[0052] The process of authenticating the existence of D1 as part of our exemplary Merkle tree is shown in Figure 12, which shows a Merkle existence proof of data block D1 in the tree represented by root R using a Merkle path. This demonstrates that performing a Merkle proof for a given block D1 and root R is effectively a traversal "up" of the Merkle tree by using only the minimum number of hash values ​​necessary.

[0053] Some embodiments of the present disclosure use these techniques to provide more efficient and secure verification methods, and attention is now directed to a discussion thereof.

[0054] Simplified Payment Validation (SPV) Because the present disclosure provides an improved SPV solution, for ease of reference, a summary of known SPV verification techniques is provided here.

[0055] In the following, consider Alice (customer) and Bob (merchant) who wish to transact at the point of sale of some goods. Using the traditional method as outlined in the Nakamoto whitepaper ("Bitcoin: A Peer-to-Peer Electronic Cash System", Satoshi Nakamoto, 2008, www.bicoin.org / bitcoin.pdf), we examine how this interaction occurs using Simple Payment Verification (SPV). The same interaction is later explained with respect to an illustrative embodiment of the invention, in the section entitled "Overview of the Invention". In both cases, consider the role of three blockchain transactions (Tx). Two transactions have spendable outputs (UTXO) owned by Alice. Tx1 - transaction with consumable output (vout-1) Tx2 - transaction with consumable output (vout-0)

[0056] These transactions Tx1, Tx2 are referred to herein as input transactions as a shorthand way of stating that they are transactions whose output is consumed by the input of some subsequent transaction, say Tx3.

[0057] The third blockchain transaction is a payment transaction. · Tx3 - A transaction using vout-0 and vout-1 as two inputs and one output paying Bob. For a simpler demonstration of the invention, there are only two inputs and one output.

[0058] These three transactions, and the Merkle path that may be used to associate them with blocks (headers), are shown diagrammatically in Figure 8.

[0059] The basic concept of SPV has been around since the Nakamoto whitepaper and was implemented in the first Bitcoin client (v 0.1, 2009). Essentially, SPV takes advantage of two properties of the Bitcoin blockchain: 1. Merkle proofs that can be easily used to verify that a given transaction is included in a Merkle tree and represented by a Merkle root; and 2. A block header that represents a block of transactions by including the Merkle root of the transaction's Merkle tree.

[0060] Combining these two properties, in order to verify that a transaction has been processed by the network, a lightweight Bitcoin client only needs to maintain a copy of the block header for the entire blockchain, rather than maintaining the blocks in their entirety. To verify that a given transaction has been processed and included in a block, an SPV client: A complete list of the latest block headers, Merkle pass for eligible transactions Only the .

[0061] From property 1, we know that an SPV user can verify that a given transaction is part of the Merkle tree represented by the Merkle root by simply performing a Merkle path authentication proof as described in the section above. And from property 2, we know that if the SPV client has a valid block header that contains this Merkle root, then the transaction is also part of a block in the blockchain. Performing this type of payment verification in Bitcoin is referred to herein as performing "SPV verification."

[0062] This SPV mechanism as specified by Nakamoto characterizes existing methods of SPV client implementation, including point of sale. Importantly, the state of the art in SPV implementation is based on a paradigm where a user verifies that a payment has been received by ensuring that the payment is included in a block (up to an appropriate depth on the blockchain, e.g., 6). In effect, this is a post-broadcast confirmation of the transaction to verify that it has been mined.

[0063] In contrast, the present invention requires that the necessary SPV checks be performed on transaction inputs prior to broadcasting the transaction. This change in emphasis greatly reduces the load and traffic on the network when dealing with invalid transactions.

[0064] The second important paradigm in existing SPV systems is that an SPV client must query every node on the network to obtain the Merkle path required for SPV confirmation. This can be found in the Bitcoin Developer Guide (https: / / bitcoin.org / en / developer-guide), which states that "SPV clients know the Merkle root and associated transaction information, and request each Merkle branch from a full node."

[0065] Embodiments of the present invention provide mechanisms and methods for SPV verification that eliminate this burden on the network by providing that users of lightweight Bitcoin clients keep, maintain, or at least have access to their own copies of the Merkle paths for any unspent transaction outputs that they own.

[0066] Referring to FIG. 9, the conventional method for implementing SPV (at the time of the transaction) is as follows.

[0067] [1] Message: From Bob to Alice Bob (the merchant) sends his public key address to Alice (the customer). Bob's message may also include the amount to be paid, along with any other spending terms, provided as a hash of Bob's chosen redemption script. · Alice also communicates the transaction ID TxID3 of the payment transaction Tx3 to Bob (not shown).

[0068] [2] A P2P network mediates the exchange between Alice and Bob. [2.i] Message: From Alice to the P2P network ·Alice broadcasts Tx3 to the network. [2.ii] Message: From Bob to the P2P network Bob queries the network to see if Tx3 is accepted for mining into the blockchain. · Bob sends successive queries [2.ii] until he is satisfied that the payment will be considered valid by the network. Note that Bob may start querying before [2.i] has been made. If Bob is satisfied, he may treat the transaction as completed, without either party waiting for the next block to be mined.

[0069] [3] SPV confirmation (message): From Bob to P2P network Bob waits for the next blocks to be mined and downloads new block headers as they are broadcast on the network. Bob sends an “SPV confirm” request to the network. This is a request for a Merkle path corresponding to Tx3 that binds Tx3 to a Merkle root in a recently mined block. If the network can provide the Merkle pass to Bob, Bob can use his SPV wallet to calculate the Merkle proof himself and verify that payment Tx3 has been processed.

[0070] This communication flow is shown in Figure 9. Note that [2.i], [2.ii], and [3] are mediated by the P2P network and therefore contribute to the traffic on the network. In the existing SPV paradigm, the required SPV confirmation [3] is After payment (Tx3) is made, -When making the payment (Tx3), With the help of other network peers who provide Merkle paths, Note also that it is executed.

[0071] This known approach will now be contrasted with the approach of the present invention.

[0072] Overview of the Disclosure

[0073] The present disclosure provides an improved security solution for verification on a blockchain network (hereafter referred to for convenience as the "Bitcoin" network) using a low bandwidth SPV system. In accordance with embodiments of the present invention, a sender of a resource (e.g., a customer) does not need to be online for a transaction to be made and / or accepted by a recipient (e.g., a merchant); only the recipient needs to be online. For convenience and ease of reference, the terms "customer" or "Alice" are used in place of "sender" and the terms "merchant" or "Bob" are used in place of "recipient."

[0074] Embodiments of the present disclosure utilize a new communication flow between the parties compared to traditional SPV transactions, as it only requires the merchant's wallet to be connected to the network. This is accomplished by the merchant's wallet creating a template (sometimes called an "unfinished transaction") with the information the customer needs to provide, e.g., change address, signature, etc. Once the merchant receives this required information from the customer, it broadcasts the transaction to the network.

[0075] Thus, the present disclosure describes the process of communication and exchanges between transacting parties and the network during a simple payment verification on the Bitcoin network: Supplier → Customer → Network → Supplier from Supplier → Customer → Supplier → Network to fundamentally change it.

[0076] Alice and Bob may exchange messages privately using a secret sharing protocol, such as that described in WO2017145016.

[0077] This change in process creates technical challenges that require new designs for both customer wallets and merchant wallets. Therefore, embodiments of the present invention provide at least the following: 1. A new customer wallet for Alice (call it the "offline wallet"): It remembers Alice's public key, private key, the transactions including their spendable outputs, all block headers, and, importantly, the Merkle paths of the transactions. (Removing the requirement for Alice to be connected to a network) 2. A new merchant wallet for Bob (call it a "Point of Sale (PoS) wallet"): It stores Bob's public key and all block headers.

[0078] A more detailed description of these components is now provided.

[0079] Referring to FIG. 10, an exemplary method for implementing SPV (at the time of the transaction) according to an embodiment of the present invention is given as follows.

[0080] [1] Message: From Bob to Alice Bob sends a payment transaction template (template Tx3) to Alice, requesting the following information from Alice: The complete transaction data for all input transactions (Tx1 and Tx2) with at least one output that Alice wants to spend as input to a payment (Tx3); A Merkle path for every input transaction (Tx1 and Tx2), linking the input transaction with each Merkle root associated with the respective block header; A completed (i.e. filled-in template) payment transaction (Tx3). Note that Bob is requesting information from Alice rather than sending his address.

[0081] [2] Message: From Alice to Bob · Alice sends the requested information to Bob: The complete transaction data for all input transactions (Tx1 and Tx2) with at least one output that Alice wants to spend as input to a payment (Tx3); A Merkle path for all input transactions (Tx1 and Tx2), linking the input transactions with their respective block headers; Complete (i.e., filled-in template) payment transaction (Tx3). In addition to filling in the template, Alice also provides her signature.

[0082] [3] SPV verification (local): Bob Bob, Transactions Tx1 and Tx2, The corresponding Merkle paths Path 1 and Path 2, Bob's local list of block headers 2. Perform SPV checking on input transactions Tx1 and Tx2 using These checks are performed locally by Bob and do not go through the P2P network. In a preferred embodiment, at this stage, Bob: Payment Tx3 is as expected by Bob, Alice's signature is valid for this transaction It also performs appropriate checks on the payment Tx3 received from Alice to ensure that

[0083] [4] Message: From Bob to the P2P network Bob broadcasts a payment transaction (Tx3) to the P2P network. In the existing paradigm, Alice submits the transaction to the network. This is done only if the SPV checks[3] for all inputs to Tx3 are positive.

[0084] [5] SPV confirmation (message): From Bob to P2P network This step is identical to step [3] in the existing paradigm of the SPV methodology (see earlier).

[0085] This communication flow is shown in Figure 10. Note that only [4] and [5] are mediated by the P2P network. Step [5] is merely an iteration of existing SPV techniques and is not a necessary feature of the proposed method. It is included here for completeness and to distinguish the present invention from existing paradigms.

[0086] According to an embodiment of the present disclosure, the required SPV verification [3] is Before the payment transaction (Tx3) is issued, For input transactions (Tx1 and Tx2) to a payment transaction (Tx3), Without the help of network peers to provide a Merkle path (provided by Alice), Note that it is executed.

[0087] Features of embodiments of the present invention include, but are not limited to, the following. Alice does not need to be online or expose any information to the network herself, which is more reliable for Alice. It also allows Alice to use devices such as smart cards that do not have the ability to connect to the network. Including the Merkle path allows Bob to immediately reject any invalid input from Alice. This reduces excess network traffic by rejecting "spam" transaction submissions with invalid Merkle paths. · Bob may have a particularly fast connection to the network, so it may be faster for Bob to validate the transaction. Because Bob creates the transaction for Alice to sign, he has greater control over the contents of the transaction; for example, Bob may choose to pay more in transaction fees to ensure that the transaction is accepted by the network. Bob's wallet does not need to contain any private keys. This increases security because unauthorized third parties cannot access or compromise the private keys. · Bob is responsible for submitting transactions to the network. Alice's SPV wallet must have a private key and the ability to sign transactions. It should therefore have sufficient capacity to perform elliptic curve point multiplication.

[0088] Considering now in more detail the various components of the arrangement according to the present disclosure.

[0089] Offline SPV Wallet An embodiment of an offline SPV is shown diagrammatically in FIG. 1 and comprises the following features: 1. TX - Preloaded full transaction data, including Alice's available unspent transaction outputs. This full transaction data, in combination with the Merkle path, constitutes a Merkle proof that the transaction Alice is spending is valid. Hashing the full transaction gives a transaction ID (TXID), which is required as part of the input data for any new transaction Alice wishes to complete. Note that providing only the TXID is not sufficient, as Bob must be able to verify that the TXID is indeed the hash of the transaction. This is only possible if Alice provides Bob with the full transaction data, so Alice must store it, or at least have access to it when it is needed. 2. Private / public keys - A wallet must have access to a set of private keys in order to sign transaction outputs, and access to public keys in order to specify change addresses when making transactions. 3. Merkle Path - Each (completed) Merkle path of a transaction including its transaction outputs (UTXOs). This is used by the merchant's point-of-sale wallet to verify that the TX is valid. Note that the Merkle proofs provided by this wallet do not prevent double-spend, but act as a fail-fast mechanism against spam attacks, thus increasing the robustness and security of the wallet. 4. Minimal Processing - An offline SPV wallet is required to sign unspent transactions in order to spend them. This means that the offline wallet (and the device it is installed on) needs to be capable of implementing cryptographic algorithms such as ECDSA, and needs to have enough processing power to be able to perform elliptic curve point multiplications and calculate hash functions. 5. Block Headers (Optional) - An offline SPV wallet may want to include block headers to verify that a payment to a point-of-sale SPV wallet has been processed. This will also require remembering the TXID and Merkle Pass after interacting with the point-of-sale wallet.

[0090] In one or more embodiments, the above may be implemented as a wallet with both online and offline states or mechanisms, which may be advantageous when the wallet needs to update its collection of UTXOs and Merkle paths.

[0091] In such an embodiment, Alice's wallet can download data by temporarily connecting to the network in the same manner as a traditional SPV wallet, which is shown in Figure 2 and may conveniently be referred to as an on- and offline SPV wallet.

[0092] Once connected, Alice's wallet can download complete transactions, Merkle paths, and block headers. A standard P2PKH transaction as known in the art with one input and two outputs is 226 bytes, the block header is 80 bytes, and the Merkle path for a transaction in a block containing 100000 transactions is approximately 560 bytes. Combining all three means that updating Alice's SPV wallet requires downloading less than 1MB of data per new input. This can be achieved even over low bandwidth connections, which is highly advantageous.

[0093] Wallets using this embodiment are advantageous because they provide the benefit of being able to facilitate offline payments and verifications using the blockchain while still maintaining the ability to connect to the network when needed. Additional online state can be used to update the list of block headers, obtain new TX and associated Merkle paths, and also send transactions when needed.

[0094] There are multiple use cases for online and offline SPVs, including software applications and contactless payment cards.

[0095] PoS SPV Wallet The PoS SPV wallet is designed to achieve the minimum functionality required for Bob to accept transfers from Alice, who is using an offline SPV wallet as described above. These requirements are that Bob: Must be able to generate point of sale transaction templates It must be possible to compute a Merkle proof associated with the block header. Must be able to connect to the network and broadcast, including querying UTXO sets It must be possible to manage the public key address for receiving payments It must be possible to update the complete TX data list, including Alice’s UTXOs. That is it.

[0096] All the above requirements are met by a PoS SPV wallet following the schematic design shown in Figure 3 and having the following features: 1. Block Headers - A PoS SPV wallet maintains an up-to-date copy of a list of block header data corresponding to blocks in the blockchain. When presented with a transaction and its Merkle path, a PoS SPV wallet can perform a simple Merkle proof by repeated hashing to the Merkle root. By comparing this root with the root in the relevant block header, Bob has an efficient fail-fast mechanism for detecting erroneous or fraudulent payments. 2. Network Connectivity - PoS SPV wallets have the ability to connect to the network, including but not limited to the ability to broadcast new signed transactions to the blockchain network and to query the existence of specific UTXOs in the current UTXO collection. 3. Public Key Storage - A PoS SPV wallet only needs to store the public key addresses from which Bob wants to receive assets or payments. This can be done in a number of ways, for example, by using deterministic secrets (such as those disclosed in WO 2017 / 0145016) or by using a hierarchical deterministic wallet structure. By storing only the public key address at the point of sale and not the associated private key, security for "card present" transactions is greatly improved as Bob's private key is not compromised and therefore funds are protected. 4. Minimal Processing - PoS SPV wallets are only required to perform the minimal processing of Merkle proofs, based on a template filled in by Alice. This greatly reduces the burden of repeatedly processing full blocks to independently obtain the Merkle path, which expedites the point of sale / transaction process and facilitates the transfer of resources across the network, improving efficiency for both Bob and Alice.

[0097] Note that in at least one embodiment, the point-of-sale SPV wallet maintains a copy of the entire list of block headers to ensure that Bob can always perform SPV verification on the Merkle path for any transaction in the blockchain's history. However, Bob may choose not to maintain a complete list of block headers, e.g., to maintain those that correspond to blocks that do not contain transactions with consumable outputs. In this case, it should be understood that Bob may have to occasionally query a third party to obtain block headers that he does not already have. The next section details the merchant point-of-sale template that Bob sends to Alice according to one or more embodiments, and it should be understood that Bob may include a request for block headers associated with his unspent transaction outputs into this template if he does not have a complete list of all block headers.

[0098] PoS SPV wallet template Looking at Figure 4, Bob’s PoS SPV wallet will request Alice’s offline (or off / online) wallet information in the following format: 1. TX / UTX - The complete transaction data from Alice's spendable transaction (as described above). 2. Transaction Template - A partially completed blockchain transaction with (at least) the output address of Bob and the amount of cryptocurrency requested by Alice. For the transaction to be completed, Alice's offline wallet must provide (at least) the TXIDs from her unspent transaction outputs, a valid signature for each of the spendable TX outputs that should be used, and the change address. 3. Merkle Path - When combined with the complete completed transaction, a Merkle proof can be constructed to verify that Alice's TX was included in the block and is therefore valid.

[0099] Note that in the simplest case, Alice needs to provide Bob with a valid payment transaction Tx3 in exchange for the goods at the PoS. According to at least one embodiment of the present invention, Bob provides a merchant template to facilitate this, but it is conceivable that no template is used. For example, if Alice already knows the price and Bob's address in advance, she can construct her payment and send it directly to Bob. Alice may also provide the required signature and output point reference without explicitly "filling" the template itself.

[0100] The complete transaction (see (1) in Figure 4) and Merkle proof (see (3) in Figure 4) can be sent by Alice and processed by Bob, in parallel and independently from Alice completing Bob's template (see (2) in Figure 4).

[0101] Delayed Transaction Submission In some cases, such as for online merchants, it may be advantageous to submit payment transactions as batches at regular intervals. This may be advantageous for technical reasons, such as waiting for an improved / optimal network connection to become available, for accounting purposes, or to reduce the total amount of transaction fees incurred.

[0102] For merchant Bob, this poses no additional challenges, but for customer Alice, it means that Alice will not be able to spend the cryptocurrency associated with Alice's change address until Bob has submitted a final signed transaction to the network.

[0103] The solution to this problem is for Bob to specify an artificial delay in processing transactions in the template he provides to Alice. Alice's offline wallet can interpret this as meaning that the change generated by a payment to Bob cannot be spent for the merchant's predefined time before submitting the batched transactions to the network. Note that in this scenario, Bob has no additional risk, since he can cancel the delivery of the purchased goods if the merchant finds evidence of double-spending before submitting the batch of transactions.

[0104] Extension to PoS SPV Wallet - Split Wallet As an extension to the PoS SPV wallet described above, it may be desirable for Bob to utilize several connected wallets with different functionality, which can be treated as a single split wallet system.

[0105] Thus, some embodiments of the present invention build on the basic concept of a Point of Sale (PoS) SPV by introducing a more advanced Master SPV that can coordinate one or many Point of Sale wallets. The combination of a Master SPV with one or more PoS SPVs is considered herein to be a "split wallet" system.

[0106] A split wallet system according to an embodiment of the present invention comprises at least one PoS SPV wallet acting as a payment terminal, coordinated by a Master SPV component. The function of the Master SPV is that the wallet: Allows storing private keys associated with public key addresses of PoS SPVs. Allows to compute the Merkle proof associated with the block header. Allows you to connect to and broadcast blockchain networks, including querying UTXO sets. · Allows communication with at least one PoS SPV wallet acting as a payment terminal.

[0107] Like all simple payment validation systems, the master wallet should be able to perform all the basic functions of a good SPV, such as verifying the Merkle proof of existence for a given transaction. This means that Bob can verify that any transaction he broadcasts from the point of sale onwards is accepted by the network and included in a block. Importantly, however, the master wallet according to an embodiment of the present invention communicates with at least one simpler Pos SPV wallet, thereby coordinating payments being processed.

[0108] It may be advantageous for the master SPV to store the private key for Bob's payment address. This allows Bob to have more security for his payment transactions when using a split wallet system. However, storing Bob's private key is an optional capability of the master wallet, whose primary function is to aggregate and coordinate payments from multiple point-of-sale wallets.

[0109] In this implementation of a merchant split wallet using only the basic Master SPV, the merchant-customer interaction is not significantly modified. PoS SPV wallets must still perform the same checks on the Merkle path and make the same queries to the network for the UTXO set. Differences in the process include: ·Selection of PoS SPV terminals to be used by Alice and Bob. · The Master SPV should continuously sync with the blockchain in the background. The private key associated with Bob's payment address receives dedicated control from the master wallet. This adds structure to the security previously provided by just storing the public key address in the point-of-sale wallet.

[0110] Note that a master wallet used as part of a split wallet implementation will typically reside in a separate location relative to the point of sale SPV, such as a corporate back office or head office, for both security and practical considerations. The merchant-customer interaction can be visualized as shown in Figure 5.

[0111] As discussed, this embodiment of using a simple master SPV as part of the merchant split wallet has utility for Bob, but still relies on the network to respond to queries for UTXO sets if the split wallet is to provide an adequate level of double-spend protection.

[0112] This may be addressed according to one or more embodiments, such that the master SPV is replaced by a stronger type of master wallet that also holds its own copy of the mempool. A split wallet architecture equipped with such a master wallet does not need to query the network to see if a customer's UTXO is not part of the current UTXO collection.

[0113] A master wallet with its own copy of the mempool functions similarly to a traditional non-mining "full node" client, but advantageously does not need to hold a full copy of the blockchain. Instead, this type of master wallet holds only a unique local copy of the block headers and the mempool. The copy of the mempool can either be built locally by synchronizing with the network, or obtained from a trusted third party or service.

[0114] The split wallet implementation using a master SPV wallet with its own copy of the mempool changes the merchant-customer interaction from the merchant's perspective. The main changes in the interaction from that described above in relation to FIG. In step 4, the merchant simply broadcasts the transaction to the network rather than appending any further queries for the UTXO set. In step 5, the merchant now performs an independent check on the validity of the customer's transaction by checking the mempool for conflicting transactions. The merchant can then decide what action to take based on the state of its synchronized copy of the mempool.

[0115] Examples of inventions used Consider a typical merchant-customer interaction, such as Alice wanting to buy something from Bob. According to one embodiment of the invention, the process is carried out as outlined below and with reference to FIG. 1. Bob creates a partially completed blockchain transaction and requests the following information from Alice, which can be packaged together as a template for Alice to fill in: a. The TX power Alice will spend to complete the purchase b. (Bitcoin) change address for Alice c. Signature from Alice d. Merkle path for TX (this does not form part of the transaction) 2. Alice completes the template by providing the required information. 3. Bob runs a Merkle proof to verify the validity of the TX provided by Alice. If the proof is not valid, Bob knows that Alice's TX was never valid in the blockchain and rejects the transaction. Advantageously, this is a fail-fast mechanism. 4. Bob broadcasts his completed transaction to the network and queries the UTXO set. a. Broadcasting allows miners to begin attempting to mine a transaction into a block. b. The query asks whether the seemingly valid UTXO provided by Alice is still in the UTXO set. This is a mechanism to prevent double consumption by Alice. 5. The network responds to Bob's UTXO query, allowing Bob to adopt one of the following courses of action: If Alice's UTXO is still part of the set of UTXOs, Bob can accept the payment while minimizing the risk of double-spending. i. The risk Bob takes can be minimized by continuing to poll the network nodes with this query for some time interval τ. ii. Bayesian analysis can be used to ensure that Bob queries a majority of nodes that are trustworthy, within some confidence interval. b. If Alice's UTXO is not part of the set of UTXOs, Bob rejects Alice's payment.

[0116] As mentioned above, embodiments of the present invention lend themselves to use and implementation in a variety of forms, which may include, for example, payment cards.

[0117] As known in the art, traditional SPV wallets verify that a transaction is not a double-spend by checking its depth in the blockchain, which it does by querying the network. Once a transaction is validated by miners and included in a block, it has one confirmation. Every additional block added to the blockchain increases the confirmation by one, and with each new confirmation, the risk of double-spending decreases. Traditional SPV wallets show a transaction as "unconfirmed" until it has six confirmations.

[0118] However, the default 6 confirmation rule is not important for Bitcoin. Not all merchants want to wait for 6 blocks (or even 1) to be generated before they are satisfied with a payment. "0-conf" is a term used in the art to describe a transaction that has not yet been included in a block. Once Alice completes her transaction, she broadcasts it to the network, and Bob should be able to find it (at least) in the mempool.

[0119] The present invention shifts the burden of broadcasting transactions to the receiver, Bob, rather than the sender, Alice, thereby minimizing the CPU required and improving Alice's experience. Bob has more control over the transaction process since he does not need to rely on Alice's connection to the network, but not so much control that it compromises Alice's security. Essentially, Alice (and only she) has the authority to accept or reject a transaction by providing a digital signature.

[0120] The Merkle path does not prevent double-spends, since 0-conf is reached only when Bob can see that the transaction being relayed by the network is in the mempool. Instead, it acts as a fail-fast mechanism, allowing Bob to immediately reject attempts to consume non-existent UTXOs. This is useful, especially since the time it takes to broadcast and query full nodes can be several seconds or more on a poor connection, preventing Bob from being used as a middleman in spam attacks.

[0121] With offline payments enabled, hardware such as prepaid smart cards can be integrated into the Bitcoin ecosystem. A payment card requires data capacity to store private keys as well as UTXOs, completed transactions, and Merkle paths. It also requires some processing power to implement the ECDSA signature algorithm. Table 1 shows a list of some electronic card types available upon registration.

[0122] [Table 2]

[0123] double consumption protection Suppose a customer, Alice, wants to exchange cryptocurrency for physical goods at a store. Traditionally, Alice would submit a transaction to the blockchain network at the point of sale (POS), and merchant Bob would receive a ping from the blockchain network. (a) returned to Bob as accepted by the network, or (b) be verified in blocks (or up to n blocks in the case of n-conf) Only when it has confirmed that either

[0124] In scenario (a), Bob knows that Alice's payment transaction to Bob is valid, and a miner will attempt to mine this payment into a block. This does not protect Bob from a simple double-spend initiated by Alice remotely submitting a conflicting transaction, but this scenario is consistent with traditional block header-based SPV.

[0125] In scenario (b), Bob knows that the payment transaction is valid and has not been double-spent. However, this requires Bob to run a full node and download the next block immediately, and in the Bitcoin network this takes on average 10 minutes before Alice can leave the premises with the goods.

[0126] Note that in this problem statement, we assume that 0-conf security is sufficient for Bob since the attack we are trying to mitigate is simple double-spend by Alice. Requiring that one or more blocks should mitigate a different attack vector by a third adversary, Carol, would overwhelm the entire network.

[0127] The following table illustrates how neither scenario (a) nor (b) would be acceptable, independently, for such a customer-merchant interaction. The table illustrates the transaction characteristics of scenarios a) and b).

[0128] [Table 3]

[0129] * means there is no full node requirement for this party. Only a solution that meets all of these criteria will be acceptable to both Bob (the merchant) and Alice (the customer) for the majority of transactions.

[0130] The merchant PoS wallet embodiments disclosed herein provide the following advantages: -Double consumption protection for merchants Instantaneous (<<10 seconds) average transaction time · Both customers and merchants can use SPV wallets at the point of sale

[0131] [Table 4]

[0132] It is anticipated that embodiments of the present invention will provide performance and results that far exceed existing SPV / cryptocurrency transaction rates and will be able to at least rival existing chip-and-pin / contactless terminal payment operations in terms of instantaneity.

[0133] Moreover, the present invention allows for payments to be cleared and approved with a high degree of certainty within about an hour (i.e., 6-conf), which is far superior to current payment clearing times of up to 60 days, i.e., VISA and Mastercard clearing times.

[0134] Variable Risk As a merchant, Bob can tune the latency for accepting payments at the point of sale. By choosing the shortest polling interval τ, Bob sets a relevant upper bound on the tolerable risk of double spend. This can allow for greater efficiency and flexibility in the merchant's payment processing.

[0135] Additionally, Bob can set a mining fee for the transaction when he creates the template. It doesn't necessarily matter who pays this fee, but the value can be used as a parameter to set the risk of double-spending to a level deemed acceptable by the merchant.

[0136] Overall, the time delay at the point of sale and the mining fee for the transaction are two parameters that can be set by the merchant and agreed to by the customer's digital signature, which can effectively tune efficiency and risk on a case-by-case basis, which may depend for example on the value of the goods that are going to be exchanged.

[0137] Turning now to FIG. 7, an illustrative simplified block diagram of a computing device 2600 that may be used to practice at least one embodiment of the present disclosure is provided. In various embodiments, the computing device 2600 may be used to implement any of the systems shown and described above. For example, the computing device 2600 may be configured for use as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 7, the computing device 2600 may include one or more processors with one or more levels of cache memory and a memory controller (collectively designated 2602) that may be configured to communicate with a storage subsystem 2606 that includes a main memory 2608 and persistent storage 2610. As shown, the main memory 2608 may include a dynamic random access memory (DRAM) 2618 and a read only memory (ROM) 2620. The storage subsystem 2606 and the cache memory 2602 may be used for storage of information, such as details associated with transactions and blocks as described in this disclosure. The processor 2602 may be utilized to provide the steps or functions of any embodiment as described in this disclosure.

[0138] The processor 2602 may also be in communication with one or more user interface input devices 2612 , one or more user interface output devices 2614 , and a network interface subsystem 2616 .

[0139] The bus subsystem 2604 may provide a mechanism for allowing various components and subsystems of the computing device 2600 to communicate with each other as intended. Although the bus subsystem 2604 is shown diagrammatically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses.

[0140] The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may act as an interface for receiving data from other systems and transmitting data from the computing device 2600 to other systems. For example, the network interface subsystem 2616 may enable a data technician to connect the device to a network so that it may be possible to transmit data to and receive data from the device while the data technician is at a remote location, such as a data center.

[0141] The user interface input devices 2612 may include one or more user input devices, such as a keyboard, a pointing device such as an integrated mouse, trackball, touchpad, or graphics tablet, a scanner, a barcode scanner, a touch screen integrated into a display, a voice recognition system, an audio input device such as a microphone, and other types of input devices. In general, use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600.

[0142] The one or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display such as an audio output device. The display subsystem may be a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a light emitting diode (LED) display, or a projection or other display device. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. The one or more user interface output devices 2614 may be used to present a user interface, for example, to facilitate user interaction with applications that execute the described processes and variations thereof, when such interaction may be appropriate.

[0143] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data constructs that may provide functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions), which when executed by one or more processors, may provide functionality of one or more embodiments of the present disclosure, may be stored in the storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. The storage subsystem 2606 may additionally provide a repository for storing data used in accordance with the present disclosure. For example, the main memory 2608 and the cache memory 2602 may provide volatile storage for programs and data. The persistent storage 2610 may provide persistent (non-volatile) storage for programs and data and may include flash memory, one or more solid-state drives, one or more magnetic hard disk drives, one or more floppy disk drives with associated removable media, one or more optical drives with associated removable media (e.g., CD-ROM or DVD or Blue-Ray drives), and other similar storage media. Such programs and data may include programs for performing the steps of one or more embodiments as described in this disclosure, as well as data associated with transactions and blocks as described in this disclosure.

[0144] The computing device 2600 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described below. In addition, the computing device 2600 may include another device that may be connected to the computing device 2600 through one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). The device that may be connected to the computing device 2600 may include multiple ports configured to accept fiber optic connectors. The device may thus be configured to convert optical signals into electrical signals that may be transmitted through the ports that connect the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, the description of the computing device 2600 depicted in FIG. 7 is intended only as a specific example to illustrate a preferred embodiment of the device. Many other configurations are possible having more or fewer components than the system depicted in FIG. 7.

[0145] The term "blockchain transaction" may be used to refer to a data structure that implements the use of cryptographic keys to accomplish the transfer of control of digital resources or assets over a blockchain network. As mentioned above, for a transaction to be written to the blockchain, the transaction must i) be validated by the first node that receives the transaction, and if the transaction is validated, the node relays it to other nodes in the network, ii) be added to a new block constructed by miners, and iii) be mined, i.e., added to the public ledger of past transactions. It will be appreciated that the nature of the work performed by miners depends on the type of consensus mechanism used to maintain the blockchain. It will be appreciated that while proof of work (PoW) is associated with the original Bitcoin protocol, other consensus mechanisms such as proof of stake (PoS), delegated proof of stake (DPoS), proof of capacity (PoC), proof of elapsed time (PoET), proof of authority (PoA), etc. may be used. Different consensus mechanisms differ in how mining is distributed among nodes, and the probability of successfully mining a block depends on, for example, the miners' hashing power (PoW), the amount of cryptocurrency held by the miners (PoS), the amount of cryptocurrency provided to representative miners (DPoS), the miners' ability to memorize a given solution to a cryptographic puzzle (PoC), and the waiting time randomly assigned to miners (PoET).

[0146] Typically, miners are incentivized or rewarded for mining blocks. For example, the Bitcoin blockchain rewards miners with newly mined cryptocurrency (Bitcoins) and fees associated with transactions in blocks (transaction fees). In the Bitcoin blockchain, the amount of cryptocurrency mined decreases over time, and eventually the only incentive is transaction fees. It will therefore be appreciated that handling transaction fees is part of the underlying mechanism for committing data to a public blockchain, such as the Bitcoin blockchain.

[0147] As previously mentioned, each transaction in a given block encodes the transfer of control of digital assets between participants of the blockchain system. Digital assets may not necessarily represent cryptocurrencies. For example, digital assets may relate to digital representations of documents, images, physical objects, and the like. Payment of cryptocurrencies and / or transaction fees to miners may simply serve as an incentive to maintain the validity of blocks in the blockchain by performing the necessary work. It may be the case that the cryptocurrency associated with the blockchain serves as security for miners, and the blockchain itself is a ledger for transactions primarily related to digital assets other than cryptocurrencies. In some cases, transfers of cryptocurrencies between participants may be handled by a different entity than the entity using the blockchain to maintain a ledger of transactions.

[0148] It should be noted that the above mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art can design many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be interpreted as limiting the claim. Words such as "comprising" and "comprises" do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. As used herein, "comprises" means "includes or consists of" and "comprising" means "including or consisting of". "Operable" or "operable to" includes "made / made to" and "consisting / configured to". The reference to an element in the singular does not exclude the reference in the plural of such element and vice versa. The invention 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 measures, several of these measures 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. [Explanation of symbols]

[0149] 2602 Processor 2604 Bus Subsystem 2606 Storage Subsystem 2608 Main memory 2610 Persistent Storage 2612 User Interface Input Device 2614 User Interface Output Device 2616 Network Interface Subsystem 2618 RAM 2620 ROM 2624 Clock

Claims

1. 1. A simplified blockchain implemented payment verification system operable to facilitate a transfer of assets on a blockchain between a transferor and a transferee, comprising: completed transaction data relating to at least one blockchain transaction; a completed Merkle path of the at least one blockchain transaction; and a first verification resource comprising: receiving and / or requesting from the first validation resource the completed transaction data for the at least one blockchain transaction and the Merkle path for the at least one blockchain transaction; a second verification resource operable to A system comprising:

2. 2. The system of claim 1, wherein a second validation resource is further operable to use the Merkle path to validate a Merkle proof for the at least one transaction.

3. 3. The system of claim 2, wherein the second validation resource is further operable to send a transaction to the blockchain upon successful validation of the Merkle proof.

4. 4. The system of claim 1, wherein the first and / or second validation resource is or comprises a smart card, a digital wallet, or a light and / or SPV wallet.

5. 5. The system of claim 1, wherein the second validation resource is operable to receive and / or request the complete transaction data and the Merkle path from the first validation resource using off-chain communication.

6. 6. The system of claim 1, wherein the system is operable to use the Merkle path to verify a Merkle proof for the at least one transaction and, upon successful verification, to transmit the transaction to the blockchain.

7. The system of claim 1 , further comprising a plurality of second validation resources and a collaboration component operable to communicate with the plurality of validation resources.

8. 8. The system of claim 1, wherein the first verification resource is the transferor of the asset and the second verification resource is the transferee of the asset.

9. a signature for spending the output of said at least one blockchain transaction; Transfer value, and / or Public Key Address 9. The system of claim 1 , wherein the second verification resource is also operable to receive and / or request from the first verification resource, or the first verification resource is also operable to transmit to the second verification resource, at least one of:

10. 1. A blockchain-implemented method of simplified payment verification for facilitating a transfer of assets on a blockchain between a transferor and a transferee, comprising: In the second verification resource, completed transaction data relating to at least one blockchain transaction; a completed Merkle path of the at least one blockchain transaction; and receiving a signal from the the transaction data and the Merkle path are received from a first validation resource that stores the transaction data and the Merkle path; Preferably, the method further comprises using the Merkle path to verify a Merkle proof for the at least one transaction. method.

11. 11. The method of claim 10, further comprising the step of sending a transaction to the blockchain upon successful verification of the Merkle proof.

12. i) verifying said Merkle proof; and / or ii) receiving or requesting the completed transaction data and Merkle path from the first validating resource; 12. The method according to claim 10 or 11, wherein the step of:

13. 13. The method of claim 10, wherein the first verification resource is the transferor of the asset and the second verification resource is the transferee of the asset.

14. i) the second validation resource is operable to transmit a transaction to the blockchain upon successful validation of the Merkle proof; and / or ii) the first and / or second validation resource is or comprises a smart card, a digital wallet, or a light and / or SPV wallet; 14. The method according to any one of claims 10 to 13.

15. A non-transitory computer-readable storage medium having stored thereon executable instructions which, when executed by a processor of a computer system, cause the computer system to at least perform an embodiment of the method or system of any one of claims 1 to 14.

Images