Computer-implemented systems and methods for effecting transfers over a blockchain network

Abstract

The present invention provides an improved simple payment verification (SPV) solution for blockchain-implemented transfers. The improved verification solution is suitable for, but not limited to, implementation in one or more SPV wallets, on a smart card, etc. According to one embodiment, a method, system or resource is provided that enables Alice to transfer assets to Bob. Bob sends a payment transaction template (template Tx3) to Alice and requests the following: the complete transaction data of all input transactions (Tx1, Tx2), including at least one output that Alice wants to spend, as input to the transfer (Tx3); the Merkle path of all input transactions (Tx1, Tx2) linking them to the respective Merkle root associated with their respective block header; the completed transfer transaction (Tx3). Alice provides this information together with her signature, optionally also a change address. Bob can then perform a local SPV check on the input transactions Tx1, Tx2 using the transactions Tx1 and Tx2, their corresponding Merkle paths path1, path2, and Bob's local list of block headers. Bob broadcasts the transfer transaction (Tx3) to the P2P network.

Description

Technical Field

[0001] This invention relates generally to resource communication and transfer via a network, and more specifically to transfer via blockchain networks and digital wallets. This invention is particularly suitable for, but not limited to, wallets used for processing the transfer of resources implemented on or communicated via a blockchain. This invention provides apparatus and techniques that offer a variety of technical advantages, including but not limited to improved security, versatility, resilience, and efficiency of digital wallets and blockchain-based communication. Background Technology

[0002] In this document, the term "blockchain" encompasses all forms of computer-based electronic distributed ledgers. These ledgers include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. It should be noted that other blockchain implementations and protocols also fall within the scope of this invention. 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 decentralized, distributed computer-based system composed of blocks, which in turn are transactions. Each transaction is a data structure that encodes the transfer of control of digital assets among participants in the blockchain system and includes at least one input and at least one output. Each block contains the hash of the previous block, and blocks are thus chained together to create a permanent, immutable record of all transactions written into the blockchain since its creation. The header of each block contains a field that provides the Merkle root for that block. The Merkle root is generated by repeatedly hashing the transaction IDs in the block together until a single hash is reached. This Merkle root provides an efficient mechanism to verify whether a transaction is part of a block, as it allows users to verify a specific transaction without downloading the entire blockchain.

[0004] A transaction includes small programs, called scripts, embedded in its inputs and outputs. These scripts specify how and by whom the transaction's output is accessed. 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 work to ensure that every transaction is valid, while invalid transactions are rejected by the network. Software clients installed on nodes perform this validation work on unspent transactions (UTXOs) by executing their lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to true, the transaction is valid and written to the blockchain. Therefore, for a transaction to be written to the blockchain, it must: i) be validated by the first node that receives the transaction, and if the transaction passes validation, this node forwards it to other nodes in the network; ii) be added to a new block being built; and iii) be mined, i.e., have been added to the public ledger of historical transactions. (Note: The validation mentioned above should not be confused with the term "verification" used in this article to refer to confirming or checking whether a particular transaction has been included in a block on the blockchain.)

[0006] Once stored as a UTXO on the blockchain, a user can transfer control of the associated assets to another address associated with an input in another transaction. This is typically accomplished using a digital wallet, which stores the public and private key pair associated with the user's assets. Known wallets come in various forms, including SPV (Simplified Payment Verification) wallets.

[0007] In the SPV-based asset exchange between Alice and Bob, both parties used the same type of SPV wallet. SPV wallets store users' private and public keys, unspent transactions, and block headers. SPV wallets also have the ability to connect to the blockchain network. The term "block header," as is known in the art, refers to the data provided at the top of a block of transactions on a blockchain. The block header uniquely identifies the block, thus locating it on the blockchain. The block header contains data fields that provide a unique summary or fingerprint of the entire block's contents. The block header includes a Merkle root, which is the hash of all transactions in that block. Users can then use this root to search the Merkle tree to check (i.e., verify) whether a specific transaction is included in a specific block on the blockchain without downloading the entire blockchain.

[0008] One advantage of SPV wallets is that they only need to check if the transaction has been verified (hence the name "Simple Payment Verification"), rather than performing a full check of the blockchain as other forms of wallets. Because SPV wallets only download the block headers and not any transactions, this reduces the required storage space from 159GB (as of November 2018) to 43MB.

[0009] Suppose Alice wants to send some assets / resources to Bob. When using a traditional SPV wallet, the communication flow between Alice and Bob is as follows:

[0010] 1. Alice creates a blockchain transaction (TX), specifies Bob's address in the output, and provides a signature for the input (from previously unspent transactions to Alice).

[0011] 2. Alice broadcasts the transaction to the blockchain network.

[0012] 3. Bob queries the network to verify whether the transaction has been accepted.

[0013] Essentially, the blockchain network acts as an intermediary between Alice's wallet and Bob's wallet. However, this is not merely a resource-intensive process; it also requires network connectivity. If the device running Alice's wallet goes offline for any reason, the transfer cannot be completed. Therefore, there are technical challenges, including but not limited to methods, systems, and devices for providing a more reliable and efficient mechanism for enabling electronic transfers from one entity (e.g., computing resources / nodes / digital wallets) to another. Summary of the Invention

[0014] Therefore, it is desirable to provide a solution that at least addresses these technical problems. Such an improved solution has now been devised. Therefore, according to embodiments of this disclosure, a system and method as defined in the appended claims are provided.

[0015] According to this disclosure, a method and a corresponding system implemented using computers and / or blockchain can be provided. The system may include one or more computer-implemented resources. These may be hardware and / or software-implemented resources.

[0016] Embodiments of this disclosure may provide computer-implemented resources operable to facilitate or enable the transfer of assets (between a sender and a receiver) within or on a blockchain network. The transferor (sender of the assets) may be referred to as Alice, and the transferee (receiver of the assets) may be referred to as Bob. Assets may be or may include any type of asset, such as any asset that can be digitally transferred via a blockchain transaction in some way.

[0017] Additionally or alternatively, the system may operate to facilitate or enable the verification of blockchain transactions. This can be SPV verification. The system can be described as an SPV system. The term "operative to" is used herein to include the terms "arrangement" and "configuration".

[0018] Embodiments of this disclosure can provide a simple payment verification system implemented on a blockchain to facilitate asset transfers between a sender and a receiver, and the system includes:

[0019] The first verification resource includes:

[0020] Complete transaction data related to at least one blockchain transaction; and

[0021] The complete Merkle path of at least one blockchain transaction;

[0022] And a second verification resource, the second verification resource being operated as follows:

[0023] Receive and / or request the complete transaction data related to the at least one blockchain transaction from the first verification resource; and the Merkel path for the at least one blockchain transaction.

[0024] According to blockchain protocols, transaction data can be completed in a manner sufficient to form a valid blockchain transaction. This can be referred to as "complete" transaction data. Additionally or alternatively, the first and / or second verification resources can be referred to as "transfer resources" or simply "computer-based resources."

[0025] The first verification resource may be substantially as disclosed herein with respect to Alice and / or in the section entitled “Offline SPV Wallet” and related figures. The first verification resource may be referred to hereinafter as Alice, and for convenience, the second verification resource may be referred to as Bob. The second verification resource may be substantially as described herein with respect to Bob or in the section entitled “PoS SPV Wallet” provided herein.

[0026] The second verification resource can be further operated to verify the Merkel proof of the at least one transaction using the Merkel path.

[0027] Advantageously, the Merkle path can be provided to Bob by Alice, rather than having to obtain it from a peer on the blockchain network. This allows Bob to perform a local SPV check on at least one transaction without needing to access or communicate with the blockchain or network.

[0028] Furthermore, off-chain communication can be used (directly) to send data, requests, and responses between Bob and Alice. The term "off-chain communication" is intended to mean communication that does not pass through, query, or interact with a blockchain or blockchain network. Alice and / or Bob may not be nodes or peers on the network.

[0029] This second verification resource can be further operated to send a transaction to the blockchain after successful verification of the Merkel proof. This can be as described and disclosed herein and referenced. Figure 8 and Figure 10 Tx3. It can be a blockchain transaction that includes an input that costs at least one blockchain transaction output (UTXO).

[0030] The first and / or second verification resources may be or may include smart cards, digital wallets or lightweight wallets and / or SPV wallets.

[0031] The second verification resource is operable to receive and / or request the complete transaction data and the Merkel path from the first verification resource using off-chain communication. "Off-chain" can mean that the communication does not involve, pass through, or query a blockchain network and / or blockchain.

[0032] The system can further operate to verify the Merkel proof of the at least one transaction using the Merkel path and send the transaction to the blockchain upon successful verification. This verification can be performed at a second verification resource or by the second verification resource (locally). It can be performed "off-chain," meaning it is not performed through, querying, or using a blockchain network or blockchain.

[0033] The system may also include multiple secondary verification resources, and a coordination component that operates to communicate with the multiple verification resources. It can essentially be the “split merchantwallet” disclosed herein.

[0034] The first verification resource can be the transferor of the asset, and the second verification resource can be the transferee of the asset.

[0035] 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 send at least one of the following to the second verification resource:

[0036] A signature used to spend the output of the at least one blockchain transaction;

[0037] Transfer value; and / or

[0038] Public key address.

[0039] The transfer value can be the amount of resources. It can be the asset or value of the asset to be transferred. It can be the payment amount.

[0040] Embodiments of this disclosure also provide a method for implementing a blockchain. This method can be a simple payment verification method. The method is arranged to facilitate asset transfers on the blockchain between a sender and a receiver. The method includes:

[0041] Received at the second verification resource: complete transaction data related to at least one blockchain transaction; and the complete Merkel path of said at least one blockchain transaction;

[0042] The transaction data and the Merkel path are received from a first verification resource that stores the transaction data and the Merkel path.

[0043] The method may further include the step of verifying the Merkel proof of the at least one transaction using the Merkel path.

[0044] The method may also include the step of sending a transaction to the blockchain after successfully verifying the Merkel proof.

[0045] The following steps can be performed off-chain:

[0046] i) Verification of the Merkel proof; and / or

[0047] ii) Receive or request the complete transaction data and Merkel path from the first verification resource.

[0048] The first verification resource can be the sender of the asset, and the second verification resource can be the receiver of the asset. The second verification resource can be operated to send a transaction to the blockchain after successful verification of the Merkel proof. The first and / or second verification resources can be or may include smart cards, digital wallets, or lightweight wallets and / or SPV wallets.

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

[0050] Any features described herein regarding a system or resource also apply to the methods disclosed herein, and vice versa.

[0051] These and other aspects of this disclosure will become apparent from the embodiments described herein, and will be set forth with reference to the embodiments described herein. Embodiments of this disclosure will now be described by way of example only and with reference to the accompanying drawings, in which: Attached Figure Description

[0052] Figure 1 An illustration of an "offline SPV wallet" according to an embodiment of the present disclosure is shown.

[0053] Figure 2 An illustration of an "online and offline SPV wallet" according to an embodiment of the present disclosure is shown.

[0054] Figure 3 An illustration of a "PoS SPV wallet" according to an embodiment of the present disclosure is shown.

[0055] Figure 4 A partial and completed template transaction according to an embodiment of this disclosure is shown, along with the associated Merkel proof.

[0056] Figure 5 The data flow and interaction between Alice and Bob when conducting transactions using a split SPV wallet according to an embodiment of this disclosure are illustrated.

[0057] Figure 6 A schematic diagram illustrating the use of an embodiment of this disclosure is shown.

[0058] Figure 7 This is a schematic diagram illustrating a computing environment that can implement various embodiments.

[0059] Figure 8 It is a diagram showing three transactions and the Merkel path that can be used to associate them with the block (header).

[0060] Figure 9 The traditional SPV payment method is shown.

[0061] Figure 10 An illustration of a method according to an embodiment of the present disclosure is shown.

[0062] Figure 11 An example of a binary Merkle tree known in the prior art is shown.

[0063] Figure 12 A Merkel existence proof is shown for data block D1 in a tree represented by root R using the Merkel path, according to the prior art. Detailed Implementation

[0064] Existing technology: Merkle tree

[0065] Since the embodiments of this disclosure make full use of the concept of Merkle trees, they are provided for illustrative purposes only.

[0066] Merkle trees are hierarchical data structures capable of securely verifying datasets. In a Merkle tree, each node is provided with an index pair (i,j), denoted as N(i,j). The indices i and j are simply numeric labels associated with a specific position in the tree. A key characteristic of Merkle trees is that the construction of each node is governed by the following (simplified) equation:

[0067]

[0068] Where k = (i + j - 1) / 2 and H are cryptographic hash functions.

[0069] The labeled binary Merkle tree constructed based on these equations is as follows: Figure 11 As shown in the figure, the case of i=j corresponds to a leaf node, and the leaf node is simply the corresponding i-th data packet D. i The hash value. The case i≠j corresponds to an internal node or a parent node, which is generated by recursively hashing and connecting child nodes until a parent node (Merkelgen) is found.

[0070] For example, node N(1,4) is constructed from four data packets, D1, ..., D4.

[0071] N(1,4)=H(N(1,2)||N(3,4))

[0072] =[H(N(1,1)||N(2,2))||H(N(3,3)||N(4,4))]

[0073] =[H(H(D1)||H(D2))||H(H(D3)||H(D4))].

[0074] The depth M of a tree 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, m root =0 and m leaf =M, where in Figure 11 In this case, M = 3.

[0075] Merkel proves

[0076] The main function of a Merkle tree is to verify a specific data packet D. i It consists of N data packets. The members of a list or set. The verification mechanism is called Merkel proof, which involves dividing the given data into packets D. i The Merkle root R is used to obtain a set of hash values ​​called Merkle paths. The Merkle paths of data packets are simply the minimum list of hashes needed to reconstruct the root R through repeated hashing and concatenation; these are often called "authentication paths." If the authenticator knows all packets D1,…,D… NIf a list is used, an existence proof can be performed simply. However, this does require significantly more storage overhead than the Merkle path and necessitates the entire dataset being available to the verifier. A comparison between using the Merkle path and using the entire list is shown in the table below, where a binary Merkle tree is used and it is assumed that the number of data blocks N is exactly a power of 2. If this is not the case, the number of hashes required for a Merkle proof will differ by ±1 in each instance.

[0077]

[0078] Table: Relationship between the number of leaf nodes in a Merkle tree and the number of hashes required for a Merkle proof.

[0079] In this simplified scenario (where the number of data packets equals the number of leaf nodes), it has been found that the number of hash values ​​required to compute the Merkel proof scales logarithmically. Clearly, the computation involves logarithmic... K The Merkel proof for N hashes is far more efficient and practical than storing N data hashes and computing a simple proof.

[0080] method

[0081] Given a Merklein form R, the goal is to prove that data block D1 belongs to the set represented by R. Merkel's proof can be performed as follows:

[0082] i. Obtain Merklegen R from a trusted source.

[0083] ii. Obtain the Merkel path Γ from the source. In this case, Γ is a set of hash values:

[0084] Γ={N(2,2),N(3,4),N(5,8)}.

[0085] iii. The proof of Merkel's calculation using D1 and Γ is as follows:

[0086] a. Hash the data block to obtain:

[0087] N(1,1)=H(D1).

[0088] b. Concatenate with N(2,2) and hash to obtain:

[0089] N(1,2)=H(N(1,1)||N(2,2)).

[0090] c. Concatenate with N(3,4) and hash to obtain:

[0091] N(1,4)=H(N(1,2)||N(3,4)).

[0092] d. Concatenate with N(5,8) and hash to obtain the root:

[0093] N(1,8)=H(N(1,4)||N(5,8)),

[0094] R′=N(1,8).

[0095] e. Compare the calculated root R′ with the root R obtained in (i):

[0096] I. If R′=R, then it confirms the existence of D1 in the tree, thus confirming the dataset.

[0097] II. If R′≠R, then the proof fails, and it cannot be confirmed that D1 is... Members.

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

[0099] As part of an exemplary Merkle tree, the process of verifying the existence of D1 is as follows: Figure 12 As shown in the figure, the Merkle existence proof for data block D1 in a tree represented by the root R using a Merkle path is illustrated. This demonstrates that, given block D1 and root R, the Merkle tree can be efficiently traversed "upwards" using only the minimum necessary hash values ​​to perform the Merkle proof.

[0100] Specific embodiments of this disclosure use these techniques to provide more efficient and secure verification solutions, and attention will now turn to the discussion.

[0101] Simple Payment Verification (SPV)

[0102] Since this disclosure provides an improved SPV solution, for ease of reference, an overview of known SPV verification techniques is now provided. In the following, consider Alice (customer) and Bob (merchant) who wish to transact at a point of sale for certain goods. As described in the Nakamoto white paper, this interaction is examined using conventional methods with Simple Payment Verification (SPV). The same interaction is described later in a section entitled “Overview of the Invention” with regard to illustrative embodiments of the invention. In both cases, consider the role of three blockchain transactions (Tx). Two transactions have spendable outputs (UTXOs) owned by Alice:

[0103] • Tx1 – A transaction with a spendable output (vout-1)

[0104] • Tx2 – Transactions with spendable output (vout-0)

[0105] These transactions Tx1 and Tx2 will be referred to as input transactions in this paper. In short, they are transactions that consist of the outputs spent on the inputs of some subsequent transactions (e.g., Tx3).

[0106] The third blockchain transaction is a payment transaction:

[0107] • Tx3 – A transaction that uses vout-0 and vout-1 as its two inputs and one output and pays Bob. For a simpler demonstration of the invention, only two inputs and one output are shown.

[0108] Figure 8 The diagram illustrates the three transactions and the Merkel path that can be used to associate them with the block (header).

[0109] The basic concept of SPV has existed since the Nakamoto white paper. Essentially, SPV utilizes two properties of blockchain:

[0110] 1. Merkel's proof, which can be readily used to verify whether a given transaction is contained in a Merkel tree and represented by a Merkel root; and

[0111] 2. The block header, which represents the transaction block through the Merkle root of the Merkle tree containing the transactions.

[0112] By combining these two properties, lightweight clients only need to maintain a copy of the block header of the entire blockchain, rather than the entire block, 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 only needs the following:

[0113] • A complete list of the latest block headers;

[0114] • The Merkel path for the transactions under consideration.

[0115] As can be seen from attribute 1, an SPV user can verify that a given transaction is part of a Merkle tree (represented by a Merkle root) simply by performing the Merkle path authentication proof explained in the previous section. Then, as can be seen from attribute 2, if the SPV client has a valid block header containing this Merkle root, then the transaction is also part of a block in the blockchain. Performing this type of payment verification is referred to in this paper as performing an "SPV check".

[0116] Nakamoto's specified SPV mechanism notifies existing methods of SPV client implementations, including those at the point of sale. Importantly, the latest technology in SPV implementations is based on a paradigm where the user verifies receipt of payment by confirming (at an appropriate depth on the blockchain, e.g., 6) that the payment has been included in a block. In effect, this is a post-broadcast check of the transaction to verify that it has been mined.

[0117] In contrast, this invention requires performing necessary SPV checks on the transaction input before broadcasting. This shift in focus significantly reduces the network burden and traffic when processing invalid transactions.

[0118] The second important example in existing SPV systems is that SPV clients must query full nodes on the network to obtain the Merkel path required for SPV checks. The developer guide states that "SPV clients know the Merkel root and associated transaction information and request the corresponding Merkel branch from full nodes."

[0119] Embodiments of the present invention provide mechanisms and methods involving SPV checks, thereby eliminating this burden on the network by stipulating that lightweight client users retain, maintain, or at least have access to their own copy of the Merkel path associated with their owned unspent transaction outputs.

[0120] The traditional method for implementing SPV (at the point of sale) is as follows, and refer to [reference needed]. Figure 9 :

[0121] [1] News: Bob tells Alice

[0122] Bob (the merchant) sends his public key address to Alice (the customer). His message may also include the amount to be paid, in addition to any other spending conditions provided as a hash of the redemption script chosen by Bob.

[0123] Alice will also send the transaction ID TxID3 of payment transaction Tx3 to Bob (not shown).

[0124] [2] P2P network mediates the exchange between Alice and Bob:

[0125] [2.i] Message: Alice to P2P Network

[0126] Alice broadcasts Tx3 to the network.

[0127] [2.ii] Message: Bob to P2P Network

[0128] Bob queries the network to check if Tx3 is accepted for mining blockchains.

[0129] Bob sends a series of queries [2.ii] until he is satisfied that the network considers the payment valid. Note that he may start querying before [2.i] occurs.

[0130] If Bob is satisfied, he can consider the transaction complete without either party having to wait for the next block to be mined.

[0131] [3] SPV check (message): Bob sends a message to the P2P network

[0132] Bob waits for the next block to be mined and downloads the new block header as it is broadcast on the network.

[0133] Bob sends an "SPV check" request to the network. This is a request for the Merkle path corresponding to Tx3, which links it to the Merkle root in the most recently mined block.

[0134] If the network can provide Bob with a Merkel path, he can use his SPV wallet to compute the Merkel proof himself and check if payment Tx3 has been processed.

[0135] Figure 9 This communication flow is illustrated in the diagram. It should be noted that [2.i], [2.ii] and [3] are mediated by a P2P network and therefore contribute to the traffic on the network. It should also be noted that in the existing SPV paradigm, the necessary SPV checks are performed [3]:

[0136] • After payment (Tx3) is submitted;

[0137] Regarding the payment (Tx3) itself;

[0138] • With the help of other network peers that provide the Merkel path.

[0139] This known method will now be compared with the method of the present invention.

[0140] Overview of embodiments of this disclosure

[0141] This disclosure provides an improved security solution for verification on blockchain networks using low-bandwidth SPV systems. According to one embodiment of the invention, the sender of the resource (e.g., a customer) does not need to be online, while the receiver (e.g., a merchant) can create and / or accept transactions. Only the receiver needs to be online. For convenience and ease of reference, the term "customer" or "Alice" will be used instead of "sender," and "merchant" or "Bob" will be used instead of "receiver."

[0142] Compared to traditional SPV transactions, the embodiments disclosed herein employ a novel communication process between the parties, as it only requires the merchant's wallet to be connected to the network. This is achieved by creating a template (which may be referred to as an "incomplete transaction") in the merchant's wallet, containing information required from the customer, such as the change address, signature, etc. Once the merchant receives this request from the customer, they broadcast the transaction to the network.

[0143] Therefore, this disclosure brings about a fundamental change to the communication and exchange process between the transacting parties and the network during a simple payment verification process on a blockchain network, from:

[0144] Merchant → Customer → Network → Merchant

[0145] arrive:

[0146] Merchant → Customer → Merchant → Network

[0147] Alice and Bob can securely exchange messages using, for example, the secret sharing protocol described in WO 2017145016.

[0148] The changes in this process raise a technical issue: both customer wallets and merchant wallets require a novel design. Therefore, embodiments of the present invention provide at least the following:

[0149] 1. Alice's novel customer wallet (called an "offline wallet"): It stores Alice's public key, private key, transactions containing spendable outputs, all block headers, and, importantly, the Merkel path of the stored transactions (removing the requirement for Alice to connect to the network).

[0150] 2. The novel Bob Merchant Wallet (called the "Point of Sale wallet"): It stores Bob's public key and all block headers.

[0151] More detailed descriptions of these components are now provided.

[0152] refer to Figure 10 An exemplary method for implementing an SPV (at the point of sale) according to an embodiment of the present invention is provided as follows:

[0153] [1] News: Bob tells Alice

[0154] Bob sends Alice a payment transaction template (Template Tx3) and requests the following information from Alice:

[0155] Complete transaction data for all input transactions (Tx1 and Tx2), including at least one output, which Alice intends to use as an input for payment (Tx3);

[0156] ο Merkle paths for all input transactions (Tx1 and Tx2), linking them to the corresponding Merkle roots associated with the corresponding block header;

[0157] ο Completed (i.e., the template was filled out) payment transaction (Tx3).

[0158] • Note that Bob requests information from Alice, rather than sending her his address.

[0159] [2] News: Alice to Bob

[0160] Alice sends the requested information to Bob:

[0161] Complete transaction data for all input transactions (Tx1 and Tx2), including at least one output, which Alice intends to use as an input for payment (Tx3);

[0162] ο Merkel paths for all input transactions (Tx1 and Tx2), linking them to the corresponding block headers;

[0163] Complete the payment transaction (Tx3) (i.e., fill out the template). In addition to filling out the template, Alice also provided her signature.

[0164] [3] SPV check (local): Bob

[0165] Bob performs SPV checks on input transactions Tx1 and Tx2 using the following:

[0166] Trade Tx1 and Tx2;

[0167] The corresponding Merkel paths, path 1 and path 2;

[0168] Bob's local block list.

[0169] These checks were performed by Bob locally, not through a P2P network;

[0170] In a preferred embodiment, at this stage, Bob also performs appropriate checks on the payment Tx3 he received from Alice to ensure that:

[0171] The payment of Tx3 was as Bob expected;

[0172] Alice's signature is valid for the transaction.

[0173] [4] News: Bob speaks to P2P networks

[0174] Bob broadcasts the payment transaction (Tx3) to the P2P network. In the existing paradigm, Alice submits the transaction to the network.

[0175] • This operation can only be performed if all SPV checks[3] of the Tx3 inputs are positive.

[0176] [5] SPV check (message): Bob sends a message to the P2P network

[0177] This step is the same as the step in the existing paradigm of the SPV method [3] (see above).

[0178] Figure 10 The communication process is illustrated in the figure. It should be noted that only [4] and [5] are mediated by a P2P network. Step [5] is merely a repetition of existing SPV technology and is not a necessary feature of the proposed method; for the sake of completeness and to distinguish it from existing paradigms, the present invention is included herein.

[0179] It should be noted that, according to the embodiments of this disclosure, necessary SPV checks are performed [3]:

[0180] • Before the payment transaction (Tx3) is submitted;

[0181] • Input transactions (Tx1 and Tx2) to the payment transaction (Tx3);

[0182] • Merkel's path can be provided without the help of network peers (provided by Alice).

[0183] Features of embodiments of the present invention include, but are not limited to:

[0184] Alice doesn't need to be online or submit any information to the network herself. This is more reliable for Alice. It also allows her to use devices that cannot connect to the network, such as smart cards.

[0185] • Including the Merkel path allows Bob to quickly reject any invalid input from Alice. This reduces unnecessary network traffic by rejecting "spam" transactions that have invalid Merkel paths.

[0186] Bob's connection to the internet is likely exceptionally fast, so he can probably verify transactions even faster.

[0187] Bob creates transactions for Alice to sign, thus having more control over the content of the transactions. For example, he can choose to pay more of the in-transaction fees, which will ensure that the transaction is accepted by the network.

[0188] Bob's wallet does not need to contain any private key. This improves security because the private key cannot be accessed or disclosed by unauthorized third parties.

[0189] The responsibility for submitting transactions to the network rests with Bob.

[0190] Alice's SPV wallet must have a private key and be able to sign transactions. Therefore, it must have sufficient processing power to perform elliptic curve multiplication.

[0191] Now consider in more detail the various components arranged in accordance with this disclosure.

[0192] Offline SPV Wallet

[0193] Offline SPV implementation examples are in Figure 1 The diagram schematically illustrates and includes the following features:

[0194] 1. TX - Preloaded complete transaction data, containing the unspent transaction outputs available to Alice. This complete transaction data, together with the Merkel path, constitutes a Merkel proof that the transaction Alice is spending is valid. Hashing the entire transaction yields a transaction identifier (TXID), which is part of the input data for the 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 she provides Bob with the complete transaction data, therefore she must store it or at least make it accessible when needed.

[0195] 2. Private Key / Public Key - A wallet must have access to a set of private keys to sign transaction outputs, and must also have access to the public key to specify change addresses when making transactions.

[0196] 3. Merkel Path - A (complete) Merkel path for each transaction, including the transaction output (UTXO). This will be used by the merchant's point-of-sale wallet to verify the validity of the transaction (TX). It should be noted that while the Merkel proof provided by this wallet does not prevent double-spending, it does act as a fail-fast mechanism against spam attacks, thereby improving the wallet's robustness and security.

[0197] 4. Minimal Processing – Offline SPV wallets require signing unspent transactions before they can be used. This necessitates that the offline wallet (and the device on which it is installed) implement cryptographic algorithms such as ECDSA, which means sufficient processing power is needed to perform elliptic curve multiplication and compute hash functions.

[0198] 5. Block Header (Optional) – Offline SPV wallets may want to include a block header to verify that payments to the point-of-sale SPV wallet have been processed. This also requires storing the TXID and Merkel path after interaction with the point-of-sale wallet.

[0199] In one or more embodiments, the above can be implemented as a wallet that simultaneously has online and offline states or functions. This can be advantageous when the wallet needs to update its UTXO and Merkel path set.

[0200] In this embodiment, Alice's wallet can temporarily connect to the network to download data in the same way as a traditional SPV wallet. This is in Figure 2 As shown, for convenience, it can be referred to as an online and offline SPV wallet.

[0201] Once connected, Alice's wallet can download the complete transaction, Merkel path, and block header. A standard P2PKH transaction with one input and two outputs, known in the art, is 226 bytes, the block header is 80 bytes, and the Merkel path for a transaction in a block containing 100,000 transactions is approximately 560 bytes. Combining these three means that updating Alice's SPV wallet only requires downloading less than 1MB of data for each new input. This can even be achieved with a low-bandwidth connection, which is highly advantageous.

[0202] Wallets using this implementation are advantageous because they offer the benefit of facilitating offline payments and verification using the blockchain, while maintaining the ability to connect to the network when needed. Additional online status can be used to update the block header list, obtain new transactions and associated Merkel paths, and even send transactions when required.

[0203] Online and offline SPVs have a variety of possible use cases, including software applications and contactless payment cards.

[0204] PoS SPV wallet

[0205] The PoS SPV wallet is designed to implement 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:

[0206] Generate point-of-sale transaction templates.

[0207] • Calculate the Merkel proof associated with the block header.

[0208] • Connect and broadcast to the network, including queries on the UTXO set.

[0209] • Public key address for managing payment receipts

[0210] • Update his complete list of TX data for the UTXO containing Alice.

[0211] according to Figure 3 The schematic design shown demonstrates that the PoS SPV wallet meets all the above requirements and includes the following features:

[0212] 1. Block Header – The PoS SPV wallet maintains an up-to-date copy of the list of block header data corresponding to blocks in the blockchain. When presenting a transaction and its Merkle path, the PoS SPV wallet can perform a simple Merkle proof by repeating the Merkle root hash.

[0213] By comparing this root with the root in the relevant block header, Bob has an effective fail-fast mechanism to detect erroneous or fraudulent payments.

[0214] 2. Network Connectivity – PoS SPV wallets have the ability to connect to networks. This includes (but is not limited to) broadcasting newly signed transactions to the blockchain network and querying whether a specific UTXO exists in the current UTXO set.

[0215] 3. Public Key Storage – A PoS SPV wallet only needs to store the public key address that Bob wants 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 / 145016) or by using a hierarchical deterministic wallet structure.

[0216] By storing only the public key address instead of the associated private key at the point of sale, the security of “card-based” transactions is greatly improved because Bob’s private key is not easily leaked, thus protecting the funds.

[0217] 4. Minimal Processing – The PoS SPV wallet only needs to perform a minimal Merkle proof process based on the template filled in by Alice.

[0218] This significantly reduces the burden of iterating and processing complete blocks to independently obtain the Merkel path, thereby speeding up the point-of-sale / transaction process, accelerating the transfer of resources across the network, and improving the efficiency of Bob and Alice.

[0219] It should be noted that, in at least one embodiment, the point-of-sale SPV wallet will maintain a copy of the entire block header list to ensure that Bob is always able to perform SPV checks on the Merkel path for any transaction in the blockchain history. However, Bob may choose not to retain the complete block header list, for example, those corresponding to blocks that do not contain transactions with spendable outputs. In this case, it should be understood that Bob may occasionally need to query a third party for block headers he does not yet have. In the next section, the merchant point-of-sale template that Bob sends to Alice according to one or more embodiments is described in detail, and it should be understood that if Bob does not have a complete list of all block headers, he can incorporate requests for block headers associated with her unspent transaction outputs into this template.

[0220] PoS SPV Wallet Template

[0221] Go to Figure 4 Bob's PoS SPV wallet requests Alice's offline (or offline / online) wallet information in the following format:

[0222] 1.TX / UTX - Complete transaction data from Alice's spendable transactions (as described above).

[0223] 2. Transaction Template - A partially complete blockchain transaction, including (at least) Bob's output address and the amount of assets Alice is requesting. To complete the transaction, Alice's offline wallet must (at least) provide the TXID from her unspent transaction outputs, a valid signature for each spendable TX output to be used, and a change address.

[0224] 3. Merkel Path - When combined with a complete, finished transaction, a Merkel proof can be constructed to verify whether Alice's TX is included in the block and is therefore valid.

[0225] It should be noted that, in the simplest case, Alice needs to provide Bob with a valid payment transaction Tx3 in order to exchange goods at the PoS. According to at least one embodiment of the invention, Bob provides a merchant template to facilitate this, but it is also conceivable not to use a template. For example, if Alice already knows the price and Bob's address beforehand, she can construct her payment and transfer the payment directly to Bob. Alice can also provide the required signature and output point reference without explicitly "filling out" the template itself.

[0226] Full transaction (see) Figure 4 (1) and Merkel's proof (see [reference]) Figure 4 (3) can be sent by Alice and processed by Bob. This can be done with Alice completing Bob's template (see...). Figure 4 (2) in the middle is completed in parallel and independently.

[0227] Delayed transaction submission:

[0228] In some cases, such as for online retailers, it may be advantageous to submit payment transactions in installments periodically. This could be beneficial for technical reasons, such as waiting for improved / optimal network connectivity to become available, for accounting purposes, or to reduce the total value of transaction fees incurred.

[0229] For merchant Bob, this presents no additional challenge, but for customer Alice, it means that she cannot use the assets associated with Alice's change address until Bob finally submits the signed transaction to the network.

[0230] The solution to this problem is that Bob specifies an artificial delay in processing transactions in the template he provides to Alice. Alice's offline wallet can interpret this as the merchant not being able to use the change generated from paying Bob within a predetermined time before the bulk transactions are submitted to the network. It should be noted that Bob faces no additional risk in this scenario, as he can cancel delivery of the purchased goods if the merchant discovers evidence of double-spending before submitting the bulk transactions.

[0231] PoSSPV Wallet Extension - Split Wallet

[0232] As an extension of the aforementioned PoS SPV wallet, Bob may want to use several connected wallets with different functionalities, which can be viewed as a single split-wallet system.

[0233] Therefore, certain embodiments of the present invention build upon the basic concept of a Point of Sale (PoS) SPV by introducing a higher-level master SPV that can coordinate one or more point-of-sale (PoS) SPVs. The combination of a master SPV and one or more PoS SPVs will be considered herein as a “split wallet” system.

[0234] The split wallet system according to an embodiment of the present invention includes at least one PoS SPV wallet, which acts as a payment terminal and is coordinated by a main SPV component. The main SPV enables the wallet to:

[0235] • Stores the private key associated with the public key address of the PoS SPV.

[0236] • Calculate the Merkel proof associated with the block header.

[0237] • Connect and broadcast to the blockchain network, including queries on the UTXO set.

[0238] • Communicates with at least one PoS SPV wallet used as a payment terminal.

[0239] Like all simple payment verification systems, the main wallet should be able to perform all the basic functions of a good SPV, such as checking the Merkel proof of existence for a given transaction. This means Bob can check whether any transaction he broadcasts from the point of sale has been accepted by the network and included in a block. However, it is important that the main wallet according to an embodiment of the invention communicates with at least one simpler PoS SPV wallet and coordinates the payments it processes.

[0240] For the main SPV, storing the private key for Bob's payment address is advantageous. This makes Bob's payment processing more secure when using a split wallet system. However, storing Bob's private key is an optional feature of the main wallet, whose primary function is to aggregate and coordinate payments from multiple point-of-sale wallets.

[0241] In this merchant-split wallet implementation (using only the base primary SPV), the interaction between merchants and customers is not strictly modified. The PoS SPV wallet must still perform the same checks on the Merkel path and issue the same queries to the network regarding the UTXO set. The differences in the process include:

[0242] • Alice and Bob's choice of PoS SPV terminal.

[0243] • The main SPV should be continuously synchronized with the backend blockchain.

[0244] The private key associated with Bob's payment address is received from the main wallet and managed in a dedicated manner. This adds structure to the security previously introduced by storing the public key address only in the point-of-sale wallet.

[0245] It should be noted that, for security and practical reasons, the main wallet used as part of a split wallet implementation typically resides in a different location than the point-of-sale (SPV), such as the company's back office or headquarters. Merchant-customer interactions can be visualized, such as... Figure 5 As shown.

[0246] As previously discussed, this implementation using a simple master SPV as part of a merchant split wallet is of practical value to Bob, but if the split wallet is to provide an appropriate level of double-spending protection, it still relies on the network to respond to queries from the UTXO set.

[0247] This can be addressed through one or more embodiments, in which the primary SPV is replaced by a more robust type of primary wallet that also maintains its own mempool copy. A split wallet architecture equipped with such a primary wallet does not require querying the network to check whether a customer's UTXO is part of the current UTXO set.

[0248] A master wallet with its own mempool copy functions similarly to a classic non-mining "full node" client, but with the advantage that it doesn't need to maintain a complete copy of the blockchain. Instead, this type of master wallet only keeps the block headers and its own local copy of the mempool. The mempool copy can be built locally through synchronization with the network or from a trusted third party or service.

[0249] The split wallet is implemented using a main SPV wallet with its own mempool copy, which changes the merchant-customer interaction from the merchant's perspective.

[0250] and Figure 5 In comparison, the main changes in the interaction described above are reflected in steps 4 and 5:

[0251] • In step 4, the merchant only broadcasts the transaction to the network, instead of adding additional queries to the UTXO set.

[0252] In step 5, the merchant now performs its own check on the validity of customer transactions by examining the mempool for conflicting transactions. The merchant can then decide what action to take based on the state of its synchronized mempool copy.

[0253] Illustrations of the invention in use

[0254] Consider a typical merchant-customer interaction where Alice wants to buy something from Bob. According to one embodiment of the invention, the process is outlined and referenced below. Figure 6 conduct:

[0255] 1. Bob created a partially completed blockchain transaction and requested the following information from Alice. This information can be packaged together as a template for Alice to fill out:

[0256] a. Alice will spend TX output to complete the purchase.

[0257] b. Alice's change address

[0258] c. Alice's signature

[0259] d.TX's Merkel path (this is not part of the deal)

[0260] 2. Alice completes the template by providing the necessary information.

[0261] 3. Bob performs a Merkel proof to check the validity of the transaction provided by Alice. If the proof is invalid, Bob knows that Alice's transaction has never been valid in the blockchain, and he rejects the transaction. Advantageously, this is a fail-fast mechanism.

[0262] 4. Bob broadcasts the complete transaction to the network and queries the UTXO set.

[0263] a. This broadcast allows network nodes to begin attempting to mine transactions into blocks.

[0264] b. This query inquires whether the UTXO provided by Alice, which appears to be valid, still exists.

[0265] UTXO concentration.

[0266] This is a mechanism to prevent Alice from double-spending.

[0267] 5. The network responds to Bob's UTXO query. This allows Bob to take one of the following actions:

[0268] a. If Alice's UTXO is still part of the UTXO set, Bob can accept the payment with minimal risk of double-spending.

[0269] i. By continuing to use this query to poll network nodes within a certain time interval τ, Bob's risk can be minimized.

[0270] ii. Bayesian analysis can be used to ensure that Bob queries the majority of honest nodes within a certain confidence interval.

[0271] b. If Alice's UTXO is not part of the UTXO set, Bob will refuse Alice's payment.

[0272] As mentioned above, embodiments of the present invention are suitable for use and implementation in a variety of forms. These forms may include, for example, payment cards.

[0273] As is known in the art, traditional SPV wallets verify that a transaction is not double-spending by checking its depth in the blockchain, which is done by querying the network. Once a transaction is verified by a network node and included in a block, it has one confirmation. The confirmation count increases by one with each new block added to the blockchain, and with each new confirmation, the risk of double-spending decreases. Traditional SPV wallets will display the transaction as "n / unconfirmed" until there are six confirmations.

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

[0275] This invention shifts the burden of broadcast transactions to the receiver, Bob, rather than the sender, Alice, thereby minimizing CPU usage and improving Alice's experience. Bob has greater control over the transaction process because he doesn't need to rely on Alice's network connection, but he also doesn't have enough control to compromise Alice's security. Essentially, Alice has (only) the right to accept or reject a transaction by providing a digital signature.

[0276] Merkel path checks do not prevent double-spending because 0-conf is only reached when Bob sees the transaction relayed across the network and in the mempool. Instead, it acts as a fail-fast mechanism, allowing Bob to immediately reject attempts to spend a non-existent UTXO. This is useful because it prevents Bob from being used as a middleman in spam attacks, especially since the time required for broadcasting and querying full nodes can exceed several seconds if the connection is poor.

[0277] With the realization of offline payments, hardware such as prepaid smart cards can be integrated into the blockchain ecosystem. Payment cards require data capacity to store private keys, UTXOs, complete transactions, and Merkel paths. To implement the ECDSA signature algorithm, payment cards also require some processing power. Table 1 lists some of the electronic card types available at the time of submission.

[0278]

[0279] Table 1: Typical Payment Card Specifications

[0280] Double spending protection

[0281] Suppose customer Alice wants to exchange a physical item in a store. Traditionally, Alice sends a transaction to the blockchain network at the point of sale (POS), and merchant Bob only allows Alice to leave with the item if he sees the transaction under the following conditions.

[0282] (a) Return it to him after it is accepted by the network; or

[0283] (b) Confirmed within a block (or, for n-conf, n block depth).

[0284] In scenario (a), Bob knows that Alice's payment transaction to him is valid, and network nodes will attempt to mine this payment into a block. While this does not protect Bob from simple double-spending caused by Alice remotely submitting conflicting transactions, this scenario is compatible with traditional block header-based SPV.

[0285] In scenario (b), Bob knows the payment transaction is valid and there is no double-spending. However, this requires Bob to run a full node and download the next block in situ. Furthermore, this takes an average of 10 minutes on the blockchain network before Alice can leave with the goods.

[0286] It should be noted that in this problem statement, it is assumed that 0-conf security is satisfactory for Bob because the attack being mitigated is a simple double cost for Alice. One or more blocks are needed to mitigate a different attack vector, namely the attack vector of a third adversary, Carol, which overwhelms the entire network.

[0287] The table below illustrates how scenarios (a) and (b) are independently accepted for this type of customer-merchant interaction. The table also shows the transaction characteristics of scenarios a) and b):

[0288] factor Scenario (a) Scene (b) Double spending protection for Bob no Acceptable Average transaction time <10s Acceptable no <10m average transaction time Acceptable no SPV compatible* (Bob) Acceptable no SPV compatible* (Alice) Acceptable Acceptable

[0289] This means that there is no full node requirement for this party. For most transactions, only solutions that meet all of these criteria can be accepted by both Bob (the merchant) and Alice (the customer).

[0290] The merchant PoS wallet implementation disclosed in this article offers the following advantages:

[0291] • Double spending protection for merchants

[0292] • Average transaction time (<<10s)

[0293] Both customers and merchants can use the SPV wallet at the point of sale.

[0294] factor Scenario (a) Scene (b) Merchant SPV Double spending protection for Bob no yes yes Average transaction time <10s yes no yes <10m average transaction time yes no yes SPV compatible* (Bob) yes no yes SPV compatible* (Alice) yes yes yes

[0295] It is conceivable that embodiments of the present invention can provide performance and results that will significantly improve existing SPV transaction rates and, at least in terms of immediacy, rival existing chip and password / contactless terminal payment interactions.

[0296] Furthermore, this invention allows for payment clearing and approval with high certainty in approximately one hour (i.e., 6-conf). This is far superior to the current payment clearing time of up to 60 days, i.e., the clearing time for VISA and Mastercard.

[0297] Variable risk

[0298] As a merchant, Bob can calibrate the delay in accepting payments at the point of sale. By selecting the minimum polling interval τ, he also sets a maximum probability of the double-spending risk he can accept. This improves the efficiency and flexibility of merchant payment processing.

[0299] Now go to Figure 7 This document provides an illustrative simplified block diagram of a computing device 2600 that can be used to implement at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 can be used to implement any system shown and described above. For example, the computing device 2600 can be configured to function as a data server, network server, portable computing device, personal computer, or any electronic computing device. Figure 7As shown, computing device 2600 may include one or more processors with one or more levels of cache and a memory controller configured to communicate with a storage subsystem 2606 including main memory 2608 and permanent memory 2610. As shown, main memory 2608 may include dynamic random access memory (DRAM) 2618 and read-only memory (ROM) 2620. Storage subsystem 2606 and cache memory can be used to store information, such as details associated with transactions and blocks described in this disclosure. Processor 2602 can be used to provide steps or functions of any embodiment described in this disclosure.

[0300] The processor 2602 can also communicate with one or more user interface input devices 2612, one or more user interface output devices 2614, and network interface subsystem 2616.

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

[0302] The network interface subsystem 2616 can provide interfaces to other computing devices and networks. The network interface subsystem 2616 can serve as an interface for receiving data from the computing device 2600 and transmitting data to other systems. For example, the network interface subsystem 2616 enables data technicians to connect devices to a network, allowing them to send and receive data to and from the device from remote locations (e.g., data centers).

[0303] User interface input device 2612 may include one or more user input devices, such as a keyboard; pointing devices, such as an integrated mouse, trackball, touchpad, or graphics tablet; a scanner; a barcode scanner; a touchscreen included in a display; audio input devices, such as a speech recognition system, a microphone; and other types of input devices. Generally, the term "input device" is used to encompass all possible types of devices and mechanisms for inputting information into computing device 2600.

[0304] 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 projector or other display device. Generally, the term "output device" is used to encompass all possible types of devices and mechanisms for outputting information from the computing device 2600. For example, one or more user interface output devices 2614 may be used to present a user interface to facilitate user interaction with applications performing described processes and variations thereof (where such interaction may be appropriate).

[0305] Storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data constructs that provide functionality for at least one embodiment of the present disclosure. When executed by one or more processors, application programs (programs, code modules, instructions) may provide functionality for one or more embodiments of the present disclosure and may be stored in storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. Storage subsystem 2606 may additionally provide a repository for storing data used according to the present disclosure. For example, main memory 2608 and cache memory may provide volatile storage for programs and data. Persistent memory 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-ROMs, DVDs, or Blu-rays) with associated removable media, and other similar storage media. Such programs and data may include programs for performing steps as described in one or more embodiments of the present disclosure, as well as data associated with transactions and blocks described in the present disclosure.

[0306] The computing device 2600 can be of various types, including portable computer devices, tablets, workstations, or any other devices described below. Additionally, the computing device 2600 may include another device that can be connected to the computing device 2600 via one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). Devices that can be connected to the computing device 2600 may include multiple ports configured to accept fiber optic connectors. Therefore, the device can be configured to convert optical signals into electrical signals, which can be transmitted via the ports to which the device is connected for processing by the computing device 2600. Due to the constantly evolving nature of computers and networks, Figure 7 The description of the computing device 2600 shown is merely used as a specific example to illustrate a preferred embodiment of the device. There may be variations... Figure 7The system shown has many other configurations with more or fewer components.

[0307] The term "blockchain transaction" can be used to refer to a data structure that enables the transfer of control of digital resources or assets via a blockchain network using cryptographic keys. As mentioned above, in order for a transaction to be written into the blockchain, the transaction must: i) be verified by the first node receiving the transaction, and if the transaction passes verification, this node relays the transaction to other nodes in the network; ii) be added to a newly constructed block; and iii) be mined, that is, have been added to the public ledger of past transactions. It should be understood that the nature of the work performed by network nodes will depend on the type of consensus mechanism used to maintain the blockchain. It should be understood that consensus mechanisms other than Proof of Work (PoW) can be used, 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.

[0308] As previously mentioned, each transaction in a given block encodes the transfer of control of digital assets among participants in the blockchain system. For example, digital assets might relate to digital representations of documents, images, physical objects, etc. The validity of blocks in the blockchain is maintained by performing necessary tasks.

[0309] It should be noted that the above embodiments are illustrative rather than limiting of the invention, and those skilled in the art can devise many alternative embodiments without departing from the scope of the invention as defined by the appended claims. Any reference numerals in parentheses in the claims should not be construed as limiting the claims. The words “comprising” and the like do not exclude the presence of elements or steps other than those listed in their entirety in any claim or specification. In this specification, “comprising” means “including” or “consisting of”. “Operational” or “operation to” is used herein to include the terms “arranged as” and “configured as”. The singular form of an element does not exclude the plural form of such elements, and vice versa. The invention can be implemented by hardware comprising several different elements and by a suitably programmed computer. In the device claims enumerating several means, several of these means may be embodied by the same hardware. The fact that certain measures are referenced in mutually different dependent claims does not mean that combinations of these measures cannot be advantageously used.

Claims

1. A blockchain-implemented simple payment verification system to facilitate a transfer of an asset in or through a blockchain maintained by a blockchain network between a first verifying resource of a transfer-out party and a second verifying resource of a transfer-in party, wherein: the first verifying resource is to send to the second verifying resource: With transfer transactions ( Tx3 The data related to the transfer transaction () Tx3 This includes the output of transferring the assets to the receiving party; With at least one blockchain transaction ( Tx1 Complete transaction data related to the at least one blockchain transaction ( Tx1 This includes unspent outputs, which are spent on the transfer transaction. Tx3 Input of ) and the at least one blockchain transaction ( Tx1 ) merkle path; and the second verifying resource is to: i) from said first verifying resource, receiving and / or requesting said complete transaction data related to said at least one blockchain transaction, and said Merkel path of said at least one blockchain transaction (Merkle Pathi) Tx1 ); ii) providing a merkle proof of the at least one blockchain transaction using the complete transaction data related to the at least one blockchain transaction and the merkle path of the at least one blockchain transaction, and using the merkle proof to verify that the at least one blockchain transaction has been mined into a block on the blockchain by the blockchain network Tx1 Tx1 ​​ and iii) sending the transfer transaction to the blockchain network upon successful verification of the Merkle proof Tx3 to transfer the asset from the transferor to the transferee.

2. The system of any preceding claim, wherein the first and / or second verifying resource is or comprises a smart card, a digital or lightweight wallet and / or an SPV wallet.

3. The system of any preceding claim, wherein the second verifying resource is to receive and / or request the complete transaction data and the Merkle path from the first verifying resource using off-chain communication.

4. The system of any preceding claim, wherein, The verification of the Merkle proof is performed off-chain by the second verifying resource.

5. The system of any preceding claim, wherein the system further comprises a plurality of second verifying resources, and a coordinating component to communicate with the plurality of second verifying resources.

6. The system of claim 1, wherein, The transfer transaction ( Tx3 This includes an output for specifying the address of the recipient of the asset.

7. The system of any preceding claim, wherein the second verifying resource is also to receive and / or request from the first verifying resource, or the first verifying resource is also to send to the second verifying resource, at least one of: a signature to spend an output of the at least one blockchain transaction; a transfer value; and / or a public key address.

8. A blockchain-implemented simple payment verification method to facilitate a transfer of an asset in or through a blockchain maintained by a blockchain network between a first verifying resource as a transfer-out party and a second verifying resource as a transfer-in party, the method comprising: i) receiving at the second verifying resource: - Transfer transaction ( Tx3 The transfer transaction ( Tx3 This includes the output of transferring the assets to the receiving party; - With at least one blockchain transaction ( Tx1 Complete transaction data related to the at least one blockchain transaction ( Tx1 This includes unspent outputs, which are spent on the transfer transaction. Tx3 Input of ) and - a Merkle path of the at least one blockchain transaction ( Tx1 ) wherein the transaction data and the Merkle path are received from the first verification resource, the first verification resource storing the Merkle path and the complete transaction data for the at least one blockchain transaction Tx1 ​ ii) The at least one blockchain transaction is provided by the second verification resource using the Merkel path. Tx1 Merkel's proof; iii) verifying, by the second verification resource, using the Merkle proof, that the at least one blockchain transaction has been mined into a block on the blockchain by the blockchain network; Tx1 ) and iv) sending, by the second verifying resource, the transfer transaction to the blockchain network upon successful verification of the Merkle proof to transfer the asset from the transferor to the transferee. Tx3 < / s> 9. The method of claim 8, wherein the following steps are performed off-chain: i) verification of the Merkle proof of the at least one blockchain transaction; and / or ii) receiving or requesting the complete transaction data and the Merkle path from the first verifying resource.

10. The method of claim 8, wherein: the first and / or second verifying resource is or comprises a smart card, a digital or lightweight wallet and / or an SPV wallet.

11. A non-transitory computer-readable storage medium having stored thereon executable instructions, wherein execution of the executable instructions by a processor of a computer system causes the computer system to perform at least an embodiment of the method or system of any preceding claim.

Images