Connecting to Blockchain Networks

Abstract

1. A computer-implemented method for transmitting a blockchain transaction to a blockchain network, the method being executed by a first party and comprising: transmitting at least a portion of a blockchain transaction to an internet server via an internet service hosted by the internet server, the internet server coupled to one or more nodes of the blockchain network and configured to transmit the blockchain transaction to the one or more nodes of the blockchain, the transmitted blockchain transaction comprising the at least the portion of the blockchain transaction.

Description

[Technical Field]

[0001] The present disclosure relates to improving connectivity of users (or other entities) to blockchain networks. [Background technology]

[0002] A blockchain refers to a form of distributed data structure in which multiple nodes in a decentralized peer-to-peer (P2P) network (hereinafter also referred to as a "blockchain network") maintain and publicly publish duplicate copies of the blockchain. A blockchain contains a chain of blocks of data, each containing one or more transactions. Each transaction, except for so-called "coinbase transactions," points to the preceding transaction in the sequence. The sequence may span one or more blocks, tracing back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to a blockchain network are included in new blocks. New blocks are generated through a process known as "mining." "Mining" involves multiple nodes competing to perform "proof-of-work," i.e., solving a cryptographic puzzle based on the presentation of a defined set of ordered and validated pending transactions awaiting inclusion in a new block of the blockchain. Notably, a blockchain may be pruned at some nodes, and block publication can be achieved through the publication of only the block header.

[0003] Transactions in a blockchain can be used for one or more of the following purposes: carrying digital assets (i.e., multiple digital tokens), ordering a set of entries in a virtual ledger or registry, receiving and processing timestamp entries, and / or chronologically ordering index pointers. Blockchains can also be used to layer additional functionality on top of them. For example, blockchain protocols may allow for the storage of additional user data or indexes to data within a transaction. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction. Thus, more complex data can be incorporated. For example, this could be used to store electronic documents, or audio or video data within a blockchain.

[0004] Nodes (sometimes called "miners") in the blockchain network perform a distributed transaction registration and validation process, described in detail below. Briefly, during this process, nodes validate transactions, insert them into a block template, and attempt to identify a valid proof-of-work solution for it. Once a valid solution is found, the new block is propagated to other nodes in the network, allowing each node to record the new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) submits the transaction to one of the nodes in the network for propagation. Nodes receiving the transaction compete to find a proof-of-work solution and include the validated transaction in a new block. Each node is configured to implement the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated or included in a block. Assuming the transaction is validated and thereby accepted into the blockchain, the transaction (including any user data) therefore remains registered and indexed at each node in the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle to generate the latest block are typically rewarded with a new transaction, called a "coinbase transaction," that generates a new quantity of digital assets, or tokens. Detection and rejection of invalid transactions is performed by competing nodes, who act as agents of the network and are incentivized to report and prevent illicit activity. Widespread publication of information allows users to continuously audit node performance. By simply publishing block headers, participants can guarantee the ongoing integrity of the blockchain.

[0006] In an "output-based" model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element that specifies the amount of a digital asset derivable from the preceding transaction sequence. A spendable output is sometimes called a UTXO (unspent transaction output). An output may further include a locking script that specifies conditions for the output's future redemption. A locking script is a predicate that defines the conditions required to validate and transfer a digital token or asset. Each input in a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a preceding transaction and may further include an unlocking script to unlock the pointed-to output's locking script. Thus, when considering a pair of transactions, we refer to them as a first transaction and a second transaction (or "target" transaction). The first transaction includes at least one output that specifies the amount of a digital asset and includes a locking script that defines one or more conditions for unlocking the output. The second target transaction includes at least one input including a pointer to an output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one validity criterion applied by each node is that the unlock script meets all of one or more conditions defined in the lock script of the first transaction, and another is that the output of the first transaction has not yet been redeemed by another, previous, valid transaction. Any node that finds the target transaction invalid according to any of these conditions will neither propagate it (as a valid transaction) (but may register an invalid transaction) nor include it in a new block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction transfers by referencing absolute account balances, rather than defining the amount transferred by referencing back to the UTXO of a previous transaction in the past sequence of transactions. The current state of all accounts is stored and constantly updated by nodes separate from the blockchain. Summary of the Invention

[0009] Users (and other types of parties, e.g., organizations, autonomous entities, etc.) typically connect directly to one or more blockchain nodes of a blockchain network. That is, a user operating a client application can connect to a blockchain node to, for example, submit transactions to the network, retrieve transactions from the blockchain, query the existence of particular unspent transaction outputs (UTXOs), etc. To perform these operations, a trusted connection between the user and the node is required. Therefore, it is desirable to increase the connectivity between users and nodes to ensure that a trusted connection to the blockchain network is maintained.

[0010] For example, consider a scenario in which a user (e.g., Alice) operating a light-client application attempts to submit a transaction to a blockchain network or query the existence of one or more UTXOs that another user (e.g., Bob) is attempting to allocate to Alice, e.g., in exchange for goods or services. If Alice cannot connect to the blockchain network, she may not be able to submit the transaction, or she may not be able to verify that Bob is not attempting to double-spend a UTXO referenced by an already validated transaction. Of course, this is case-sensitive, depending on whether additional information is available, as there is other information that validates the UTXO (e.g., the UTXO's Merkle path). Alice may not be able to connect to a blockchain node due to issues with connecting to the node itself, or because the node to which Alice normally connects is no longer operating as a node on the network.

[0011] According to one aspect disclosed herein, there is provided a computer-implemented method for transmitting a blockchain transaction to a blockchain network, the method being performed by a first party and comprising: A method is provided, comprising: transmitting at least a portion of a blockchain transaction to an internet server via an internet service hosted by the internet server, the internet server coupled to one or more nodes of the blockchain network and configured to transmit blockchain transactions to the one or more nodes of the blockchain, the transmitted blockchain transaction comprising the at least a portion of the blockchain transaction.

[0012] According to another aspect disclosed herein, there is provided a computer-implemented method for transmitting a blockchain transaction to a blockchain network, the method being performed by an internet server configured to couple to one or more blockchain nodes; receiving at least a portion of a blockchain transaction from a first party via an internet service hosted by an internet server; transmitting a blockchain transaction to the one or more blockchain nodes, the blockchain transaction including the at least part of the blockchain transaction; A method is provided which includes:

[0013] A first party (e.g., Alice) forms a connection to an internet server (e.g., a web server or mail server) that is connected to one or more blockchain nodes. Thus, Alice does not need to be directly connected to the blockchain network, but instead can use an internet server that has a permanent connection to one or more nodes. The internet server acts as a gateway between Alice and the blockchain network. Rather than Alice having to rely on her connection to the network, Alice can use an internet server that can maintain multiple individual connections to different nodes. If the server is experiencing problems with one or more particular connections, or if one or more of the nodes drops out of the blockchain network, the server can instead route Alice's transactions to the network through one or more different nodes.

[0014] In some examples, an internet server may maintain a permanent connection to the blockchain network through at least one node, e.g., by maintaining a connection to the same node for a given period of time, or by maintaining connections to different nodes at different points throughout that period.

[0015] In some embodiments, the internet server may be a web page, such as a social media site. The web page may have embedded functionality configured to receive or generate one or more components of a transaction, such as a signature generated using Alice's private key. The components of the transaction or the completed transaction are then sent to the server hosting the web page, which then forwards the transaction to the blockchain network. Depending on the particular configuration, the server may generate the transaction itself by inputting the components provided or generated by the web page into a transaction template.

[0016] In other embodiments, the internet service may be a mail service, i.e., an email application. The email application may have embedded functionality that allows users to interact with the blockchain network from within the application. As described in more detail below, the mail server hosting the email application may maintain a list of peers (contracts) linked to or known to Alice, who also operates a blockchain client application. Each public key or blockchain address (e.g., public key hash) may be stored in association with Alice's contract. This can be used to indicate to Alice which of her contracts she can assign her digital assets to, and the blockchain address of her contract to use to do so. Note that these examples equally apply to the web page implementation described above.

[0017] According to another aspect disclosed herein, there is provided a computer-implemented method for discovering one or more blockchain nodes of a blockchain network, wherein an internet server maintains a list of identifiers, each identifier associated with a respective blockchain node, the method comprising: obtaining one or more identifiers from the internet server, each identifier associated with a respective blockchain node; using the one or more identifiers obtained to bind to the associated one or more blockchain nodes; A method is provided which includes: [Brief explanation of the drawings]

[0018] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference is made, by way of example only, to the accompanying drawings, in which: [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] 1 shows a schematic diagram of some examples of transactions recorded on a blockchain. [Figure 3A] FIG. 2 is a schematic block diagram of a client application. [Figure 3B] 3B is a simplified simulated representation of an exemplary user interface that may be presented by the client application of FIG. 3A. [Figure 4] 1 is a schematic block diagram of an exemplary system for implementing embodiments of the present invention. [Figure 5] 1 illustrates a schematic diagram of a blockchain transaction flow from a user to a blockchain network, according to an embodiment of the present invention. [Figure 6] FIG. 2 is a sequence diagram illustrating an exemplary embodiment of the present invention. [Figure 7] FIG. 4 is a sequence diagram illustrating another exemplary embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0019] Exemplary System Overview 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, which is typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes multiple blockchain nodes 104 that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Each blockchain node 104 is therefore highly coupled to other blockchain nodes 104.

[0020] Each blockchain node 104 includes a peer computing device, with different nodes 104 belonging to different peers. Each blockchain node 104 includes a processing device including one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or other devices such as field programmable gate arrays (FPGAs) and application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may include one or more memory units using one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives.

[0021] A blockchain 150 includes a chain of blocks of data 151, each copy of which is maintained at each of multiple nodes 104 in a decentralized or blockchain network 106. As noted above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, data can be removed from the blockchain 150 as long as each blockchain node 150 stores the block header (described below) for each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 includes at least one input and at least one output. Each output specifies a quantity representing an amount of a digital asset as an asset. In this example, the output is cryptographically locked to user 103 (requiring that user's signature or other solution to unlock it and thereby redeem or spend it). Each input points to an output of a preceding transaction 152, thereby linking the transactions.

[0022] Each block 151 also contains a block pointer 155 that points back to an earlier block 151 in the chain, defining a sequential order for the blocks 151. Each transaction 152 (other than a coinbase transaction) contains a pointer to a previous transaction, defining an order for the sequence of transactions (Note: the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 goes back to the genesis block (Gb) 153, which was the first block in the chain. Early in the chain 150, one or more original transactions 152 pointed to the genesis block 153 rather than to a preceding transaction.

[0023] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 across the network 106. Each blockchain node 104 is configured to generate blocks 151 and store respective copies of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set (or pool) 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is sometimes referred to as a "mempool." This term, as used herein, is not limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid and that the node 104 is obligated to not accept other transactions that attempt to use the same output.

[0024] For a given current transaction 152j, the inputs (or each of them) contain a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output is redeemed or "spent" in the current transaction 152j. In general, a previous transaction can be any transaction in the ordered set 154 or any block 151. A previous transaction 152i does not necessarily have to exist when the current transaction 152j was created or sent to the network 106, but a previous transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" herein refers to something that precedes in the logical sequence linked by a pointer, and not necessarily to the time of creation or transmission in the chronological order. Thus, it does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion of orphan transactions below). A preceding transaction 152i may equally be referred to as an antecedent or predecessor transaction.

[0025] The input of the current transaction 152j also includes an input authorization, e.g., the signature of the user 103a to whom the output of the previous transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user or entity 103b defined in the output of the current transaction 152j. In some cases, a transaction 152j may have multiple outputs to divide the input amount among multiple users or entities (one of which may be the original user or entity 103a to provide change). In some cases, a transaction may have multiple inputs and combine amounts from multiple outputs of one or more previous transactions and redistribute them into one or more outputs of the current transaction.

[0026] According to a Bitcoin-like output-based transaction protocol, when an entity 103, such as an individual user or an organization, wants to act on a new transaction 152j (either manually or through an automated process used by a party), the acting entity sends the new transaction from its computer terminal 102 to a recipient. The acting party or recipient eventually sends this transaction to one or more blockchain nodes 104 of the network 106 (which today are typically servers or data centers, but in principle other user terminals are also possible). In some examples, it is not excluded that the party 103 acting on the new transaction 152j can send the transaction directly to one or more blockchain nodes 104 rather than to a recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied to each blockchain node 104. The blockchain node protocol typically requires the blockchain nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In the case of such output-based transaction protocols, this may involve checking that a cryptographic signature or other authentication of party 103 included in the input of new transaction 152j matches a condition defined in the output of the preceding transaction 152j that the new transaction assigns, which condition typically includes at least checking that the cryptographic signature or other authentication in the input of new transaction 152j unlocks the output of the preceding transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the preceding transaction 152i, or may be simply fixed in the blockchain node protocol, or a combination thereof.In any case, if the new transaction 152j is valid, the blockchain node 104 forwards the new transaction to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104, following the same node protocol and applying the same tests, forward the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

[0027] In an output-based model, the definition of whether a given allocated output (e.g., UTXO) is allocated (e.g., spent) is whether it has already been validly redeemed by an input of another onward transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not yet been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not propagated or recorded in the blockchain 150 (unless it is flagged as invalid and propagated to change). This prevents double-spending, where a transactor attempts to allocate the same transaction output multiple times. On the other hand, an account-based model prevents double-spending by maintaining account balances. Again, because of the defined order of transactions, account balances have a single, defined state at a time.

[0028] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process called mining, which is underpinned by a "proof-of-work." Blockchain nodes 104 add new transactions to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded in the blockchain 150. Blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. This typically involves looking for a "nonce" value such that when the nonce is concatenated with a representation of the ordered pool 154 of pending transactions and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition may be that the hash output has a predetermined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle; other types are not excluded. A property of a hash function is that it has an unpredictable output given its input. Therefore, this search can only be performed by brute force and therefore consumes a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0029] A first blockchain node 104 that solves the puzzle notifies the network 106 and provides its solution as a proof. This solution can be easily checked by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to verify that the hash output satisfies the conditions). The first blockchain node 104 propagates the block upon agreement of a threshold of other nodes to accept the block, thus enforcing the protocol rules. The ordered set of transactions 154 is then recorded by each of the blockchain nodes 104 as a new block 151 in the blockchain 150. The new block 151n is also assigned a block pointer 155, pointing to the previously created block 151n-1 in the chain. The significant amount of effort required to generate the proof-of-work solution, e.g., in the form of a hash, signals the first node 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction, otherwise known as a double-spend. Once created, blocks 151 cannot be modified because they are known and maintained by each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose an order on the blocks 151. As transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, this provides an immutable public ledger of transactions.

[0030] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be solving the puzzle based on different snapshots of the pool of unpublished transactions 154, depending on when they began searching for a solution or the order in which transactions were received. Whoever solves the puzzle first defines the transactions 152 to be included in the next new block 151n, in the order in which the current pool of unpublished transactions 154 is updated. Blockchain nodes 104 then continue competing to produce blocks from the newly defined ordered pool of unpublished transactions 154. There is also a protocol for resolving possible "forks," which occur when two blockchain nodes 104 solve the puzzle within a very short time of each other, causing inconsistent views of the blockchain to propagate between the nodes 104. In essence, whenever a branch of a fork grows, the longest one becomes the final blockchain 150. Note that this does not affect users or agents of the network, since the same transactions appear in both branches.

[0031] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate an additional, approved amount of a digital asset in a new special type of transaction that distributes an additional defined amount of the digital asset (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of the digital asset from one agent or user to another). This special type of transaction is typically called a "coinbase transaction," but may also be called an "initiation transaction" or "generation transaction." It typically forms the first transaction of a new block 151n. The proof-of-work signals that the node that constructed the new block intends to follow protocol rules so that this special transaction can later be redeemed. Blockchain protocol rules may require this special transaction to expire, e.g., 100 blocks, before it can be redeemed. A regular (non-generating) transaction 152 often specifies an additional transaction fee in one of its outputs, further rewarding the blockchain node 104 that generated the block 151n in which the transaction was published. This fee is usually called a "mining fee" and will be explained later.

[0032] Due to the resources involved in validating and publishing transactions, at least each of the blockchain nodes 104 typically takes the form of a server including one or more physical server units, or an entire data center. However, in principle, any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

[0033] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 to perform one or more respective roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood that any operation attributed to a blockchain node 104 may be performed by software executing on the processing unit of each computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer such as the operating system layer or protocol layer, or any combination thereof.

[0034] Also connected to the network 101 are computing devices 102 for each of a number of parties 103 that act as consumer users. These users can interact with the blockchain network but do not participate in validating transactions and constructing blocks. Some of these users or agents may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store copies of the blockchain 150 (e.g., have obtained a copy of the blockchain from a blockchain node 104).

[0035] Some or all of the parties 103 may be coupled as part of a different network, for example, a network overlaid on the blockchain network 106. Users of the blockchain network (often called "clients") can be said to be part of the system that includes the blockchain network 106. However, these users are not blockchain nodes 104 because they do not perform the required role of a blockchain node. Instead, each party 103 may utilize the blockchain 150 by interacting with the blockchain network 106 and thereby coupling (i.e., communicating) with the blockchain nodes 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that many more such parties 103 and their respective computer devices 102 can exist and participate in the system 100, but are not shown for convenience. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, although it will be understood that this is not limiting and that references herein to Alice or Bob can be interchangeably referred to as "first party" and "second party," respectively.

[0036] Each party's 103 computing device 102 includes a respective processing unit that includes one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each party's 103 computing device 102 further includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. This memory may include one or more memory units that use one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory on each party's 103 computing device 102 stores software, including a respective instance of at least one client application 105, configured to operate on the processing unit. It will be understood that any actions attributed to a party 103 given herein may be performed using software executing on the processing unit of each party's 102 computing device. Each party's 103 computing device 102 includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing device 102 of a given party 103 may include one or more other networked resources, such as cloud computing resources, accessed via a user terminal.

[0037] The client application 105 may be initially provided to the computing equipment 102 of any given party 103 on one or more suitable computer-readable storage media, for example downloaded from a server, or on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk, for example a CD or DVD ROM, or removable optical drive.

[0038] The client application 105 has at least a "wallet" functionality, which has two main functions. One of these is to allow each party 103 to create, authorize (e.g., sign), and send transactions 152 to be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report to each party the amount of digital assets it currently owns. In an output-based system, this second function involves reconciling the amounts defined among the outputs of various transactions 152 scattered throughout the blockchain 150 belonging to that party.

[0039] NOTE: While various client functions are sometimes described as being integrated into a given client application 105, this is not necessarily limiting; instead, any client function described herein may be implemented in two or more different application suites, interfacing, for example, via an API, or one plugging into the other. More generally, client functions may be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following is described in terms of a client application 105, it will be understood that this is not limiting.

[0040] An instance of a client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet functionality of the client 105 to transmit transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in embodiments, actually inspect the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions, in part, through its public visibility). The wallet functionality on each computing device 102 is configured to form and transmit transactions 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and to forward transactions 152 for propagation throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol, together with a given node protocol, implements a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used for all nodes 104 in the network 106.

[0041] When a given party 103, e.g., Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, she formulates the new transaction (using the wallet functionality of her client application 105) according to the relevant transaction protocol. She then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 with the best connection to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j meets certain conditions for being "valid," examples of which will be detailed shortly. In some transaction protocols, the conditions for validation may be configurable on a per-transaction basis via a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or may be defined by a combination of the script and the node protocol.

[0042] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set 154 of the blockchain maintained by that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, assuming the transaction 152j is valid, this means that it will soon be propagated throughout the network 106.

[0043] Once placed in the ordered pool 154 of pending transactions maintained at a given blockchain node 104, the blockchain nodes 104 begin competing to solve a proof-of-work puzzle for the latest version of their respective pools of transactions, including the new transaction 152. (Note that other blockchain nodes 104 attempt to solve the puzzle based on different pools 154 of transactions, but whoever comes first defines the set of transactions included in the latest block 151.) Eventually, the blockchain nodes 104 will solve the puzzle for the portion of the ordered pool 154 that includes Alice's transaction 152j.) Once proof-of-work has been done for the pool 154 containing the new transaction 152j, it becomes part of one of the blocks 151 in the blockchain 150. Because each transaction 152 consists of a pointer to the previous transaction, the order of the transactions is also immutably recorded.

[0044] Different blockchain nodes 104 may initially receive different instances of a given transaction and may therefore have conflicting views of which instances are "valid" before one instance is published into a new block 151, at which point all blockchain nodes 104 agree that only the published instance is the valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the one not yet published in a block 151).

[0045] As part of the account-based transaction model, another type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol. In an account-based model, each transaction transfers by referencing an absolute account balance, rather than defining the amount transferred by referencing back to the UTXO of a previous transaction in a series of past transactions. The current state of every account is stored and constantly updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using an account's sequential transaction record (the so-called "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field can also sign a transaction. This data field may point back to a previous transaction, for example, if a previous transaction ID is included in the data field.

[0046] <UTXOベースのモデル> Figure 2 shows an example of a transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not intended to be limiting to all possible implementations. Note that the exemplary UTXO-based protocol is described with reference to Bitcoin, but could equally be implemented on other exemplary blockchain networks.

[0047] In a UTXO-based model, each transaction (“Tx”) 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). A UTXO includes a value that specifies an amount of a digital asset, which represents a set number of tokens on the distributed ledger. Among other information, a UTXO may also include the transaction ID of the transaction from which it originated. The transaction data structure may also include a header 201, which may include indicators of the sizes of the input and output fields 202 and 203. The header 201 may also include the transaction's ID. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the outstanding transaction 152 submitted to the node 104.

[0048] For example, suppose Alice 103a wants to create transaction 152j to transfer the amount of the digital asset in question to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1." It takes the amount of the digital asset locked to Alice and puts it into the output 203 of the preceding transaction 152i in the sequence, transferring at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 could point to any preceding (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0049] The preceding transaction Tx0 may already be validated and included in a block 151 of the blockchain 150 when Alice creates her new transaction Tx1, or at least when she submits it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the ordered set 154, in which case it will be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be generated and submitted to the network 106, or Tx0 may be submitted after Tx1 if the node protocol allows for buffering of "orphan" transactions. The terms "preceding" and "following" used herein in the context of a sequence of transactions refer to the order of transactions in a sequence defined by transaction pointers specified within the transaction (e.g., which transactions point to which other transactions). They may be equivalently replaced by "preceding" and "successor," or "ancestor" and "descendant," "parent" and "child," etc. This does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (a descendant transaction or "child") that points to a preceding transaction (an ancestor transaction or "parent") is not validated unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain amount of time to wait for its parent, depending on the node protocol and / or node behavior.

[0050] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, labeled herein as UTXO0. Each UTXO includes a value specifying the quantity of the digital asset represented by the UTXO and a locking script that defines the conditions that must be met by an unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the quantity to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script typically defines the unlocking conditions as follows: the unlocking script in the input of the subsequent transaction includes a cryptographic signature of the party to whom the preceding transaction was locked.

[0051] A lock script (aka scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S) used by blockchain networks. A lock script specifies the information needed to consume a transaction output 203, e.g., requirements for Alice's signature. An unlock script appears in the transaction output. An unlock script (aka scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the criteria of the lock script. For example, it may include Bob's signature. An unlock script appears in the transaction input 202.

[0052] In the example shown, UTXO0 of output 203 of Tx0 is A ], which means that Alice's signature SigP must be present for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction that attempts to redeem UTXO0 to be valid). A [Checksig P A] is the public key P from Alice's public-private key pair. A , a representation (i.e., a hash) of Tx1's input 202. Tx1's input 202 includes a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0, in order to distinguish it among any other possible outputs of Tx0. Tx1's input 202 further includes an unlock script that contains Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <SigP A The data (or "message") that Alice needs to sign to provide a valid signature may be defined by the lock script, or by the node protocol, or a combination of these.

[0053] When a new transaction Tx1 arrives at a blockchain node 104, the node applies its node protocol, which involves running the lock script and unlock script together to check whether the unlock script meets the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A > || [Checksig P A ]

[0054] where "||" denotes concatenation, "<...>" means placing data on a stack, and "[...]" are functions contained in the lock script (in this example, a stack-based language). Equivalently, the scripts may be executed one by one with a common stack rather than concatenating them. Either way, when executed together, the scripts will share Alice's public key P, which is contained in the lock script in the output of Tx0. Ais used to authenticate that the unlock script in Tx1's input contains Alice's signature, which signs the expected portion of the data. The expected portion of the data ("message") must also be included to perform this authentication. In an embodiment, the signed data includes the entirety of Tx1 (thus, there is no need to include a separate element specifying the signed portion of the data in plaintext, since the signed portion of the data is already inherently present).

[0055] The details of authentication using public-private cryptography will be well known to those skilled in the art. Essentially, if Alice signs a message using her private key, then another entity, such as node 104, given Alice's public key and the message in plaintext, can authenticate that the message must have been signed by Alice. Signatures typically involve hashing the message, signing the hash, and tagging the message as the signature, allowing the owner of the public key to authenticate the signature. Thus, in embodiments, reference to signing a particular piece of data, portion of a transaction, etc., may mean signing a hash of the piece of data or portion of a transaction.

[0056] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (in the example shown, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of pending transactions 154. The blockchain node 104 forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106, thereby causing it to propagate throughout the network 106. Once Tx1 is validated and included in the blockchain 150, it defines it as having consumed UTXO0 from Tx0. Note that Tx1 is only valid if it uses unspent transaction outputs 203. If it attempts to consume outputs that have already been consumed by another transaction 152, Tx1 becomes invalid, even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the UTXO referenced in the preceding transaction Tx0 has already been spent (whether it already forms a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database that marks UTXOs 203 that transactions 152 have spent, but ultimately, what defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in blockchain 150.

[0057] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another basis for invalidity in most transaction models. Therefore, such a transaction is not propagated and is not included in block 151.

[0058] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety; it is not possible to "leave" some of the amount defined in the UTXO while another amount is spent. However, amounts from a UTXO can be split among multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 of Tx0 can be split among multiple UTXOs of Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use the remaining amount to give herself change or pay another party in the second output of Tx1.

[0059] In particular, Alice must typically also include a fee for any Bitcoin nodes 104 that successfully include her transaction 104 in block 151. If Alice does not include such a fee, Tx0 will likely be rejected by the blockchain nodes 104, and thus, although technically valid, it will not be propagated and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept transaction 152 if they do not want to). In some protocols, transaction fees do not require their own separate output 203 (i.e., they do not require a separate UTXO). Instead, the difference between the total amount indicated by input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by the node 104 that wins the proof-of-work competition that produces the block containing UTXO1. However, nothing necessarily precludes that a transaction fee may alternatively or additionally be explicitly specified in a unique one of the UTXOs 203 of transaction 152.

[0060] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 in the blockchain 150. Thus, typically, a given party 103's assets are dispersed across the UTXOs of various transactions 152 throughout the blockchain 150. No single number is stored anywhere in the blockchain 150 that defines a given party's 103 total balance. It is the role of the wallet function in the client application 105 to compile the value of all the various UTXOs locked to each party that have not yet been spent in another onward transaction. This can be done by querying the copy of the blockchain 150 stored on one of the Bitcoin nodes 104.

[0061] Note that script code is often expressed generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to represent a specific function. "OP_...." represents a specific opcode in a scripting language. As an example, OP_RETURN, when preceded by OP_FALSE at the beginning of a lock script, is an opcode in a scripting language to generate an unspent output of a transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include a document that is desired to be stored in the blockchain.

[0062] Typically, the input to a transaction is a public key P AIn embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and all or some of the transaction outputs. The specific portion of the outputs to sign depends on the SIGHASH flag, which is a four-byte code typically included at the end of the signature that selects which outputs are signed (and is therefore fixed at the time of signing).

[0063] A lock script is sometimes referred to as a "scriptPubKey," indicating that each transaction typically includes the public key of the party being locked. An unlock script is sometimes referred to as a "scriptSig," indicating that it typically provides the corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the conditions for redeeming a UTXO include authenticating a signature. More generally, a scripting language may be used to define any one or more conditions. Therefore, the more general terms "lock script" and "unlock script" are preferred.

[0064] As shown in FIG. 1, the client applications on each of Alice's and Bob's computing devices 102a, 102b may include additional communication capabilities. This additional functionality allows Alice 103a to establish a separate side channel 301 with Bob 103b (at the invitation of either party or a third party). The side channel 301 allows for the exchange of data separately from the blockchain network. Such communication is sometimes referred to as “off-chain” communication. For example, it may be used to exchange transactions 152 between Alice and Bob without them being registered on the blockchain network 106 or progressing on the chain 150 until one of the parties chooses to broadcast the transactions 152 to the network 106. Sharing transactions in this manner is sometimes referred to as sharing a “transaction template.” The transaction template may lack one or more inputs and / or outputs necessary to form a complete transaction. Alternatively or additionally, the side channel 301 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0065] The side channel 301 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as a local area network, such as a mobile cellular network or a local wireless network, or a direct wired or wireless link between Alice and Bob's devices 102a, 102b. In general, the side channel 301 referred to anywhere herein may include any one or more links via one or more networking technologies or communication media for exchanging data "off-chain," i.e., separately from the blockchain network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 301. Thus, it should be noted that when Alice and Bob are said to exchange particular information, pieces of data, etc., over the side channel 301, this does not necessarily mean that all of these pieces of data need to be transmitted over the exact same link or the same type of network.

[0066] Client Software 3A illustrates an exemplary implementation of a client application 105 for implementing embodiments of the disclosed techniques. The client application 105 includes a transaction engine 301 and a user interface (UI) layer 302. The transaction engine 301 is configured to perform the underlying transaction-related functions of the client 105, such as forming transactions 152, receiving and / or sending transaction and / or other data via side channels 107, and / or sending transactions to one or more nodes 104 for propagation through the blockchain network 106, as described in further detail in accordance with the schemes described above.

[0067] The UI layer 302 is configured to render a user interface via user input / output (I / O) means of each user computing device 102, including outputting information to each user 103 by user output means of the device 102 and receiving input from each user 103 by user input means of the device 102. For example, the user output means may include one or more display screens (touch or non-touch screen) to provide visual output, one or more speakers to provide audio output, and / or one or more tactile output devices to provide tactile output, etc. The user input means may include, for example, one or more touchscreen input arrays (the same or different from those used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and voice recognition algorithms for receiving voice or voice input, one or more gesture-based input devices for receiving input in the form of manual or physical gestures, or one or more mechanical buttons, switches, joysticks, etc.

[0068] Note: Although various functions herein may be described as being integrated into the same client application 105, this is not necessarily limiting and may instead be implemented in two or more separate applications, e.g., one plugging into the other or interfacing via an API (application programming interface). For example, the functionality of the transaction engine 301 may be implemented in an application separate from the UI layer 302, or in the functionality of a given module, or the transaction engine 301 may be split among more than one application. Also, this does not exclude some or all of the described functionality being implemented, for example, in the operating system layer. When reference is made elsewhere in this specification to a single or given application 105, it is understood that this is merely an example and, more generally, that the described functionality may be implemented in any form of software.

[0069] 3B provides a simulated representation of an example user interface (UI) 300 that may be rendered by the UI layer 302 of the client application 105a on Alice's device 102a. It is understood that a similar UI may be rendered by a client 105b on Bob's device 102b or on any other party's device.

[0070] 3B shows the UI 300 from Alice's perspective. The UI 500 may include one or more UI elements 304, 305, 306 that are rendered as separate UI elements via user output means.

[0071] For example, the UI elements may include one or more user-selectable elements 304, such as different buttons on a screen or different options in a menu. The user input means is configured to allow a user 103 (in this case, Alice 103a) to select or operate one of the options by clicking or touching a UI element on the screen or by speaking the name of the desired option (Note: "manual" as used herein simply means the opposite of automatic and is not necessarily limited to the use of hands). The options allow a user (e.g., Alice) to submit data, such as part or all of a blockchain transaction, to an internet server or to generate a signature.

[0072] Alternatively or additionally, the UI element may include one or more data entry fields 305 into which a user can enter data, such as a signature or a blockchain address. These data entry fields may be rendered via a user output means, e.g., on-screen, and data may be entered into the fields via a user input means, e.g., a keyboard or touchscreen. Alternatively, data may be received verbally, e.g., based on voice recognition.

[0073] Alternatively or additionally, the UI elements may include one or more information elements 306 that are output to output information to the user, which may for example be drawn on a screen or rendered audibly.

[0074] For example, this / these may be rendered on the screen or audibly rendered. The functionality of these UI elements will be discussed in more detail shortly. It is also understood that the UI 300 shown in FIG. 3B is merely a schematic mockup and may in fact include one or more additional UI elements, which are not shown for the sake of brevity.

[0075] Connecting to Blockchain Networks FIG. 4 illustrates an exemplary system 400 for implementing an embodiment of the present invention. The system includes an internet server 401, a first party 402a, and a blockchain network 106 or at least one or more nodes 104 of the blockchain network 106. The system may also include a second party 402b. Each of the first and second parties 402a, 402b may play the role of Alice 103a or Bob 103b as described with reference to FIG. 1. That is, the first party 402a may include a respective computing device 102a and operate a client application 105a configured to perform some or all of the actions related to Alice 103a. Similarly, the second party 402b may include a respective computing device 102b and operate a client application 105b configured to perform some or all of the actions related to Bob 103b. Note that the first party 402a may perform some or all of the actions related to Bob 103b, and vice versa.

[0076] The internet server 401 includes processing equipment including one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or other devices such as field programmable gate arrays (FPGAs) and application-specific integrated circuits (ASICs). The internet server 401 also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may include one or more memory units using one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory or EEPROMs, and / or optical media such as optical disk drives. The memory on the internet server 401 may store software configured to execute on the processing equipment. The software may be initially provided to the Internet server 401 on one or more suitable computer-readable storage media, for example downloaded from a server, or on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk, for example a CD or DVD ROM, or removable optical drive.

[0077] Internet servers themselves are well known, so their general functions will not be described in detail here. Generally, Internet servers 401 may take any of the following forms: database server, mail server, web server, game server, or application server. Internet servers 401 may alternatively take other forms. A database server is a server that uses database applications to provide database services to other computer programs or computers. A web server is a server configured to fulfill client requests on the World Wide Web. Web servers typically host one or more websites and handle incoming network requests via HTTP and several other related protocols. An application server typically provides both the facilities for generating web applications and the server environment in which they run. A game server (sometimes called a host) is a server that is the official event source in a multiplayer video game. Servers transmit enough data about their internal state to allow connected clients to maintain an accurate version of their own game world for display to players. They also receive and process each player's input.

[0078] Internet server 401 is configured to host (i.e., serve) Internet services to clients connected to it. The type of Internet service hosted by Internet server 401 depends on the type of Internet server 401. If Internet server 401 is a web server, the Internet service is a website, while if Internet server 401 is a mail server, the Internet service is a mailbox. Similarly, a game server hosts Internet services in the form of online video games, a database server hosts Internet services in the form of online databases, and an application server hosts Internet services in the form of applications that run using the Internet.

[0079] Instead of directly connecting to one or more blockchain nodes 104 to submit a blockchain transaction to the blockchain network, the first party 402a (i.e., the client application 105a operated by the first party 402a) is configured to connect to the internet server 401 via an internet service hosted by the internet server 401. The first party 402a, again via the internet service, provides one or more components of the blockchain transaction to the internet server 401. That is, the first party 402a transmits at least a portion of the blockchain transaction to the internet server 401 via the internet service. In some examples, the first party 402a provides a complete blockchain transaction. In other examples, the first party 402a transmits one or more inputs and / or one or more outputs of the blockchain transaction to complete a transaction template. Note that transmitting an input or an output may be considered to mean transmitting input data (e.g., an unlock script or a portion of the unlock script) or output data (e.g., a lock script or a portion of the lock script). For example, the first party 402a may send a signature generated using a private key owned by the first party 402a to the internet server 401. As another example, the first party 402a may provide a public key or public key hash that may be linked to the first party 402a or the second party 402b.

[0080] The internet service hosted by internet server 401 may include one or more data entry fields (i.e., input fields) for entering data. The first party 402a may use the data entry fields to enter transaction data, such as a signature, a public key, a transaction identifier, a transaction outpoint, etc. Similarly, the internet service may include one or more functions for generating transaction data, such as a signature or a public key hash.

[0081] Note that preferably, the first party 402a has a secure communication channel with the internet server 401 and / or the first party 402a uses one or more cryptographic techniques to protect security and / or privacy, as discussed below.

[0082] The internet server 401 is configured to obtain one or more transaction components and send a transaction including these components to one or more blockchain nodes 104. When the first party 402a provides a complete transaction, the internet server 401 forwards the transaction to the blockchain node 104. Alternatively, the internet server 401 may generate a transaction based on the transaction components, for example by inputting the components, i.e., data, into a transaction template.

[0083] 5 illustrates an example flow of a transaction from a first party 402a through an internet server 401 to a blockchain network. As shown, in reality, there may be many different parties 402 (e.g., users) served by multiple internet servers 401. Any given internet server 401 may serve a single party 402 or multiple parties 402. Similarly, an internet server 401 may be connected to only one blockchain node 104 or to multiple blockchain nodes 104.

[0084] The internet server 401 may maintain a permanent connection to the blockchain network 106 via one or more respective connections to each blockchain node 104. Alternatively, the internet server 401 may periodically connect to one or more blockchain nodes 104, or the internet server 401 may connect on an ad-hoc basis.

[0085] Internet server 401 may maintain connections to a minimum number of blockchain nodes. For example, if the number of connections falls below a predetermined minimum, internet server 401 may connect to one or more additional nodes to bring the number of connections back up to at least the predetermined minimum.

[0086] In contrast to this, the first party 402a does not need to have a permanent connection to the internet server 401, but instead can connect to the internet server 401 on an ad-hoc basis via an internet service, for example when using the internet service, although the possibility that the first party 402a is permanently connected to the internet server 401 via the internet service is not excluded.

[0087] In embodiments in which system 400 includes second party 402b, second party 402b can send a request message to first party 402a. The request message can be sent directly to first party 402a, for example, via side channel 107. Alternatively, the request message can be sent via internet server 401. That is, second party 402a can use an internet service hosted by internet server 401 to send the request message to internet server 401, and the internet server can use the internet service to submit the request message to first party 402a. As an illustrative example, the request message can be entered and submitted using a website (e.g., a social media site) hosted by web server 401.

[0088] The request message can include a request to allocate a number of digital assets owned by the first party 402a to the second party 402b, e.g., in exchange for goods or services. Additionally or alternatively, the request message can include one or more components of a blockchain transaction. For example, the request message can include a lock script that includes a public key (or a hash thereof) linked to the second party 402b.

[0089] In response to receiving the request message, the first party 402a can send the blockchain transaction (or at least one or more components of the blockchain transaction) to the internet server 401. By way of example, the second party 402b can send a blockchain address to the first party 402a (e.g., via the internet server 401), and the first party 402a can send a signature to unlock the UTXO to the internet server 401. The internet server 401 can then formulate a transaction for sending to the blockchain network 106 based on these components.

[0090] It should be noted that the first party 402a may perform any action associated with the request message described as being performed by the second party 402b, with any necessary adaptations, i.e., the first party 402a may send a request message to the second party 402b to allocate an amount of digital assets to a blockchain address linked to the first party 402a.

[0091] In some embodiments, after first party 402a transmits a blockchain transaction (or a component thereof) to internet server 401, internet server 401 may send an update message to first party 402a after internet server 401 later transmits the blockchain transaction to blockchain network 106. The update message is presented to first party 402a via an internet service.

[0092] Generally, an update message includes information about a transaction that has been sent and submitted to the blockchain network 106. The update message may include a copy of the transaction itself, i.e., the transaction including the components provided by the first party 402a and submitted to the network 106. The update message may additionally or alternatively include a message including an indication that the transaction was successfully published in the blockchain 150. The indication may include the block header of the block 151 in which the transaction is included. In some examples, the update message may include a Merkle path to verify that the transaction is included in the block 151. The Merkle path includes a hash of the transaction as well as a set of hashes used to calculate the Merkle root of the Merkle tree. If the Merkle root generated using the Merkle path and the hash of the transaction corresponds to the block header of the block 151 in the blockchain 150, the first party 402a can verify that the transaction was included in that block 151.

[0093] As another optional feature, the internet server 401 can be configured to maintain a list of contacts (i.e., other parties 402) associated with the first party 402a. For each contact, the internet server 401 can also record one or more blockchain addresses (e.g., public keys or public key hashes) linked to, i.e., owned by, that contact. The internet server 401 can forward the list of contacts and / or blockchain addresses to the first party 402a via an internet service. The first party 402a can use this information to connect to the first party's contacts. In this sense, connecting with a contact may include assigning a digital asset owned by the first party 402a to one of the contacts (e.g., the second party 402b).

[0094] As mentioned above, the internet server 401 may be a web server hosting a web service, e.g., a website. That is, the web server 401 may provide one or more web pages to the first party 402a. Preferably, the first party 402a (i.e., a client application operated by the first party 402a) and the web server 401 communicate using the Hypertext Transfer Protocol (HTTP). For example, a transaction (or a component thereof) may be sent to the web server 401 using HTTP. Similarly, request messages may be sent to / received from the web server 401 using HTTP. Update messages may also be sent from the web server 401 to the first party 402a using HTTP. While HTTP is preferred, it is not excluded to send data between the first party 402a and the web server using alternative protocols, such as Simple Mail Transfer Protocol (SMTP) or File Transfer Protocol (FTP).

[0095] Alternatively, the internet server 401 may be a mail server hosting a mail service, e.g., an email application. From the perspective of the first party 402a, the mail server may be an incoming mail server and / or an outgoing mail server. The first party 402a and the mail server may communicate using either a Simple Mail Transfer Protocol (SMTP) for outgoing messages and a Post Office Protocol (POP), e.g., POP3, or an Internet Message Access Protocol (IMAP), for incoming messages.

[0096] A website or email application may include built-in functionality configured to transmit blockchain transactions or components thereof to a web server or mail server, respectively. For example, an existing email application may be modified to include data entry fields or "buttons" configured to receive and / or generate transaction data. Websites (e.g., social media sites or other types of web pages) may also include similarly configured functionality.

[0097] The following provides further details regarding web and mail servers configured to implement embodiments of the present invention.

[0098] Internet server 401 may be a Web 2.0 server. Web 2.0 stands for the second generation of the World Wide Web. Web 2.0 provides an interactive and dynamic web experience for users to share information online through social media, blogs, and other web-based communities. While the back-end infrastructure of the web remains the same, the front-end has been enhanced with web browser technologies supported, for example, by AJAX and JavaScript frameworks, to support new user information flows and dynamic content that responds to user input.

[0099] Web 2.0 servers (and web servers in general) may be used to propagate transactions to blockchain nodes 104 on the blockchain network 106. A user 402a may operate a browser-based client application, which may operate a simplified payment verification (SPV) method. The application may appear as a browser extension on a Web 2.0 platform, such as a social media site. A user may create a transaction using the application API. The application then propagates the transaction to one or more blockchain nodes 104 via one or more Web 2.0 servers. These blockchain nodes may validate the transaction and send an update back to the client application, for example, via the Web 2.0 server. Figure 5 illustrates this process schematically.

[0100] SPV client applications may utilize the present invention because they require a high level of connectivity. Such applications may also require a high level of security because sensitive data is included in transactions published on the blockchain 150. As such, data submitted to the web server may be encrypted by the user 402a or by the web service.

[0101] Connecting to the blockchain network 106 using a web server may also be used to bootstrap new users during network discovery. URL Flux-based Command and Control (UFCC) is a centralized architecture for communication using Web 2.0 services. UFCC manages the peer list in the network via web links to active peers. The links are typically uploaded to a common Web 2.0 service that promises 24-hour online availability. For SPV client applications, a UFCC communication system can be implemented to connect with other online peers (i.e., peers operating respective instances of SPV client applications) during the bootstrap procedure.

[0102] A blockchain node 104 can use a similar bootstrapping process to discover other blockchain nodes 104 when joining the blockchain network 106. For example, the blockchain node 104 can download a list of other blockchain nodes 104 (such as a list of contacts on a social media account) to learn which blockchain nodes 104 are active (e.g., "online") in the blockchain network 106 in order to broadcast transactions to the online nodes 104. This list may be maintained by an internet server 401, which may transmit the list to the node 104 upon request, for example. The list may include a list of identifiers (e.g., network addresses, public keys, etc.), each associated with a different node 104.

[0103] The internet server may be a mail server. A mail server may be used to provide client applications similar to email accounts. The mail server aggregates UTXOs by monitoring the addresses (e.g., public keys or public key hashes) of users 402 (account holders) and stores the account information on the mail server. This information may be presented to users when they access their accounts.

[0104] A mail server may be non-custodial, i.e., the server does not store digital keys on behalf of the first party 402a. The server 401 may file know-your-customer (KYC) information that proves the identity of the account holder (first party 402a). This information may be stored on-chain or off-chain. For example, the server 401 may store a pointer to the location of a digital identity certificate embedded in the blockchain transaction. The server 401 monitors the associated transaction ID in the UTXO set to ensure that the user's authenticated key is up-to-date, i.e., the digital certificate has not expired. The server 401 may submit a transaction to the blockchain 150 only if the user's authenticated key has not expired. Note that this is applicable to other types of Internet servers 401 as well.

[0105] As mentioned above, cryptographic techniques may be used to ensure user security and / or privacy are maintained as transactions propagate through the internet server 401. For example, the first party 402a may implement digital key management to rotate unique digital key pairs used to sign individual transactions. For example, the same key is not used multiple times to sign a transaction. Similarly, the second party 402b (e.g., a merchant) may ensure compliance with know-your-customer (KYC) and / or anti-money laundering (AML) regulations by requiring the first party 402a to sign transactions with an authenticated key. Because it is desirable for digital key pairs to be used only once, a hierarchical decision key derived from an authenticated root key may be used to cryptographically link a user's digital key pair to an authenticated identity. See, for example, GB 1913704.1. This method can also be combined with a secret value derivation method to create a private link between the sender and the receiver by embedding a shared secret in the key derivation path (see, for example, WO / 2017 / 145016). As another example, additional measures can be taken to protect a user's private key, which is linked to a larger fund. A user can partially sign a transaction with a digital signature derived from a share of their private key. A threshold number of signatures must be reached to broadcast the complete transaction. Note that a perfect private key (the combination of all key shares) does not exist; that is, it cannot be stolen from a user's web wallet by a malicious agent. Those skilled in the art are familiar with threshold signature schemes. Finally, the first party 402a can use an encrypted browser, which can encrypt traffic using TLS client / server key encryption according to the HTTPS communication protocol. This could be an SSL server certificate and an SSL client certificate from the web wallet issuer based on both the user's and the server's Elliptic Curve Digital Signature Algorithm (ECDSA) keys.

[0106] Figures 6 and 7 illustrate exemplary use cases of the present invention. Figure 6 illustrates a merchant (second party 402b) using blockchain 150 to sell a product to a user (first party 402a). Figure 7 illustrates a merchant using blockchain 150 to receive a product refund request from a user. It is understood that this example is for illustrative purposes only, and that the technology may be more generally applicable to other use cases. That is, embodiments of the present invention are not limited to customer-merchant type interactions.

[0107] The sequence shown in FIG. 6 is as follows. It will be understood that some steps are optional. In step 1, merchant 402b sends a payment request to internet server 401. The payment request may include a request for an amount of digital assets. The payment request may include a locking script, or a portion of a locking script, for locking the amount of digital assets to a blockchain address associated with merchant 402b. Note that if internet server 401 is operated by a trusted third party and / or a secure communication channel is used, the payment request preferably includes only a portion of the locking script, rather than the complete locking script. In step 2, internet server 401 stores the request to send to customer 402a when the customer comes online, for example, when accessing a web service or email application. In step 3, customer 402a comes online, and internet server 401 sends a request to customer 402a. In step 4, customer 402a responds to the request. Customer 402a can reject the request and therefore send a rejection message back to internet server 401, which forwards it to merchant 402b. Alternatively, as shown in Figure 6, customer 402a may accept the request, which may involve the customer sending a signature back to internet server 401, such as a signature to unlock a UTXO of a previous transaction.

[0108] Internet server 401 can then take any of several options, two of which are shown. In one example, in step 5a, internet server 401 submits the signed transaction directly to blockchain network 106. For example, internet server 401 can complete a transaction template using the data included in the payment request and a signature from customer 402a. In steps 6a and 7a, internet server 401 sends updates to merchant 402b and customer 402a, respectively. The updates can include a Merkle path to verify that the transaction is included in block 151 or other data related to the transaction.

[0109] In another example, in step 5b, the internet server 401 sends the signed transaction to the merchant 402b. In step 6b, the merchant can check and complete, e.g., sign, the transaction before sending it to the internet server 401. Alternatively, the merchant can submit the transaction to the blockchain network 106 if it is directly connected to the node 104. In step 7b, the internet server 401 sends the transaction to the blockchain network 106. In steps 8b and 9b, the internet server 401 sends updates to the merchant 402b and the customer 402a, respectively.

[0110] The sequence shown in FIG. 7 is as follows. It will be understood that some steps are optional. The steps in FIG. 7 are similar to those in FIG. 6. In step 1, customer 402a sends a refund request to internet server 401. The refund request may include a request for an amount of digital assets. The refund request may include a locking script, or a portion of a locking script, for locking the amount of digital assets to a blockchain address associated with customer 402a. As in the case of a payment request, if internet server 401 is operated by a trusted third party and / or a secure communication channel is used, the refund request preferably includes only a portion of the locking script rather than the complete locking script. In step 2, internet server 401 stores the request to send to merchant 402a when the merchant comes online, e.g., accesses a web service or email application. In step 3, merchant 402b comes online, and internet server 401 sends a request to merchant 402b. Internet server 401 may send the customer's authenticated key as proof that merchant 402b will accept the request. In step 4, merchant 402b responds to the request. Merchant 402b can reject the request by sending a rejection message back to internet server 401, which forwards it to customer 402a. Alternatively, merchant 402a can accept the request, as shown in FIG. 7. This may involve merchant 402b sending a signature back to internet server 401, such as a signature to unlock a UTXO of a previous transaction. Internet server 401 may store the complete transaction and Merkle path if sent by merchant 402b. Alternatively, merchant 402b may download the input transaction and look up the Merkle path. In step 5, internet server 401 submits the signed transaction directly to blockchain network 106.For example, internet server 401 can complete the transaction template using the data included in the refund request and the signature from merchant 402b. In steps 6 and 7, internet server 401 sends updates to merchant 402b and customer 402a, respectively. The updates can include a Merkle pass to verify that the transaction is included in block 151 or other data related to the transaction.

[0111] In summary, existing web and mail server infrastructure can be used to increase connectivity for users (and other parties) 402 to the blockchain network 106. Blockchain transactions may be broadcast to blockchain nodes 104 via web servers (e.g., Web 2.0 servers). Network discovery can be improved during the bootstrapping procedure of new users to active peers that are also connected to web or email services. The present invention is particularly advantageous for light-client applications using SPV methods that require high levels of network connectivity. Because light clients do not require access to the entire blockchain, transactions can be propagated via web or email services. Due to their typically large user bases and 24-hour online availability, Web 2.0 services (and other Internet services) are very effective in facilitating transaction propagation for blockchain client applications. In addition to HTTP-based applications, transactions can be propagated using mail servers similar to email accounts using the SMTP and IMAP / POP protocols.

[0112] <Conclusion> Other variations or uses of the disclosed technology may become apparent to those skilled in the art after reading the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

[0113] For example, some embodiments described above have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it is understood that the Bitcoin blockchain is one particular example of a blockchain 150, and the above description may apply generally to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 above may be replaced with the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchain, blockchain network, and / or blockchain nodes may share some or all of the above-described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104.

[0114] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the above-mentioned functions of generating, publishing, propagating, and storing blocks 151 in the blockchain 150. It is not excluded that there are other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, a network entity may perform the functions of propagating and / or storing blocks, but may not generate and publish blocks (recall that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0115] In non-preferred embodiments of the present invention, blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of generating, publishing, propagating, and storing blocks 151 of blockchain 150. For example, in these other blockchain networks, "node" may be used to refer to a network entity that is configured to generate and publish blocks 151 but does not store and / or propagate the blocks 151 to other nodes.

[0116] More generally, references above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element." Such entities / elements are configured to perform some or all of the roles of generating, publishing, propagating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above with reference to blockchain nodes 104.

[0117] It will be appreciated that the above embodiments have been described by way of example only. More generally, a method, apparatus or program may be provided in accordance with any one or more of the following:

[0118] (Statement 1) 1. A computer-implemented method for transmitting a blockchain transaction to a blockchain network, the method being performed by a first party and comprising: 1. A method comprising: transmitting at least a portion of a blockchain transaction to an internet server via an internet service hosted by the internet server, the internet server coupled to one or more nodes of the blockchain network and configured to transmit blockchain transactions to the one or more nodes of the blockchain, the transmitted blockchain transaction comprising the at least a portion of the blockchain transaction.

[0119] (Statement 2) The method according to statement 1, wherein the Internet server is a Web server and the Internet service is a Web service.

[0120] (Statement 3) The method described in statement 2, wherein the at least a portion of the blockchain transaction is transmitted to the web server using Hypertext Transfer Protocol (HTTP).

[0121] (Statement 4) The method of statement 1, wherein the Internet server is a mail server and the Internet service is a mail service.

[0122] (Statement 5) The method described in statement 4, wherein the at least part of the blockchain transaction is sent to the mail server using Simple Mail Transfer Protocol (SMTP).

[0123] (Statement 6) the internet service includes an input field for entering data; A method according to any one of statements 1 to 5, wherein the method includes a step of inputting the at least part of the blockchain transaction via the input field.

[0124] (Statement 7) A method according to any one of statements 1 to 6, comprising the step of generating said at least part of said blockchain transaction.

[0125] (Statement 8) A method according to any of statements 1 to 6, wherein at least a portion of the blockchain transaction is generated by a second party.

[0126] (Statement 9) A method according to any one of statements 1 to 8, wherein the at least part of the blockchain transaction includes respective digital signatures generated by the first party and / or the second party.

[0127] (Statement 10) 10. The method of any of statements 1 to 9, wherein said at least part of said blockchain transaction is a complete blockchain transaction.

[0128] (Statement 11) receiving a request message from the internet server via the internet service, wherein the sending of the at least part of the blockchain transaction is in response to receiving the request message, the request message comprising: a request to allocate unspent transaction outputs of a previous blockchain transaction to the second party, the request originating from the second party; and / or the at least a portion of the blockchain transaction generated by the second party; The method according to any one of statements 1 to 10, including:

[0129] (Statement 12) sending a request message to the internet server via the internet service, wherein the sending of the at least portion of the blockchain transaction is in response to receiving a response to the request message, the request message comprising: a request to allocate unspent transaction outputs of a previous blockchain transaction to the first party, the request originating from the first party; and / or the at least a portion of the blockchain transaction generated by the first party; The method according to any one of statements 1 to 10, including:

[0130] (Statement 13) receiving an update message from the Internet server via the Internet service, the update message comprising: the blockchain transaction; an indication that the blockchain transaction has been published in a block on the blockchain; and / or a Merkle pass to verify that the blockchain transaction is included in the block of the blockchain; A method according to any one of statements 1 to 12, including at least one of:

[0131] Request messages can be sent and received using HTTP. Update messages can be received using HTTP. Request or update messages can be received using either the Post Office Protocol (POP) or the Internet Message Access Protocol (IMAP). Request messages can be sent and received using SMTP.

[0132] (Statement 14) 14. The method of any of statements 1-13, comprising receiving a list of contracts associated with the first party from the internet server via the internet service, wherein for each contract in the list, the list includes one or more blockchain addresses associated with the contract.

[0133] (Statement 15) 15. The method of statement 14, wherein the output of the blockchain transaction is locked to a blockchain address associated with one of the contracts.

[0134] (Statement 16) 1. A computer-implemented method for transmitting a blockchain transaction to a blockchain network, the method being performed by an internet server configured to couple to one or more blockchain nodes; receiving at least a portion of a blockchain transaction from a first party via an internet service hosted by an internet server; transmitting a blockchain transaction to the one or more blockchain nodes, the blockchain transaction including the at least part of the blockchain transaction; A method comprising:

[0135] (Statement 17) 17. The method of statement 16, wherein the Internet server is a Web server and the Internet service is a Web service.

[0136] (Statement 18) 18. The method described in statement 17, wherein the at least a portion of the blockchain transaction is received from the first party using Hypertext Transfer Protocol (HTTP).

[0137] (Statement 19) 17. The method of statement 16, wherein the Internet server is a mail server and the Internet service is a mail service.

[0138] (Statement 20) 19. The method of claim 19, wherein the at least a portion of the blockchain transaction is received from the first party using Simple Mail Transfer Protocol (SMTP).

[0139] (Statement 21) A method according to any of statements 16 to 20, comprising generating the blockchain transaction using said at least part of said blockchain transaction.

[0140] (Statement 22) receiving a request message from a second party via the Internet service; sending the request message to the first party via the Internet service; the request message includes: a request to allocate unspent transaction outputs of a previous blockchain transaction to said second party; and / or the at least a portion of the blockchain transaction generated by the second party; The method according to any one of statements 1 to 21, including:

[0141] (Statement 23) sending an update message to the first party via the Internet service, the update message comprising: the blockchain transaction; an indication that the blockchain transaction has been published in a block on the blockchain; and / or a Merkle pass to verify that the blockchain transaction is included in the block of the blockchain; A method according to any one of statements 1 to 22, including at least one of:

[0142] (Statement 24) The method of statement 22 dependent on statement 17, wherein the request message is sent using HTTP.

[0143] (Statement 25) The method of statement 23 dependent on statement 17, wherein the update message is transmitted using HTTP.

[0144] (Statement 26) The method according to statement 22 dependent on statement 19, wherein the request message is sent using SMTP.

[0145] (Statement 27) The method of statement 23 dependent on statement 19, wherein the update message is sent using SMTP.

[0146] (Statement 28) maintaining a list of contracts associated with the first party, the list of contracts including, for each contract, one or more blockchain addresses associated with the contract; sending the list of contracts to the first party; 28. The method according to any one of statements 16 to 27, including:

[0147] (Statement 29) 1. A computer-implemented method for discovering one or more blockchain nodes of a blockchain network, wherein an internet server maintains a list of identifiers, each identifier associated with a respective blockchain node, the method comprising: obtaining one or more identifiers from the internet server, each identifier associated with a respective blockchain node; using the one or more identifiers obtained to bind to the associated one or more blockchain nodes; A method comprising:

[0148] (Statement 30) 30. The method of claim 29, wherein the method is performed by another blockchain node other than the one or more blockchain nodes.

[0149] (Statement 31) A computer device comprising: a memory including one or more memory units; a processing device including one or more processing units; Including, A computing device, wherein the memory stores code configured to execute on the processing device, the code configured to execute the method described in any of statements 1 to 30 when executed on the processing device.

[0150] (Statement 32) A computer program embodied on a computer-readable storage device and configured to perform the method according to any one of statements 1 to 30 when executed on a computing device.

[0151] According to another aspect disclosed herein, there may be provided a method including operations of the first party and the internet server.

[0152] According to another aspect disclosed herein, there may be provided a system including computer equipment of the first party and the internet server.

Claims

1. 1. A computer-implemented method for transmitting a blockchain transaction to a blockchain network, the method being performed by a first party and comprising: transmitting at least a portion of a blockchain transaction to an internet server via an internet service hosted by the internet server, the internet server coupled to one or more nodes of the blockchain network and configured to transmit blockchain transactions to the one or more nodes of the blockchain, the transmitted blockchain transaction including the at least a portion of the blockchain transaction; receiving a list of contacts associated with the first party from the internet server via the internet service, wherein for each contact in the list, the list includes one or more blockchain addresses associated with the contact; A method comprising:

2. The method of claim 1 , wherein the Internet server is a Web server and the Internet service is a Web service.

3. 3. The method of claim 2, wherein the at least a portion of the blockchain transaction is transmitted to the web server using Hypertext Transfer Protocol (HTTP).

4. 2. The method of claim 1, wherein the Internet server is a mail server and the Internet service is a mail service.

5. 5. The method of claim 4, wherein the at least part of the blockchain transaction is sent to the mail server using Simple Mail Transfer Protocol (SMTP).

6. the internet service includes an input field for entering data; The method according to any one of claims 1 to 5, further comprising the step of inputting the at least part of the blockchain transaction via the input field.

7. The method of any of claims 1 to 6, comprising generating the at least part of the blockchain transaction.

8. The method of any of claims 1 to 6, wherein the at least part of the blockchain transaction is generated by a second party.

9. 9. The method of claim 8, wherein the at least part of the blockchain transaction includes respective digital signatures generated by the first party and / or the second party.

10. The method of any of claims 1 to 9, wherein the at least part of the blockchain transaction is a complete blockchain transaction.

11. receiving a request message from the internet server via the internet service, wherein transmitting the at least part of the blockchain transaction is in response to receiving the request message, the request message comprising: a request to allocate unspent transaction outputs of a previous blockchain transaction to the second party, the request originating from the second party; and / or the at least a portion of the blockchain transaction generated by the second party; The method of claim 8, comprising:

12. sending a request message to the internet server via the internet service, wherein the sending of the at least portion of the blockchain transaction is in response to receiving a response to the request message, the request message comprising: a request to allocate unspent transaction outputs of a previous blockchain transaction to the first party, the request originating from the first party; and / or the at least a portion of the blockchain transaction generated by the first party; The method according to any one of claims 1 to 10, comprising:

13. receiving an update message from the internet server via the internet service, the update message comprising: the blockchain transaction; an indication that the blockchain transaction has been published in a block of the blockchain; and / or a Merkle pass to verify that the blockchain transaction is included in the block of the blockchain; The method according to any one of claims 1 to 12, comprising at least one of:

14. The method of any preceding claim, wherein an output of the blockchain transaction is locked to a blockchain address associated with one of the contacts.

15. 1. A computer-implemented method for transmitting a blockchain transaction to a blockchain network, the method being performed by an internet server configured to couple to one or more blockchain nodes; receiving at least a portion of a blockchain transaction from a first party via an internet service hosted by the internet server; transmitting a blockchain transaction to the one or more blockchain nodes, the blockchain transaction including the at least part of the blockchain transaction; maintaining a list of contacts associated with the first party, the list of contacts including, for each contact, one or more blockchain addresses associated with the contact; sending the list of contacts to the first party; A method comprising:

16. 16. The method of claim 15, wherein the Internet server is a web server and the Internet service is a web service.

17. 17. The method of claim 16, wherein the at least a portion of the blockchain transaction is received from the first party using Hypertext Transfer Protocol (HTTP).

18. 16. The method of claim 15, wherein the Internet server is a mail server and the Internet service is a mail service.

19. 20. The method of claim 18, wherein the at least a portion of the blockchain transaction is received from the first party using Simple Mail Transfer Protocol (SMTP).

20. 20. The method of any of claims 15 to 19, comprising generating the blockchain transaction using the at least part of the blockchain transaction.

21. receiving a request message from a second party via the Internet service; sending the request message to the first party via the Internet service; the request message includes: a request to allocate unspent transaction outputs of a previous blockchain transaction to the second party; and / or the at least a portion of the blockchain transaction generated by the second party; The method according to any one of claims 15 to 20, comprising:

22. sending an update message to the first party via the Internet service, the update message comprising: the blockchain transaction; an indication that the blockchain transaction has been published in a blockchain block; and / or a Merkle pass to verify that the blockchain transaction is included in the block of the blockchain; The method according to any one of claims 15 to 21, comprising at least one of:

23. 22. The method of claim 21 dependent on claim 16, wherein the request message is sent using HTTP.

24. 23. The method of claim 22 dependent on claim 16, wherein the update message is transmitted using HTTP.

25. 22. A method according to claim 21 dependent on claim 18, wherein the request message is sent using SMTP.

26. 23. A method according to claim 22 when dependent on claim 18, wherein the update message is sent using SMTP.

27. A computer device comprising: a memory including one or more memory units; a processing device including one or more processing units; Including, A computing device, wherein the memory stores code configured to run on the processing device, the code being configured to perform a method according to any one of claims 1 to 26 when executed on the processing device.

28. A computer program embodied on a computer readable storage device and arranged to perform the method of any of claims 1 to 26 when run on a computing device according to claim 27.

Images