Computer-Implemented System and Method for Conducting Transfers Over a 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 via blockchains. The present invention provides apparatus and techniques that offer 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] This document uses the term "blockchain" 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 illustrative purposes, this document may refer to Bitcoin; however, 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.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized, distributed system composed 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 contains at least one input and at least one output. Each block contains a hash of the previous block, allowing blocks to be strung together to create a permanent, immutable record of all transactions 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 pairs of transaction IDs from the block together until a single hash is arrived at. This Merkle root provides an efficient mechanism for verifying that a transaction is part of a block, allowing users to verify a specific transaction without downloading the entire blockchain.

[0004] Transactions have small programs, known as scripts, embedded in their inputs and outputs that specify how the transaction's outputs can be accessed and by whom. 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 each transaction is valid; invalid transactions are rejected by 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, it must i) be validated by the first node that receives the transaction; 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 confirming 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 parties use the same type of SPV wallet. The SPV wallet stores users' 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 it can be located on the blockchain. The block header includes 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 confirm (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, as 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 download only 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 previous 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 a network connection. 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 are provided systems and methods as defined in the accompanying claims. [Means for solving the problem]

[0014] According to the present disclosure, computer- and / or blockchain-implemented methods and corresponding systems may be provided. The systems may comprise one or more computer-implemented resources, which 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 person sending the assets) may be referred to as Alice, and the transferee (the person receiving the assets) may be referred to as Bob. The assets may be or comprise any type of asset, for example, a portion of cryptocurrency or a token, or anything else that can be transferred digitally in some way 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] Embodiments of the present disclosure may provide a system operable to facilitate the transfer of assets on a blockchain between a transferor and a transferee, the system comprising: completed transaction data for at least one blockchain transaction; The completed Merkle path of at least one blockchain transaction and a first verification resource comprising: receiving and / or requesting 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 as 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 verification resource may be further operable to use the Merkle path to verify 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 submit a transaction to the blockchain upon successful verification 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 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 query a blockchain network and / or blockchain.

[0026] The system may be further operable to use a Merkle path to verify a Merkle proof for at least one transaction and, upon successful verification, submit the transaction to a blockchain. The verification may be performed (locally) at or by a second verifying resource. It may be performed "off-chain," meaning 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 collaboration component operable to communicate with the plurality of validation resources, which may be substantially what is 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, an asset or asset value to be transferred, or a payment amount.

[0031] 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 for 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 the 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 verifying resource may be the transferor of the asset, and the second verifying resource may be the transferee of the asset. The second verifying resource may be operable to transmit the transaction to the blockchain upon successful verification of the Merkle proof. The first and / or second verifying 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 that, 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 herein, wherein embodiments of the present disclosure will now be described, by way of example only, with reference to the accompanying drawings. [Brief explanation of the drawings]

[0039] [Figure 1] FIG. 1 illustrates an “offline SPV wallet” according to an embodiment of the present disclosure. [Figure 2] FIG. 1 illustrates an “Online and Offline SPV Wallet” according to an embodiment of the present disclosure. [Figure 3] FIG. 1 illustrates a “PoS SPV wallet” according to an embodiment of the present disclosure. [Figure 4] FIG. 1 illustrates partial and completed template transactions and associated Merkle proofs, according to an embodiment of the present disclosure. [Figure 5] FIG. 1 illustrates 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] 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 can 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 for a data block D1 in a tree represented by root R using a Merkle path according to the prior art. DETAILED DESCRIPTION OF THE INVENTION

[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 numeric labels relating 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 (simplified) 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 Figure 11, from which it can be seen that the case i=j corresponds to a leaf node, which is simply the data D i It can be seen that the hash of the i-th packet corresponding to i≠j corresponds to an internal or parent node, which is generated by recursively hashing and concatenating 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 the node resides. For example, in Figure 11, m 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 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". An existence proof is a proof that for all packets D1, ..., D N is known to the prover. However, this requires a much larger storage overhead than a Merkle path and also requires the entire data set to be 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 exactly 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 equals 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, we can reduce the log k It is clearly much more efficient and practical to compute a Merkle proof involving N hashes.

[0050] method Given a Merkle root R, let D∈{D1, ... , D N}, a Merkle proof can be performed 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 route R obtained in (i) with the calculated route R'. I. If R'=R, then the existence of D1 in the tree, and therefore the dataset D, is confirmed. II. If R' ≠ R, 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 the 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 for 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 essentially 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 Verification (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. We will examine how this interaction occurs using simplified payment verification (SPV) using the traditional method as outlined in the Nakamoto white paper ("Bitcoin: A Peer-to-Peer Electronic Cash System", Satoshi Nakamoto, 2008, www.bicoin.org / bitcoin.pdf). The same interaction is later described 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 (UTXOs) 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 to pay 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 a block (header), are shown schematically 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. A Merkle proof that can be easily used to verify that a given transaction is contained 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, a lightweight Bitcoin client only needs to maintain a copy of the block header for the entire blockchain, rather than maintaining the full block, in order to verify that a transaction has been processed by the network. 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 path for eligible transactions Only requires

[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 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 was mined.

[0063] In contrast, the present invention requires that the necessary SPV checks be performed on transaction inputs before the transaction is broadcast. This shift in emphasis significantly reduces the load and traffic on the network when dealing with invalid transactions.

[0064] The second key 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 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 due, along with any other spending conditions, provided as a hash of Bob's chosen redemption script. · Alice also communicates the transaction ID TxID3 of 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 P2P network ·Alice broadcasts Tx3 to the network. [2.ii] Message: From Bob to 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] is 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 block to be mined and downloads new block headers as they are broadcast on the network. Bob sends an "SPV confirm" request to the network, which is a request for a Merkle path corresponding to Tx3 that ties 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 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 (hereinafter for convenience referred to as the "Bitcoin" network) using a low-bandwidth SPV system. According to 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 receiver (e.g., a merchant). Only the receiver 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 "receiver."

[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 wallet to be connected to the network. This is achieved by the merchant 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, this disclosure describes the process of communication and exchange 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 to

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

[0077] This process change creates technical challenges that require new designs for both the customer wallet and the merchant wallet. Therefore, embodiments of the present invention provide at least the following: 1. A new customer wallet for Alice (called the "offline wallet"): It stores Alice's public key, private key, transactions including spendable outputs, all block headers, and, importantly, the Merkle path of the stored transactions. (removing the requirement for Alice to be connected to a network) 2. A new merchant wallet for Bob (called 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) that links the input transaction with the respective 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: 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) that links 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 to perform SPV checking on input transactions Tx1 and Tx2. 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 P2P network Bob broadcasts a payment transaction (Tx3) to the P2P network. In the existing paradigm, Alice submits a 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 method (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 confirmation [3] is Before the payment transaction (Tx3) is issued, -When 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: 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 excessive 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 the transaction is accepted by the network. Bob's wallet does not need to contain any private keys, which increases security as 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 the private key and the ability to sign transactions, and therefore it should have sufficient power to perform elliptic curve point multiplication.

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

[0089] Offline SPV Wallet An embodiment of an offline SPV is shown schematically in FIG. 1 and comprises the following features: 1. TX - Preloaded complete transaction data, including Alice's available unspent transaction outputs. This complete transaction data, in combination with the Merkle path, constitutes a Merkle proof that the transaction Alice is spending is valid. Hashing the complete 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 insufficient, 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 complete transaction data, so Alice must store it, or at least have access to it when needed. 2. Private / Public Keys - Wallets must have access to a set of private keys in order to sign transaction outputs, and public keys in order to specify change addresses when making transactions. 3. Merkle Path - The (completed) Merkle path of each transaction, including the transaction output (UTXO). This is used by merchant point-of-sale wallets to verify that the TX is valid. Note that the Merkle proof provided by this wallet does not prevent double-spend, but acts as a fail-fast mechanism against spam attacks, thus increasing the robustness and security of the wallet. 4. Minimal Processing - Offline SPV wallets are required to sign unspent transactions in order to spend them, which means that the offline wallet (and the device on which it is installed) needs to be capable of implementing cryptographic algorithms such as ECDSA, and has enough processing power to be able to perform elliptic curve point multiplication and calculate hash functions. 5. Block Header (Optional) - Offline SPV wallets may wish to include block headers to verify that payments to point-of-sale SPV wallets have been processed. This also requires storing 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 100,000 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 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 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 require Bob to: Must be able to generate point of sale transaction templates It must be possible to compute the 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, with the following features: 1. Block Headers - PoS SPV wallets maintain an up-to-date copy of the 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 - The PoS SPV wallet only needs to store the public key addresses from which Bob wishes to receive assets or payments. This can be done in several 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 minimal processing of Merkle proofs based on templates filled in by Alice. This significantly reduces the burden of iterating through full blocks to independently obtain Merkle paths, 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 the complete list of block headers, e.g., to maintain those corresponding to blocks that do not contain transactions with consumable outputs. In this case, it should be understood that Bob may occasionally have to 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; it should be understood that if Bob does not have a complete list of all block headers, Bob may incorporate requests for block headers associated with his unspent transaction outputs into this template.

[0098] PoS SPV wallet template Looking at Figure 4, Bob's PoS SPV wallet requests Alice's offline (or off / online) wallet information in the following format: 1. TX / UTX - The complete transaction data from Alice's consumable transaction (as described above). 2. Transaction Template - A partially completed blockchain transaction with (at least) Bob's output address and the amount of cryptocurrency requested by Alice. For the transaction to complete, 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 to be used, and a 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 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 in" the template itself.

[0100] The complete transaction (see (1) in Figure 4) and Merkle proof (see (3) in Figure 4) can be submitted 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 in 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 submits 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 to mean that the change generated by paying Bob will not be able to be spent for the merchant's predetermined time before submitting the batched transactions to the network. Note that in this scenario, there is no additional risk to Bob, since the merchant can cancel the delivery of the purchased goods if it finds evidence of double-spending before submitting the batch of transactions.

[0104] PoS SPV Wallet Extension - 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 for the wallet to: Allows storing private keys associated with public key addresses of PoS SPVs. Allows computing Merkle proofs associated with block headers. 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 verification 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, a master wallet according to embodiments of the present invention communicates with at least one simpler Pos SPV wallet, coordinating payments processed thereby.

[0108] It may be advantageous for the master SPV to store the private key for Bob's payment address. This allows Bob to have greater 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 basic Master SPV, the merchant-customer interaction is not strictly 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. Process differences include: ·Selection of PoS SPV terminals to be used by Alice and Bob. The Master SPV should continuously synchronize with the blockchain in the background. The private key associated with Bob's payment address is under dedicated control from the master wallet. This adds structure to the security previously provided by simply 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 company's back office or head office, for both security and practical reasons. 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 collections 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 maintain a complete copy of the blockchain. Instead, this type of master wallet only maintains its own local copy of the block headers and 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 implementation of a split wallet using a master SPV wallet with its own copy of the mempool changes the merchant-customer interaction from the merchant's perspective. The main change in interaction from that described above in connection with FIG. In step 4, the merchant simply broadcasts the transaction to the network rather than adding 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 the synchronized copy of the mempool.

[0115] Examples of inventions used Consider a typical merchant-customer interaction, where Alice wants 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 spends 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 the completed transaction to the network and queries the UTXO set. a. Broadcasting allows miners to begin attempting to mine transactions into blocks. 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, which allows Bob to adopt one of the following courses of action: a. If Alice's UTXO is still part of the UTXO set, 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 UTXO set, 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, including, 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 a miner 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 six-confirmation rule is not important for Bitcoin. Not all merchants want to wait six blocks (or even one) 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 because 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, because it reaches 0-conf 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 with poor connectivity, 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. Payment cards require data capacity to store private keys as well as UTXOs, completed transactions, and Merkle paths. They also require some processing power to implement the ECDSA signature algorithm. Table 1 lists 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 submits a transaction to the blockchain network at the point of sale (POS), and the merchant, Bob, receives a confirmation that this transaction is (a) returned to Bob as accepted by the network, or (b) be confirmed in blocks (or up to n blocks in the case of n-conf) Only when Alice has confirmed one of the following will she be allowed to take the item away.

[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. While this does not protect Bob from a simple double-spend initiated by Alice remotely submitting a conflicting transaction, 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, which on the Bitcoin network takes an average of 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 one or more blocks to mitigate a different attack vector from a third adversary, Carol, would overwhelm the entire network.

[0127] The following table shows how neither scenario (a) nor (b) is independently acceptable for such a customer-merchant interaction: The table shows 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 also allows for payments to be cleared and approved with a high degree of certainty within approximately one 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 adjust the latency for accepting payments at the point of sale. By choosing the shortest polling interval τ, Bob sets a reasonable 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 creating 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 adjust efficiency and risk on a case-by-case basis, which may depend, for example, on the value of the commodity that is 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), which may be configured to communicate with a storage subsystem 2606, which 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 the various components and subsystems of the computing device 2600 to communicate with each other as intended. Although the bus subsystem 2604 is shown schematically 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 allow a data technician to connect the device to a network so that the data technician can transmit data to and receive data from the device while 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 touchscreen 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 encompass 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 computing device 2600. The one or more user interface output devices 2614 may be used, for example, to present a user interface 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 the 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 the 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 (e.g., CD-ROM, DVD, or Blue-Ray drives) with associated removable media, 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] Computing device 2600 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described below. Additionally, computing device 2600 may include another device that may be connected to computing device 2600 through one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). A device that may be connected to 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 connecting the device to computing device 2600 for processing. Due to the ever-changing nature of computers and networks, the description of 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 over digital resources or assets through a blockchain network. As discussed above, for a transaction to be written to the blockchain, it must: i) be validated by the first node that receives the transaction; 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; or iii) be mined, i.e., added to the public ledger of past transactions. It will be understood that the nature of the work performed by miners depends on the type of consensus mechanism used to maintain the blockchain. While proof of work (PoW) is associated with the original Bitcoin protocol, it will be understood that 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 also be used. Different consensus mechanisms differ in how mining is distributed among nodes, and the probability of successfully mining a block depends, for example, on the hashing power of the miners (PoW), the amount of cryptocurrency held by the miners (PoS), the amount of cryptocurrency provided to representative miners (DPoS), the ability of the miners to memorize a given solution to a cryptographic puzzle (PoC), and the waiting time randomly assigned to the miners (PoET).

[0146] Typically, miners are incentivized or rewarded for mining blocks. For example, the Bitcoin blockchain rewards miners with newly minted 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 be appreciated, therefore, 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 a digital asset between participants in the blockchain system. Digital assets do not necessarily correspond to cryptocurrency. For example, digital assets may relate to digital representations of documents, images, physical objects, etc. Payment of cryptocurrency and / or transaction fees to miners may simply serve as an incentive for maintaining 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, with the blockchain itself being a ledger for transactions primarily related to digital assets other than cryptocurrency. In some cases, transfers of cryptocurrency between participants may be handled by an entity different from the entity using the blockchain to maintain the ledger of transactions.

[0148] It should be noted that the above-mentioned embodiments illustrate rather than limit the present invention, and that those skilled in the art can design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed 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 to / made to" and "consisting to / configured to." The singular reference to an element does not exclude the plural reference of such elements, and vice versa. The present 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 transfer of assets on or through a blockchain network between a first verifying resource of a transferor and a second verifying resource of a transferee, wherein the first verifying resource and the second verifying resource are not mining nodes on the blockchain network, the system comprising: Completed transaction data for at least one blockchain transaction (Tx1); and a completed Merkle path of the at least one blockchain transaction; and a first verification resource comprising: receiving and / or requesting the completed transaction data for the at least one blockchain transaction and the Merkle path for the at least one blockchain transaction from the first validation resource; a second verification resource operable to A system comprising:

2. i) the at least one blockchain transaction (Tx1) has an output that is consumable by an input of a further transaction (Tx3); ii) the further transaction (Tx3) includes an output transferring the asset from the transferor to the transferee.

3. a second verifying resource using the Merkle path to verify the Merkle proof for the at least one blockchain transaction; If the Merkle proof is successfully verified, send the further transaction (Tx3) to the blockchain network. The system of claim 2 , further operable to:

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 lightweight and / or SPV wallet.

5. 5. The system of claim 1, wherein the second validation resource is operable to receive and / or request the completed 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 blockchain transaction, and upon successful verification, to transmit the transaction to the blockchain.

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

8. a signature for spending the output of said at least one blockchain transaction; Transfer value, and / or Public Key Address 8. 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:

9. 1. A method implemented in a simplified payment verification blockchain for facilitating a transfer of assets on or through a blockchain network between a first verifying resource of a transferor and a second verifying resource of a transferee, wherein the first verifying resource and the second verifying resource are not mining nodes on the blockchain network, the method comprising: In the second verification resource, Completed transaction data for at least one blockchain transaction (Tx1); and a completed Merkle path of the at least one blockchain transaction; and receiving a signal from the the transaction data and Merkle path are received from the first validation resource, which stores the transaction data and Merkle path; method.

10. The method described in claim 9, further comprising a step of using the Merkle path to verify a Merkle proof for the at least one blockchain transaction.

11. i) the at least one blockchain transaction (Tx1) has an output that is consumable by an input of a further transaction (Tx3); ii) the further transaction (Tx3) comprises an output transferring the asset from the transferor to the transferee.

12. 12. The method of claim 11, further comprising the step of transmitting the further transaction (Tx3) to the blockchain network upon successful verification of the Merkle proof.

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

14. the first and / or second validation resource is or comprises a smart card, a digital wallet, or a lightweight and / or SPV wallet; 14. The method according to any one of claims 11 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 the method of any one of claims 9 to 14 or the system embodiment of any one of claims 1 to 8.

Images