COMPUTER-IMPLEMENTED METHODS AND SYSTEMS FOR IMPROVED COMMUNICATIONS ACROSS A BLOCKCHAIN NETWORK

TECHNICAL FIELD

Embodiments disclosed herein relate to improvements for transmission of data e.g. packets of data across a computer-implemented network. Embodiments are particularly suited for, but not limited to, transmission of blockchain-related data and communications between parties wishing to receive, process, respond to and/or store such data/communications. In particular, examples relate to enhanced solutions for sending and receiving electronic communications such as messages, alerts, notifications, updates and/or other content to interested, associated or relevant parties.

BACKGROUND

Devices on the Internet are assigned a unique identifier (address) that allows them to be identified and located on the network by other devices. The initial IP protocol was built with the expectation that the number of IP addresses that could be generated from the 32bit length address block would be sufficient to uniquely identify all of the devices that would connect to the Internet. However, neither the enormous private and commercial appeal of the Internet, nor the variety and quantity of devices that would seek to connect to it, was conceivable when the initial IP protocol was designed. As a result, it became evident over time with the growth in personal computing and mobile computation technology that the 4.3 billion addresses that are possible with IPv4 was insufficient.

While the threat of exhaustion of IPv4 addresses led to some creative ways of mitigating the limited set (e.g., Classless Inter-Domain Routing (CIDR), Unnumbered interface, and network address translation), these measures were not sufficient to address the issue. The advent of Internet of Things (loT) exacerbated the limitations of IPv4 even further in the near and long term.

Due to these challenges, IPv6 was proposed as a replacement for the IPv4 address standard. Central to IPv6 was its use of a 128bit address which can theoretically produce 3.4 x 10 ³⁸ addresses. While several ranges of the key space are pre-designated for specific purposes, the remaining address space is large enough to meet current and future needs of each resource that connects to the Internet having its own unique IPv6 address. Although the most significant advantage of IPv6 is that of a larger address space, there are several other advantages that IPv6 is expected to provide. These include the IPv6 approach toward multicasting and anycasting. Multicasting, which enables the transmission of a data packet to multiple destinations in a single send operation, is native to the base specification of IPv6. For IPv6, packets are sent to a multicast group address; the packets are then sent on to the members of the group. On the other hand, an IPv6 anycast transmission enables a source resource to send a data packet to a group address but only one recipient of the group (the topologically closest to the sender) receives the transmitted data.

The group subscription model of multicasting and its incorporation in IPv6 protocol leads to greater efficiencies in transmission of data packets across the Internet and less network congestion in comparison with other ways of transmitting/casting packets such as unicasting and broadcasting. Unicasting is a one-to-one connection where a packet is sent from one IP address to another. Broadcasting is a one-to-all transmission where a packet is sent to all addresses/nodes in the network. Thus, the use of multicasting in IPv6 provides a more efficient and scalable solution for transmitting data over the Internet.

Beyond just the Internet, the need for efficient transfer of data transmission is also critical for other networks. For example, scalability is a significant technical challenge for many distributed ledgers given the limited maximum size of blocks that they utilise (e.g., BTC's 1MB block limitation). As such protocols require that more, smaller blocks be propagated through the network, the network becomes congested and slows down. Transactions take longer to be mined and confirmed. Network performance is degraded and the system's impaired functionality results in the BTC ledger being impractical for use with applications that require fast processing capabilities.

On the other hand, the Bitcoin SV protocol allows the use of larger blocks (currently 4GB and are progressing towards terabyte blocks). The technical challenge arises of how to distribute these larger blocks across the nodes in the ledger's network of nodes in a swift, secure and efficient way. Therefore, in respect of blockchain-related applications, there is a need for technical solutions which provide improved blockchain networks, greater efficiencies in terms of time, processing resources and network performance.

A further challenge resides in the controlled and/or managed transmission of packets of data across a network in a contractual manner, whether it be a one-to-one or one-to-many exchange. Known publisher-subscriber exchanges are inefficient and/or difficult to scale. A solution has now been devised which addresses at least these and other technical problems.

TERMINOLOGY

As known in the prior art, the term "node" can mean a basic unit of a data structure (in Computer Science), or a point of connection in a communication network (networking/telecoms), an entity in a mesh network, or a computing resource that runs an implementation of a blockchain protocol e.g. a miner on the Bitcoin network. Alongside these, a device or system on a network can also be called a "host" or "peer", depending on the context. In relation to the present disclosure there is, therefore, a potential for confusion between the various terms given that certain embodiments may encompass or intersect across various technical fields.

Therefore, to avoid confusion and for the sake of clarity, we will use the umbrella term "network resource" "processing resource", "computer-based resource" or simply "resource" to include "node", "peer" or "host", or any device/system on a network. Herein, we prefer to use the term "node" as typically meaning (but not necessarily limited to) a node on a blockchain network e.g. a miner.

Also, we may refer herein to the Bitcoin protocol/network/ledger for the sake of convenience and because it is the most widely known of such technologies. However, the disclosure is not limited to use with Bitcoin and other ledger-based protocols/networks are intended to fall within the scope of the disclosure. For example, blockchain protocols, networks and implementations that comprise a Proof-of-Stake mechanism, or utilise an account-based model rather than UTXO-based, fall within the scope of the present disclosure. It should also be noted that "Bitcoin" is not limited to meaning any particular Bitcoin-related protocol, and any protocol or implementation flowing from, varying from or deviating from the original Bitcoin protocol is intended to fall within the scope of the disclosure. Public, private or permissioned blockchains also fall within the scope of the present disclosure.

The term "blockchain-related data" as used herein includes, but is not limited to, any data which is used, transmitted, received, stored or otherwise processed in respect of an operation, functionality or service performed in respect of, or for the purpose of implementing, a blockchain protocol or blockchain-based application.

SUMMARY Embodiments of the disclosure provide solutions for the transmission of data across a computer- based network. Preferably:

• the solutions comprise the use of IPv6; and/or

• the data is blockchain related data but is not limited for use only with regard to blockchains and blockchain related data; and/or

• the network is a distributed network such as, for example, a ledger (blockchain) network, or any Peer-to-Peer (P2P) network.

In an example embodiment of the disclosure, computer-based resources may be associated to form one or more multicast groups, each group having its own, respective multicast address. A multicast group address is a logical, collective identifier for the resources in the group so that they can all receive data packets from sending nodes via multicast communications. In some embodiments, the address is an IPv6 multicast address, and the data is sent and received over the internet.

In one particularly advantageous example, the disclosure can be used to send data from a sending resource to a multicast group of receiving resources, and the data relates to at least part of blockchain block and/or blockchain transaction. In such an example, the sending resource only has to send the data once for all intended recipients to receive a copy, rather than sending multiple times to each individual recipient as per unicast.

In one or more embodiments, the group of receiving resources may form an overlay network. The overlay network may be an overlay relative to a blockchain network that is associated with a given blockchain protocol. The blockchain network may comprise full blockchain nodes, each of which run a client in accordance with the protocol, and which perform at least one of: mining, validation, consensus and blockchain maintenance functions in accordance with and specified by the blockchain protocol. In some embodiments, a full node may comprise a mempool for storage of transactions prior to them being written to the blockchain ledger, as described below and known in the art. Additionally, or alternatively, the full blockchain node may be substantially as described below and in reference to accompanying Figures 1 to 4 as blockchain node 104. In one or more embodiments, one some or all of the receiving resources are not full nodes on the blockchain network. In one or more embodiments disclosed herein, one some or all of the receiving resources may be operative to perform a subset of the protocol-specified functions that the full blockchain nodes run. The receiving resources in each group can be of various types, forms, configurations or purpose, and the sending resource may be a member of the group or external to it. The disclosure is not intended to be limited as to the type or nature of the data being sent, or the purpose for which it is sent. In one or more embodiments, however, one, some or all of the sending and/or receiving nodes in a group may be full nodes on a blockchain network, or nodes on an overlay network, and the data may comprise data relating to unconfirmed transactions that have been verified but not yet written to the blockchain ledger. In such an embodiment, systems and methods may be provided for implementing a mempool in or associated with a blockchain network or an overlay network that interacts with the blockchain network.

Advantageous applications of the disclosure can include, not least, the ability to send data to groups of computing resources which provide distributed and/or parallelised blockchain related functionalities. Such functionalities could, for example, be mining functionalities, on-chain searching functionalities, validation functionalities etc. At least one of the technical objectives of the present disclosure may be to enhance scalability of a blockchain network and/or the scalability of an overlay network that functions as an overlay on top of an (underlying) blockchain network. The underlying blockchain network may be a peer-to-peer (P2P) network 106 as described herein and with reference to Figures 1 to 4. In accordance with embodiments of the disclosure, at least one or some of the technical improvements provided may relate not just to faster or more efficient prorogation of transactions as they travel through the conventional (underlying) blockchain network, but to improved throughput of transactions or blocks or parts thereof.

Referring to Figure 5, three groups of resources 501 are shown. Multicast group "a" 502a contains five resources 501, multicast group "b" 502b contains four resources, and multicast group "c" 502c contains three resources. It should be understood that the number of resources 501 in each multicast group has no bearing on the invention. For instance, a first group may have ten resources 501, a second group one resource 501, and a third group a hundred resources 501. A multicast group 502 is a group of resources addressable via a single multicast address, as explained herein. A resource 501 that sends any type of data to another resource may be referred to herein as a sending resource, and a recipient of the data may be referred to as a receiving resource. Figure 5 illustrates each of the three multicast groups of resources communicating with one another. A communication may comprise sending one or more packets of data in a transmission. The data may be blockchain-related data but not necessarily so. The transmission may comprise data relating to a request for data from one or more recipients. Alternatively, the transmission may simply provide data to the recipients and may not comprise a request for a response. The disclosure is not limited with regard to the nature, form or type of actions performed by the recipient(s) upon receipt of the data from the sending resource. The transmission may be performed using multicast and/or anycast.

When using multicast, a resource of a multicast group, for example group 502a, may send data to the same group 502a, and/or another multicast group e.g. 502b, in the form of a single transmission to a single multicast address corresponding to or associated with multicast group 502a/502b. In this way, only one transmission is sent and only (but all) resources that are members of the receiving multicast group receive the data.

When using anycast, a resource 501 of a multicast group, for example group 502a, may transmit data by sending it to the same group 502a or another multicast group e.g. 502b in the form of a single transmission to a single anycast address corresponding to or associated with multicast group 502b. The data packet(s) are routed to a resource 501 of multicast group 502b that is determined to be the topologically closest to the sending resource. The receiving resource may then forward the data to one or more of the other resources of multicast group "b" or to any other resource(s) in one or more of the other groups, or even to any other resource that is not part of any group. In this way, only one data transmission is sent to a single recipient within a particular group but then that data can be disseminated across other members of the group via a multicast transmission. This is advantageous in situations where only one or a subset of the multicast group needs to receive the transmission in order to provide the data to the entire group. Similarly, a resource of a multicast group may send or receive data using multicast or anycast.

When using multicast, a resource of a multicast group, for example group "b", may send data, such as requested data in response to such a request, by sending the data to multicast group "a" in the form of a singular data transmission to a single multicast address corresponding to multicast group "a". In this way, only one data transmission instance is required and only the member resources of multicast group "a" receive the data. In this embodiment, the sending resource may be referred to as a "sending resource" and the member resources of multicast group "a" as "receiving resources". When using anycast, a resource of a multicast group, for example group "b", may send data, such as requested data in response to a received request, by sending the data to multicast group "a" in the form of a singular data transmission to a single anycast address corresponding to multicast group "a". The data is routed to a resource of multicast group "a" determined to be topologically closest to the resource that sent the data. The receiving resource may then forward the data to the other resources of multicast group "a". In this way, only one data transmission instance is required to have the data arrive at multicast group "a", only the member resources of multicast group "a" receive the data, and the possibility that only a subset of the multicast group needs the data is addressed.

In one example, a sending and/or receiving resource is configured for generating, storing, processing, accessing and/or maintaining a packet of data, said packet of data preferably including blockchain related data. An allocated address is determined from the packet of data , and the packet of data is transmitted, at least in part, from the resource across an electronic network to the allocated address.

Determining the allocated address can include processing the packet of data to determine a key, and selecting at least one address from a set of addresses using the key. The key can be determined by parsing the packet of data. The sending resource can hold a data structure including a set of allocated addresses associated with a corresponding set of keys.

Allocation can complement the efficient and scalable solutions for transmitting data using IPv6, as taught herein, and the propagation of at least one packet of data can be balanced by spreading-out, the transmission of packets of data within a network. Nodes and/or routers can be configured to sign-up or subscribe to one or more allocated addresses e.g. a sub-set of the plurality of multicast addresses, thus enabling the balancing of the transmission of packets of data across the resources associated with the allocated addresses. Balancing can be achieved through distribution of the propagated packets of data across a range of nodes and/or routers that selectively subscribe to allocated multicast groups and/or receive from multicast addresses. Balancing can inhibit bottlenecks in the transmission of packets of data, in particular when the packets of data are large blocks, which could result in a delay at a node or router, or when the packets of data are transactions and the volume of transactions floods the network by propagating in a universal manner. In an embodiment including sending data, a plurality of the resources of a multicast group may each send a portion of the data. In an embodiment, each resource of the plurality may send a hash of the data and/or a hash of the respective portion of the data. The hash may be sent instead of or in addition to the data itself. This distribution helps reduce congestion in the network.

In embodiments, one or more of the resources in a multicast group may be: a resource in a blockchain network, a computing resource associated with or controlled by a financial institution; a merchant; and/or a digital wallet.

In an additional or alternative embodiment, the request may comprise a request for a communication or alert relating to a blockchain-related event or activity. In an embodiment, the sent data comprises a communication or alert relating to a blockchain related event or activity. The communication or alert may relate to a double spend or double spend attempt within the blockchain network.

In embodiments, the data requested and/or sent includes: blockchain-related data, such as a blockchain transaction or part thereof; at least a part of a blockchain block; at least a part of a blockchain transaction script; at least a part of a Merkle path or Merkle proof; and/or data for use with, or associated with, a consensus mechanism of a blockchain network.

In an embodiment, a resource of a multicast group communicates with one or more of the other multicast groups via an Internet Protocol (IP) multicast address. In an embodiment, a resource of a multicast group communicates with one or more of the other multicast groups via an IPv4 multicast address. In an embodiment, a resource of a multicast group communicates with one or more of the other multicast groups via an IPv6 multicast address. In an embodiment, resources and/or groups of resources may be separated from one another such that they communicate via the Internet.

In an embodiment, each of the multicast groups comprises one or a plurality of receiving resources. In an embodiment, each receiving resource within a given group of receiving resources is operative to receive data sent to the multicast address of the given group of receiving resources.

In an embodiment, a resource subscribes to a group of receiving resources. In an embodiment, the resource subscribes by sending a signal to a network. In an embodiment, a resource leaves a group of receiving resources. In an embodiment, the resource leaves the group by ceasing to send a signal to a network.

In an embodiment, a receiving resource in the a group of receiving resources performs a functionality specified by a blockchain protocol, a calculation or other operation related to a mining or consensus function specified in a blockchain protocol, a Simplified Payment Verification (SPV) operation, a validation of a blockchain transaction before or after it has been written to a blockchain, a search of a blockchain to identify, locate and/or confirm the presence of a given transaction or block within a blockchain, generates a blockchain transaction, writes a transaction to the blockchain, and/or broadcasts a transaction to a blockchain network.

In an embodiment, each of the one or more groups may be polled for a target response by sending a portion of blockchain-related data from a sending resource to one or more groups of receiving resources.

In accordance with one or more embodiments, there may be provided a computer-implemented communication method comprising a mechanism for distributing blockchain and/or cryptocurrency- related communications such as alerts, notifications and updates across an electronic network to one or more recipients as efficiently and swiftly as possible. Preferred embodiments use IPv6 multicast to perform such improved communications. A multicast communication may comprise a code, flag or filter which enables the communication to be targeted at particular recipient(s), and allow multicast group members that have no interest or authorised access to the contents of the communication to ignore it. Thus, improvements are provided in respect of processing resources and time. In some examples, the disclosure can be advantageous for the implementation of a blockchain-related alert key or system which can aid in network responses to emergencies or threats, thus improving the security of the blockchain network.

BRIEF DESCRIPTION OF THE DRAWINGS

To assist understanding of embodiments of the present disclosure and to show how such embodiments may be put into effect, reference is made, by way of example only, to the accompanying drawings in which:

Figure 1 is a schematic block diagram of a system for implementing a blockchain. Figure 2 schematically illustrates some examples of transactions which may be recorded in a blockchain.

Figure 3A is a schematic block diagram of a client application.

Figure 3B is a schematic mock-up of an example user interface that may be presented by the client application of Figure 3A.

Figure 4 is a schematic block diagram of some node software for processing transactions.

Figure 5 shows an embodiment of the invention, in which resources belonging to multicast groups communicate with one another for the secure, efficient and speedy distribution of electronic data.

Figure 6a shows example of an IPv4 address in dot-decimal notation.

Figure 6b shows an example of an IPv6 address in hexadecimal notation.

Figure 6c shows how an address prefixes can be reserved for representing IPv6 address types.

Figure 7 shows a unicast transmission of a data packet from a server's address to the global unicast address of a computer (shown as PCI).

Figure 8 shows a multicast transmission, for comparison with the unicast transmission of Figure 7; here, the data packet sent from the server is routed through the internet to the multicast address for retrieval by subscribers.

Figure 9 shows an anycast transmission, for comparison with Figures 7 and 8, in which the server sends a data packet to an anycast address; the data packet is forwarded to the topologically nearest router/node of a subscribed set of resources.

Figure 10 shows block propagation in the Bitcoin network.

Figure 11 shows an example embodiment of the disclosure, in which a node in a blockchain network performs a multicast transmission of one or more mined blocks. Figure 12 shows an example embodiment of the disclosure, in which a node in a blockchain network performs an anycast transmission to an anycast address.

Figure 13 shows an example embodiment of the disclosure, in which the use of multicast and anycast transmissions are combined for the purpose of block distribution.

Figure 14 provides an illustration of an advantageous use of multicasting of blocks in accordance with an embodiment of the disclosure, including a consideration of geographical factors for enhancing distribution speed and efficiency.

Figure 15 shows a node on a blockchain network broadcasting a block via multicast transmission to key nodes in the network.

Figure 16 shows a node B on a blockchain network broadcasting via multicast transmission to a plurality of nodes N1 to N4 in the network.

Figures 17(a) to (d) are tables indicating examples of values derived from portions of data that are used to identify and/or determine an allocated address.

Figure 18 shows a node B on a blockchain network broadcasting via multicast transmission to allocated addresses via each of its eight outputs to nodes N1 to N8 in the network.

Figure 19 shows a node B on a blockchain network, receiving data from node A, and broadcasting via multicast transmission to allocated addresses represented by a plurality of nodes N1 to N4 in the network.

Figure 20 shows a node B on a blockchain network, which has subscribed to receive multicast broadcasts from nodes C, D and E, and broadcasting to allocated addresses via multicast transmission to each of its eight outputs to nodes N1 to N8 in the network.

Figure 21 shows a node B transmitting a packet of data to a multicast group, a first subscriber and a second subscriber, wherein the second subscriber optionally further transmits the packet of data to the first user either directly or via a second multicast group. Figure 22 shows a node B transmitting eight packets of data to eight respective multicast groups, a first subscriber subscribing and accessing packets of data from two of the eight multicast groups, and a second subscriber that, optionally, aggregates said eight packets of data and transmits them to a ninth multicast group thus providing the first subscribe to alternative access to said eight packets of data.

Figure 23 shows a node B transmitting eight packets of data to eight respective multicast groups, and six subscribers, nominally drones, accessing one or more packets of data.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS OF THE DISCLOSURE

By way of technical background, and with particular reference to figures 6 to 9, we provide an explanation of some transmission protocols and techniques that can be used in combination with the disclosure to provide the technical effects and benefits of the various embodiments.

As known in the prior art, Internet Protocol (IP) is the communications protocol that provides an identification and location system for computers on networks and routes data packets across the Internet. Resources (i.e. devices/systems) on the Internet are assigned a unique IP address for identification and location definition. IPv6 was designed with a view to providing a solution to the IP address deficiencies arising from IPv4.

IPv6 Addresses:

An example of an IPv4 address in dot-decimal notation is shown in Figure 6a. It is composed of four 8-bit sections, each separated by dots and referred to as an octet.

For the purpose of comparison, an example of an IPv6 address is shown in Figure 6b in hexadecimal notation, wherein each hexadecimal character represents a series of 4 bits. The address is composed of eight 16-bit sections, each separated by colons. Each 16-bit section is referred to as a hextet. This address can be simplified using a variety of rules, including i) replacing multiple consecutive all-zero hextets with a double colon (only once), and ii) removing any leading zeros for hextets; this produces:

2001:db8::alll:b222:0:abcd

Given the difference in the address formats, IPv6 allows for a greater quantity of addresses compared to IPv4. In turn, this provides the ability to reserve address subspaces for different address types. Address prefixes are reserved for representing various address types as illustrated in Figure 6c, in which the global prefix is the block of IP addresses provided to an end user by their Internet Services Provider (ISP). At minimum, it is 88 bits long, with the Subnet ID comprising 16 bits and the host/lnterface ID comprising 64-bits.

These address types typically represent different methods of casting information within the network, including those shown in the Table below:

Table 1

Multicast:

Multicast is a one-to-many network transmission solution where a sending resource transmits a single data packet to multiple destinations. The resource only sends one copy of the data through the network. Resources that have subscribed to the data feed that the sender transmits on would then receive a copy of the data after it is replicated at the applicable junction in the network. Multicast transmissions are especially efficient with respect to bandwidth consumption as the sending resource only sends one copy of the data even though all group subscribers receive a copy. This is in contrast to unicasting where the sending resource establishes a connection with each intended recipient and sends each a separate copy of the data.

As shown in Figure 6c, subspaces of IPv6 addresses can be designated for use with different types of addresses (unicast, multicast, etc). The address shown in Figure 6c

(2001: 0db8 : alll: b222: 0: abed) is an example of such an address. For a unicast transmission, the data packets are sent from one global unicast address to another. There are different types of IPv6 unicast addresses. A global unicast address is a routable unicast address. (This is similar in usage to that of a public IPv4 address) - see, for example, https://www.ciscopress.com/articles/article. asp?p=2803866&seqNum=4. With reference to Figure 7, a unicast transmission of a data packet from the server's address to the global unicast address of PCI would result in the data packet being routed through the internet and arriving at PCI with address 2001 : db8 : alll: b222: 0: abed. PCI would be the only resource that processes the data packet.

For multicast, as opposed to sending the data packet to an address of PCI, the data packet is sent to a multicast address. This would be to an IPv6 address with the prefix FF. Resources that would like to receive the data from the deriver join the multicast group of that multicast address. This is called their "subscription".

When the data packet is sent from the server it is routed through the Internet to the multicast address (e.g., 'RLocal' in Figure 8, which shows a multicast transmission from a Server to subscribers PCI and PC2). On the packet's arrival, the subscribers e.g. PCI and PC2, are able to retrieve the data, whereas non-subscribers PC3 and PC4 will ignore the data packet. This multicast reduces the need to send two separate data packets from the server to PCI and PC2. Only on arrival at RLocal are separate copies of the data packet created.

For the multicast packet to have arrived at PCI, the resource PCI would have to make a report to RLocal that they would like to join the multicast group FF00:/8. When RLocal sees this report, it will open an interface to PCI with the promise of forwarding any multicasting messages to PCI if it sees any of the multicast packets on the network. A router in the network (e.g., R2) would have been selected as the Rendezvous Point (RP) for the multicast to FF00:/8. Knowing that the best path to R2 runs through Rl, RLocal will send a join report to R1 asking R1 to forward the request for the FF00:/8 multicast transactions to the Rendezvous Point R2. Rl will send a join report to R2. If the Rendezvous Point is to receive a multicast packet it will forward this packet to Rl which then passes it on to RLocal, which then in turn passes it on to PCI.

Anycast

IPv6 anycast comprises a situation in which multiple routers share a common IPv6 anycast address. An anycast address, as shown in Table 1 above, shares the same prefix as global unicast address. For example:

2001: db8: : alll: b222: 0: abed can also be used as an anycast address. If a data packet is sent by a sending resource to an anycast address it is forwarded to the nearest router/nodes of a subscribed set of resources. While geographical distance is a factor in determining the nearest resource, there are other influencing factors in the calculation such as: number of hops, efficiency, latency and cost. In the end, for anycast, only one resource is expected to receive the data packet and is often described as a one-to-nearest transmission.

With reference to Figure 9, which shows an anycast transmission from a Server to Router R3, it can be seen that the packet is sent to the anycast address, 2001: dZ>8:/32, shared by at least three routers (Rl, R3, RLocal). The closest of these is R3 so the data packet is sent to R3. Recall that 'nearest' does not necessarily refer to geographical proximity.

ILLUSTRATIVE EMBODIMENTS

Turning now to a discussion of illustrative embodiments of the disclosure, and with reference to Figures 5 to 15, a solution is provided that utilises these transmission techniques for fast, secure and scalable distribution of data across a computing network. In our preferred embodiment, the data is communicated across a network e.g. the Internet, from one or more sending resources to one or a plurality of receiving resources. In some scenarios, the receiving resources are organised in logical groups and each group can comprise one or more resources. The resources can comprise any type of computing resource, controlled by or belonging to any organisation(s), and arranged for use for any suitable purpose. Each resource may comprise one or more hardware and/or software components, and arranged for communication with other resources over an electronic network. In some cases, a resource may be a mining node on a blockchain network, while in other cases it may be a digital wallet, a cryptocurrency exchange, or a search engine, or a file server, or a service provider etc. There is no limitation on the type, form, purpose or configuration of the resource(s).

Each group is associated with a respective group identifier that serves as a unique address to which data can be sent. All resources in a given group are associated with the group's address and, therefore, can receive data that is sent from a sender to that group address. The address may be a multicast address and, in a preferred embodiment, is an IPv6 multicast address. Therefore, each group of receiving resources is represented by an IP address. Therefore, the group address can be used to implement 1-to-many communications in that a sending resource need only send a packet of data once to the group address in order for each resource in the group to receive it, rather than sending it to each and every resource in a 1-to-l communication (such as performed in a unicast transmission). Receiving resources may subscribe to i.e. join a group by sending a Multicast Listener Discovery (MLD) message which signals its intention to participate. Advantageously, a joining resource can be located on a local network (LAN) or on the internet, as multicast groups are not constrained by local or global network geography. The resource can receive multicast packets sent to that group address as long as it is signalling its membership of the group. Therefore, resources can join or leave a group dynamically, at any time, by simply signalling to the network to join, or ceasing to signal to the network for that group.

Therefore, a multicast group is used to identify groups of recipients, each of whom has an interest in, or need for, the particular data transmissions that are sent to that group's address. While only resources that belong to a given group can be receivers, the data can be sent to the group by any resource irrespective of whether it is part of the multicast group or not. Resources in one group can send to another group and vice versa.

Multicast Listener Discovery (MLD) and MLD Snooping

As known in the art, MLD is built into the IPv6 protocol. See, for example, https://en.wikipedia.org/wiki/Multicast Listener Discovery. MLD snooping uses MLD to provide numerous efficiencies because it avoids flooding packets across networks and thus transmission of data to network resources that have not signalled an interest in receiving that data. In addition, it provides improved network security because it avoids Denial of Service (DOS) attacks from unknown network sources.

By default, MLD snooping is disabled. As a result, when a switch receives a packet that has a multicast address it is sent to all interface ports in its VLAN except the port that the packet was received on. In other words, the switch floods the packet across the VLAN. If a resource is not a member of the multicast group and not interested in the data on that channel, it ignores the packet. Clearly, this gives rise to unnecessary network traffic and inefficient use of energy and processing resources.

However, when MLD snooping is enabled, the switch forwards the multicast-addressed packet only to interface ports that that have signalled an interest in receiving packets destined for that address. In other words, it only sends the packet to ports belonging to members that have subscribed to that multicast group. Thus, MLD snooping allows a sending resource to selectively transmit data packets to resources which have indicated an interest in receiving them. If no network resources are subscribed to the multicast group, the sending resource does not send any packets. Further details can be found at: https://techhub.hpe.com/eginfolib/networking/docs/switches/W B/15-18/5998- 8170 wb 2920 ipy6 config guide/content/v33585413.html.

DISTRIBUTION OF BLOCKCHAIN-RELATED DATA:

In one particularly advantageous scenario, the sending and/or receiving resources are computing resources which are operative to send, receive, store and/or process blockchain-related data. In one example, these resources could be nodes in a blockchain network that implement a particular blockchain protocol (e.g. Bitcoin SV protocol). A multicast group may be created comprising all nodes in the blockchain network, or a subset of the nodes. For example, the multicast group may be set up to share data between a pool of miners, or a set of PoW calculating resources, or any other type of operation. In other examples, though, one some or none of the resources may be nodes on a blockchain network but may be resources which process data in some way for blockchain and/or cryptocurrency-related purposes. These could include, for example, providers of digital wallets, cryptocurrency exchanges, banks and financial institutions, distributed verification providers etc.

The efficiencies of IPv6 are considered as advantageous to blockchain networks such as Bitcoin because 1) Bitcoin is itself maintained by a network of distributed nodes; and 2) these nodes communicate peer-to-peer over the Internet.

For the Bitcoin network, each node is expected to store up-to-date copies of the blockchain/ledger, the mempool (dataset of unconfirmed transactions) and the UTXO set (list of all unsent transaction outputs). To maintain the most current versions of those datasets requires continuous communication between the nodes, where validated transactions and blocks are shared between them. A block contains a set of transactions as well as the block header. The block header itself contains the nonce used to mine the block, as well as the Merkle root that represents the set of transactions in the block. Embodiments may be used to advantage in respect of:

• Transaction Propagation:

When a wallet submits a transaction to the Bitcoin network (e.g., a user purchases an item in store with Bitcoin), a full node 104 that receives the transaction checks whether the transaction is valid (content satisfies all the rules of the version of the Bitcoin protocol of the node's software) and whether the transaction is not a double-spend of a transaction already in the mempool. (A "double spend" occurs when two spending transactions attempt to spend the same output of a given funding transaction on the blockchain). If both criteria are satisfied, the Bitcoin node 104 updates its personal mempool, and sends the validated transaction to a set of other Bitcoin nodes to which it connects. Each of these receiving nodes go on to perform the same validity checks, update, and transaction transmission steps. This allows for the propagation of transactions across the Bitcoin network

• Block Propagation:

We refer to Figure 10 which illustrates a block propagation between nodes in a blockchain e.g. Bitcoin network. When a node mines a new block from a pool of transactions in its mempool, it updates its data stores (UTXO set, mempool, blockchain) and relays the new block to its connected nodes. For the Bitcoin protocol nodes can have at most 125 connections, only 8 of these being outgoing connections.

These connected nodes, in turn, perform their own validity checks on the block, update their datastores, and relay the blocks onwards. This allows for the propagation of blocks across the Bitcoin network.

The speed of transaction and block propagation is particularly important as a node and/or wallet would require the most current version of their datasets (UTXO set, mempool, blockchain) in order to minimise the risk of double spending. It is also in the best interest of full, mining nodes 104 to be aware of the most recent block mined, at the earliest time. This is to reduce their time spent generating a Proof Work (PoW) for a pool of transactions where some or all of these transactions have already been included in a mined block.

For the BTC network, newly mined blocks take an average of 10s to propagate through the network. This propagation time is proportional to the size of the block (1MB max for the BTC network). On the other hand, nodes that implement the Bitcoin SV protocol, which allows large block sizes, need inventive solutions for reducing the time to propagate their large blocks. Therefore, faster block propagation is crucial for scalability.

• Block Header Propagation

Given that nodes receive transactions from multiple sources, and their mempools are likely to share transactions, it may be inefficient to send the entirety of a newly mined block to the at least 8 outgoing connections, as the receiving nodes are likely to already have copies of many of the transactions in the mined block in their mempool.

To address this, rather than sending the newly mined block to an outpoint node, the sending node can send a copy of the block header along with a list of transaction IDs (hash of the transaction) contained in the block. In some embodiments this may be an ordered list depending on the blockchain protocol that is being used. This (ordered) list, along with the Merkle root and nonce of the header, can prove the validity of the mined block. The receiving node can use the ordered list to determine which, if any, transactions it does not already possess in its mempool. It can then send a request to the sending node for copies of the outstanding transactions. Upon receipt of the request, these are sent by the sending node to the requesting node. The requesting node then composes or compiles the block based on the transactions and header information it has received from the sending node, and then adds the new block to their copy of the blockchain.

MULTICAST DISTRIBUTION USING IPv6:

In accordance with some embodiments, IPv6 transmission of data packets are employed to advantage in respect of block distribution across or within a blockchain network. Figure 11 shows an example of Multicast distribution of mined blocks from Node 5 to a network of nodes. Nodes in the blockchain network (or a subset of the network) that wish to receive block updates, based on specific criteria, may elect to subscribe to a shared multicast address. One or more sending (source) nodes may send applicable blocks to the multicast address. These may be full blocks or partial blocks, and may be mined or pre-mined blocks.

In the example of Figure 11, blockchain node 4 receives Bitcoin transactions from PCI, PC2 and Node 5 and was able to successfully produce a mined block. This it seeks to distribute as efficiently as possible to a set of interested nodes. In the example these interested nodes would be Node 1 and Node 2. Both nodes have subscribed to the multicast address 2001:db8:/32. Node 4 sends one copy of the block to the multicast address. On arrival at this address, the block is replicated, and a copy sent to the subscriber nodes Node 1 and Node 2.

As mentioned above in respect of block header propagation, sending a complete block to a recipient may mean that the node receives copies of transactions that it already possesses. This may give rise to inefficiencies if the required data, or at least part of it, can be accessed locally rather than needing to be sent across a network. With this in mind, variations of the following process may be performed:

• rather than sending an entire block via multicast, the sending node may instead send, via IPv6 multicast, only the block header and the (ordered) list of transactions to the multicast address; therefore, all subscribed nodes will receive this information via the multicast transmission;

• each receiving (i.e. subscribed) node uses the received information to determine which, if any, outstanding transactions they need in order to generate the complete block

• if a receiving node determines that at least one transaction is needed for it to generate the block, that node sends a request to the sending node (via a unicast transmission) for the required i.e. missing transactions; the request comprises the IDs of their missing transactions;

• the sending node receives the request from the receiving node; the sending node sends a transmission comprising the requested, missing transactions to the receiving node. Preferably, this would be a unicast transmission to only the individual receiving node that has sent the request. This is because the sets of outstanding nodes for the respective receiving nodes are likely to be unique, lessening the value or benefit of sending the outstanding transactions to the whole subscribing group via IPv6 multicast.

MLD Snooping As mentioned above, MLD snooping can provide significant efficiencies and benefits for the transmission of data across networks. In respect of blockchain related services or functionalities, this can greatly improve blockchain implemented applications and service providers, as well as enhancing the networks which implement the underlying blockchain protocol itself.

Using IPv6 multicast, a sending resource has the ability to enable MLD snooping. Embodiments of the present disclosure may include, at least but not limited to, features as included in clause set 8 below. This enables the sender to transmit packets selectively to only those resources which have indicated a desire to receive them. This means that transmission of blockchain-related or relevant data can be effectively targeted to specific destinations. This effectively changes the flow of information from being a push pattern to a subscription/publication pattern; i.e., receiving hosts subscribe to an IPv6 Multicast group and packets are then forwarded from the switches running MLD Snooping (layer 2) to the routers running MLD (layer 3) to the receiving hosts. As a result, only necessary traffic is forwarded through the network. This addresses, at least in part, the widely recognised technical challenge of how to achieve scalability within blockchain networks which requires extremely high volumes of transactions per second to be sent. Thus, blockchain-related methods and systems which incorporate the use of MLD snooping facilitate or enable the construction of improved blockchain networks and blockchain-implemented applications.

By way of example, consider an IPv6 Multicast group of 2 members, Alice and Bob, who wish to participate in an SPV verification. Suppose that one of them is a merchant and the other is a customer wishing to purchase goods or services from the merchant using Bitcoin. The use of MLD & MLD Snooping greatly improves the SPV transaction by allowing both Alice & Bob to receive a Merkle Path as a response to a submission to nodes on the Bitcoin network. In some embodiments, certain nodes on the blockchain network may provide this functionality as a subscription-based service. In other examples, applications and services may subscribe to Multicast group addresses to receive submitted blockchain transactions upstream from the blockchain nodes themselves. This is possible because the transactions are public. This improved data flow enables blockchain transactions to be verified via Merkle Proofs using their Merkle Paths, rather than scanning or iterating over a blockchain ledger. Again, this provides a more efficient solution for the construction of blockchain related applications which need to interact with, use or interrogate blockchain-related data.

Advantageously, some embodiments of the present disclosure provide solutions for implementing a mempool or a UTXO set for a blockchain network. According to such embodiments, nodes on the network may be blockchain nodes, and may join a multicast group as described herein. The nodes may be full blockchain nodes 104. The nodes may transmit blockchain related data between the group members by way of an IPv6 multicast message. The blockchain related data may be or comprise at least one unconfirmed blockchain transaction or at least one unspent transaction output (UTXO). Although International patent application WO2018/234987 discloses the use of multicast for propagation of initial transactions through an overlay network of specialised nodes that sits on top of a blockchain network, it does not disclose the use of IPv6 multicast for use with (full) nodes on a blockchain network itself. Moreover, it does not disclose the use of multicast for propagation of unconfirmed transactions such as required for the implementation of a mempool. In fact, the Bitcoin network still does not use IPv6 for internode communication, and WO2018/234987 actively discloses the use of a DHT instead of multicast because it suggests that the network lacks the ability to scale sufficiently to cope with the increased transaction output that Multicast distribution would bring with it. ANYCAST DISTRIBUTION USING IPv6:

Anycast is particularly applicable for instances where speed of transmission is of particular concern. With respect to block propagation in a blockchain network, nodes desire receiving a copy of a newly mined block as soon as possible. As nodes obtain a copy of a newly mined block, they may choose to join an anycast address. This essentially means assigning themselves (i.e. a network interface) an anycast address. The anycast address is, essentially, a shared unicast address. An interested node can then send a request transmission to the anycast address indicating that that they are seeking a copy of the newly mined block and/or requesting a copy of the newly mined block. The request transmission will arrive at the topologically closest node of the anycast address. This nearest node will then send a copy of the mined block directly (using unicast) to the node that requested it.

Figure 12 shows an example of an Anycast transmission from Node 5 to anycast address 2001:db8:/32. Nodes 1, 2, and 3 have obtained copies of the newly mined block. On receiving and validating a copy of the mined block, they each assign themselves to the anycast address 2001:db8:/32. It is a shared understanding that this anycast address means that this address represents that the recipient is in possession a copy of a newly mined block. Node 5 sends a request for a copy of the block to the anycast address; the node (of nodes 1,2, and 3) that is the nearest topologically closest will be the node that receives the request.

In the case of Figure 12, the closest is Node 1. Said node will then, if it chooses, send a copy of the block to Node 5 via unicast. Given the node that is in closest proximity is chosen, this means that Node 1 is likely to more quickly receive a complete copy of the block.

Note however that 'nearest' node is dependent on several factors other than geographical proximity; latency and costs were listed as factors in its determination. If the channel to Node 1 becomes overwhelmed with block transmission and block-requests, the calculation of 'nearest' will possibly select another node as the new nearest node. This distributes the requests and block transmissions across the nodes in possession of a new block.

In the case of block header transmission, the process may still operate as described above. In a preferred embodiment, the request for the block header of a newly mined block will be performed through the anycast request. When the nearest node is determined, a unicast transmission will be sent from the requesting node (Node 5) asking for the outstanding transactions from the nearest node (Node 1). Recall that the outstanding transactions are the transactions in the newly mined block that are not in the mempool of the requesting node. These outstanding transactions will be sent to the requesting node (Node 5).

DISTRIBUTION USING MULTICAST WITH ANYCAST AND/OR UNICAST

Figure 13 provides an illustration of the use of Multicast with Anycast for block distribution. In such an embodiment, the previously described uses of multicast and anycast are combined to provide a solution in which blocks are sent from a source node (N1 in layer 0 of Figure 13) to multicast- subscribed nodes (N2...N4, layer 1). Other interested nodes (N6, N7 in layer 2) determine, via an anycast query transmission, which members of the multicast group (layer 1) is their closest peer. These layer 2 nodes then proceed to download the blocks from the nearest layer 1 node.

For Figure 13, the node N1 is the first to mine a block and multicasts this block to a set of subscribers N2, N3, and N4. N5 is not a subscriber. Each of these nodes is expected to also assign themselves an anycast address (shared unicast address). Nodes that share this address are expected to be nodes with a newly mined block. Nodes N1 and N7 are interested in this new block and send a request (Q.) to the anycast address shared by N2, N3, and N4. The request is routed to the nearest node. For N6, the nearest node is N2. N2 receives the request for the blocks and sends this block to N6. For N7's request, this arrives at N4 (nearest node). N4 sends the block to N7 via a unicast transmission.

This can be implemented using a fixed anycast address as follows. It should be noted that this is provided for illustration only, and some of the following steps may be omitted and the order in which they are provided below is not intended to be limiting, as some steps may be performed in a different order from that shown below; the following list of steps is not intended to be exhaustive: i. A set of associated (e.g. key stakeholder) nodes come to an agreement on their shared obligation, responsibility or goal (e.g. to distribute large blocks, or blocks in accordance with a particular protocol, or in accordance with the terms of an agreement). ii. These associated nodes subscribe to a shared multicast address. The multicast address may be determined by one or more of the nodes, or may be determined by an address determining party which sends the multicast address to the associated nodes. Upon subscribing to the address, these nodes are now group members of the multicast i.e., they listen to the multicast address. ill. The associated nodes promote/advertise their service to a wider network e.g. the Bitcoin network, or at least their local or designated communities or associations in the network iv. At least one of the associated nodes, or another party, promotes the shared multicast address to the wider (Bitcoin) network or at least their respective local or designated communities. Nodes that mine a new block are asked to send their new block (or block header and ordered list of transactions) to this multicast address. v. At least one of the associated nodes or another party communicates a unique anycast address to the wider Bitcoin network or at least their respective local or designated communities. vi. A node (which may be an associated node or a non-associated node) mines a new block. vii. The mining node i.e. the node that has mined the new block sends the new block (or the block header and list of transactions) to the multicast address. viii. The block (or block header and transactions) is routed via IPv6 to all members of the multicast group; in other words, the data is sent via a multicast transmission to the multicast address ix. At least one, but preferably all, of the associated nodes performs the necessary check to validate the legitimacy of the newly mined block x. If a block header and list of transactions has been sent rather than a full block: a. the associated node compares the transactions in ordered list against the transactions that it has in its mempool. If it is unable to match at least one transaction in the list with a transaction in its mempool, the associated node sends a unicast request to the mining node asking for the outstanding transaction(s). b. The mining node sends the missing transaction(s) to the key node via a unicast transmission.

In cases where anycast is used:

1. Non-associated nodes may intermittently send requests to the anycast address of the multicast group. The request message may include the unicast address of the sending node.

2. If an associated node (i.e. receiving multicast group member) with an anycast address receives a request for a copy of the new block, the associated node then sends a copy of the block (or block header and transaction list) to the requesting node via unicast (Receiving a request via anycast means that the group member is the nearest in the group to the request-sending node).

3. If block header and ordered list is sent to a non-associated node: a. the node checks its mempool for the transactions in ordered list i.e. as above, it inspects its mempool and checks to see if each transaction in the list is in its mempool; if any transactions in the list are absent from the mempool, the node sends a unicast request to the associated node asking for the outstanding (absent) transaction(s) b. The associated node sends the missing transaction(s) via a unicast transmission to the node.

After a certain amount of time has passed or criteria has been met (e.g., the block was sent to at least 25 nodes by the associated node), the associated node may de-assign itself from the anycast address. The associated node focuses on listening for new blocks at the multicast address

It should be noted that:

• a node can be listening for new blocks at the multicast address simultaneously while it is receiving block requests and disseminating new blocks.

• a node can subscribe to multiple multicast addresses i.e., it can be listening on the Bitcoin network for multiple, different types of blocks.

• a node can remove itself from a multicast group or anycast address by its own choosing.

Given the limitation typically found in Bitcoin network implementations on the number of outbound nodes (8 for BSV), a node seeking fast propagation of its newly mined block may find value in careful consideration of what the at most 8 nodes it connects to should be.

As an example, the 8 nodes could be strategically chosen based on their geographical location, in that each may be a high capacity node, centralised within their geographical region. ('High capacity' includes factors such as bandwidth, low latency, computational power, storage). These nodes 8 nodes join a multicast for new block propagation, i.e., listen to a shared multicast address. Any node that mines a block would see fit to perform a multicast to this set of 8 centralised nodes who would then, in turn, communicate the block to other nodes in their respective geographical regions.

Consider Figure 14, which provides an example of blockchain-related data distribution using multicasting of a block-related data and anycasting based on geographical location. A block mined by node N1 in Canada is sent via multicast to key central nodes in Brazil (N2), Germany (N4) and Nigeria (N3). A node (N5) in Australia sends a request to the shared anycast address of N2, N3, and N4 for the new block. The request arrives at N3 in Nigeria (determined as nearest) who then sends the new block to node N5 in Australia.

Note that the centralisation of key nodes within the Bitcoin network may not map directly to geographical locations. These nodes may be 'topologically centralised' or have a high degree of centrality in emergent clusters/communities in the network. As an example, Tao et al. [Tao, B., Dai, H.N., Wu, J., Ho, I.W.H., Zheng, Z. and Cheang, C.F., 2021. Complex network analysis of the bitcoin transaction network. IEEE Transactions on Circuits and Systems II: Express Briefs, 69(3), pp.1009- 1013] show the presence of communities within the Bitcoin Core network. The network in Figure 15 shows the node N1 broadcasting a block via multicast to key 'central' nodes (N2...N8) in the Bitcoin network. These receiving nodes can then distribute the block-related data to other nodes in their communities.

BALANCING

As described above in relation to Figure 5, packets of data can be transmitted to at least one multicast address, wherein one or more packets of data are included in a transmission. The term packet of data can be used to refer to an individual packet of data e.g. a blockchain transaction, or a collection of packets of data e.g. a blockchain block comprising a plurality of transactions. The packet of data and the data therein may be blockchain-related data but not necessarily so. Packets of data, therefore, are propagated across as described herein. Packets of data can include, for example, blockchain transactions, blockchain blocks and block headers.

Multicasting and its incorporation in IPv6 protocol can provide greater efficiencies in transmission of packets of data of data packets across the Internet and less network congestion in comparison with other ways of transmitting/casting packets such as unicasting and broadcasting.

As a compliment to the efficient and scalable solution for transmitting data using IPv6, as taught herein, the propagation of packets of data can be balanced. Transmission of a packet of data can be improved using allocated addresses such that their associated resources are used during the propagation of packets of data within a network.

Allocated addresses are determined from the packet of data itself. A plurality of multicast addresses is provided to enable the propagation of all packets of data, and one from the plurality of addresses is selected based on the packet of data to be transmitted. This functions to balance, or spread-out, the transmission of packets of data within a network. Nodes and/or routers can be configured to sign-up or subscribe to one or more allocated addresses e.g. a sub-set of the plurality of multicast addresses, thus enabling the balancing of the transmission of packets of data across the resources associated with the allocated addresses. Balancing can inhibit bottlenecks in the transmission of packets of data, in particular when the packets of data are large blocks, which could result in a delay at a node or router, or when the packets of data are transactions and the volume of transactions floods the network by propagating in a universal manner.

Load balancing can be achieved through allocation of propagation to an allocated address. A resource, such as a sending and/or receiving resource is configured to send and/or receive packets of data, such as a record, is adapted to generate, store, process, access and/or maintain a record of a packet of data. The packet of data can include blockchain related data. The resource can determine from the packet of data an allocated address. The resource can then send, at least in part, a transmission of the packet of data from the sending resource across an electronic network to the allocated address. Additionally or alternatively, the resource can subscribe to a group e.g. a multicast group to receive transmissions sent to an allocated address e.g. an allocated multicast address. Using an allocated address in the sending and/or receiving of packets of data, wherein the selection of the allocated address is based on the packet of data, can enable load balancing by spreading the distribution of packets of data across respective allocated addresses and their associated resources. This provides several significant technical improvements, including enhanced efficiency and utilisation of resources and energy.

Figure 16 shows a sending resource B transmitting a packet of data to four nodes, N1 to N4. Each of the transmissions is sent to a multicast group. The nodes N1 to N4 subscribe to multicast addresses. Node Nl, however, subscribes to an allocated address i.e. a multicast group for receiving packets of data transmitted to an allocated address, as indicated by the dashed line. Resource B determines the allocated address based on the packet of data. Therefore, not all packets of data are sent to node Nl, only these sent to an allocated address. By subscribing to the allocated address, node Nl receives a subset of the packets of data transmitted from the resource B, wherein said subset is determined from the packet of data itself. In this way, node Nl only receives a transmission for a subset of packets of data e.g. packets of data, that have been sent to the allocated address.

In this example, nodes N2 to N4 subscribe to a multicast group to receive any packet of data, irrespective of the packet of data being sent, while node Nl is concerned with receiving selected packets of data, said selection being made via a subscription to a multicast group for the allocated address. In practice, however, each of the nodes N1 to N4 can subscribe to a multicast group for a different allocated address. For example, the resource B can determine that a packet of data is sent to one of four allocated addresses, such that four sub-sets of packets of data are determinable from the set of packets of data, and each of the nodes N1 to N4 subscribes to a multicast group to receive the respective sub-sets.

Through allocation, and balancing, the transmission of packets of data can at least one of improve efficiency, enable scalability, support balancing of resources in a network and inhibit bottlenecks. Moreover, allocation enables at least one of the processing, storing and validating of information associated with the packet of data e.g. each UTXO and/or transaction to be managed more efficiently, as described and taught in PCT/EP2022/080084 and PCT/EP2022/080081, herein incorporated by reference in their entirety.

Using a packet of data to determine at least one of the allocated addresses that said packet of data is sent to enables the propagation of packets of data across a network to be balanced. Balancing can be achieved through distribution of the propagated packets of data across a range nodes and/or routers that selectively subscribe to allocated multicast groups and/or receive from multicast addresses. Distributing the propagation of packets of data using allocated addresses as taught herein can be analogous and complementary to the distribution of the validation of data and, therefore, the following applications are herein incorporated by reference in their entirety: PCT/EP2022/079825; PCT/EP2022/080084; PCT/EP2022/079830; PCT/EP2022/079447 ;

PCT/EP2022/079837; and PCT/EP2022/080014

The allocated address, therefor, can be a multicast address associated with a group of receiving resources, such as nodes N1 of Figure 16. By way of a non-limiting example, the packet of data can include at least a portion of a transaction (Tx) e.g. a blockchain transaction. Although the methods of allocation taught herein can be applied to any packet of data they are particularly suited and beneficial in blockchain-related applications using block-chain related data e.g. blocks, block headers etc. .

Using packets of data including blockchain data as an example, e.g. the packet of data includes UTXO data, said packet of data can, by way of example, be allocated to one allocated address from a group of eight allocatable. Figure 17(a), by way of non-limiting example, illustrates eight allocated addresses, each of which correspond to a binary value, wherein the binary value is derivable from the packet of data. For example, the binary value of the UTXO data within the packet of data began with '110', then the packet of data would be sent to allocated address '7'. The range of allocated addresses is scalable e.g. the total number of allocated addresses can be 16, 256 or 1024. Each allocated address, therefore, can be allocated a range of packets of data to send and/or receive, store and/or maintain.

Bitcoin nodes have 125 inputs and eight outputs and, therefore, Figure 18 represents an arrangement wherein the resource B is a node on the blockchain network transmitting to eight allocated addresses, through each of its dedicated outputs e.g. a packet of data having a packet of data can be sent to one of eight nodes N1 to N8. This can be achieved, by way of example, using the table in Figure 17(a). Each output from resource B can transmit to an allocated address according to the packet of data to be transmitted e.g. to an allocated multicast address/group. The nodes N1 to N8 subscribe to the respective allocated multicast addresses. By subscribing to an allocated address, node N1 receives a subset of the packets of data transmitted from the resource B, wherein said subset of data e.g. the packets of data, are determined from the packet of data itself. Using the example of Figure 17(a), node N1 subscribes to receive all packets of data having a binary value beginning '000'.

Determining an allocated address from a packet of data can include parsing the data therein. Using the example of a UTXO again, a portion of the data from an unspent transaction output (UTXO) and/or a transaction (Tx) containing a UTXO can be retrieved and/or received and parsed. Parsing is just one example of processing the packet of data to determine which allocated address to which a packet of data is transmitted. The parsing can be performed by the sending resource e.g. node B in Figure 16, or the resource 501 of Figure 5. Following parsing, the packet of data is directed for transmission to the allocated address for receipt by a multicast group.

In another example, wherein the packet of data is a block, an allocated address can be determined from processing the packet of data therein e.g. by processing the block header. Using the block header example, it can be parsed to determine which allocated address the block is transmitted to. The parsing can be performed by the sending resource e.g. node B in Figure 16, or the resource 501 of Figure 5. Following parsing, the packet of data is directed for transmission to the allocated address. The transmission of blocks, therefore, is spread across the network and addresses e.g. multicast addresses according to the packet of data itself. Identification and/or allocation of the address can be performed by the node and/or switch, e.g. those described in relation to the nodes 'N' and routers 'R' shown in Figures 11 to 15. The node, switch or router function as the sending resource and/or receiving resource within the network.

When the address allocation is determined, e.g. it is determined from the packet of data, which includes a packet of data having a UTXO/Tx will be held, the sending resource can selectively transmit the packet of data. Similarly, recipients of data in the network can subscribe to multicast groups dedicated to those allocated addresses. In this way, a transmission and/or a subscription by a resource can dedicate itself to the packets of data it processes. As described herein, the packet of data determines the allocated address from the data therein, which can include at least one of: a UTXO identifier; a hash of the UTXO script; the transaction identification (TXID).

The sending resource can hold a data structure e.g. a look-up table that includes a set of allocated addresses associated with a corresponding set of keys. A packet of data can be processed to determine an associated key. A sending resource can use the determined key to identify the allocated address to which the packet of data is to be transmitted. A receiving resource can use the set of keys to identify and subscribe to groups that receive data sent to a multicast address, said multicast address being the allocated addresses associated with the corresponding set of keys. Determining the allocated address can include parsing the packet of data to determine a key, and selecting at least one address from a set of addresses using the key.

The packet of data is processed e.g. parsed, to provide a key that corresponds to an allocated address e.g. multicast address, to which the packet of data is transmitted. The key derived from the packet of data can be determined either directly, by using a portion of the data e.g. the key determines the allocated address, or indirectly, by processing e.g. hashing a portion of the data such that the resulting hash determines the allocated address. At least one of the data, the key, and the resulting hash can comprise at least one of: an alphanumeric number; and a binary number. The number is used to determine the allocated address from the data structure.

By way of non-limiting example, the packet of data includes a portion of data comprising an unspent transaction output (which may be a UTXO in some embodiments but not in others, according to the blockchain/protocol that is being used for a given implementation) and/or a transaction (Tx) containing (e.g.) a UTXO. An input to a transaction includes: a transaction ID, which references the transaction that contains the UTXO being spent; an output index e.g. Vout, which identifies which UTXO for that transaction is referenced; a script (for example a scriptSig), which satisfies the conditions placed on the output, for unlocking it; and a sequence number.

A potential recipient of some cryptocurrency associated with the output can verify, for example, whether there is a double-spend. The potential recipient, therefore, subscribes to a group that receive data at a multicast address e.g. node N1 in Figure 16. A node e.g. node B in Figure 16, acts as a sending resource to broadcast the transaction as quickly and efficiently as possible, and without delay or interruption. Node B, therefor, either processes the transaction directly, or receives it from a third party, and uses the packet of data of the transaction, and a portion of data from the UTXO and/or the associated transaction information to determine an allocated address. This determination can use a portion of data that is unique to the UTXO such that a key can be determined, which subsequently determines to which allocated address the associated information can be transmitted to.

Figure 19 represents a scenario in which a resource A engages with resource B to establish a transaction. Upon receipt of a packet of data of the transaction, said packet of data corresponding to the transaction, resource B can transmit the packet of data to the network to an allocated address defined by the packet of data. In this way the network, e.g. blockchain network, is notified of the packet of data e.g. transaction, such that errors or problems e.g. a double-spend can be identified.

Using the transaction identification (TxID) as a non-limiting example, the TxID is commonly referred to in its hexadecimal form, and can also be represented as a binary number. Figures 17(a) to (d) are data structures e.g. tables indicating how a portion of the data can be used to determine an allocated address. The portion of data e.g. TxID can be parsed directly or processed e.g. hashed. In Figure 17(a), the TxID is parsed such that the first 3 digits of the TxID in binary form are selected as a key, and the address allocated according to the binary value e.g. information associated with a TxID having a binary number with '101' as the first three digits is allocated for storage/processing in allocated address '6'. Using the first three digits binary enables one of eight addresses to be determined, while Figure 17(c) indicates how taking the first four digits from a TxID in binary form supports allocation between 16 address e.g. information associated with a TxID beginning with binary number with '1011' as the first four digits is allocated for storage/processing in allocated address '12'. Alternatively, the hexadecimal value of the TxID can be used, as indicated in Figure 17(b), in which a single hex value maps to an address e.g. 'c' to '13', and in Figure 17(d), in which a range of hex values are allocated an address e.g. information associated with a TxID beginning '76' is allocated to address '8'.

Alternatively, a portion of the data can be processed e.g. hashed, to produce a hexadecimal or binary number, so the portion of data and subsequent determination of a key to identify/allocate the address is not limited to the TxID.

The portion of data selected from a transaction or its UTXO, or the processed value e.g. hashed value, is pseudorandom. The allocation to an address, therefore, is load balanced i.e. the portion of data that is used to determine a key for allocating an address is pseudorandom and distributes processing and/or storage between the plurality of sending resources and/or groups subscribing to multicast addresses. It follows that propagation of information associated with the packet of data e.g. transaction/UTXO is distributed across the plurality of addresses. The balancing of allocation between the addresses minimises the risk of some resources lying idle while others become overloaded and thus risk degradation of performance or even failure. The resilience, performance and/or efficiency of the network, therefore, is improved.

The packet of data, and data therein, therefore, can be used to (i) determine the allocated address for transmission, and thereafter (ii) provide a reference for identifying the group and/or allocated address and/or information associated with the data within the resource e.g. within a database.

It follows that the packet of data and portion of data therein is derived from a blockchain, and determines a key and corresponding allocated address and/or resource that can receive and store information associated with said data e.g. information associated with an unspent transaction output (UTXO) and/or a transaction (Tx) containing a UTXO.

Packets of data can include, at least in part, at least one of: a Merkle Tree of the block in which said transaction (Tx) is recorded; the Merkle root the block in which said transaction (Tx) is recorded; a Merkle path, which enables the determination of the value for the Merkle root for the block in which said transaction (Tx) is recorded, from a hash of said transaction (Tx); a Merkle proof; a block identifier (blockJD) associated with the blockchain block; a transaction identifier (TxID) associated with a transaction (Tx) in the plurality; of blockchain transactions within the blockchain block; a function of the block identifier (blockJD) and the transaction identifier (TxID); and a concatenation of the block identifier (blockJD) and the transaction identifier (TxID). The sending resource can include information and packets of data required to determine the validity of a data within a packet of data e.g. output/UTXO. Additionally or alternatively, the sending resource can itself, or via a validator, generate packets of data that validate and/or support the validation of the output/UTXO and/or indicate whether there has been a double-spend. The sending resource can at least one of: validate and/or verifying said UTXO; perform at least part of a Simplified Payment Verification (SPV) process for said UTXO; confirm whether a given blockchain transaction (Tx) is contained within the blockchain block; generate a hash of at least one of the blockchain transactions, using the hash to construct a Merkle path and/or checking whether the hash matches a transaction identifier (TxID) in a header of the blockchain block; and determine a Merkle proof for said UTXO.

By providing a means for identifying an allocated address based on a packet of data e.g. from a UTXO/transaction, an improved means for transmitting packets of data can be achieved thus improving efficiency and scalability.

The sending resource and/or receiving resource has been described in relation to a single packet of data - additionally or alternatively the sending resource and/or receiving resource, via subscription, can generates, stores, processes, accesses and/or maintains a block comprising a plurality of packets of data, wherein each of the packets of data in the block includes blockchain related data. The sending resource and/or receiving resource can determine for each packet of data in the block an allocated address. The sending resource can send, at least in part, a transmission of each packet of data in the block from the sending resource across an electronic network to the respective allocated address.

When sending the packets of data to their respective allocated addresses, the block can be split into sub-blocks, and the sending resource transmits each sub-block across an electronic network to a corresponding allocated address. Using Figure 18 as an example, a plurality of packets of data can be split in to eight sub-blocks, each sub-block being sent to a corresponding allocated address as represented by N1 to N8. By way of example, the node B functioning as a sending resource can group all packets of data beginning with a binary value of '000' to an allocated multicast address to which node N1 subscribes, as per Figure 17(a). Figure 20 illustrates that the resource, node B, can be a sending resource and a receiving resource. Node B, as an example of a sending and/or receiving resource subscribes to at least one receiving resource and/or at least one multicast group, as taught herein in relation to Figures 8 and 9, and the corresponding description. Packets of data are received from resources represented by nodes C, D and E. To be clear, the sending resource, e.g. node B, additionally or alternatively operates as a receiving resource. Node B, therefore, is configured to receive a packet of data and/or the plurality of packets of data having a packet of data. Node B can then relay the packet of data, which can include blockchain related data to the allocated address, or relay a block comprising a plurality of packets of data to the respective allocated addresses.

Node B can additionally or alternatively operate to collect and/or consolidate at least one of a packet of data, plurality of packets of data and a block of packets of data, which are received from nodes C, D and/or E. The node B can then relay the packets of data, or block of packets of data, to corresponding allocated addresses. After collecting at least one of the packets of data, plurality of packets of data or block, node B can parse the or each packet of data therein to determine a respective key and relay the or each packet of data to at least one address from a set of addresses using the key e.g. relay the or each packet of data or block to multicast addresses represented by nodes N1 to N8.

The sending or receiving resource e.g. node B, subscribes to a multicast group that functions as a multicast address configured to receive at least one packet of data allocated to said multicast address. Said allocation can be determined from the at least one packet of data. Subsequent processing e.g. parsing of the packets of data can determine which allocated address a packet of data is transmitted.

Node B can subscribe to a group of receiving resources by sending a signal to a network, such as the internet and/or a blockchain network. Node B can leave a group of receiving resources, preferably wherein the resource leaves the group by ceasing to send a signal to the network. In this way, node B can 'switch-on' to assign itself to group and subsequently 'switch-off' thus de-assigning the sending resource from a sending address. De-assigning can be performed in response to a determination that a predetermined condition has been met e.g. that the blockchain-related data was sent to a predetermined number of receiving resources, and/or that a certain amount of time has elapsed, or a given date and time is reached etc. The packet of data can comprise a communication or alert relating to a blockchain related event or activity, such as a notification from a member of a cryptocurrency group, or any party that has an interest in receiving such notifications and has joined the group. An alert can include a notification of a double spend or double spend attempt within a blockchain network, which has been issued by a receiving node, such as a mining node or service provider, in a multicast group.

The sending and/or receiving resource can be arranged, configured and/or operative to perform one or more of the following: a functionality specified by a blockchain protocol; a calculation or other operation related to a mining or consensus function specified in a blockchain protocol; a Simplified Payment Verification (SPV) operation; the calculation or verification of a Merkle path, proof or root of a Merkle path; a validation of a blockchain transaction before or after it has been written to a blockchain; a search of a blockchain to identify, locate and/or confirm the presence of a given transaction or block within a blockchain; generate a blockchain transaction, write a transaction to the blockchain, and/or broadcast a transaction to a blockchain network.

A packet of data can comprise at least one of: at least part of a blockchain transaction; at least part of a blockchain block; at least part of a blockchain transaction script; a Merkle Tree of the block in which said packet of data is recorded; the Merkle root the block in which said packet of data is recorded; a Merkle path, which enables the determination of the value for the Merkle root for the block in which said packet of data is recorded, from a hash of said packet of data; a Merkle proof; data for use with, or associated with, a consensus mechanism of a blockchain network the result of, or data relating to, a proof-of-stake or proof-of-work operation; a block identifier (blockJD) associated with the blockchain block; a transaction identifier (TxID) associated with a transaction (Tx) in the plurality of blockchain transactions within the blockchain block; a function of the block identifier (blockJD) and the transaction identifier (TxID); a concatenation of the block identifier (blockJD) and the transaction identifier (TxID); a digital signature; an authentication code; a signature message for determining a transactional state; a protocol flag; a discretionary public key (DPK); and a discretionary transaction ID (DTxID). Such embodiments may utilise one or more features as disclosed in any one or more of the following applications, which are herein incorporated by reference in their entirety: PCT/IB2019/059807, PCT/IB2019/059808, PCT/IB2019/059809, PCT/IB2019/059793, PCT/IB2019/059795, PCT/IB2019/059791, PCT/IB2019/059803, and PCT/IB2019/060226. The sending and/or receiving resource can comprise at least one of: a node in a blockchain network; a service provider arranged to provide a blockchain-related service; a computing resource associated with or controlled by a financial institution; a cryptocurrency exchange or component thereof; a merchant resource or component thereof; a digital wallet or component thereof; a software component operative to perform or facilitate a Simplified Verification Payment (SPV) operation, or process the result of a SPV operation; a MLDvl host or MLDv2 host on a network, a network switch or a router.

We now provide some examples use cases for the purpose of illustration and without limitation.

CONTROLLED ACCESS

Additionally or alternatively to the transmission of packets of data using nodes and/or routers, as taught herein, which optimise the dissemination and/or balancing of resources through management and/or allocation, Figures 21 to 23 illustrate examples of controlled access to packets of data using exchanges between recipients - recipients in the examples are, nominally Alice 'A', Charlie 'C' or Dave 'D', and sending resources are, nominally, Bob 'B' or Charlie 'C' - said exchanges using Multicast Groups 'MG', each group having its own, respective multicast address. The senders, recipients and multicast groups can be part of a network e.g. nodes in a blockchain network, as taught herein.

In Figure 21, a sending resource represented by Bob B or Charlie C function to perform at least one of generating, storing, processing, accessing and/or maintaining a packet of data. The packet of data may include blockchain related data. Bob or Charlie send, at least in part, a transmission of the packet of data from across an electronic network to a multicast group MG1, MG2. Bob represents a node from which the packets of data originate.

The multicast groups make available the packet of data for an end-user, nominally Alice A. Alice can be described as the consumer of the packet of data e.g. the end-user. Charlie, however, can also access and/or subscribe to multicast group MG1, and make said packet of data available directly to Alice, the end-user, or via a further multicast group MG2.

In one or more embodiments, access to the multicast group (and thus the data sent to subscribers of the group) may be controlled via the execution of a smart contract that is executed in association with a blockchain. This may be the Ethereum block, the Bitcoin blockchain or a blockchain implemented via any other blockchain protocol. For example, users wishing to join the group may be required to meet one or more conditions specified in the smart contract, and upon successful fulfilment of the condition(s) they may be provided with the necessary information to be able to subscribe to the group and begin receiving packets of data on from the multicast stream. For example, the user may be provided with a key or token or other resource that enables them to join the group. The conditions could comprise any suitable condition such as payment of a joining fee, or provision of identity-related data for verification of the user's identity etc. The same or a further smart contract may control ongoing access by the user to the multicast group and the data packets that are disseminated to/across it. For example, the smart contract may require that the user pays a fee, updates their identity verification documents or performs some other action at periodic intervals.

Hashed lines are indicated in Figure 21 to indicate the optional transmission of the packet of data between Bob and Alice i.e. via Charlie. While Alice can obtain the packet of data from MGl, said data can be, for example, be a live transmission of multimedia data e.g. a football match. Alice may not be able to watch it live, thus an intermediary e.g. Charlie C also subscribes to receive the packet of data from MGl and store it to make it available to Alice independently of Bob's transmission. Charlie can transmit the packet of data to Alice either directly or via a further multicast group, MG2, at a different time from the original transmission.

In one example, Bob operates as a node and transmits a packet of data to a multicast address e.g. MGl. The transmission can include, at least in part, a block header and a list of one or more blockchain transactions and/or blockchain transaction identifiers (TxIDs). The multicast address e.g. an IPv6 multicast address, is subscribed to by a plurality of receiving nodes, which can include Alice and Charlie. The or each node can be i.e. the sending node and/or at least one of the receiving nodes a node on a blockchain network.

With reference to the intermediary, Charlie, a sending resource or node can additionally function as a receiving resource or node, which can at least one of send, store, process, accessing and/or maintaining the packet of data.

The packet of data is transmitted directly to multicast group MGl and indirectly to multicast group MG2, and consumers and/or end-users of the packet of data can obtain said packet by subscribing to the multicast groups. In light of the teaching and Figures herein, it is clear that the sending resource e.g. a node or router can transmit a plurality of packets of data, and/or the receiving resource e.g. node can receive a plurality of packets of data. By way of non-limiting example, the packet of data can be multimedia data and, at least in part, a data stream, such as a multimedia communication channel.

The multimedia data can be, for example, a football match, or sub-parts thereof. While a football match can be transmitted via a single channel that includes a combination of video and audio, the footage of the football match can be provided in many parts, with one or more parts being transmitted over different channels. For example, multiple video streams can be provided, each stream supported by a different channel. For example, parts can include different camera angles, goal-line camera views, audio-commentary in different languages, replays etc. Each of the channels can be transmitted in different packets of data to respective multicast groups.

Using Figure 22, by way of example, node B transmits packets of data in six different streams, to respective multicast groups, MGa to MGf, said packets including multimedia data for a live football match. Groups MGa and MGb receive packets of data including visual camera angle data, the former following the gameplay, and the latter showing exclusive goal-line activity. Groups MGc and MGd receive packets of data including commentary in different languages, the former in English, and the latter in German. Groups MGe and MGf receive packets of data for optional extras, the former providing exclusive replay actions, and the latter providing footage from a referee-mounted bodycamera.

During the match, Alice streams the match-play and English commentary by accessing multicast groups MGa and MGc. Simultaneously, and optionally, Charlie at node C accesses and captures the data packets from all multicast groups MGa to MGf. The captured data is collected and/or aggregated by Charlie at node C and made available, separately and independently via a multicast group MGm, wherein MGm makes available all the data packets transmitted from node B to multicast groups MGa to MGf, thus offering all match information, languages and camera views on- demand. Alice can access group MGm to watch match-play contained in the packet(s) of data again, or access additional information. An intermediary, such as Charlie, can operate to consolidate e.g. pool packets of data from one of more multicast group for subsequent transmission to another multicast group The sending resource e.g. node B can send a plurality of packets of data. Additionally or alternatively, the packet of data can have sub-components providing a plurality of data channels. The packets of data can be separable for independent transmission to a multicast group according to (i) the function of the channel, as described in the example above in relation to different aspects of a football match, and/or (ii) be based on the packet of data itself, as described in Clause 9 and the associated description.

The teaching herein is not limited to a football match and, by way of other examples, the transmission of packets of data can be applied to: delivery drivers, wherein a control room sends out packets of data relating to delivery addresses, journeys to take, traffic information, weather information and the like can be selectively received by delivery vehicles; the operation and/or coordination of drones; the management of a warehouse and the goods therein; and subscription media services, such as Netflix™ or Sky™ television.

The packet(s) of data and/or the multicast group can be secured e.g. encrypted or otherwise locked by an access-key, wherein the access-key must be applied during a subscription to the multicast group and/or used upon the packet of data to access the content therein. Separate access-keys can be required to access different multicast groups and/or packets of data. For example, a first accesskey can be required to access a packet of data, while a second access-key can be required to access the multicast group e.g. via a subscription.

The sending resource can determine whether an access-key is required to access a packet of data - by securing access to the multicast group and/or securing the data. The sending resource can manage the access to the multicast group e.g. manage the subscription, which requires an access key. In the examples, Bob B and Charlie C are sending resources, and each can respectively manage securing the packets of data they transmit and/or access to the multicast groups that they transmit to. Alice can access the packets of data by subscribing to a service that provides an access-key for joining and receiving packets of data from the multicast group. Additionally or alternatively, Alice can obtain an access-key or subscribe to a service that provides an access-key, thus enabling Alice to unlock secured packets of data.

The sending resources and/or the manager of a multicast group can generate the access-key required by: the intermediary e.g. Charlie C, who acts as an aggregator, and pools packets of data for subsequent access by an end-user such as Alice; and/or the end-user e.g. Alice A, a subscriber. The access key, in one example, is provided to Charlie and Alice.

The access-key can be obtained by an intermediary or end-user e.g. aggregator or end-user in a conventional exchange i.e. providing an access-key in exchange for payment. In light of the teaching herein, which uses, at least, blockchain related data and interactions between nodes on a blockchain network, and blockchain transactions, then at least one access key is provided to an intermediary or an end-user via a payment channel, which are known from: https://wiki.bitcoinsv.io/index.php/Payment Channels.

Using a payment channel, at least one access-key can be exchanged for payment quickly and efficiently using blockchain transactions. In practice, an intermediary or an end-user can use and/or establish a payment channel to obtain a bundle of access-keys. The payment channel, and provision of keys can be handled by the originator of the data or a third-party service provider.

Efficient access to secure packets of data using access-keys benefits from the use of a payment channel, wherein use of each key to subscribe and/or unlock a packet of data can trigger automatic payment to, for example, the sending resource, where the sending resource is the source of packets of data. An access-key can provide access to the multicast group and/or packet of data for at least one of (i) a fixed period of time, and (ii) a fixed quantity of data, (iii) a fixed quantity of units, (iv) a fixed number of packets of data, and (v) unlimited access.

The sending resource e.g. Bob or Charlie, can transmit packets of data to numerous multicast groups. The IPv6 protocol and scope of blockchain applications is such that the volume is packets of data being transmitted can be significant, said packets being transmitted to an equally significant volume of multicast groups. While this enables a scalable and granular means of disseminating packets of data, bottlenecks can be mitigated and the use of resources balanced.

In addition to the transmission and/or subscription and/or access techniques taught herein, sending resources can allocate packets of data to multicast addresses, wherein said multicast addresses are determined from at least one of: the packet of data; and the access key.

Allocation techniques taught in relation to features and embodiments of enumerated clause set 9 and elsewhere herein can be applied to complement the efficient and scalable solutions for transmitting data using IPv6, as taught herein. Balancing can inhibit bottlenecks in the transmission of packets of data, in particular when the packets of data are large blocks, which could result in a delay at a node or router, or when the packets of data are transactions and the volume of transactions floods the network by propagating in a universal manner.

The teaching herein additionally or alternatively applies to a receiving resource, such as an end-user or an aggregator e.g. Alice A or Charlie C, which can store, process, access and/or maintain a packet of data, said packet of data preferably including blockchain related data. The receiving resource receives, at least in part, a transmission of the packet of data via a multicast group that received the packet of data from an electronic network. The packet of data is consumed by an end-user, such as Alice, and/or an aggregator such as Charlie. As described above, Alice and/or Charlie can access secured packets of data using an access-key, wherein the packet of data and/or access to the multicast group is secured and accessible using the access-key. The access-key can be obtained via a payment channel established with at least one of the originator of the packet of data, the sending resource and the multicast group.

Figure 21 illustrates a further example of how a sending resource e.g. Bob, represented by node B, transmits packets of data to eight different multicast groups - nominally MGa to MGh. Bob functions as a blockchain node and, therefore, has eight outputs. The packets of data can be transmitted to a respective multicast group based on the packet of data being transmitted, said packet of data being used to determine the allocated address i.e. multicast group. The determination of the allocation can be implemented, by way of example, using the teaching of clause 9, herein, and the data table of Figure 17(a).

Alternatively, the allocation can be determined using the access-key and/or the content of the packet of data. For example, the multicast groups - nominally MGa to MGh - can hold data associated with a geographical location, which is received from a transmission from node B, Bob, the sending resource. Each geographical location can have its own access key that can be obtained via a subscription.

In one example, the sending resource transmits packets of data e.g. map and traffic information associated with a city having eight districts. Six autonomous vehicles e.g. taxis, operating in a dronelike manner, are labelled DI to D6 and are required to transport goods or occupants within the city. Each drone, DI to D6, operating as a taxi determines its start and end-point for a given journey, and the districts it is required to travel through. The drone then accesses the corresponding packets of data associated with those districts from the multicast group associated with those districts e.g. by subscribing.

Each district and/or drone can be licensed. Therefore, for a drone to operate in one or more districts, it requires a license for each district, said license providing an access-key corresponding to the packets of data associated with the licensed district. Alternatively, or additionally, each drone can obtain a license and corresponding access key by subscribing to the required multicast groups from which the required license, map and traffic data can be obtained. A subscription can be made when required, and switched 'on' or 'off' according to requirements. The subscription to a multicast group to obtain packets of data for a licensed district can be time-based, unit-based etc.

In the example of Figure 23, drones DI, D2, D4 and D5 start and stop in the same districts, and switch-on to receive, or otherwise subscribe to, respectively, multicast groups Mga and MGb. Drone D3, however, travels across three districts and accesses packets of data associated with districts MGa, MGb and MGc. In contrast, drone D6 travels across six districts and accesses packets of data associated with districts MGc to MGh. During normal operations, drone D6 may only operate in the district supported by MGc, and be required to travel to other districts on-demand. Drone D6, therefore, can take an annual subscription to the access-key for the multicast group MGc and/or the data it provides, while subscribing as-and-when required to other multicast groups when travelling in other districts.

Overall, Figures 21 to 23, and the non-limiting examples teach methods and the associated system requirements for a controlled transmission, dissemination and/or access to packets of data. The packets of data can comprise information such as, for example, multimedia content, map data or similar content. Access can be achieved through subscriptions, which can be paid for using, for example, payment channels that are supported by blockchain nodes and a blockchain network. An example application can be a "pay per view" or "pay per use" service. Embodiments can be of particular use for applications in which enhanced control is required over data that is streamed from a source to multiple potential data consumers.

Thus, some examples provided herein relate to the transmission of packets of data using nodes and/or routers, which optimise the dissemination and/or balancing of resources through management and/or allocation, as summarised in the clauses. In particular, examples relate to the controlled transmission and/or access to those packets of data. More particularly, contractual access e.g. payment for the packets of data is provided. In accordance with one possible aspect, the invention may reside in a computer-implemented method comprising operating a sending resource for generating, storing, processing, accessing and/or maintaining a packet of data, said packet of data preferably including blockchain related data. The sending resource can be the originator of the packets of data e.g. the creator or the producer, or the sending resource can be an operator, such as distributor who collates, aggregates or pools packets of data for subsequent transmission e.g. independently of the original transmission or creation of the data. The sending resource may send, at least in part, a transmission of the packet of data from the sending resource (across an electronic network) to a multicast group. The multicast group makes the packet of data available for (access by) an end-user.

A plurality of packets of data can be sent and/or received. By way of example, rather than transmit a movie in a large packet of data, said movie can be divided into multiple parts, each part being sent as a single packet of data. The packet of data can be, at least in part, a data stream, such as a multimedia communication channel. The packet of data can have sub-components for providing a plurality of data channels.

The end-user may typically be a consumer who accesses the packets of data via the multicast groups e.g. they are a subscriber. The multicast group and/or the packets of data can be secured, and a recipient e.g. an end-user can pay to obtain an access-key for accessing the multicast group and/or the packet of data. A plurality of access-keys can be provided. A first access-key can be required to access the packet of data. A second access-key can be required to access the multicast group.

The sending resource can generate the access-key. The sending resource can send the required access-key to at least one of the receiver and an end-user of the packet of data for accessing the packet of data. The access-key can be provided during an exchange using a payment channel. Additionally, or alternatively, in some embodiments a smart contract may be used in conjunction with a blockchain to control initial and/or ongoing access by the user to the multicast group. The smart contract may, when executed in association with the blockchain, require fulfilment of one or more conditions by the user in order to subscribe to the group and/or continue to be a member of the group. The access-key can be configured to provide access to packets of data and/or simultaneously represent a license and/or access to a digital asset or physical asset secured with a digital lock. The access-key can provide access e.g. to the multicast group and/or packet of data, for at least one of (i) a fixed period of time, (ii) a fixed quantity of data, (iii) a fixed quantity of units, (iv) a fixed number of packets of data, and (v) unlimited access.

In another example, a computer-implemented method comprises operating a receiving resource for storing, processing, accessing and/or maintaining a packet of data, said packet of data preferably including blockchain related data. The method further includes receiving, at least in part, a transmission of a packet of data via a multicast group that received the packet of data from an electronic network, and consuming the packet of data as an end-user. The packet of data and/or access to the multicast group can be secured. The receiving resource can obtain access using an access key. The access key can be obtained via a payment channel.

The packet of data can include at least one of: a portion of a transaction (Tx); an output (e.g. UTXO) identifier; a hash of a script (e.g. a script associated with an output in a transaction); a transaction identifier (TXID); a blockchain block; and/or a block header.

Example Use case 1: Network Communications such as Double Spend Alerts and The "First Seen Rule", Network Notifications Etc.:

It is well understood that communications across all types of electronic networks give rise to various, significant technical challenges. In respect of blockchain related networks, in particular, there may be an additional need to disseminate information and data as quickly and efficiently as possible to at least one set or sub-set of targeted recipients that may need to act upon that information/data. Certain embodiments of the present disclosure may use IPv6 multicast communications to achieve or at least facilitate the goal of distributing data/information to a set of receiving resources that are subscribers to a multi cast group as taught herein.

The multicast communication may be:

• an alert: for example, a warning that something may occur, or may not have occurred, or that a risk or potential event that may be detrimental or otherwise relevant to at least part of the network/group, has been identified; the recipient may need to take responsive action; the need for responsive action may be indicated in the alert or may be made known to the recipient(s) in some other manner; for example, the responsive action may be to apply a security fix, a software upgrade or prohibit processing/spending/transfer of a portion of cryptocurrency;

• a notification: for example, an informative message; e.g. an update is available for download, an event may/will/has occurred; or any other news that may be of relevance to the recipient(s);

• an instruction or trigger: for example, the message may comprise executable code, or data which causes at least one recipient to take at least one action in response to the instruction/trigger. In this way, the multicast communication may control, direct or influence the behaviour of one or more recipients.

We will use the term "communication" to include but not be limited to these examples, and include (without limitation) the terms "alert", "notification", "instruction", "update" and/or "trigger".

Embodiments of the disclosure can be utilised to advantage in transmitting communications across an electronic network, such as the internet, so that interested or potentially interested parties can receive the data/information contained with those communications. Embodiments according to these example use cases may comprise features substantially as described in the enumerated clauses provided herein, in particular with respect to clause set 11.

In some embodiments, possibly relating to scenarios where the communication comprises blockchain protocol-level information/data that a sending resource wishes or needs to share, the subscribers to the multicast group may be restricted to certain types or forms of receiving resources. For example, in some embodiments the receiving resources may be full nodes e.g. miners on a blockchain network. Additionally, or alternatively, the receiving resources may comprise non-mining nodes. In other examples, one or more of the receiving resources, and/or the sending resource, may be a vehicle or drone, which may be autonomous, semi-autonomous or operated by human operator(s). The following examples are not intended to be exclusive or exhaustive, and the features of these examples may be used in isolation or in combination with one another. Cryptocurrency Alert Key Implementation Using IPv6 Multicast

In one example, an embodiment may use an IPv6 multicast communication to implement an alert key mechanism for disseminating critical, urgent or essential communications to entities on a network. Embodiments of the disclosure present advantages for the dissemination of cryptocurrency-related communications e.g. alerts and notifications to relevant parties such as nodes on a blockchain network. In accordance with the present disclosure, a blockchain/cryptocurrency alert system can be implemented in which network-relevant data can be broadcast via an IPv6 multicast communication to all or some nodes/receiving resources on the network. The alert may comprise data relating to for example, at least one of: a security patch, a fix or update relating to a potential security exploit, an updated version of a blockchain protocol, a software update, a cryptocurrency double spend attempt, a legal (court-ordered) prohibition, restriction or order, an access code for an Alert Key and so on. Parties having an interest in a particular blockchain network/protocol may subscribe to a multicast group that is set up for communicating relevant information to such parties.

The alert may trigger or require a response by at least one recipient of the alert. For example, the response may comprise one or more of:

• "freezing" or temporary/permanent prohibition of processing of at least one block, transaction or transaction output; for example, this may comprise prohibition of spending a portion of cryptocurrency or unspent output, or validating one or more (blockchain) transactions, or including one or more transactions in a block for potential inclusion in a distributed ledger; the freezing/prohibition action may comprise marking or identifying a portion of data such as at least part of a transaction or block as invalid, unspendable, rejected or to be disregarded;

• Forwarding (i.e. onward transmission) of the alert from the at least one recipient to at least one further recipient; the at least one further receiving resource may comprise at least one further IPv6 multicast address; this allows communications to be sent from one multicast group to one or more further multicast groups, and thus provides a quick and efficient mechanism for dissemination of data such as, for example, time critical updates, notifications, warnings or security patches and solutions;

• downloading, accessing, installing and/or executing a portion of code or data to the receiving resource(s) or one or more further resource(s); for example, the code or data may relate to at least one of: a security patch, a fix or update relating to a potential security exploit, an updated version of a blockchain protocol, a software update, a cryptocurrency double spend attempt, a legal (court-ordered) prohibition, restriction or order.

Using a Code, Flag, Marker or other Identifier to Filter IPv6 Communications to The Network In another example embodiment, the communication may comprise a code, flag, marker or other identifier which functions as a filter.

The filter may be provided in the communication at a pre-designated location and/or in a predetermined format such that at least one or some of the receiving resources are able to identify, understand and/or act upon the filter. In some embodiments, the filter may be provided in the control information of the IPv6 packet (the packet header) or in the payload of user data. In some embodiments, the filter can be a hexadecimal or binary code, and may be associated with or indicative of a pre-determined signal, state or meaning. Additionally, or alternatively, the filter may be associated with or indicative of a type of intended recipient(s). Thus, the filter can serve as a means for targeting communications at specific receivers or groups/subsets of receivers based on: the content/type of communication that is being sent; and/or an intended or desired set of receiving resources.

For example, suppose that a sending resource sends a communication to a group of receiving resources that have subscribed to a particular IPv6 multicast address which has been set up for the dissemination of messages relating to a particular blockchain network. Some of the subscribers may be full (mining) nodes on the blockchain network, while others may simply be service providers that use the blockchain to perform blockchain-related activities on behalf of third parties, such as block validations, SPV and wallet-related services etc. Suppose now that the sending resource has become aware of malevolent activity that might affect the entire blockchain network and all parties that use and interact with it. The sending resource wishes to alert all subscribers as they have an interest in that blockchain. Therefore, the sending resource may generate and send an IPv6 multicast communication to the group address, with information and/or instructions relating to the malevolent activity included in the payload portion of the IPv6 packet. The packet may also contain a flag which indicates that the message is for the attention of all subscribers. Therefore, each subscribing interface detects the packet that has been sent to the group address and processes it. It may take responsive action(s) in response to the information conveyed in the communication, such as ignoring a particular block of transactions or designating an output as already spent.

In another scenario, however, the sending resource may wish to send a communication that is only relevant to a sub-set of the subscribing resources. For example, if a protocol update has occurred or a security exploit has been detected, mining nodes may need to install a software update. Such updates may not be of relevance to other subscribers that do not operate as full nodes on the network, and so it would be inefficient for them to receive and process a communication that they do not need to act upon. Therefore, to improve efficiency and security of communications across the network, the sending resource may include a filter in the communication which indicates that it is relevant only to certain members. When a member sees the IPv6 packet, it can inspect the filter. If the filter indicates that the packet is only relevant to full nodes, the full node members will interpret this accordingly and will process the data in the packet and take one or more appropriate courses of action e.g. install an update. Non-mining nodes, however, will ignore the packet as the filter has flagged that the contents are not relevant to them. This saves energy, resources and time for members of the group.

Moreover, such a flag mechanism allows different types of communications to be targeted at specific sub-groups of members, and thus provides an improved electronic communications solution across the blockchain-related group of members. Further still, it enables the generation and transmission of hierarchies of communications and alerts, as the filter mechanism can provide complex and structured forms selective targeting of different types for communications for different members of one or more multicast groups.

In a preferred embodiment, some or all of the data in the communication may be encrypted or otherwise secured for privacy and security purposes. Thus, sensitive information, or information intended only for certain recipient(s) can be protected. For example, the data in the payload of the IPv6 packet may be encrypted using a cryptographic key, or masked, or encoded using some other security mechanism or algorithm. Authorised recipients may be provided with the means to unlock e.g. decode the secured data so that it can be read and used as appropriate by the recipient. The unlocking mechanism could, for example, be a key, an access code or some secret that is known to the recipient(s). The unlocking mechanism may be provided to the authorised recipient(s) by the communication generator/sender or a trusted party associated with or acting on behalf of them.

Additionally, or alternatively, at least a portion of the communication may be marked in some way such that a recipient can be assured that it has been generated and/or sent from or on behalf of a particular entity. The entity may be known by the recipient(s) as a legitimate or authorised source of communications and data. In some examples, the authenticity of the communication may be attested by the signing of at least a portion of the communication using a secret or private key that is known to belong to the legitimate entity. In other examples, the communication may comprise a watermark, secret code, steganography or message which can be used by the recipient(s) to verify that the communication has been sent from or on behalf of a legitimate source.

The "first seen Rule" and Double Spends

Satoshi Nakamoto's white paper, "Bitcoin: A Peer-To-Pe er Electronic Cash System", introduced the concept of the "first seen rule" in respect of transactions and blocks on the Bitcoin network.

According to this rule, when a mining node is evaluating a block in accordance with the protocol, it considers the first seen block to be the first valid block that was broadcast to the network and which is furthest from the Genesis block in a valid chain. This is important in respect of avoiding a "double spend" scenario.

As explained at the Bitcoin SV wiki (https://wiki.bitcoinsv.io/index.php/First_seen_rule):

"When two blocks are competing in an orphan race and a node is trying to build upon one of them, if a new block is discovered upon the competitor, the node will stop working on the block it saw first and move to the longest chain ... When receiving transactions, the first seen rule is applied to determine which transaction is valid in the case of a doublespend. When a node detects a double-spend, it always considers the transaction that it received first as the valid spender of that coin.

The rule has been extended further to add, any blocks which are discovered that include the double-spend transaction, those blocks should also be considered invalid and the node should continue to mine against it, unless a second block is discovered on top of that block, indicating a majority of the network has determined that the other transaction was the first seen. "

Therefore, it is vitally important to get communications out to the network as quickly as possible. Each "hop" that has to be made from node to node to completely distribute the information across the network costs time and, therefore, security of the network is decreased. At present, such communications are sent around the network using unicast transmissions, meaning that for each message there is one sender and one receiver, requiring multiple hops as the information is relayed from node to node.

However, in accordance with the present disclosure, a communication such as the notification of a double spend (or attempted/possible double spend) can be sent to the mining nodes in the multicast group(s) so that all relevant nodes receive the alert at the same time, as quickly as possible, and can take the necessary remedial action. There are no "hops" as the message is relayed from one node to another. Instead, each node that has joined the multicast group is listening to the subscription stream and will pick up the message themselves. Therefore, such embodiments provide improvements in terms of processing, time and security in respect of network communications and alerts.

In other example applications, the multicast group may comprise members who are not miners or full nodes on the network, but need to share blockchain-related information such as transactions, blocks, or parts of blocks. For example, one, some or all of the members might be merchants or other parties wishing to send, receive or otherwise process blockchain transactions. In some cases, the merchants may wish to perform an SPV verification of a transaction and need to share information regarding Merkle paths and block headers for use in the SPV verification. The block discovery creates a hash header or block header. These are sent to all SPV nodes. The use of multicast enables the delivery of this data in a near instant communication.

In another example, the sending resource may be a source of digital currency such as a central bank, and the receivers may be banks or other financial institutions that process that digital currency. The central bank may, for example, issue a Central Bank Digital Currency (CBDC). In respect of traditional cash, a minting source distributes the physical notes and coins to individual banks by transporting it in vehicles. With the case of digital cash, the distribution can be handled via a multicast group wherein the members of the group are the banks that the central bank wishes to distribute the funds to.

Example Use case 2: Distributed Blockchain Functionalities:

Embodiments can be used in respect of any type of data, and the sending and/or receiving resources can be arranged or operative to perform any type of functionality. In one non-limiting example, data relating to a Merkle challenge substantially as described in International patent application PCT/EP2023/051529 may be sent to a multicast group. In such a scenario, suppose that a resource wishes to delegate storage of a file or other resource to multiple storage providers so the sending resource generates a Merkle tree which represents various segments of the file and then sends the file to one or more storage providers. Later, when the sending resource wishes to confirm that a storage provider still has an unaltered copy of the data they were sent, the sender alters the data in a particular way, re-calculates the Merkle root for the tree, and asks the storage provider to make the same alteration to their copy and send back their recalculated Merkle root. The resource can quickly confirm whether the storage provider was able to provide the expected Merkle root. If the Merkle root that is sent back does not match what the resource expects it to be, the storage provider's copy must have been compromised or altered in some way. When used in conjunction with the present disclosure, the resource may send separate parts of the file to different storage providers, each of which are members of a given multicast group. When confirmation of the file's integrity is required, or re-assembly of the constituent parts is required, the resource requests this by poling the group.

In another example use case, the data that is sent to the multicast group is blockchain related data in the sense that it forms at least part of a blockchain transaction or block of transactions, at least part of a locking or unlocking script, or comprises data relating to a Merkle proof/path, or data for use in implementing a consensus mechanism e.g. PoW or PoS related data. The Merkle proof data may comprise data relating to a blockchain transaction and data for proving (or validating) that the transaction is contained within a particular block. Merkle proofs and their use for verifying the transactions in a block are known in the art, along with related techniques such as Simplified Payment Verification (SPV). Other, non-limiting examples of blockchain related data could include data for use with, or associated with, a consensus mechanism of a blockchain network. For example, this could be data relating to a proof-of-work PoW calculation or some other blockchain consensus mechanism. In one example, this could be data relating to a PoW calculation such as described in UK patent application number GB2206634.4. When used for blockchain-related purposes, at least one receiving resource in the group may be arranged, configured and/or operative to perform one or more of the following: a functionality specified and/or required/needed by a blockchain protocol; a calculation or other operation related to a mining or consensus function specified in a blockchain protocol; a Simplified Payment Verification (SPV) operation; a validation of a blockchain transaction before or after it has been written to a blockchain; a search of a blockchain to identify, locate and/or confirm the presence of a given transaction or block within a blockchain; generation of a blockchain transaction, submission of a transaction to the blockchain, and/or broadcast a transaction to a blockchain network.

Example Use case 3: Resolving Packet Loss

In other examples, a combination of multicast, anycast and unicast transmissions can be used to advantage by members of a multicast group to ensure or achieve incomplete receipt of data from a sending resource. Consider a scenario in which a sending resource wishes to send a portion of data to all members of a multicast group, but a receiving member of the group fails to receive all of the transmitted data. This is not an uncommon challenge within networking (see https://en.wikipedia.org/wiki/Packet loss).

Say, for example, a multicast transmission comprising 10 packets of data is sent to a multicast group but a particular group member (that we'll call the receiving resource) has only received 8 of the 10 data packets that were sent. The receiving resource is missing packets 2 and 7. The receiving resource may obtain the missing data packets by requesting them from the closest member of the multicast group using an anycast transmission. The receiving resource knows that the other group members will all have received the data transmission because it was sent to the multicast group.

This solution may be performed using the following method, comprising the steps:

1. using a multicast transmission to send a portion of data (e.g. comprised in a plurality of data packets) from a sending resource to a group of resources associated with a multicast address;

2. determining, at a resource within the group of resources, that the resource has not received the complete portion of data; 3. sending an anycast transmission from the resource to the closest other member of the multicast group requesting the missing sub-portions (packets) of the data that have not been received by the resource; and/or

4. receiving, at the resource from the closest other member of the multicast group, the missing (dropped) sub-portions of data. The missing sub-portions of data may be provided to the resource from the closest other member by any suitable method such as unicast.

This provides a solution to the technical problem of how to solve or address packet loss. The use of an initial transmission via multicast, combined with recovery of the dropped packets using an anycast request to the closest member and a unicast response providing the dropped data, provides an efficient and swift approach. As with other use case examples and embodiments, this technique can be utilised with any type of data, and by any type of resource including, but not limited to, blockchain related data/resources.

Example Use case 4: Efficient, cost effective balanced distribution using allocated address.

In another example, using the teaching herein, a resource B, as shown in Figures 16 to 20, referred to nominally as 'Bob' operates as a node e.g. node B, on a network e.g. a blockchain network as shown and described in relation to Figure 5. Bob operates to forward or route data, packets of data or other such packets of data across the network. Bob can communicate using any combination of multicast, anycast and unicast transmissions. Bob can also subscribe to a multicast group configured to receive communications from at least one multicast address. Bob, or any of the resources herein, may also communicate with anyone else on the network securely in a peer-to-peer manner using the teaching of W02017/145016, incorporated herein in its entirety.

Bob seeks to ensure that information essential to the stability of the network, such as a blockchain network, is communicated across the network efficiently and without delay. An example of essential information can be a new transaction - sharing the details of the transaction across the network is important to inhibit double-spending. It follows that Bob can share any transaction he generates and/or transactions he receives, e.g. from Alice, with the network.

Bob is not limited to sharing details of transaction he has generated, or received from Alice, but any packet of data or block of data received from the network. In an example where Bob is a blockchain node, he will have 125 inputs and 8 outputs. Bob, therefore, can subscribe to receive data from multiple sources e.g. multicast addresses, and transmit to multiple addresses e.g. multicast addresses. Data received and transmitted can include, by way of non-limiting example, packets of data of data listed in clause 9.16 herein. An example, however, uses the transmission of a transaction and, optionally, data associated with the transaction for validation e.g. SPV using a Merkle proof.

Transmitting packets of data, such as records or blocks of data across the network takes time to propagate. Transmitting to multicast addresses and/or receiving packets of data by subscribing to a multicast address or group improves the transmission. However, to minimise propagation delays and/or bottlenecks a set of packets of data e.g. a packet of data can be divided into sub-sets, with each sub-set allocated to a different address e.g. multicast address. By way of example, a block can be propagated according to the packets of data therein, or a property of the block, which determine an allocated address e.g. an allocated multicast group address to which it is transmitted.

Additionally or alternatively, the block can be divided into parts, with packets of data therein segregated and transmitted separately according to the 'key' determined for each of the packets of data therein.

By allocating sub-sets of packets of data to an address, the efficiency of transmission can be improved by inhibiting bottlenecks and load-balancing across the network. Allocation is determined from the packet of data itself, and using the example of a transaction received from Alice, Bob can process Alice's transaction and transmit it to an allocated address. Alice's transaction can be parsed and/or hashed to generate a key. The key can be derived from a binary or hexadecimal value of transaction data or hash, and the key can correspond to an allocated address, as shown and described in relation to Figures 17(a) to (d).

Bob, therefore, functions as a source of packets of data transmitted across the network. Bob can be the originator of the packet of data, or he can receive a packet of data, such as a transaction, directly from Alice. Rather than randomly transmitting the packet of data across the network Bob processes the packet of data to determine which allocated address to send the transmission to.

Further, Bob can consolidate packets of data and transmit to allocated addresses in blocks, said allocated addressed determined from the packets of data, which can be grouped according to their 'key' that is used to determine the allocated address. While Bob can generate a transaction, or receive a transaction from Alice, Bob also operates to receive packets of data from other nodes in the network. Upon receipt of packets of data or blocks of packets of data, Bob can at least one of: i. consolidate packets of data that were sent to allocated addresses e.g. multicast addresses that Bob subscribes to, and transmit those packets of data to corresponding allocated addresses, ii. consolidate packets of data that were sent to allocated addresses e.g. multicast addresses that Bob subscribes to, and processing e.g. parsing the packets of data therein to determine an allocate address for each of the corresponding packets of data and transmit those packets of data to their respective allocated addresses either individually or in blocks, said blocks holding packets of data sharing the same allocated address, and ill. receiving packets of data that were sent to allocated addresses e.g. multicast addresses that Bob subscribes to, processing e.g. parsing the packets of data therein to determine an allocate address for each of the corresponding packets of data and transmit those packets of data to their respective allocated addresses either individually or in blocks, said blocks holding packets of data sharing the same allocated address.

Bob can 'switch-on' and 'switch-off' his subscription to a group of receiving resources by sending a signal to a network, or ceasing to send the signal to the network. In this way, Bob can regulate the volume of packets of data received and/or transmitted according to at least one of: his capacity; a time window; a contracted period; network capacity and transmission levels e.g. are packets of data being reaching a threshold number of nodes within a threshold period of time.

ENUMERATED CLAUSES:

Enumerated clauses are now provided for the purpose of illustrating some possible embodiments that may be provided in accordance with the disclosure. The clause sets provided below are for illustration and not to be construed as limiting, exclusive or exhaustive. Features recited in one clause set may be utilised and incorporated into one or more of the other clause sets. In any one or more of the following clause sets, embodiments may provide a computer implemented method, and/or a data distribution method. Additionally, or alternatively, embodiments may provide improved data transmission or exchange methods or improved electronic communications.

A computer implemented data distribution method is disclosed. The method may comprise sending a portion of (e.g. blockchain-related) data from a sending resource to one or more groups of receiving resources; each of the one or more groups may be associated with a respective address; the address may be a multicast address. Phrased another way, groups of resources may be formed wherein, for each group, resources are subscribing members of the group, and all members are associated with an address that identifies that group. Embodiments of the disclosure may comprise the step of generating, creating or providing an IPv6 multicast address.

One some or all of the receiving resources may be a full node 104 on a blockchain network, or a node in an overlay network that sits on top of but communicates with one or more full node(s) on the blockchain network. The sending resource may be a full blockchain node 104 or a node on an blockchain overlay network that sits on top of but communicates with one or more full node(s) on the blockchain network. These features may apply to one or more of the clause sets provided below.

Some embodiments may provide solutions for implementing a mempool for a blockchain network.

Some embodiments may provide solutions for implementing a UTXO set for a blockchain network.

Also disclosed herein is:

• computer equipment comprising memory comprising one or more memory units and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any embodiment described or defined herein; and/or

• a computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any described or defined herein.

Clause set 1:

There may be provided:

Clause 1.1 - A method comprising: sending a transmission from at least one sending resource to at least one receiving resource; the sending and/or receiving resource may be a node on a network.

The sending and/or receiving resource may be a MLDvl host or MLDv2 host on a network, a network switch or a router. The transmission may be sent by the sending resource in accordance with a multicast forwarding table. Features recited in respect of clause set 8 may be incorporated into clause set 1 or any other clause set.

In accordance with an alternative (but not exclusive) wording, there may be provided: a computer implemented method comprising: sending a portion of blockchain-related data from a sending resource across a network to a multicast address associated with a group of receiving resources. The group of receiving resources may be one of a plurality of receiving resources, each group in the plurality being associated with a respective multicast address. In some embodiments, the blockchain related data may be sent to one, some or all of the groups. When it is sent to more than one group, the data is sent to the each of the respective multicast addresses for the groups that the data is being sent to.

The network may be a Peer-to-Peer (P2P) network and/or a distributed network. It may be a blockchain network wherein nodes on the blockchain network are operative to perform operations in accordance with a protocol of the blockchain. In other embodiments, the network may be the internet or a LAN or a VLAN or a telecommunications network, , or packet switching network 101.

The sending resource and/or at least one receiving resource may be arranged to perform operations in accordance with a protocol of a given blockchain. Additionally, or alternatively, the sending resource and/or at least one receiving resource may be a node on a blockchain network, a cryptocurrency exchange resource, a digital wallet, or a provider of blockchain related services. In some example embodiments, the at least one receiving node is not a node on the blockchain network; in other words, it may be external to the blockchain network, and/or may not be arranged to implement the blockchain protocol or perform consensus/protocol-related functionalities. Additionally, or alternatively, in some example embodiments the sending resource is not a node on the blockchain network.

Additionally, or alternatively, the sending resource and/or at least one receiving resource may be a resource that is arranged and/or operative to process blockchain-related data such as data pertain to any one or more of:

• blockchain transactions

• at least one unconfirmed blockchain transaction

• at least one unspent transaction output (UTXO)

• block-related data

• Merkle paths and/or proofs for verification or other purposes Proof-of-work and/or proof-stake operations or any other consensus operations blockchain mining operations blockchain related alerts or signals relevant or useable by some or all of: o nodes on a blockchain network; and/or o users of a blockchain network e.g. exchanges, wallets and providers of blockchain- related services.

The transmission may comprise (at least) data related to:

• one or more blockchain transactions; the data may comprise at least one whole transaction and/or part of at least one transaction;

• a block of blockchain transactions;

• at least one Merkle path and/or Merkle proof; the Merkle path/proof data may comprise at least part of a Merkle tree related to a block of transactions; it may be suitable for verification, e.g. an SPV style verification, or for confirmation that a given node or root is in a given path or tree, or for any one or more other purposes;

• a Proof-of-work and/or proof-stake operation, or any other consensus-related operation performed by a node on a blockchain network;

• one or more blockchain mining operations, such as those performed by a node on a blockchain network;

• blockchain related alerts or signals relevant or useable by some or all of: o nodes on a blockchain network; and/or o users of a blockchain network e.g. exchanges, wallets and providers of blockchain- related services, one or more nodes in an overlay network that is an overlay relative to the blockchain network.

The at least one sending resource may send the transmission to the at least one receiving resource in response to a request. The request may be sent by the at least one receiving resource, or by a further resource. The request may be received by the at least one sending resource from the at least one receiving request or the further resource. The request may comprise a request for data. The request may comprise blockchain related data such a data relating to one or more blockchain transactions or transaction IDs (TxIDs), one or more blockchain blocks or block header(s) and/or at least part of a Merkle path or proof. The data may be transmitted across an electronic network as/in the form of one or more packets of data ("data packets"). Preferably these are IPv6 packets.

Clause 1.2 The method of clause 1.1 wherein the transmission is performed over a public network such as the Internet; preferably wherein: the transmission is an IPv6 transmission, an IPv4 transmission, an anycast transmission or a multicast transmission.

Clause 1.3 The method of clause 1.1 or 1.2 wherein the sending resource and/or at least one receiving resource: is a member of an anycast group; and/or is a member of a multicast group.

Clause Set 2:

Additionally or alternatively, one or more embodiments of the disclosure can be defined in accordance with the following clauses. Any of the clauses defined in clause set 2 may be combined with one or more of the clauses of any other clause set provided herein, or any other feature disclosed herein.

Clause 2.1 A method comprising: sending, by a receiving resource, a request for blockchain-related data to a sending address associated with members of one of a plurality of groups of sending resources on a network; and receiving blockchain-related data from at least one sending resource of the group in response to the request.

The sending address may be a sending anycast address or multicast address. The method may be a computer-implemented data distribution method. Additionally, or alternatively, it may be an improved data transmission or exchange method or electronic communication method.

Clause 2.2 The method of clause 2.1, wherein receiving the blockchain-related data comprises receiving the blockchain-related data via a unicast or multicast transmission from the at least one sending resource.

Clause 2.3 The method of clause 2.2 or 2.1, wherein receiving the blockchain-related data comprises receiving the blockchain-related data via an anycast transmission from the at least one sending resource. Clause 2.4 The method of any preceding clause, wherein the received blockchain-related data comprises one or a plurality of portions of blockchain-related data received from a plurality of members of the group.

Clause 2.5 The method of clause 2.4 wherein each portion of blockchain-related data comprises a hash of the respective portion.

Clause 2.6 The method of any preceding clause, comprising sending an anycast or multicast query transmission and receiving, (from a nearest sending resource), at least part of: a blockchain block, a blockchain transaction and/or a Merkle path in response to the anycast or multicast query transmission.

Clause 2.7 The method of any preceding clause, wherein the sending address is associated with sending resources which are in possession of a complete copy of a blockchain block.

Clause 2.8 The method of clause 2.7, comprising receiving, from a (topologically) nearest receiving resource, an anycast or multicast query transmission and sending, to the (topologically) nearest receiving resource, at least part of: a blockchain block, a blockchain transaction and/or Merkle path in response to the anycast or multicast query transmission.

Clause 2.9 A method (e.g. computer implemented data distribution method) comprising: sending, by a sending resource, blockchain-related data to a receiving address associated with members of one of a plurality of groups of receiving resources on a network. The receiving address may be an anycast or multicast address.

Clause 2.10 The method of any preceding clause, wherein the blockchain-related data comprises a hash of the data.

Clause 2.11 The method of clause 2.9 or 2.10, comprising de-assigning the sending resource from a sending address.

Clause 2.12 The method of clause 2.12, wherein the de-assigning is performed in response to a determination that a predetermined condition has been met e.g. that the blockchain-related data was sent to a predetermined number of receiving resources, and/or that a certain amount of time has elapsed, or a given date and time is reached etc

Clause 2.13 The method of clause 2.12, wherein the de-assigning is performed in response to a determination that a preselected time period has elapsed.

Clause Set 3:

Additionally or alternatively, one or more embodiments of the disclosure can be defined in accordance with the following clauses. Any of the clauses defined in clause set 3 may be combined with one or more of the clauses of any other clause set provided herein, or any other feature disclosed herein. Clause 3.1. A computer implemented data distribution method comprising: sending a portion of blockchain-related data from a (or at least one) sending resource on a network to one or more groups of receiving resources on a/the network, wherein each of the one or more groups is associated with a respective multicast address. The network may be the internet. In a preferred embodiment, all receiving resources in each group shares a common multicast address that is unique for that group; each group of resources has a respective multicast address that all of the group's members subscribe to in order to receive multicast transmissions sent to that group's shared multicast address.

The at least one sending resource may send the portion of data via a transmission. The data portion(s) may be sent to the at least one group of receiving resources in response to a request or as part of a request. The request may comprise a request for data. The request may comprise blockchain related data such a data relating to one or more blockchain transactions or transaction IDs (TxIDs), one or more blockchain blocks or block header(s) and/or at least part of a Merkle path or proof. The data may be sent via the internet.

Clause 3.2. A method according to claim Clause 3.1 wherein the sending resource and/or one, some or all of the receiving resources in at least one of the one or more groups is/are or comprises: a node in a network; this may be a blockchain network or the internet or a telecommunications network; or a node in an overlay network that is an overlay relative to the (underlying) blockchain network; a computing resource associated with or controlled by a financial institution; a merchant resource; a cryptocurrency exchange; a computing resource arranged to perform or facilitate an SPV verification, or use the result of an SPV verification; a provider of blockchain-related services; and/or a digital wallet.

Clause 3.3. A method according to Clause 3.1 or Clause 3.2, wherein the data comprises: a communication or alert relating to a blockchain related event or activity. Clause 3.4. A method according to Clause 3.3, wherein the alert relates to a double spend or double spend attempt within the blockchain network.

Clause 3.5. A method according to any preceding clause, wherein the blockchain related data comprises one, some or all of: i) at least part of a blockchain transaction; ii) at least part of a blockchain block; iii) at least part of a blockchain transaction script; iv) at least part of a Merkle path, Merkle tree or Merkle proof; v) data for use with, or associated with, a consensus mechanism of a blockchain network vi) the result of a proof or stake or proof of work operation; vi) the result of a verification operation comprising the verification of a blockchain block or an SPV verification.

Clause 3.6. A method according to any preceding clause, wherein the blockchain-related data is sent by the sending resource to the one or more groups of receiving resources using a multicast communication.

Clause 3.7. A method according to any preceding clause, wherein: i) the multicast address is an IP multicast address; and/or ii) the multicast address is a IPv6 multicast address; and/or iii) the blockchain-related data is sent to the one or more groups of receiving resources over the Internet.

Clause 3.8. A method according to any preceding clause wherein: each of the one or more groups of receiving hosts comprises one or a plurality of receiving resources; and/or each receiving peer within a given group of receiving resources is operative to receive data sent to the multicast address of the particular group of receiving resources.

Clause 3.9. a method according to any preceding clause and comprising the step: subscribing, by a resource, to a group of receiving resources; preferably wherein the resource subscribes by sending a signal to a/the network; (the network may be the internet) leaving, by a resource, a group of receiving resources; preferably wherein the resource leaves the group by ceasing to send a signal to the network.

Clause 3.10. A method according to any preceding clause wherein: the sending and/or at least one receiving resource in the at least one or more groups of receiving resources is arranged, configured and/or operative to perform one or more of the following: a functionality specified by a blockchain protocol; a calculation or other operation related to a mining or consensus function specified in a blockchain protocol; a Simplified Payment Verification (SPV) operation; the calculation or verification of a Merkle path, proof or root of a Merkle path; a validation of a blockchain transaction before or after it has been written to a blockchain; a search of a blockchain to identify, locate and/or confirm the presence of a given transaction or block within a blockchain; generate a blockchain transaction, write a transaction to the blockchain, and/or broadcast a transaction to a blockchain network.

Clause 3.11. A method according to any preceding claim and comprising the step of: poling each of the one or more groups for a target response by sending the portion of blockchain-related data from the sending resource to the one or more groups of receiving resources.

Clause 3.12. A computer-implemented method comprising the steps: sending a multicast communication to a group of resources on a blockchain network.

Clause 3.13. A method according to clause 12, wherein at least one, some or all of the following apply: i) the communication is sent from a sending resource to the group of resources; ii) the group of resources is a multicast group, and one or some of the resources in the group of resources is a receiving resource of the multicast group; iii) the communication relates to a double spend or double spend attempt within the network; iv) the communication is an alert.

Clause 3.14. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of Clauses 3.1 to 3.13.

Clause 3.15. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of clauses 3.1 to 3.13.

Clause set 4:

Additionally, or alternatively, one or more embodiments of the disclosure can be defined in accordance with the following clauses. Any of the clauses defined in clause set 4 may be combined with one or more of the clauses of any other clause set provided herein, or any other feature disclosed herein.

Clause 4.1. A method comprising the steps: sending a multicast communication from a sending resource to at least one group of resources, wherein preferably: i) the sending resource and/or at least one resource in the at least one group is or comprises: a node on a blockchain network; and/or a digital wallet or a digital wallet provider; and/or a cryptocurrency exchange; and/or a resource associated with one or a plurality of blockchain mining nodes; and/or a service provider arranged to provide blockchain-related services to one or more users.

Clause 4.2. A method according to clause 4.1, wherein: i) the communication is sent over a public network, preferably the Internet; and/or ii) the at least one group of resources is a multicast group comprising member resources arranged or operative to receive communications sent to a (multicast) address associated with the multicast group; and/or iii) the communication relates to a double spend or double spend attempt within the network; and/or iv) the communication is an alert or other communication comprising blockchain-related data. Clause set 5:

Additionally, or alternatively, one or more embodiments of the disclosure can be defined in accordance with the following clauses. Any of the clauses defined in clause set 5 may be combined with one or more of the clauses of any other clause set provided herein, or any other feature disclosed herein.

Embodiments disclosed herein may provide methods and techniques for improved electronic communications between resources over a network. The embodiments may be arranged to ensure or improve the reliability of a data exchange between the parties or transfer from one to another of the parties. In one possible form of wording, such an embodiment may comprise a method which includes one, some or all of the following steps:

Sending at least one data packet across an electronic network from one or more sending resources to one or more receiving resources. The one or more resources may be members of a multicast group. In other words, they may be subscribers to a common (shared) multicast address; additionally, or alternatively, one or more of the receiving resources may be associated with a shared anycast address; in some cases, the one or more sending resources may also be associated with the shared multicast and/or anycast address; the at least one data packet may be sent to the shared multicast address.

The at least one data packet may be received by at least one of the receiving resources;

The method may further comprise one or more of:

• Determining, by the at least one receiving resource and upon receipt of the at least one data packet, whether at least one further data packet should be received (or is required) by the at least one receiving resource;

• Sending, from the at least one receiving resource to at least one further resource, a request for the at least one further data packet; preferably wherein:

■ the at least one further resource is a member of the multicast group; and/or

■ the at least one further resource is a member of the anycast group; and/or

■ the request is sent using a multicast transmission, an anycast transmission or a unicast transmission;

• Receiving the request for the at least one further data packet from the at least one receiving resource by the at least one further resource; • Sending the at least one further data packet from the at least one further resource to the at least one receiving resource; preferably wherein the at least one data packet is sent to the at least one receiving resource using a unicast transmission.

In an alternative form of wording, such an embodiment may be described as provided in the following clauses. Features from the preceding method may be included in any of the clauses below and vice versa.

Clause 5.1. A method comprising the steps: sending a request from a (request) sending resource that is a member of resource group to at least one further resource that is a member of the resource group, wherein preferably: i) the request comprises a request for one or more packets of data; and/or ii) the request is sent as a result of an incomplete receipt of a data transmission sent to the sending resource, preferably wherein the incomplete data transmission was sent to the sending resource and/or at least one further resource via or by a multicast transmission sent to the resource group; and/or iii) the request is sent as any anycast transmission to the (topologically) closest resource in the resource group relative to the sending resource; and/or iv) the request is sent as any multicast transmission to the (topologically) closest resource in the resource group; and/or v) the request is sent as a result of an incomplete receipt (by the sending resource) of a data transmission sent (by a data sending resource) to the (request) sending resource, preferably wherein the request comprises a request for at least one portion (e.g. packet) of data that the (request) sending resource has failed to receive as a result of incomplete receipt of the data transmission.

Clause 5.2. A method according to clause 5.1 wherein the sending resource and/or at least one further resource is or comprises: a node on a blockchain network; and/or a digital wallet or a digital wallet provider; and/or a cryptocurrency exchange or component thereof; and/or a resource associated with or in communication with one or a plurality of blockchain mining nodes; and/or a service provider arranged to provide blockchain-related services to one or more users; and/or a resource arranged to perform, facilitate or use the result of an SPV verification, the resource may comprise software operative to perform or facilitate a Simplified Verification Payment (SPV) operation, or process the result of an SPV operation.

Clause 5.3. A method according to clause 5.1, or 5.2 wherein: i) the communication is sent over a public network, preferably the Internet; and/or ii) the at least one group of resources is a multicast group comprising member resources arranged or operative to receive communications sent to a (multicast) address associated with the multicast group; and/or iii) the communication relates to a double spend or double spend attempt within the network; and/or iv) the communication is an alert or other communication comprising blockchain-related data; and/or v) the communication comprises blockchain-related data and/or at least part of a Merkle path or Merkle tree; and/or vi) data for performing or facilitating an SPV-style verification.

Clause 5.4. A method according to clause 5.1, 5.2 or 5.3, and comprising the step providing, from the further resource to the (request) sending resource, one or more portions of data.

Also in accordance with one or more embodiments there may be provided a method comprising: providing, in response to a request from a (request) sending resource, at least one portion of data to the (request) sending resource; preferably, the (request) sending resource is a member of resource group and the at least one portion of data is provided to the sending resource by or from a further resource that is a member of the resource group; and wherein preferably: i) the request comprises a request for one or more packets of data; and/or ii) the request is sent to the further resource as a result of an incomplete receipt of a data transmission sent to the sending resource, preferably wherein the incomplete data transmission was sent to the (request) sending resource and/or at least one further resource via or by a multicast transmission sent to the resource group; and/or iii) the request is sent as any anycast transmission to the (topologically) closest resource in the resource group relative to the sending resource; and/or iv) the request is sent as any multicast transmission to the (topologically) closest resource in the resource group; and/or v) the request is sent as a result of an incomplete receipt (by the sending resource) of a data transmission sent (by a data sending resource) to the (request) sending resource, preferably wherein the request comprises a request for at least one portion (e.g. packet) of data that the (request) sending resource has failed to receive as a result of incomplete receipt of the data transmission.

Clause set 6:

Additionally, or alternatively, one or more embodiments of the disclosure can be defined in accordance with the following clauses. Any of the clauses defined in clause set 6 may be combined with one or more of the clauses of any other clause set provided herein, or any other feature disclosed herein.

Clause 6.1 A method comprising one or more of the following steps:

1. Forming or providing a group (set) of network nodes;

2. Associating the group of nodes with multicast address; these nodes are now group members of the multicast i.e., they listen to the multicast address; in another form of wording, steps 1 and 2 can be phrased as: joining, by one or more nodes, a multicast group;

3. Promoting/advertising/communicating an available service and/or resource, wherein the promoting/advertising/communicating of the service is performed by one or more nodes/members of the group to one or more recipients on a network; the network may or may not be a blockchain network; this communication may be or comprise an invitation to send data to the group members via the multicast address;

4. Promoting/advertising/communicating, by the one or more nodes/members, the group's shared multicast address to the one or more recipients on the network; in one or more embodiments, this may comprise inviting or requesting that the recipient(s) send (e.g. blockchain related) data to the group members at the group multicast address e.g. inviting or requesting blockchain mining nodes to send one or more new blocks to the group's shared multicast address, or transactions, Merkle trees, etc or parts thereof; in some embodiments, step 4 (i.e. sharing of the multicast address) may be combined with step 3 (i.e. the advertising of the service to recipients on the network);

5. Promoting/advertising/communicating, by one or more nodes/members of the group, a unique anycast address to the network recipients;

6. Mining, by a blockchain mining node, a new block or blockchain transactions;

7. Sending the new block from the mining node to the group's shared multicast address; note; in other embodiments the data requested by the group member(s) and send to them by the network recipients may not comprise or be related to blockchain data such as blocks or transactions; in some embodiments the data could be any type of data, or could be blockchain related data such as whole or partial blocks, whole or partial transactions, data for consensus-related operations, data for validating transactions and/or blocks, data for SPV style verifications, whole or parts of Merkle trees/paths etc

8. Routing the data (e.g. a block or part of a block) to all members of the multicast group; this may be performed over the Internet, using IPv6 transmission

9. intermittently sending, from the one or more nodes/members, requests to the anycast address of the multicast group; preferably, the request includes the unicast address of the sending node;

10. associating a node (member) with the previously promoted anycast address; preferably wherein this is performed upon receipt of a new block or other type of data;

11. Sending, by the node/member a copy of the data (e.g. block or part of a block) to the requesting node via a unicast transmission; this may be performed if a node (multicast group member) with the anycast address receives a request for a copy of the new block;

12. de-assigning the node/group member from the anycast address; in some examples, this is performed upon determination that a predetermined amount of time has passed or a predetermined criteria has been met;

13. listening, by the node/group member, for new data transmissions send to the group's multicast address

One or some of the above noted steps can be omitted or performed in a different order from that shown above, or may be conflated with one or more other steps.

Clause set 7:

Additionally, or alternatively, one or more embodiments of the disclosure can be defined in accordance with the following clauses. Any of the clauses defined in clause set 7 may be combined with one or more of the clauses of any other clause set provided herein, or any other feature disclosed herein.

A method according to this embodiment may be substantially as described herein, and in particular with respect to block header propagation. In accordance with one possible for of wording, such an embodiment may comprise a computer-implemented method that includes the step of sending data from a sending node to a plurality of receiving nodes. Preferably, each of the receiving nodes is associated with an IPv6 multicast address. The data may comprise at least part of a block header of (for) a blockchain block; and a list of one or more blockchain transactions included in the blockchain block that the header relates to.

The method may further comprise the step of using the data, by at least one of the receiving nodes, to identify at least one further blockchain transaction (i.e. at least one "missing" transaction) that the at least one receiving node needs in order to generate the blockchain block. In other words, the at least one receiving node will only be able to generate a complete, full version or copy of the blockchain block if it has a) the blockchain header and b) a complete list of the transactions that are contained in that block. Therefore, the at least one receiving node may perform a check to identify any further transactions that it needs, which were not included in the list sent by the sending node. Identification of the at least one further blockchain transaction may comprise searching for the at least one further blockchain transaction in a stored set of blockchain transactions. The set of stored transactions may be maintained by the at least one receiving node. Additionally or alternatively, it may be accessible to the at least one receiving node or available for access by the node.

The method may comprise the step of obtaining the at least one further (missing) transaction from the stored set of blockchain transactions and using the at least one further transaction and the list of blockchain transaction(s) to generate the blockchain block.

However, if the at least one further transaction is not found in the set of stored transactions, the method may comprise the step of sending a request for the at least one further blockchain transaction from the at least one receiving node to one or more of: the sending node, or the IPv6 multicast address, or one or more further nodes. The method may comprise the step of receiving the request by the sending node from the at least one receiving node; and sending a transmission from the sending node to the at least one receiving node, the transmission comprising the at least one further blockchain transaction. The transmission may be a unicast transmission. Additionally, or alternatively, the embodiment may be described in the following clauses. Any feature included in any of these clauses may also be incorporated into or combined with the preceding method steps and vice versa.

Clause 7.1 A computer-implemented method comprising the step: sending, from a sending node to a multicast address, (at least part of) a block header and a list of one or more blockchain transactions and/or blockchain transaction identifiers (TxIDs); preferably wherein the (IPv6) multicast address is subscribed to by a plurality of receiving (i.e. subscribing) nodes.

In some embodiments, the sending node and/or at least one of the receiving nodes is a node on a blockchain network. Preferably the multicast address is an IPv6 multicast address.

Clause 7.2: A method according to 7.1, and comprising the step: using, by at least one but preferably all of the receiving nodes, the received information to identify any missing transaction(s) the at least one receiving node needs in order to generate a complete block having the block header; preferably wherein, a transaction is a missing transaction if it is in the list of one or more transactions but not included in a set of transactions e.g. mempool that is maintained by the at least one receiving node and/or accessible by the at least one receiving node.

Clause 7.3: A method according to 7.1 or 7.2, and comprising the step: if the receiving node identifies any missing transaction(s), sending a request from the at least one receiving node to the sending node (preferably via a unicast transmission) or the multicast group (preferably via a multicast or anycast transmission) for the missing transaction(s) or transaction identifier(s); preferably, the request comprises the respective transaction identifier(s) (TxIDs) for the requested missing transaction(s).

Clause 7.4: A method according to 7.1, 7.2 and/or 7.3, and comprising the step: receiving the request by the sending node from the receiving node.

Clause 7.5: A method according to 7.1, 7. 2, 7.3 and/or 7.4, and comprising the step: sending a transmission from the sending node to the receiving node, the transmission comprising the requested, missing transaction(s) and/or transaction identifier(s); preferably wherein, the transmission is a unicast transmission; the unicast transmission is preferably sent only to the individual receiving node that has sent the request.

The method may further comprise: using the list of one or more transactions/TxIDs and the at least one requested, missing transaction(s) and/or transaction identifier(s) to generate a blockchain block comprising the block header. This may be performed upon receipt of the transmission by the receiving node. The receiving node may then perform one or more blockchain-related operations e.g. a verification or validation operation.

Clause set 8:

Additionally, or alternatively, one or more embodiments of the disclosure can be defined in accordance with the following clauses. Any of the clauses defined in clause set 8 may be combined with one or more of the clauses of any other clause set provided herein, or any other feature disclosed herein.

8.1 A method comprising the steps: sending a transmission (communication) across an electronic network to a multicast address from a sending resource that has Multicast Listener Device (MLD) snooping enabled; and wherein: i) the transmission comprises blockchain-related data; and/or ii) the multicast address is associated with at least one receiving resource that is: a node in a network; this may be a blockchain network or the internet or a telecommunications network; a computing resource associated with or controlled by a financial institution; a merchant-controlled resource; a cryptocurrency exchange or component thereof; a computing resource arranged to perform or facilitate an SPV verification, or use the result of an SPV verification; a provider of blockchain-related services; and/or a digital wallet or component thereof; and/or a resource comprising software operative to perform or facilitate a Simplified Verification Payment (SPV) operation, or process the result of an SPV operation iii) the transmission is or comprises data relating to an alert, preferably wherein the alert is related to, relevant to or arranged for utilisation by one or more nodes on a blockchain network; and/or iv) the transmission comprises: blockchain-related data and/or at least part of a Merkle path or Merkle tree; and/or data for performing or facilitating an SPV-style verification, or using the result of an SPV verification.

One or more receiving resources may be associated with the multicast address. In other words: at least one receiving resource may be subscribed to (i.e. listening to) the multicast address. The receiving resource(s) may be referred to as a multicast group. The multicast address may be an IPv6 address. The sending resource and/or receiving resource(s) may be devices or systems on a network. This may be a physical network or a logical network. It may be a VLAN. The sending resource may be a multicast router.

Clause 8.2 A method according to clause 8.1, wherein the sending resource is operative to send the transmission to a list of one or more device ports on the electronic network that have indicated or signalled an interest or intent to receive the transmission.

The list may be an IPv6 multicast forwarding table or database.

Clause 8.3 A method according to clause 8.1 or 8.2 wherein: i. the sending resource is configured and/or operative to monitor MLD messages between receiving resources and/or multicast routers; and/or ii. the sending resource may inspect or utilise the (monitored) MLD messages to generate a list of IPv6 addresses and the respective network interfaces that are connected to the receiving resource(s).

Clause 8.4 A method according to any preceding clause of clause set 8, wherein the sending resource is operative to: i) send the transmission only to network interfaces that are connected to respective receiving resources which are associated with (subscribed to/listening to network traffic addressed to) the multicast address; and/or ii) not send the transmission if no receiving resources are associated with the multicast address. Clause 8.5 A method according to any preceding clause of clause set 8, wherein:

One or more of the receiving resources is operative to send a membership report comprising a list of source addresses. The membership report may be sent in INCLUDE or EXCLUDE mode.

The sending and/or receiving resources may be operative to implement MLD Snooping substantially as described in the art at: https://www.juniper.net/documentation/us/en/software/junos/m ulticast/topics/concept/mld- snooping-overview-l2.html.

Clause set 9:

Additionally, or alternatively, one or more embodiments of the disclosure can be defined in accordance with the following clauses. Any of the clauses defined in any of clause sets 1 to 8 may be combined with one or more of the clauses of any other clause set provided herein, or any other feature disclosed herein.

Clause 9.1 A computer-implemented method comprising: sending and/or receiving resource for generating, storing, processing, accessing and/or maintaining a packet of data, said packet of data preferably including blockchain related data; determining from the packet of data an allocated address; and sending, at least in part, a transmission of the packet of data from the sending resource across an electronic network to the allocated address.

Clause 9.2. The method of clause 9.1, wherein the allocated address is a multicast address associated with a group of receiving resources.

Clause 9.3. The method of any preceding clause, wherein the record includes at least one of: a portion of a transaction (Tx); an output identifier; a hash of a script; the transaction identification (TXID); a blockchain block; and a block header. The output identifier may be an identifier associated with an output in the blockchain transaction (Tx). For example, it may be a UTXO identifier. The hash of a script may be a hash of a script associated with an output of the transaction (Tx) (e.g. a UTXO script).

Clause 9.4. The method of any preceding clause, wherein determining the allocated address includes processing the packet of data to determine a key, and selecting at least one address from a set of addresses using the key, said processing preferably including parsing the packet of data. Clause 9.5. The method of any preceding clause, wherein the sending resource holds, provides or comprises a data structure including a set of allocated addresses associated with a corresponding set of keys.

Clause 9.6. The method of any preceding clause, wherein the sending resource generates, stores, processes, accesses and/or maintains a (blockchain) block (of zero or more blockchain transactions) comprising a plurality of packets of data, wherein each of the packets of data in the block includes blockchain related data.

The method may comprise the step of: determining for each packet of data in the block an allocated address; and sending, at least in part, a transmission of each packet of data in the block from the sending resource across an electronic network to the respective allocated address.

Clause 9.7. The method of clause 9.6, wherein the block is split into sub-blocks, and the sending resource transmits each sub-block across an electronic network to a corresponding allocated address.

Clause 9.8. The method of clause 9.6 or 9.7, wherein the plurality of packets of data are split in to eight sub-blocks, each sub-block being sent to a corresponding allocated address.

Clause 9.9. The method of any preceding clause, wherein the sending resource additionally or alternatively operates as a receiving resource, the method further comprising: receiving the packet of data and/or the plurality of packets of data, and at least one of: propagating the packet of data to the allocated address. Preferably, propagating the block comprises transmitting a plurality of packets of data to the respective allocated addresses; consolidating the block and/or transmitting the plurality of packets of data for propagation to corresponding allocated address.

Additionally, or alternatively, the method may comprise the step of collecting at least one of the packet of data, plurality of packets of data or block - and then parsing each packet of data to determine a key and propagating each packet of data to at least one address from a set of addresses, using the key.

Clause 9.10. The method of any preceding clause, wherein the sending or receiving resource subscribes to at least one receiving resource and/or at least one multicast group. Clause 9.11. The method of clause 9.10, wherein the sending or receiving resource subscribes to a multicast address configured to receive at least one packet of data allocated to said multicast address. Preferably, said allocation is determined from the at least one packet of data.

Clause 9.12. The method of clause 9.10 or 9.11, further including the sending resource: subscribing to a group of receiving resources by sending a signal to a network, such as the internet and/or a blockchain network; and/or leaving a group of receiving resources, preferably wherein the resource leaves the group by ceasing to send a signal to the network. Aspects of clause 9 can be combined with clause 9.2.

Clause 9.13. The method of any preceding clause, wherein the packet of data comprises: a communication, notification, message or alert relating to a blockchain related event or activity.

Clause 9.14. The method of any preceding clause, wherein the alert relates to a double spend or double spend attempt within a blockchain network.

Clause 9.15. The method of any preceding clause, wherein the sending and/or receiving resource is arranged, configured and/or operative to perform one or more of the following: a functionality specified by a blockchain protocol; a calculation or other operation related to a mining or consensus function specified in a blockchain protocol; a Simplified Payment Verification (SPV) operation; the calculation or verification of a Merkle path, proof or root of a Merkle path; a validation of a blockchain transaction before or after it has been written to a blockchain; a search of a blockchain to identify, locate and/or confirm the presence of a given transaction or block within a blockchain; generate a blockchain transaction, write a transaction to the blockchain, and/or broadcast a transaction to a blockchain network.

Clause 9.16. The method of any preceding clause, wherein the packet of data comprises at least one of: at least part of a blockchain transaction; at least part of a blockchain block; at least part of a blockchain transaction script; a Merkle Tree of the block in which said packet of data is recorded; the Merkle root the block in which said packet of data is recorded; a Merkle path, which enables the determination of the value for the Merkle root for the block in which said packet of data is recorded, from a hash of said packet of data; a Merkle proof; data for use with, or associated with, a consensus mechanism of a blockchain network the result of, or data relating to, a proof-of-stake or proof-of-work operation; a block identifier (blockJD) associated with the blockchain block; a transaction identifier (TxID) associated with a transaction (Tx) in the plurality of blockchain transactions within the blockchain block; a function of the block identifier (blockJD) and the transaction identifier (TxID); a concatenation of the block identifier (blockJD) and the transaction identifier (TxID); a digital signature; an authentication code; a signature message for determining a transactional state; a protocol flag; a discretionary public key (DPK); and a discretionary transaction ID (DTxID).

Clause 9.17. The method of any preceding clause, wherein the sending and/or receiving resource is comprises: a node in a blockchain network; a service provider arranged to provide a blockchain-related service; a computing resource associated with or controlled by a financial institution; a cryptocurrency exchange or component thereof; a merchant resource or component thereof; a digital wallet or component thereof; a software component operative to perform or facilitate a Simplified Verification Payment (SPV) operation, or process the result of a SPV operation; a MLDvl host or MLDv2 host on a network, a network switch or a router.

Clause 9.18. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of clauses 9.1 to 9.17.

Clause 19. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of clauses 9.1 to 9.17.

Clause set 10:

Additionally, or alternatively, one or more embodiments of the disclosure can be defined in accordance with the following clauses. Any of the clauses defined in any of clause sets 1 to 9 may be combined with one or more of the clauses of any other clause set provided herein, or any other feature disclosed herein.

Clause 10.1 A computer-implemented method comprising: operating a sending resource for generating, storing, processing, accessing and/or maintaining a packet of data, said packet of data preferably including blockchain related data; and sending, at least in part, a transmission of the packet of data from the sending resource across an electronic network to a multicast group, wherein the multicast group makes available the packet of data for an end-user. The packet of data can be made available through controlled access. The controlled access can be managed (i) via controlled access to the multicast group e.g. via subscription, and/or (ii) controlled access to a packet of data. Controlled access can be configured by the sending resource e.g. by implementing controlled access to the multicast group, and/or by securing the packet of data prior to transmission.

Clause 10.2. The method of clause 10.1, further comprising: a receiving resource for storing, processing, accessing and/or maintaining the packet of data.

Clause 10.3. The method of clause 10.2, wherein: the receiving resource subscribes to the multicast group or another multicast group for receiving the packet of data or another packet of data.

Clause 10.4. The method of any preceding clause, wherein: the sending resource transmits a plurality of packets of data, and/or the receiving resource receives a plurality of packets of data.

Clause 10.5. The method of any preceding clause, wherein packet of data is, at least in part, a data stream, such as a multimedia communication channel. Clause 10.6. The method of any preceding clause, wherein the packet of data has sub-components for providing a plurality of data channels.

Clause 10.7. The method of any preceding clause, wherein the packet of data and/or access to the multicast group is secured and accessible using an access-key and/or a smart contract.

Clause 10.8. The method of clause 10.7, wherein a first access-key is required to access the packet of data, and a second access-key is required to access the multicast group.

Clause 10.9. The method of clause 10.7 or 10.8, wherein the sending resource generates the accesskey, and sends the required access-key to at least one of the receiver and an end-user of the packet of data for accessing the packet of data.

Clause 10.10 The method of clause 10.9, wherein the access-key is provided during an exchange using a payment channel and/or a smart contract.

Clause 10.11. The method of any of clauses 10.7 to 10.10, wherein the access-key provides access to the multicast group and/or packet of data for at least one of (i) a fixed period of time, (ii) a fixed quantity of data, (iii) a fixed quantity of units, (iv) a fixed number of packets of data, and (v) unlimited access.

Clause 10.12. The method of any of clauses 10.4 to 10.11, wherein: the sending resource transmits the plurality of packets of data to respective allocated addresses, wherein the allocated addresses are determined from the respective packets of data, or the access key; and/or the receiving resource receives the plurality of packets of data from at least one multicast group and aggregates the packets of data.

Clause 10.13. The method of clause 10.12, wherein the allocated address is a multicast address associated with a group of receiving resources.

Clause 10.14. A computer-implemented method comprising: operating a receiving resource for storing, processing, accessing and/or maintaining a packet of data, said packet of data preferably including blockchain related data; and receiving, at least in part, a transmission of a packet of data via a multicast group that received the packet of data from an electronic network, and consuming the packet of data as an end-user.

Clause 10.15. The method of clause 10.14, wherein the packet of data and/or access to the multicast group is secured and accessible using an access-key, preferably obtained via a payment channel.

Clause 10.16. The method of any preceding clause, wherein the packet of data includes at least one of: a portion of a transaction (Tx); an output identifier; a hash of a script; a transaction identification (TXID); a blockchain block; and a block header. The output identifier may be, for example, a UTXO. The script may be associated with an output provided within a blockchain transaction.

Clause 10.17. The method of any preceding clause, wherein the packet of data comprises at least one of: at least part of a blockchain transaction; at least part of a blockchain block; at least part of a blockchain transaction script; a Merkle Tree of the block in which said packet of data is recorded; the Merkle root the block in which said packet of data is recorded; a Merkle path, which enables the determination of the value for the Merkle root for the block in which said packet of data is recorded, from a hash of said packet of data; a Merkle proof; data for use with, or associated with, a consensus mechanism of a blockchain network the result of, or data relating to, a proof-of-stake or proof-of-work operation; a block identifier (blockJD) associated with the blockchain block; a transaction identifier (TxID) associated with a transaction (Tx) in the plurality of blockchain transactions within the blockchain block; a function of the block identifier (blockJD) and the transaction identifier (TxID); a concatenation of the block identifier (blockJD) and the transaction identifier (TxID); a digital signature; an authentication code; a signature message for determining a transactional state; a protocol flag; a discretionary public key (DPK); and a discretionary transaction ID (DTxID).

Clause 10.18. The method of any preceding clause, wherein the sending and/or receiving resource comprises: a node in a blockchain network; a service provider arranged to provide a blockchain-related service; a computing resource associated with or controlled by a financial institution; a cryptocurrency exchange or component thereof; a merchant resource or component thereof; a digital wallet or component thereof; a software component operative to perform or facilitate a Simplified Verification Payment (SPV) operation, or process the result of a SPV operation; a MLDvl host or MLDv2 host on a network, a network switch or a router.

Clause 10.19. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of clauses 10.1 to 10.18.

Clause 10.20. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of clauses 10.1 to 10.18.

Clause Set 11:

Additionally or alternatively, one or more embodiments of the disclosure can be defined in accordance with the following clauses. Any of the clauses defined in clause set 11 may be combined with one or more of the clauses of any other clause set provided herein, or any other feature disclosed herein. The method may be described as a network security solution and/or an (electronic) communication or data transfer solution.

11.1 A computer-implemented method comprising: sending, by a sending resource, a blockchain or cryptocurrency-related communication to an IPv6 multicast address for receipt by at least one receiving resource; and/or receiving, by at least one receiving resource, a blockchain or cryptocurrency-related communication sent by a sending resource to an IPv6 multicast address. A method according to clause 11.1, wherein: the communication is or comprises a blockchain and/or cryptocurrency-related alert, blockchain or cryptocurrency-related software update, blockchain or cryptocurrency-related notification or other blockchain or cryptocurrency-related communication. A method according to clause 11.1 or 11.2, wherein: the IPv6 multicast address is associated with communications relating to a particular blockchain network or cryptocurrency. A method according to any preceding clause wherein: the at least one receiving resource comprises one or a plurality of mining, verification, wallet and/or service providing resources arranged to operate on or in conjunction with a blockchain network. A method according to any preceding clause and comprising the step of: taking at least one responsive action, by the at least one receiving resource, in response to the blockchain or cryptocurrency-related communication. The at least one responsive action may comprise one or more of: i) sending a communication to one or more recipients; ii) accessing, installing and/or executing a portion of data, optionally wherein the portion of data comprises one or more machine-executable instructions; iii) marking or identifying at least one transaction output, transaction or block of transactions or portion of cryptocurrency as invalid, unspendable, rejected or to be disregarded. A method according to any preceding clause and comprising the step of: forwarding the communication, by at the least one of the receiving resource, to at least one further receiving resource; optionally wherein: the at least one further receiving resource comprises at least one further IPv6 multicast address. A method according to any preceding clause, wherein: i) the blockchain or cryptocurrency-related communication is signed, marked or otherwise authenticated by a generating resource that has been designated as a legitimate source or provider of the communication; and/or ii) the blockchain or cryptocurrency-related communication is encoded or otherwise secured such that the contents of the blockchain or cryptocurrency-related communication can only be accessed, decoded, read, executed or processed by using at least one unlocking mechanism such as a key, access code or secret. A method according to clause 11.7 and comprising the step: providing the at least one key, access code or secret to at the at least one receiving resource or another resource that is authorised to access, decode, read, execute or process the contents of the blockchain or cryptocurrency-related communication. A method according to any preceding clause wherein the blockchain or cryptocurrency-related communication comprises a filter code, flag, marker or other identifier, and preferably wherein: the filter is arranged to serve as a means for targeting/identifying the blockchain or cryptocurrency-related communication at/to one or more receiving resources of the at least one receiving resource based on: the content or type of blockchain or cryptocurrency-related communication that is being sent; and/or an intended, selected or desired set of receiving resources. . A method according to clause 11.9, wherein: the filter is provided in the blockchain or cryptocurrency-related communication at a predesignated location and/or in a pre-determined format. . A method according to clause 11.9 or 11.10, wherein the method comprises the step of: processing or ignoring the blockchain or cryptocurrency-related communication, by the at least one receiving resource, based upon the filter. 11.12. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any preceding clause.

11.13. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of clauses 11.1 to 11.11.

Clause Set 12

Additionally, or alternatively, one or more embodiments of the disclosure can be defined in accordance with the following clauses. Any of the clauses defined in clause set 12 may be combined with one or more of the clauses of any other clause set provided herein, or any other feature disclosed herein.

In one or more embodiments, however, one, some or all of the sending and/or receiving nodes in a group may be full nodes on a blockchain network, or nodes on an overlay network, and the data may comprise (data relating to) unconfirmed transactions that have been verified but not yet written to the blockchain ledger. In such an embodiment, systems and methods may be provided for implementing a mempool (also known as a memory pool) that forms part of, is provided in or is associated with a blockchain network or an overlay network that interacts with the blockchain network. This may be referred to herein as a 'blockchain overlay network'. According to https://wiki.bitcoinsv.io/index.php/l\/lining, it is known that 'mempools are temporary transaction stores and can be used to hold transactions grouped in different ways, such as transactions to be mined in the next block, transactions to watch, or transactions which cannot be mined due to an nLocktime/nSequence lock.' Without limitation, the term mempool as used herein may comprise this definition.

In other embodiments, systems and methods may be provided for implementing a UTXO set.

Therefore, there may be provided:

Clause 12.1 A method of implementing a memory pool or a UTXO set of a blockchain network, the method comprising the step of: sending a transmission from a sending resource to at least one receiving resource, or receiving a transmission from a sending resource by at least one receiving resource, wherein: the sending resource and/or at least one receiving resource is a node on a network; and the transmission is sent using IPv6 multicast and comprises at least part of a blockchain transaction.

In some embodiments, the at least part of a blockchain transaction may comprise a whole blockchain transaction. The transaction may have been validated (verified) by a verifying entity which is operative to verify the transaction in accordance with a blockchain protocol. The transaction may be unconfirmed, waiting to be successfully mined into a block on the blockchain ledger that is associated with the blockchain protocol.

In some embodiments, the at least part of a blockchain transaction may comprise a UTXO.

Clause 12.2 A method according to clause 12.1, wherein i) the sending resource and/or at least one receiving resource is a full or lightweight node on a blockchain network; or ii) the sending resource and/or at least one receiving resource is a node on a blockchain overlay network.

EXAMPLE SYSTEM OVERVIEW

For the purpose of illustration only and with reference to Figures 1 to 4, we now provide an example of a computing environment in which one or more embodiments of the disclosure can be put into effect. The reference numerals referred to below refer to Figures 1 to 4.

Figure 1 shows an example system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104 that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Whilst not illustrated, the blockchain nodes 104 may be arranged as a near-complete graph. Each blockchain node 104 is therefore highly connected to other blockchain nodes 104. Each blockchain node 104 comprises computer equipment of a peer, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 comprises processing apparatus comprising one or more processors, e.g. one or more central processing units (CPUs), accelerator processors, application specific processors and/or field programmable gate arrays (FPGAs), and other equipment such as application specific integrated circuits (ASICs). Each node also comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as a hard disk; an electronic medium such as a solid-state drive (SSD), flash memory or EEPROM; and/or an optical medium such as an optical disk drive.

The blockchain 150 comprises a chain of blocks of data 151, wherein a respective copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 in the distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in full. Instead, the blockchain 150 may be pruned of data so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, wherein a transaction in this context refers to a kind of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of a transaction model or scheme. A given blockchain will use one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output specifies an amount representing a quantity of a digital asset as property, an example of which is a user 103 to whom the output is cryptographically locked (requiring a signature or other solution of that user in order to be unlocked and thereby redeemed or spent). Each input points back to the output of a preceding transaction 152, thereby linking the transactions.

Each block 151 also comprises a block pointer 155 pointing back to the previously created block 151 in the chain so as to define a sequential order to the blocks 151. Each transaction 152 (other than a coinbase transaction) comprises a pointer back to a previous transaction so as to define an order to sequences of transactions (N.B. sequences of transactions 152 are allowed to branch). The chain of blocks 151 goes all the way back to a genesis block (Gb) 153 which was the first block in the chain. One or more original transactions 152 early on in the chain 150 pointed to the genesis block 153 rather than a preceding transaction. Each of the blockchain nodes 104 is configured to forward transactions 152 to other blockchain nodes 104, and thereby cause transactions 152 to be propagated throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and to store a respective copy of the same blockchain 150 in their respective memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into blocks 151. The ordered pool 154 is often referred to as a "mempool". This term herein is not intended to limit to any particular blockchain, protocol or model. It refers to the ordered set of transactions which a node 104 has accepted as valid and for which the node 104 is obliged not to accept any other transactions attempting to spend the same output.

In a given present transaction 152j, the (or each) input comprises a pointer referencing the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "spent" in the present transaction 152j. In general, the preceding transaction could be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i need not necessarily exist at the time the present transaction 152j is created or even sent to the network 106, though the preceding transaction 152i will need to exist and be validated in order for the present transaction to be valid. Hence "preceding" herein refers to a predecessor in a logical sequence linked by pointers, not necessarily the time of creation or sending in a temporal sequence, and hence it does not necessarily exclude that the transactions 152i, 152j be created or sent out-of-order (see discussion below on orphan transactions). The preceding transaction 152i could equally be called the antecedent or predecessor transaction.

The input of the present transaction 152j also comprises the input authorisation, for example the signature of the user 103a to whom the output of the preceding transaction 152 i is locked. In turn, the output of the present transaction 152j can be cryptographically locked to a new user or entity 103b. The present transaction 152j can thus transfer the amount defined in the input of the preceding transaction 152i to the new user or entity 103b as defined in the output of the present transaction 152j. In some cases a transaction 152 may have multiple outputs to split the input amount between multiple users or entities (one of whom could be the original user or entity 103a in order to give change). In some cases a transaction can also have multiple inputs to gather together the amounts from multiple outputs of one or more preceding transactions, and redistribute to one or more outputs of the current transaction. According to an output-based transaction protocol such as bitcoin, when a party 103, such as an individual user or an organization, wishes to enact a new transaction 152j (either manually or by an automated process employed by the party), then the enacting party sends the new transaction from its computer terminal 102 to a recipient. The enacting party or the recipient will eventually send this transaction to one or more of the blockchain nodes 104 of the network 106 (which nowadays are typically servers or data centres, but could in principle be other user terminals). It is also not excluded that the party 103 enacting the new transaction 152j could send the transaction directly to one or more of the blockchain nodes 104 and, in some examples, not to the recipient. A blockchain node 104 that receives a transaction checks whether the transaction is valid according to a blockchain node protocol which is applied at each of the blockchain nodes 104. The blockchain node protocol typically requires the blockchain node 104 to check that a cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in an ordered sequence of transactions 152. In such an output-based transaction protocol, this may comprise checking that the cryptographic signature or other authorisation of the party 103 included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 152i which the new transaction assigns, wherein this condition typically comprises at least checking that the cryptographic signature or other authorisation in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked to. The condition may be at least partially defined by a script included in the output of the preceding transaction 152i. Alternatively it could simply be fixed by the blockchain node protocol alone, or it could be due to a combination of these. Either way, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same test according to the same blockchain node protocol, and so forward the new transaction 152j on to one or more further nodes 104, and so forth. In this way the new transaction is propagated throughout the network of blockchain nodes 104.

In an output-based model, the definition of whether a given output (e.g. UTXO) is assigned (e.g. spent) is whether it has yet been validly redeemed by the 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 which it attempts to redeem has not already been redeemed by another transaction. Again if not valid, the transaction 152j will not be propagated (unless flagged as invalid and propagated for alerting) or recorded in the blockchain 150. This guards against double-spending whereby the transactor tries to assign the output of the same transaction more than once. An account-based model on the other hand guards against double-spending by maintaining an account balance. Because again there is a defined order of transactions, the account balance has a single defined state at any one time.

In addition to validating transactions, blockchain nodes 104 also race to be the first to create blocks of transactions in a process commonly referred to as mining, which is supported by "proof-of-work". At a blockchain node 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then race to assemble a new valid block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically this comprises searching for a "nonce" value such that when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed, then the output of the hash meets a predetermined condition. E.g. the predetermined condition may be that the output of the hash has a certain predefined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle, and other types are not excluded. A property of a hash function is that it has an unpredictable output with respect to its input. Therefore this search can only be performed by brute force, thus consuming a substantive amount of processing resource at each blockchain node 104 that is trying to solve the puzzle.

The first blockchain node 104 to solve the puzzle announces this to the network 106, providing the solution as proof which can then be easily checked by the other blockchain nodes 104 in the network (once given the solution to a hash it is straightforward to check that it causes the output of the hash to meet the condition). The first blockchain node 104 propagates a block to a threshold consensus of other nodes that accept the block and thus enforce the protocol rules. The ordered set of transactions 154 then becomes recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n pointing back to the previously created block 151n-l in the chain. The significant amount of effort, for example in the form of hash, required to create a proof-of-work solution signals the intent of the first node 104 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 doublespending. Once created, the block 151 cannot be modified since it is recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106. The block pointer 155 also imposes a sequential order to the blocks 151. Since the transactions 152 are recorded in the ordered blocks at each blockchain node 104 in a network 106, this therefore provides an immutable public ledger of the transactions.

Note that different blockchain nodes 104 racing to solve the puzzle at any given time may be doing so based on different snapshots of the pool of yet-to-be published transactions 154 at any given time, depending on when they started searching for a solution or the order in which the transactions were received. Whoever solves their respective puzzle first defines which transactions 152 are included in the next new block 151n and in which order, and the current pool 154 of unpublished transactions is updated. The blockchain nodes 104 then continue to race to create a block from the newly-defined ordered pool of unpublished transactions 154, and so forth. A protocol also exists for resolving any "fork" that may arise, which is where two blockchain nodesl04 solve their puzzle within a very short time of one another such that a conflicting view of the blockchain gets propagated between nodes 104. In short, whichever prong of the fork grows the longest becomes the definitive blockchain 150. Note this should not affect the users or agents of the network as the same transactions will appear in both forks.

According to the bitcoin blockchain (and most other blockchains) a node that successfully constructs a new block 104 is granted the ability to newly assign an additional, accepted amount of the digital asset in a new special kind of transaction which distributes an additional defined quantity of the digital asset (as opposed to an inter-agent, or inter-user transaction which transfers an amount of the digital asset from one agent or user to another). This special type of transaction is usually referred to as a "coinbase transaction", but may also be termed an "initiation transaction" or "generation transaction". It typically forms the first transaction of the new block 151n. The proof-of- work signals the intent of the node that constructs the new block to follow the protocol rules allowing this special transaction to be redeemed later. The blockchain protocol rules may require a maturity period, for example 100 blocks, before this special transaction may be redeemed. Often a regular (non-generation) transaction 152 will also specify an additional transaction fee in one of its outputs, to further reward the blockchain node 104 that created the block 151n in which that transaction was published. This fee is normally referred to as the "transaction fee", and is discussed blow.

Due to the resources involved in transaction validation and publication, typically at least each of the blockchain nodes 104 takes the form of a server comprising one or more physical server units, or even whole a data centre. However in principle any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

The memory of each blockchain node 104 stores software configured to run on the processing apparatus of the blockchain node 104 in order to perform its respective role or roles and handle transactions 152 in accordance with the blockchain node protocol. It will be understood that any action attributed herein to a blockchain node 104 may be performed by the software run on the processing apparatus of the respective computer equipment. The node software may be implemented in one or more applications at the application layer, or a lower layer such as the operating system layer or a protocol layer, or any combination of these.

Also connected to the network 101 is the computer equipment 102 of each of a plurality of parties 103 in the role of consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and recipients in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or recipients. For instance, some parties may act as storage entities that store a copy of the blockchain 150 (e.g. having obtained a copy of the blockchain from a blockchain node 104).

Some or all of the parties 103 may be connected as part of a different network, e.g. a network overlaid on top of the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network 106; however, these users are not blockchain nodes 104 as they do not perform the roles required of the blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e. communicating with) a blockchain node 106. Two parties 103 and their respective equipment 102 are shown for illustrative purposes: a first party 103a and his/her respective computer equipment 102a, and a second party 103b and his/her respective computer equipment 102b. It will be understood that many more such parties 103 and their respective computer equipment 102 may be present and participating in the system 100, but for convenience they are not illustrated. Each party 103 may be an individual or an organization. Purely by way of illustration the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be appreciated that this is not limiting and any reference herein to Alice or Bob may be replaced with "first party" and "second "party" respectively. The computer equipment 102 of each party 103 comprises respective processing apparatus comprising one or more processors, e.g. one or more CPUs, GPUs, other accelerator processors, application specific processors, and/or FPGAs. The computer equipment 102 of each party 103 further comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media. This memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as hard disk; an electronic medium such as an SSD, flash memory or EEPROM; and/or an optical medium such as an optical disc drive. The memory on the computer equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 arranged to run on the processing apparatus. It will be understood that any action attributed herein to a given party 103 may be performed using the software run on the processing apparatus of the respective computer equipment 102. The computer equipment 102 of each party 103 comprises 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 computer equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources accessed via the user terminal.

The client application 105 may be initially provided to the computer equipment 102 of any given party 103 on suitable computer-readable storage medium or media, e.g. downloaded from a server, or provided 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 such as a CD or DVD ROM, or a removable optical drive, etc.

The client application 105 comprises at least a "wallet" function. This has two main functionalities. One of these is to enable the respective party 103 to create, authorise (for example sign) and send transactions 152 to one or more bitcoin nodes 104 to then be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report back to the respective party the amount of the digital asset that he or she currently owns. In an outputbased system, this second functionality comprises collating the amounts defined in the outputs of the various 152 transactions scattered throughout the blockchain 150 that belong to the party in question.

Note: whilst the various client functionality may be described as being integrated into a given client application 105, this is not necessarily limiting and instead any client functionality described herein may instead be implemented in a suite of two or more distinct applications, e.g. interfacing via an API, or one being a plug-in to the other. More generally the client functionality could be implemented at the application layer or a lower layer such as the operating system, or any combination of these. The following will be described in terms of a client application 105 but it will be appreciated that this is not limiting.

The instance of the client application or software 105 on each computer equipment 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 is also able to contact blockchain nodes 104 in order to query the blockchain 150 for any transactions of which the respective party 103 is the recipient (or indeed inspect other parties' transactions in the blockchain 150, since in embodiments the blockchain 150 is a public facility which provides trust in transactions in part through its public visibility). The wallet function on each computer equipment 102 is configured to formulate and send transactions 152 according to a transaction protocol. As set out above, each blockchain node 104 runs software configured to validate transactions 152 according to the blockchain node protocol, and to forward transactions 152 in order to propagate them throughout the blockchain network 106. The transaction protocol and the node protocol correspond to one another, and a given transaction protocol goes with a given node protocol, together implementing a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all the nodes 104 in the network 106.

When a given party 103, say Alice, wishes to send a new transaction 152j to be included in the blockchain 150, then she formulates the new transaction in accordance with the relevant transaction protocol (using the wallet function in her client application 105). She then sends the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which she is connected. E.g. this could be the blockchain node 104 that is best connected to Alice's computer 102. When any given blockchain node 104 receives a new transaction 152j, it handles it in accordance with the blockchain node protocol and its respective role. This comprises first checking whether the newly received transaction 152j meets a certain condition for being "valid", examples of which will be discussed in more detail shortly. In some transaction protocols, the condition for validation may be configurable on a per-transaction basis by scripts included in the transactions 152. Alternatively the condition could simply be a built-in feature of the node protocol, or be defined by a combination of the script and the node protocol. On condition that the newly received transaction 152j passes the test for being deemed valid (i.e. on condition that it is "validated"), any blockchain node 104 that receives the transaction 152j will add the new validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Further, any blockchain node 104 that receives the transaction 152j will propagate the validated transaction 152 onward to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, then assuming the transaction 152j is valid, this means it will soon be propagated throughout the whole network 106.

Once admitted to the ordered pool of pending transactions 154 maintained at a given blockchain node 104, that blockchain node 104 will start competing to solve the proof-of-work puzzle on the latest version of their respective pool of 154 including the new transaction 152 (recall that other blockchain nodes 104 may be trying to solve the puzzle based on a different pool of transactionsl54, but whoever gets there first will define the set of transactions that are included in the latest block 151. Eventually a blockchain node 104 will solve the puzzle for a part of the ordered pool 154 which includes Alice's transaction 152j). Once the proof-of-work has been done for the pool 154 including the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Each transaction 152 comprises a pointer back to an earlier transaction, so the order of the transactions is also immutably recorded.

Different blockchain nodes 104 may receive different instances of a given transaction first and therefore have conflicting views of which instance is 'valid' before one instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only 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 then that blockchain node 104 must accept this and will discard (i.e. treat as invalid) the instance which it had initially accepted (i.e. the one that has not been published in a block 151).

An alternative type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol, as part of an account-based transaction model. In the accountbased case, each transaction does not define the amount to be transferred by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored, by the nodes of that network, separate to the blockchain and is updated constantly. In such a system, transactions are ordered using a running transaction tally of the account (also called the "position"). This value is signed by the sender as part of their cryptographic signature and is hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed the transaction. This data field may point back to a previous transaction, for example if the previous transaction ID is included in the data field.

UTXO-BASED MODEL

Figure 2 illustrates an example transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated "Tx") is the fundamental data structure of the blockchain 150 (each block 151 comprising one or more transactions 152). The following will be described by reference to an output-based or "UTXO" based protocol. However, this is not limiting to all possible embodiments. Note that while the example UTXO-based protocol is described with reference to bitcoin, it may equally be implemented on other example blockchain networks.

In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure comprising one or more inputs 202, and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which can be used as the source for the input 202 of another new transaction (if the UTXO has not already been redeemed). The UTXO includes a value specifying an amount of a digital asset. This represents a set number of tokens on the distributed ledger. The UTXO may also contain the transaction ID of the transaction from which it came, amongst other information. The transaction data structure may also comprise a header 201, which may comprise an indicator of the size of the input field(s) 202 and output field(s) 203. The header 201 may also include an ID of the transaction. In embodiments the transaction ID is the hash of the transaction data (excluding the transaction ID itself) and stored in the header 201 of the raw transaction 152 submitted to the nodes 104.

Say Alice 103a wishes to create a transaction 152j transferring an amount of the digital asset in question to Bob 103b. In Figure 2 Alice's new transaction 152j is labelled "Tx" . It takes an amount of the digital asset that is locked to Alice in the output 203 of a preceding transaction 152i in the sequence, and transfers at least some of this to Bob. The preceding transaction 152i is labelled "Txo in Figure 2. Txo and Txi are just arbitrary labels. They do not necessarily mean that Txo is the first transaction in the blockchain 151, nor that Txi is the immediate next transaction in the pool 154. Txi could point back to any preceding (i.e. antecedent) transaction that still has an unspent output 203 locked to Alice. The preceding transaction Txo may already have been validated and included in a block 151 of the blockchain 150 at the time when Alice creates her new transaction Txi, or at least by the time she sends it to the network 106. It may already have been included in one of the blocks 151 at that time, or it may be still waiting in the ordered set 154 in which case it will soon be included in a new block 151. Alternatively Txo and Txi could be created and sent to the network 106 together, or Txo could even be sent after Txi if the node protocol allows for buffering "orphan" transactions. The terms "preceding" and "subsequent" as used herein in the context of the sequence of transactions refer to the order of the transactions in the sequence as defined by the transaction pointers specified in the transactions (which transaction points back to which other transaction, and so forth). They could equally be replaced with "predecessor" and "successor", or "antecedent" and "descendant", "parent" and "child", or such like. It does not necessarily imply an order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (the descendent transaction or "child") which points to a preceding transaction (the antecedent transaction or "parent") will not be validated until and 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 time to wait for the parent, depending on the node protocol and/or node behaviour.

One of the one or more outputs 203 of the preceding transaction Txo comprises a particular UTXO, labelled here UTXOo. Each UTXO comprises a value specifying an amount of the digital asset represented by the UTXO, and a locking script which defines a condition which must be met by an unlocking script in the input 202 of a subsequent transaction in order for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). Le. the locking script defines an unlocking condition, typically comprising a condition that the unlocking script in the input of the subsequent transaction comprises the cryptographic signature of the party to whom the preceding transaction is locked.

The locking script (aka scriptPubKey) is a piece of code written in the domain specific language recognized by the node protocol. A particular example of such a language is called "Script" (capital S) which is used by the blockchain network. The locking script specifies what information is required to spend a transaction output 203, for example the requirement of Alice's signature. Unlocking scripts appear in the outputs of transactions. The unlocking script (aka scriptSig) is a piece of code written the domain specific language that provides the information required to satisfy the locking script criteria. For example, it may contain Bob's signature. Unlocking scripts appear in the input 202 of transactions.

So in the example illustrated, UTXOo 'm the output 203 of Txo comprises a locking script [Checksig PA] which requires a signature Sig PA of Alice in order for UTXOo to be redeemed (strictly, in order for a subsequent transaction attempting to redeem UTXOo to be valid). [Checksig y contains a representation (i.e. a hash) of the public key /^ from a public-private key pair of Alice. The input 202 of Txi comprises a pointer pointing back to Txi (e.g. by means of its transaction ID, TxIDo, which in embodiments is the hash of the whole transaction Txo}. The input 202 of Txi comprises an index identifying UTXOo within Txo, to identify it amongst any other possible outputs of Txo. The input 202 of Txi further comprises an unlocking script <Sig PA> which comprises a cryptographic signature of Alice, created by Alice applying her private key from the key pair to a predefined portion of data (sometimes called the "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these.

When the new transaction Txi arrives at a blockchain node 104, the node applies the node protocol. This comprises running the locking script and unlocking script together to check whether the unlocking script meets the condition defined in the locking script (where this condition may comprise one or more criteria). In embodiments this involves concatenating the two scripts:

<Sig P _A > <PA> | | [Checksig PA where "| |" represents a concatenation and "<...>" means place the data on the stack, and "[...]" is a function comprised by the locking script (in this example a stack-based language). Equivalently the scripts may be run one after the other, with a common stack, rather than concatenating the scripts. Either way, when run together, the scripts use the public key PA of Alice, as included in the locking script in the output of Txo, to authenticate that the unlocking script in the input of Txi contains the signature of Alice signing the expected portion of data. The expected portion of data itself (the "message") also needs to be included in order to perform this authentication. In embodiments the signed data comprises the whole of Txi (so a separate element does not need to be included specifying the signed portion of data in the clear, as it is already inherently present). The details of authentication by public-private cryptography will be familiar to a person skilled in the art. Basically, if Alice has signed a message using her private key, then given Alice's public key and the message in the clear, another entity such as a node 104 is able to authenticate that the message must have been signed by Alice. Signing typically comprises hashing the message, signing the hash, and tagging this onto the message as a signature, thus enabling any holder of the public key to authenticate the signature. Note therefore that any reference herein to signing a particular piece of data or part of a transaction, or such like, can in embodiments mean signing a hash of that piece of data or part of the transaction.

If the unlocking script in Txi meets the one or more conditions specified in the locking script of Txo (so in the example shown, if Alice's signature is provided in Txi and authenticated), then the blockchain node 104 deems Txi valid. This means that the blockchain node 104 will add Txi to the ordered pool of pending transactions 154. The blockchain node 104 will also forward the transaction Txi to one or more other blockchain nodes 104 in the network 106, so that it will be propagated throughout the network 106. Once Txi has been validated and included in the blockchain 150, this defines UTXOXrom Txgas spent. Note that Txi can only be valid if it spends an unspent transaction output 203. If it attempts to spend an output that has already been spent by another transaction 152, then Txi will be invalid even if all the other conditions are met. Hence the blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Txo is already spent (i.e. whether it has already formed a valid input to another valid transaction). This is one reason why it is important for the blockchain 150 to impose a defined order on the transactions 152. In practice a given blockchain node 104 may maintain a separate database marking which UTXOs 203 in which transactions 152 have been spent, but ultimately what defines whether a UTXO has been spent is whether it has already formed a valid input to another valid transaction in the blockchain 150.

If the total amount specified in all the 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 transactions will not be propagated nor included in a block 151.

Note that in UTXO-based transaction models, a given UTXO needs to be spent as a whole. It cannot "leave behind" a fraction of the amount defined in the UTXO as spent while another fraction is spent. However the amount from the UTXO can be split between multiple outputs of the next transaction. E.g. the amount defined in UTXOo'm Txo can be split between multiple UTXOs in Txi. Hence if Alice does not want to give Bob all of the amount defined in UTXOo, she can use the remainder to give herself change in a second output of Txi, or pay another party.

In practice Alice will also usually need to include a fee for the bitcoin node 104 that successfully includes her transaction 104 in a block 151. If Alice does not include such a fee, Txo may be rejected by the blockchain nodes 104, and hence although technically valid, may not be propagated and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept transactions 152 if they don't want). In some protocols, the transaction fee does not require its own separate output 203 (i.e. does not need a separate UTXO). Instead any difference between the total amount pointed to by the input(s) 202 and the total amount of specified in the output(s) 203 of a given transaction 152 is automatically given to the blockchain node 104 publishing the transaction. E.g. say a pointer to UTXOo is the only input to Txi, and Txi has only one output UTXOi. If the amount of the digital asset specified in UTXOo is greater than the amount specified in UTXOi, then the difference may be assigned by the node 104 that wins the proof-of-work race to create the block containing UTXOi. Alternatively or additionally however, it is not necessarily excluded that a transaction fee could be specified explicitly in its own one of the UTXOs 203 of the transaction 152.

Alice and Bob's digital assets consist of the UTXOs locked to them in any transactions 152 anywhere in the blockchain 150. Hence typically, the assets of a given party 103 are scattered throughout the UTXOs of various transactions 152 throughout the blockchain 150. There is no one number stored anywhere in the blockchain 150 that defines the total balance of a given party 103. It is the role of the wallet function in the client application 105 to collate together the values of all the various UTXOs which are locked to the respective party and have not yet been spent in another onward transaction. It can do this by querying the copy of the blockchain 150 as stored at any of the bitcoin nodes 104.

Note that the script code is often represented schematically (i.e. not using the exact language). For example, one may use operation codes (opcodes) to represent a particular function. "OP_..." refers to a particular opcode of the Script language. As an example, OP_RETURN is an opcode of the Script language that when preceded by OP_FALSE at the beginning of a locking script creates an unspendable output of a transaction that can store data within the transaction, and thereby record the data immutably in the blockchain 150. E.g. the data could comprise a document which it is desired to store in the blockchain. Typically an input of a transaction contains a digital signature corresponding to a public key PA. In embodiments this is based on the ECDSA using the elliptic curve secp256kl. A digital signature signs a particular piece of data. In some embodiments, for a given transaction the signature will sign part of the transaction input, and some or all of the transaction outputs. The particular parts of the outputs it signs depends on the SIGHASH flag. The SIGHASH flag is usually a 4-byte code included at the end of a signature to select which outputs are signed (and thus fixed at the time of signing).

The locking script is sometimes called "scriptPubKey" referring to the fact that it typically comprises the public key of the party to whom the respective transaction is locked. The unlocking script is sometimes called "scriptSig" referring to the fact that it typically supplies the corresponding signature. However, more generally it is not essential in all applications of a blockchain 150 that the condition for a UTXO to be redeemed comprises authenticating a signature. More generally the scripting language could be used to define any one or more conditions. Hence the more general terms "locking script" and "unlocking script" may be preferred.

SIDE CHANNEL

As shown in Figure 1, the client application on each of Alice and Bob's computer equipment 102a, 120b, respectively, may comprise additional communication functionality. This additional functionality enables Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of either party or a third party). The side channel 107 enables exchange of data separately from the blockchain network. Such communication is sometimes referred to as "off- chain" communication. For instance this may be used to exchange a transaction 152 between Alice and Bob without the transaction (yet) being registered onto the blockchain network 106 or making its way onto the chain 150, until one of the parties chooses to broadcast it to the network 106. Sharing a transaction in this way is sometimes referred to as sharing a "transaction template". A transaction template may lack one or more inputs and/or outputs that are required in order to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction related data, such as keys, negotiated amounts or terms, data content, etc.

The side channel 107 may be established via the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established via a different network such as a mobile cellular network, or a local area network such as a local wireless network, or even a direct wired or wireless link between Alice and Bob's devices 102a, 102b. Generally, the side channel 107 as referred to anywhere herein may comprise 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. Where more than one link is used, then the bundle or collection of off-chain links as a whole may be referred to as the side channel 107. Note therefore that if it is said that Alice and Bob exchange certain pieces of information or data, or such like, over the side channel 107, then this does not necessarily imply all these pieces of data have to be send over exactly the same link or even the same type of network.

CLIENT SOFTWARE

Figure 3A illustrates an example implementation of the client application 105 for implementing embodiments of the presently disclosed scheme. The client application 105 comprises a transaction engine 401 and a user interface (Ul) layer 402. The transaction engine 401 is configured to implement the underlying transaction-related functionality of the client 105, such as to formulate transactions 152, receive and/or send transactions and/or other data over the side channel 301, and/or send transactions to one or more nodes 104 to be propagated through the blockchain network 106, in accordance with the schemes discussed above and as discussed in further detail shortly.

The Ul layer 402 is configured to render a user interface via a user input/output (I/O) means of the respective user's computer equipment 102, including outputting information to the respective user 103 via a user output means of the equipment 102, and receiving inputs back from the respective user 103 via a user input means of the equipment 102. For example, the user output means could comprise one or more display screens (touch or non-touch screen) for providing a visual output, one or more speakers for providing an audio output, and/or one or more haptic output devices for providing a tactile output, etc. The user input means could comprise for example the input array of one or more touch screens (the same or different as that/those used for the output means); one or more cursor-based devices such as mouse, trackpad or trackball; one or more microphones and speech or voice recognition algorithms for receiving a speech or vocal input; one or more gesturebased input devices for receiving the input in the form of manual or bodily gestures; or one or more mechanical buttons, switches or joysticks, etc.

Note: whilst the various functionality herein may be described as being integrated into the same client application 105, this is not necessarily limiting and instead they could be implemented in a suite of two or more distinct applications, e.g. one being a plug-in to the other or interfacing via an API (application programming interface). For instance, the functionality of the transaction engine 401 may be implemented in a separate application than the Ul layer 402, or the functionality of a given module such as the transaction engine 401 could be split between more than one application. Nor is it excluded that some or all of the described functionality could be implemented at, say, the operating system layer. Where reference is made anywhere herein to a single or given application 105, or such like, it will be appreciated that this is just by way of example, and more generally the described functionality could be implemented in any form of software.

Figure 3B gives a mock-up of an example of the user interface (Ul) 500 which may be rendered by the Ul layer 402 of the client application 105a on Alice's equipment 102a. It will be appreciated that a similar Ul may be rendered by the client 105b on Bob's equipment 102b, or that of any other party.

By way of illustration Figure 3B shows the Ul 500 from Alice's perspective. The Ul 500 may comprise one or more Ul elements 501, 502, 502 rendered as distinct Ul elements via the user output means.

For example, the Ul elements may comprise one or more user-selectable elements 501 which may be, such as different on-screen buttons, or different options in a menu, or such like. The user input means is arranged to enable the user 103 (in this case Alice 103a) to select or otherwise operate one of the options, such as by clicking or touching the Ul element on-screen, or speaking a name of the desired option (N.B. the term "manual" as used herein is meant only to contrast against automatic, and does not necessarily limit to the use of the hand or hands).

Alternatively or additionally, the Ul elements may comprise one or more data entry fields 502. These data entry fields are rendered via the user output means, e.g. on-screen, and the data can be entered into the fields through the user input means, e.g. a keyboard or touchscreen. Alternatively the data could be received orally for example based on speech recognition.

Alternatively or additionally, the Ul elements may comprise one or more information elements 503 output to output information to the user. E.g. this/these could be rendered on screen or audibly.

It will be appreciated that the particular means of rendering the various Ul elements, selecting the options and entering data is not material. The functionality of these Ul elements will be discussed in more detail shortly. It will also be appreciated that the Ul 500 shown in Figure 3 is only a schematized mock-up and in practice it may comprise one or more further Ul elements, which for conciseness are not illustrated.

NODE SOFTWARE

Figure 4 illustrates an example of the node software 450 that is run on each blockchain node 104 of the network 106, in the example of a UTXO- or output-based model. Note that another entity may run node software 450 without being classed as a node 104 on the network 106, i.e. without performing the actions required of a node 104. The node software 450 may contain, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related functional modules 455. Each node 104 may run node software that contains, but is not limited to, all three of: a consensus module 455C (for example, proof-of-work), a propagation module 455P and a storage module 455S (for example, a database). The protocol engine 401 is typically configured to recognize the different fields of a transaction 152 and process them in accordance with the node protocol. When a transaction 152j (Txj) is received having an input pointing to an output (e.g. UTXO) of another, preceding transaction 152i (TXm-i), then the protocol engine 451 identifies the unlocking script in Txj and passes it to the script engine 452. The protocol engine 451 also identifies and retrieves Tx _t based on the pointer in the input of Txj. Tx _t may be published on the blockchain 150, in which case the protocol engine may retrieve Tx _t from a copy of a block 151 of the blockchain 150 stored at the node 104. Alternatively, Txt may yet to have been published on the blockchain 150. In that case, the protocol engine 451 may retrieve Tx _t from the ordered set 154 of unpublished transactions maintained by the nodel04. Either way, the script engine 451 identifies the locking script in the referenced output of Tx _t and passes this to the script engine 452.

The script engine 452 thus has the locking script of Tx _t and the unlocking script from the corresponding input of Txj. For example, transactions labelled Tx ₀ and Tx _r are illustrated in Figure 2, but the same could apply for any pair of transactions. The script engine 452 runs the two scripts together as discussed previously, which will include placing data onto and retrieving data from the stack 453 in accordance with the stack-based scripting language being used (e.g. Script).

By running the scripts together, the script engine 452 determines whether or not the unlocking script meets the one or more criteria defined in the locking script - i.e. does it "unlock" the output in which the locking script is included? The script engine 452 returns a result of this determination to the protocol engine 451. If the script engine 452 determines that the unlocking script does meet the one or more criteria specified in the corresponding locking script, then it returns the result "true". Otherwise it returns the result "false".

In an output-based model, the result "true" from the script engine 452 is one of the conditions for validity of the transaction. Typically there are also one or more further, protocol-level conditions evaluated by the protocol engine 451 that must be met as well; such as that the total amount of digital asset specified in the output(s) of Txj does not exceed the total amount pointed to by its inputs, and that the pointed-to output of Tx _t has not already been spent by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 together with the one or more protocol-level conditions, and only if they are all true does it validate the transaction Txj. The protocol engine 451 outputs an indication of whether the transaction is valid to the application-level decision engine 454. Only on condition that Txj is indeed validated, the decision engine 454 may select to control both of the consensus module 455C and the propagation module 455P to perform their respective blockchain-related function in respect of Txj. This comprises the consensus module 455C adding Txj to the node's respective ordered set of transactions 154 for incorporating in a block 151, and the propagation module 455P forwarding Txj to another blockchain node 104 in the network 106. Optionally, in embodiments the applicationlevel decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. E.g. the decision engine may only select to publish the transaction on condition that the transaction is both valid and leaves enough of a transaction fee.

Note also that the terms "true" and "false" herein do not necessarily limit to returning a result represented in the form of only a single binary digit (bit), though that is certainly one possible implementation. More generally, "true" can refer to any state indicative of a successful or affirmative outcome, and "false" can refer to any state indicative of an unsuccessful or nonaffirmative outcome. For instance in an account-based model, a result of "true" could be indicated by a combination of an implicit, protocol-level validation of a signature and an additional affirmative output of a smart contract (the overall result being deemed to signal true if both individual outcomes are true).