Computer-Implemented Method and System for Improved Communication on a Blockchain Network

Abstract

The present invention resides in a computer-implemented communication method. The method includes a mechanism for delivering blockchain- and / or cryptocurrency-related communications, such as alerts, notifications, and updates, to one or more recipients over an electronic network as efficiently and quickly as possible. In embodiments, such improved communications may be performed using IPv6 multicast. The communications may include codes, flags, or filters that enable communications to be targeted to specific recipients, allowing multicast group members who are not interested in or authorized to access the content of the communication to ignore it. This provides improvements in processing resources and time. In some examples, the present disclosure may be advantageous for implementing blockchain-related alert systems or systems that can increase network responsiveness to emergencies or threats, thereby improving the security of blockchain networks.

Description

[Technical Field]

[0001] Embodiments disclosed herein relate to improvements to the transmission of data, e.g., packets of data, over computer-implemented networks. The embodiments are particularly, but not exclusively, suited to the transmission of blockchain-related data and communications between parties wishing to receive, process, respond, 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 and from interested parties, related parties, and involved parties. [Background technology]

[0002] Devices on the Internet are assigned a unique identifier (an address) that enables them to be identified by other devices and to locate them on the network. The original IP protocol was built with the expectation that the number of IP addresses that could be generated from a 32-bit address block would be sufficient to uniquely identify every device connecting to the Internet. However, the overwhelming appeal of the Internet to individuals and businesses, nor the variety and volume of devices seeking to connect to the Internet, was not anticipated when the original IP protocol was designed. As a result, with the growth of personal and mobile computing technology, it soon became clear that the 4.3 billion addresses possible with IPv4 were insufficient.

[0003] The threat of IPv4 address exhaustion has spawned some creative ways to mitigate the limited set (e.g., classless addressing (CIDR), unnumbered interfaces, network address translation), but these measures have not been sufficient to address the problem. The emergence of the Internet of Things (IoT) is set to further exacerbate IPv4's limitations in both the short and long term.

[0004] Due to these challenges, IPv6 was proposed as a replacement for the IPv4 address standard. At its core, IPv6 has a theoretical 3.4 x 10 38 The first major advance was the use of 128-bit addresses, which can generate 128 addresses. While some ranges of the key space are pre-designated for specific purposes, the remaining address space is large enough to meet the current and future needs for each resource connecting to the Internet to have its own unique IPv6 address. While the most significant advantage of IPv6 is its large address space, there are several other advantages that IPv6 is expected to offer, including its approach to multicast and anycast.

[0005] Multicast, which allows a data packet to be sent to multiple destinations in a single send operation, is inherent in the base specification of IPv6. In IPv6, packets are sent to a multicast group address, which then transmits the packet to the members of the group. On the other hand, anycast transmission in IPv6 allows a source resource to send a data packet to a group address, but only one receiver in the group (the receiver topologically closest to the sender) receives the transmitted data.

[0006] The group subscription model of multicast and its incorporation into the IPv6 protocol leads to increased efficiency in sending data packets over the Internet and reduced network congestion compared to other methods of transmitting / casting packets, such as unicast and broadcast. Unicast is a one-to-one connection where a packet is sent from one IP address to another. Broadcast is a one-to-all transmission where a packet is sent to all addresses / nodes in a network. Therefore, the use of multicast in IPv6 provides a more efficient and scalable solution for transmitting data over the Internet.

[0007] The need for efficient transport of data transmissions is important not only for the Internet, but also for other networks. For example, scalability is a key technical challenge for many distributed ledgers due to limitations on the maximum size of blocks used (e.g., BTC's 1MB block limit). As such protocols require more and smaller blocks to be propagated through the network, the network becomes congested and slows down. Transactions take longer to mine and confirm. This reduces network performance and impairs system functionality, making the BTC ledger impractical for use in applications requiring high-speed processing power.

[0008] On the other hand, the Bitcoin SV protocol allows for the use of larger blocks (currently 4GB, with progress towards terabyte blocks). This raises the technical challenge of how to distribute these large blocks across the nodes in the ledger's node network in a fast, secure, and efficient manner. Therefore, there is a need for an improved blockchain network, a technical solution that provides greater efficiency in terms of time, processing resources, and network performance for blockchain-related applications.

[0009] A further challenge lies in providing controlled and / or managed transmission of packets of data over a network in a contractually agreed-upon manner, whether in a one-to-one or one-to-many exchange. Known publisher-subscriber exchanges are inefficient and / or difficult to scale.

[0010] Solutions have now been devised to address at least these and other technical problems.

[0011] term As known in the art, the term "node" can refer to a fundamental unit of data structure (in computer science), or a connection point in a communications network (networking / telecom), 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, devices or systems on a network may also be referred to as "hosts" or "peers" depending on the context. Thus, with respect to the present disclosure, confusion may arise between various terms given that some embodiments may encompass or traverse various technical fields.

[0012] Therefore, to avoid confusion and for clarity, we will use the inclusive terms "network resource," "processing resource," "computer-based resource," or simply "resource" to include "node," "peer," or "host," or any device / system on the network. In this specification, we prefer to use the term "node" to mean, typically, but not necessarily, a node on a blockchain network, e.g., a miner.

[0013] Also, we may refer to the Bitcoin protocol / network / ledger herein for convenience and because it is the most widely known of such technologies. However, this disclosure is not limited to use with Bitcoin, and other ledger-based protocols / networks are intended to fall within the scope of this disclosure. For example, blockchain protocols, networks, and implementations that include a proof-of-stake mechanism or utilize an account-based model rather than a UTXO-based model are intended to fall within the scope of this disclosure. Also, note that "Bitcoin" is not limited to referring to a specific Bitcoin-related protocol; any protocol or implementation that flows from, varies, or deviates from the original Bitcoin protocol is intended to fall within the scope of this disclosure. Public, private, or permissioned blockchains are also intended to fall within the scope of this disclosure.

[0014] The term "blockchain-related data" as used herein includes, but is not limited to, any data used, transmitted, received, stored, or otherwise processed in connection with an operation, function, or service performed in connection with, or for purposes of implementing, a blockchain protocol or a blockchain-based application. [Prior art documents] [Patent documents]

[0015] [Patent Document 1] International Publication No. WO2018 / 234987 [Patent Document 2] PCT International Application No. PCT / EP2022 / 080084 [Patent Document 3] PCT International Application No. PCT / EP2022 / 080081 [Patent Document 4] PCT International Application No. PCT / EP2022 / 079825 [Patent Document 5] PCT International Application No. PCT / EP2022 / 079830 [Patent Document 6] PCT International Application No. PCT / EP2022 / 079447 [Patent Document 7] PCT International Application No. PCT / EP2022 / 079837 [Patent Document 8] PCT International Application No. PCT / EP2022 / 080014 [Patent Document 9] PCT International Application No. PCT / IB2019 / 059807 [Patent Document 10] PCT International Application No. PCT / IB2019 / 059808 [Patent Document 11] PCT International Application No. PCT / IB2019 / 059809 [Patent Document 12] PCT International Application No. PCT / IB2019 / 059793 [Patent Document 13] PCT International Application No. PCT / IB2019 / 059795 [Patent Document 14] PCT International Application No. PCT / IB2019 / 059791 [Patent Document 15] PCT International Application No. PCT / IB2019 / 059803 [Patent Document 16] PCT International Application No. PCT / IB2019 / 060226 [Patent Document 17] International Publication No. PCT / EP2023 / 051529 [Patent Document 18] UK Patent Application GB2206634.4 [Patent Document 19] International Publication No. WO2017 / 145016 [Non-patent literature]

[0016] [Non-Patent Document 1] Tao, B., Dai, HN, Wu, J., Ho, IWH, Zheng, Z. and Cheang, CF, 2021. Complex network analysis of the bitcoin transaction network. IEEE Transactions on Circuits and Systems II: Express Briefs, 69(3), pp.1009-1013 Summary of the Invention [Means for solving the problem]

[0017] Embodiments of the present disclosure provide a solution for the transmission of data over a computer-based network. Preferably, - These solutions involve the use of IPv6, and / or - the data is blockchain-related data, but is not limited to use solely in connection with blockchain and blockchain-related data; and / or - The network is a decentralized network, for example a ledger (blockchain) network or any peer-to-peer (P2P) network.

[0018] In an exemplary embodiment of the present disclosure, computer-based resources may be associated to form one or more multicast groups, each group having its own respective multicast address. The multicast group address is a logical, collective identifier for the resources in the group so that they can all receive data packets from a sending node via multicast communication. In some embodiments, the address is an IPv6 multicast address, and data is sent and received over the Internet.

[0019] In one particularly advantageous example, the present disclosure may be used to transmit data from a transmitting resource to a multicast group of receiving resources, the data relating to at least a portion of a blockchain block and / or blockchain transaction. In one such example, the transmitting resource need only send the data once to all intended recipients that should receive a copy, rather than multiple times to each individual recipient as in unicast.

[0020] In one or more embodiments, a group of receiving resources may form an overlay network. The overlay network may be an overlay for a blockchain network associated with a given blockchain protocol. The blockchain network may include full blockchain nodes, each of which executes a client according to the protocol and performs at least one of mining, validation, consensus, and blockchain maintenance functions specified by the blockchain protocol. In some embodiments, a full node may include a member pool for storing transactions before they are written to the blockchain ledger, as described below and known in the art. Additionally or alternatively, a full blockchain node may be substantially as described below and with reference to accompanying Figures 1-4 as blockchain node 104. In one or more embodiments, one or some or all of the receiving resources are not full nodes on the blockchain network. In one or more embodiments disclosed herein, one or some or all of the receiving resources may be operable to perform a subset of the protocol-specified functions that a full blockchain node performs.

[0021] The receiving resources within each group may be of various types, forms, configurations, or purposes, and the transmitting resources may be members of the group or may be external to the group. This disclosure is not intended to be limiting with respect to the type or nature of the data transmitted or the purpose for which it is transmitted.

[0022] However, in one or more embodiments, one or some or all of the sending and / or receiving nodes in the group may be full nodes on the blockchain network or nodes on an overlay network, and the data may include data related to unconfirmed transactions that have been validated but not yet written to the blockchain ledger. In such embodiments, systems and methods may be provided for implementing a member pool within or associated with a blockchain network or an overlay network that interacts with the blockchain network.

[0023] Advantageous applications of the present disclosure may include, among other things, the ability to send data to a group of computing resources that provide distributed and / or parallelized blockchain-related functions. Such functions may be, for example, mining functions, on-chain discovery functions, validation functions, etc. At least one technical objective of the present disclosure may be to enhance the 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 with reference to FIGS. 1 to 4. According to embodiments of the present disclosure, at least one or some of the provided technical improvements may relate to faster or more efficient propagation of transactions through a conventional (underlying) blockchain network, as well as improved throughput of transactions or blocks or portions thereof.

[0024] Referring to Figure 5, three groups of resources 501 are illustrated. Multicast group "a" 502a includes five resources 501, multicast group "b" 502b includes four resources, and multicast group "c" 502c includes three resources. It should be understood that the number of resources 501 in each multicast group is not relevant to the present invention. For example, a first group may have 10 resources 501, a second group may have 1 resource 501, and a third group may have 100 resources 501. A multicast group 502 is a group of resources addressable via a single multicast address, as described herein. A resource 501 that transmits any type of data to another resource may be referred to herein as a transmitting resource, and the receiver of the data may be referred to as a receiving resource.

[0025] FIG. 5 illustrates each of three multicast groups of resources communicating with each other. The communication may include sending one or more packets of data in a transmission. The data may be, but is not necessarily, blockchain-related data. The transmission may include data related to a request for data from one or more recipients. Alternatively, the transmission may simply provide data to the recipient and may not include a request for a response. This disclosure is not limited with respect to the nature, form, or type of action performed by the recipient after receiving the data from the transmitting resource. The transmission may be performed using multicast and / or anycast.

[0026] When using multicast, a multicast group, e.g., group 502a, may send data to the same group 502a and / or to 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 not all) resources that are members of the receiving multicast group receive the data.

[0027] When using anycast, resources 501 of a multicast group, e.g., group 502a, may transmit data to the same group 502a or to another multicast group, e.g., 502b, by sending the data in the form of a single transmission to a single anycast address corresponding to or associated with multicast group 502b. The data packet is routed to resources 501 of multicast group 502b that are determined to be topologically closest to the transmitting 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 in one or more 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 receiver in a particular group, but the data can then be spread throughout the other members of the group via multicast transmission. This is advantageous in situations where only one or a subset of the multicast group needs to receive the transmission to provide the data to the entire group. Similarly, resources in a multicast group may transmit or receive data using multicast or anycast.

[0028] When using multicast, resources of a multicast group, e.g., group "b," may transmit data, such as data requested in response to such a request, by sending the data to multicast group "a" in the form of a single data transmission to a single multicast address corresponding to multicast group "a." In this manner, only one data transmission instance is required, and only member resources of multicast group "a" receive the data. In this embodiment, the transmitting resources may be referred to as "transmitting resources," and the member resources of multicast group "a" may be referred to as "receiving resources."

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

[0030] In one example, the sending and / or receiving resource is configured to generate, store, process, access, and / or maintain packets of data, said packets of data preferably including blockchain-related data, an assigned address is determined from the packets of data, and the packets of data are transmitted, at least in part, from the resource to the assigned address over an electronic network.

[0031] Determining the assigned addresses can include processing the packet of data to determine a key and selecting at least one address from the set of addresses using the key. The key can be determined by parsing the packet of data. The transmission resource can maintain a data structure that includes a set of assigned addresses associated with a corresponding set of keys.

[0032] Allocations, as taught herein, can complement efficient and scalable solutions for transmitting data using IPv6, where propagation of at least one packet of data can be balanced by spreading the transmission of the packet of data within the network. Nodes and / or routers can be configured to sign up for or subscribe to one or more assigned addresses, e.g., a subset of multiple multicast addresses, thus enabling balancing of the transmission of packets of data across resources associated with the assigned addresses. Balancing can be achieved through distributing propagated packets of data across a range of nodes and / or routers that selectively subscribe to the assigned multicast group and / or receive from the multicast address. Balancing can mitigate bottlenecks in the transmission of packets of data, particularly when the packets of data are large blocks that could result in delays in the nodes or routers, or when the packets of data are transactions and propagation in a generic manner would result in the transactions flooding the network.

[0033] In an embodiment involving transmitting data, multiple resources in a multicast group may each transmit a portion of the data. In an embodiment, each resource in the multiple resources may transmit a hash of the data and / or a hash of a respective portion of the data. The hash may be transmitted instead of or in addition to the data itself. This distribution helps reduce network congestion.

[0034] In an embodiment, one or more of the resources in the multicast group may be resources in a blockchain network, computing resources associated with or controlled by a financial institution, merchants, and / or digital wallets.

[0035] In additional or alternative embodiments, the request may include a request for a communication or alert related to a blockchain-related event or activity. In one embodiment, the transmitted data includes a communication or alert related to a blockchain-related event or activity. The communication or alert may be related to a double spend or attempted double spend within the blockchain network.

[0036] In embodiments, the requested and / or transmitted data includes blockchain-related data such as a blockchain transaction or portion thereof, at least a portion of a blockchain block, at least a portion of a blockchain transaction script, at least a portion of a Merkle path or Merkle proof, and / or data for use with or associated with the consensus mechanism of a blockchain network.

[0037] In one embodiment, resources in a multicast group communicate with one or more of the other multicast groups via an Internet Protocol (IP) multicast address. In one embodiment, resources in a multicast group communicate with one or more of the other multicast groups via an IPv4 multicast address. In one embodiment, resources in a multicast group communicate with one or more of the other multicast groups via an IPv6 multicast address. In one embodiment, resources and / or resource groups may be separated from one another to communicate over the Internet.

[0038] In one embodiment, each of the multicast groups comprises one or more receiving resources, and in one embodiment, each receiving resource within a given group of receiving resources is operable to receive data transmitted to a multicast address of the given group of receiving resources.

[0039] In one embodiment, a resource subscribes to a group of receiving resources, hi one embodiment, a resource subscribes by transmitting a signal to the network.

[0040] In one embodiment, a resource leaves the group of receiving resources. In one embodiment, a resource leaves the group by ceasing to transmit signals to the network.

[0041] In one embodiment, a receiving resource in a receiving resource group performs functions specified by a blockchain protocol, computations or other operations related to mining or consensus functions specified in the blockchain protocol, Simplified Payment Verification (SPV) operations, validating blockchain transactions before or after they are written to the blockchain, searching the blockchain to identify, locate, and / or confirm the existence of a given transaction or block within the blockchain, generating blockchain transactions, writing transactions to the blockchain, and / or broadcasting transactions to the blockchain network.

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

[0043] According to one or more embodiments, a computer-implemented communication method may be provided that includes a mechanism for delivering blockchain- and / or cryptocurrency-related communications, such as alerts, notifications, and updates, over an electronic network to one or more recipients as efficiently and quickly as possible. In a preferred embodiment, such improved communications are performed using IPv6 multicast. The multicast communications may include codes, flags, or filters that enable communications to be targeted to specific recipients, allowing multicast group members who are not interested in or authorized to access the content of the communication to ignore it. This provides improvements in processing resources and time. In some examples, the present disclosure may be advantageous for implementing blockchain-related alert systems or systems that can increase network responsiveness to emergencies or threats, thereby improving the security of blockchain networks.

[0044] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Brief explanation of the drawings]

[0045] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 is a diagram illustrating schematically some examples of transactions that may be recorded on a blockchain. [Figure 3A] FIG. 2 is a schematic block diagram of a client application. [Figure 3B] 3B is a schematic diagram of a mock-up of an exemplary user interface that may be presented by the client application of FIG. 3A. [Figure 4] FIG. 1 is a schematic block diagram of some node software for processing transactions. [Figure 5]FIG. 1 is a diagram of one embodiment of the present invention showing how resources in a multicast group communicate with each other to deliver electronic data securely, efficiently, and quickly. [Figure 6a] FIG. 1 is a diagram illustrating an example of an IPv4 address in dotted decimal notation. [Figure 6b] FIG. 10 is a diagram showing an example of an IPv6 address in hexadecimal notation. [Figure 6c] FIG. 1 illustrates how address prefixes can be reserved to represent IPv6 address types. [Figure 7] 1 illustrates a unicast transmission of a data packet from a server's address to a global unicast address of a computer (shown as PC1). [Figure 8] For comparison with the unicast transmission of FIG. 7, we now show a multicast transmission in which data packets sent by a server are routed through the Internet to a multicast address and retrieved by subscribers. [Figure 9] For comparison with Figures 7 and 8, this figure shows an anycast transmission in which a server sends a data packet to an anycast address, and the data packet is forwarded to the topologically closest router / node of the resource's subscribed set. [Figure 10] FIG. 1 illustrates block propagation within the Bitcoin network. [Figure 11] FIG. 1 illustrates an example embodiment of the present disclosure in which nodes of a blockchain network perform multicast transmissions of one or more mined blocks. [Figure 12] FIG. 1 illustrates an example embodiment of the present disclosure in which nodes of a blockchain network perform anycast transmissions to an anycast address. [Figure 13] FIG. 1 illustrates an exemplary embodiment of the present disclosure in which the use of multicast and anycast transmissions is combined for block distribution purposes. [Figure 14]FIG. 1 illustrates the advantageous use of block multicasting according to one embodiment of the present disclosure, including consideration of geographic factors to increase delivery speed and efficiency. [Figure 15] FIG. 1 illustrates nodes on a blockchain network broadcasting blocks via multicast transmission to key nodes in the network. [Figure 16] A diagram illustrating node B on a blockchain network broadcasting via multicast transmission to multiple nodes N1 to N4 in the network. [Figure 17] 10(a)-(d) are tables showing example values ​​derived from portions of the data used to identify and / or determine assigned addresses. [Figure 18] FIG. 1 illustrates a node B on a blockchain network broadcasting via a multicast transmission to an assigned address via each of eight outputs to nodes N1 through N8 in the network. [Figure 19] FIG. 1 illustrates node B on a blockchain network receiving data from node A and broadcasting it via multicast transmission to assigned addresses represented by multiple nodes N1 to N4 in the network. [Figure 20] FIG. 1 illustrates node B on a blockchain network that has subscribed to receive multicasted broadcasts from nodes C, D, and E, and broadcasts to assigned addresses via multicast transmissions to each of eight outputs to nodes N1 through N8 in the network. [Figure 21] FIG. 1 illustrates a Node B transmitting packets of data to a multicast group, a first subscriber, and a second subscriber, the second subscriber optionally further transmitting packets of data to the first user directly or via a second multicast group. [Figure 22]FIG. 1 illustrates a Node B transmitting eight packets of data to eight respective multicast groups, a first subscriber that subscribes to and accesses packets of data from two of the eight multicast groups, and a second subscriber that optionally aggregates the eight packets of data and transmits them to a ninth multicast group, thereby providing the first subscriber with alternative access to the eight packets of data. [Figure 23] FIG. 1 illustrates 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 THE INVENTION

[0046] By way of technical background, and with particular reference to Figures 6 through 9, we provide a description of several transmission protocols and techniques that may be used in conjunction with the present disclosure to provide the technical effects and advantages of various embodiments.

[0047] As known in the art, the Internet Protocol (IP) is a communications protocol that provides an identification and location system for computers on a network and routes data packets across the Internet. Resources (i.e., devices / systems) on the Internet are assigned unique IP addresses for identification and location definition. IPv6 was designed to provide a solution to the IP address shortage that resulted from IPv4.

[0048] IPv6 address: An example of an IPv4 address in dotted decimal notation is shown in Figure 6a. It consists of four 8-bit sections, each separated by a dot, called an octet.

[0049] For comparison, an example IPv6 address is shown in hexadecimal notation in Figure 6b, with each hexadecimal character representing a sequence of four bits. The address is composed of eight 16-bit sections, each separated by a colon. Each 16-bit section is called a hextet. This address can be abbreviated using various rules, including i) replacing multiple consecutive all-zero hextets with a double colon (only once), and ii) removing leading zeros for hextets, which results in 2001:db8::a111:b222:0:abcd Form. Considering the differences in address formats, IPv6 allows for a larger amount of addresses than IPv4. As a result, this allows for the reservation of address subspace for different address types. Address prefixes are reserved to represent various address types as illustrated in Figure 6c, where the global prefix is ​​the block of IP addresses provided to end users by Internet Service Providers (ISPs). At a minimum, it is 88 bits long, with the subnet ID containing 16 bits and the host / interface ID containing 64 bits.

[0050] These address types typically represent different ways of casting information within a network, including those shown in the table below.

[0051] [Table 1]

[0052] Multicast: Multicast is a one-to-many network transmission solution in which a transmitting resource transmits a single data packet to multiple destinations. The resource only sends one copy of the data through the network. Resources subscribed to the data feed transmitted by the sender then receive copies of the data after it has been replicated at the appropriate junctions in the network. Multicast transmission is particularly efficient in terms of bandwidth consumption because the transmitting resource only sends one copy of the data even if all group subscribers receive a copy. This is in contrast to unicast, in which the transmitting resource establishes a connection with each intended receiver and sends a separate copy of the data to each.

[0053] As shown in Figure 6c, IPv6 address subspaces can be designated for use with different types of addresses (unicast, multicast, etc.). The address shown in Figure 6c (2001:0db8::a111:b222:0:abcd) is an example of such an address. In a unicast transmission, a data packet is sent from one global unicast address to another. There are different types of IPv6 unicast addresses: Global unicast addresses are routable unicast addresses (their usage is similar to public IPv4 addresses) - see, for example, https: / / www.ciscopress.com / articles / article.asp?p=2803866&seqNum=4.

[0054] Referring to Figure 7, the unicast transmission of the data packet from the server's address to the global unicast address of PC1 results in the data packet being routed through the Internet and arriving at PC1 with address 2001:db8::a111:b222:0:abcd. PC1 becomes the only resource available to process the data packet.

[0055] For multicast, as opposed to sending data packets to PC1's address, data packets are sent to a multicast address, which is an IPv6 address with the prefix FF. Resources that want to receive data from the deriver join the multicast group at that multicast address. This is called a "subscription."

[0056] When a data packet is sent from the server, it is routed through the Internet to a multicast address (e.g., "RLocal" in Figure 8 indicates a multicast transmission from the server to subscribers PC1 and PC2). When the packet arrives, subscribers, e.g., PC1 and PC2, can read the data, while non-subscribers PC3 and PC4 ignore the data packet. This multicast reduces the need to send two separate data packets from the server to PC1 and PC2. A separate copy of the data packet is made only upon arrival at RLocal.

[0057] For the multicast packet to arrive at PC1, resource PC1 must report to RLocal that it wants to join the multicast group FF00: / 8. When RLocal sees this report, it opens an interface to PC1 in the expectation that it will forward any multicast messages to PC1 if it sees any multicast packets on the network. A router in the network (say, R2) will have been selected as the rendezvous point (RP) for multicasts to FF00: / 8. Knowing that the best path to R2 is through R1, RLocal sends a join report to R1 asking R1 to forward the request for the FF00: / 8 multicast transaction to the rendezvous point R2. R1 sends the join report to R2. When the rendezvous point receives the multicast packet, it forwards this packet to R1, which then passes the packet to RLocal, which then passes the packet to PC1.

[0058] Anycast IPv6 anycast includes the situation where multiple routers share a common IPv6 anycast address. As shown in Table 1 above, any anycast address shares the same prefix as a global unicast address. For example, 2001:db8::a111:b222:0:abcd can also be used as an anycast address.

[0059] When a data packet is sent by a transmitting resource to an anycast address, it is forwarded to the router / node closest to the resource's subscribed set. Geographic distance is one factor in determining the closest resource, but there are other influencing factors in the calculation, such as number of hops, efficiency, latency, and cost. Ultimately, in anycast, only one resource is expected to receive the data packet, which is often described as one-to-nearest-neighbor transmission.

[0060] Referring to Figure 9, which shows an anycast transmission from the server to router R3, we see that the packet is sent to 2001:db8: / 32, an anycast address shared by at least three routers (R1, R3, and RLocal). The closest of these is R3, so the data packet is sent to R3. Recall that "closest" does not necessarily mean geographic proximity.

[0061] Illustrative Embodiments Next, referring to the description of exemplary embodiments of the present disclosure and referring to FIGS. 5 through 15, a solution utilizing these transmission technologies for fast, secure, and scalable data delivery over a computing network is provided. In our preferred embodiment, data is transmitted from one or more transmitting resources to one or more receiving resources via communication over a network, e.g., the Internet. In some scenarios, the receiving resources are organized into logical groups, each of which can include one or more resources. The resources can include any type of computing resource controlled by or belonging to any organization and configured for use for any suitable purpose. Each resource can include one or more hardware and / or software components and can be configured to communicate with other resources over an electronic network. In some cases, a resource can be a mining node on a blockchain network, and in other cases, it can be a digital wallet, a cryptocurrency exchange, a search engine, a file server, or a service provider. There are no limitations on the type, form, purpose, or configuration of the resources.

[0062] Each group is associated with a respective group identifier, which 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 can therefore receive data 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. Each group of receiving resources is therefore represented by an IP address. Group addresses can therefore be used to implement one-to-many communication, as a sending resource only needs to send a packet of data once to the group address for each resource in the group to receive, rather than sending to each and every resource in a one-to-one communication (as is done with unicast transmission).

[0063] A receiving resource may subscribe, or join, a group by sending a Multicast Listener Discovery (MLD) message announcing its intention to join. Advantageously, participating resources can be located on a local network (LAN) or on the Internet, since multicast groups are not subject to the geographic constraints of local or global networks. As long as a resource announces its membership in a group, it can receive multicast packets sent to that group address. Thus, a resource can dynamically join or leave a group at any time by simply announcing its intention to join to the network, or by ceasing to announce the group to the network.

[0064] Thus, a multicast group is used to identify a group of receivers, each of which is interested in or has a need for a particular data transmission sent to the group's address. Only resources that belong to a given group can be receivers, but data can be sent to a group by any resource, whether it belongs to the multicast group or not. Resources that belong to one group can send to the other group, and vice versa.

[0065] Multicast Listener Discovery (MLD) and MLD Snooping As is known in the art, MLD is built into the IPv6 protocol. See, for example, https: / / en.wikipedia.org / wiki / Multicast_Listener_Discovery. MLD snooping provides many efficiencies over the use of MLD, as it avoids flooding the entire network with packets and thus avoids transmitting data to network resources that have not signaled an interest in receiving that data. In addition, it improves network security by avoiding Denial of Service (DOS) attacks from unknown network sources.

[0066] By default, MLD snooping is disabled. As a result, when a switch receives a packet addressed to a multicast group, it sends the packet to all interface ports in the VLAN except the port on which the packet was received. In other words, the switch floods the packet throughout the entire VLAN. If a resource is not a member of the multicast group and is not interested in the data on that channel, it ignores the packet. Obviously, this results in unnecessary network traffic and inefficient use of energy and processing resources.

[0067] However, when MLD snooping is enabled, the switch forwards multicast-addressed packets only to interface ports that have indicated an interest in receiving packets destined for that address. In other words, it sends packets only to ports that belong to members that are subscribed to that multicast group. Thus, MLD snooping allows a transmitting resource to selectively transmit data packets to resources that have indicated an interest in receiving them. If no network resources are subscribed to the multicast group, the transmitting resource will not transmit any packets. Further details can be found at https: / / techhub.hpe.com / eginfolib / networking / docs / switches / WB / 15-18 / 5998-8170_wb_2920_ipv6_config_guide / content / v33585413.html.

[0068] Distribution of blockchain-related data: In one particularly advantageous scenario, the sending and / or receiving resources are computing resources that operate to transmit, receive, store, and / or process blockchain-related data. In one example, these resources may be nodes in a blockchain network that implements a particular blockchain protocol (e.g., the Bitcoin SV protocol). A multicast group may be created that includes all nodes in the blockchain network, or a subset of nodes. For example, a multicast group may be set up to share data among a pool of miners, or a set of PoW computational resources, or other types of operations. However, in other examples, one or some of the resources may be nodes on the blockchain network, or none of the resources may be such nodes, but one or some of the resources may be resources that process data in some way for blockchain and / or cryptocurrency-related purposes, or none of the resources may be such resources. These may include, for example, digital wallet providers, cryptocurrency exchanges, banks and financial institutions, decentralized validation providers, etc.

[0069] The efficiency of IPv6 is believed to be advantageous for blockchain networks such as Bitcoin because 1) Bitcoin itself is maintained by a network of decentralized nodes, and 2) these nodes communicate peer-to-peer over the Internet.

[0070] In the Bitcoin network, each node is expected to store an up-to-date copy of the blockchain / ledger, member pool (a dataset of unconfirmed transactions), and UTXO set (a list of all unsent transaction outputs). Maintaining the most up-to-date versions of these datasets requires continuous communication between nodes, with validated transactions and blocks being shared between nodes. A block contains a set of transactions as well as a block header. The block header itself contains a nonce used to mine the block as well as a Merkle root representing the set of transactions in the block. Embodiments may be advantageously used for: - Transaction propagation: When a wallet submits a transaction to the Bitcoin network (e.g., a user uses Bitcoin to purchase an item at a store), the full node 104 receiving the transaction checks whether the transaction is valid (whether the contents meet all of the rules of the Bitcoin protocol version of the node's software) and whether the transaction is not a double-spend of a transaction already in its member pool. (A "double-spend" occurs when two payment transactions attempt to use the same output of a given funding transaction on the blockchain.) If both criteria are met, the Bitcoin node 104 updates its personal member pool and sends the validated transaction to the set of other Bitcoin nodes it connects to. Each of these receiving nodes proceeds to perform the same validity check, update, and transaction transmission steps. This enables the transaction to propagate across the Bitcoin network. - Block propagation: We refer to Figure 10, which illustrates block propagation between nodes in a blockchain, e.g., the Bitcoin network. When a node mines a new block from the pool of transactions in its member pool, it updates its data stores (UTXO set, member pool, blockchain) and relays the new block to connected nodes. For the Bitcoin protocol, a node can have a maximum of 125 connections, of which only 8 are outgoing connections.

[0071] These connected nodes then perform validity checks on the block, update their data stores, and relay the block onward, enabling the propagation of the block across the Bitcoin network.

[0072] The speed of transaction and block propagation is especially important because nodes and / or wallets need the most up-to-date versions of data sets (UTXO set, member pool, blockchain) to minimize the risk of double spending. It is also in the best interest of full mining nodes 104 to know at the earliest possible point in time that the latest block has been mined. This reduces the time spent generating proof-of-work (PoW) for a pool of transactions where some or all of these transactions are included in blocks that have already been mined.

[0073] In the BTC network, a newly mined block takes an average of 10 seconds to propagate through the network. This propagation time is proportional to the size of the block (maximum 1MB for the BTC network). On the other hand, nodes implementing the Bitcoin SV protocol, which allows for large block sizes, need our solution to reduce the time it takes to propagate those large blocks. Therefore, faster block propagation is crucial for scalability.

[0074] - Block header propagation Given that a node likely receives transactions from multiple sources and its member pools likely share transactions, it may be inefficient to send the entire newly mined block to at least eight outgoing destinations, as the receiving node likely already has many copies of the transactions in that mined block in its member pool. To address this, rather than sending the newly mined block to the outpoint node, the sending node can send a copy of the block header along with a list of transaction IDs (hashes of the transactions) contained in the block. In some embodiments, this may be an ordered list, depending on the blockchain protocol being used. This (ordered) list, along with the header's Merkle root and nonce, can prove the validity of the mined block. The receiving node can use this ordered list to determine which transactions, if any, it does not already have in its member pool. It can then send a request to the sending node for a copy of the outstanding transactions. Upon receiving the request, these are sent by the sending node to the requesting node. The requesting node then constructs or compiles a block based on the transaction and header information received from the sending node and adds the new block to its copy of the blockchain.

[0075] Multicast delivery using IPv6: According to some embodiments, IPv6 transmission of data packets is advantageously employed for block distribution on or within a blockchain network. Figure 11 illustrates an example of multicast distribution of mined blocks from node 5 to a network of nodes. Based on certain criteria, nodes within the blockchain network (or a subset of the network) that wish to receive block updates may choose to subscribe to a shared multicast address. One or more sending (source) nodes may send relevant blocks to the multicast address. These may be full or partial blocks, and may be mined or pre-mined blocks.

[0076] In the example of Figure 11, blockchain node 4 has received Bitcoin transactions from PC1, PC2, and node 5 and has successfully produced a mined block. It now wants to distribute this as efficiently as possible to a set of interested nodes. In this example, these interested nodes would be node 1 and node 2. Both nodes subscribe to the multicast address 2001:db8: / 32. Node 4 sends one copy of the block to the multicast address. After arriving at this address, the block is replicated and copies are sent to subscriber nodes node 1 and node 2.

[0077] As noted above with respect to block header propagation, sending a complete block to a recipient may mean receiving copies of transactions that the node already owns, which can be inefficient if the required data, or at least part of it, can be accessed locally rather than needing to be transmitted over the network. With this in mind, the following process variation can be implemented. - Rather than sending the entire block via multicast, the sending node may instead send only the block header and the (ordered) list of transactions via IPv6 multicast to a multicast address, so that all subscribed nodes receive this information via the multicast transmission. - Each receiving (i.e., subscribed) node uses the received information to determine which outstanding transactions, if any, it needs to generate a complete block. - If a receiving node determines that at least one transaction is required to generate a block, it sends (via unicast transmission) a request to the sending node for the required, i.e., missing, transactions, including the IDs of those missing transactions. - The sending node receives the request from the receiving node. - The sending node sends a transmission containing the requested, missing transactions to the receiving node. Preferably, this is a unicast transmission only to the individual receiving node that sent the request. This is because the set of outstanding nodes for each receiving node is likely to be unique, reducing the value or advantage of sending outstanding transactions to the entire subscribed group via IPv6 multicast.

[0078] MLD Snooping As discussed above, MLD snooping can bring significant efficiencies and benefits to the transmission of data over networks. With respect to blockchain-related services or functions, this can significantly improve blockchain-implementing applications and service providers, and even strengthen networks that implement the underlying blockchain protocol itself.

[0079] Using IPv6 multicast, transmitting resources can enable MLD snooping. Embodiments of the present disclosure may include at least, but not limited to, features such as those included in item set 8 below. This allows senders to selectively send packets only to resources that have indicated an interest in receiving them. This means that transmissions of blockchain-related or associated data can be effectively targeted to specific destinations. This effectively changes the flow of information from a push pattern to a subscription / publish pattern: a receiving host subscribes to an IPv6 multicast group, and packets are then forwarded from a switch running MLD snooping (Layer 2) to a router running MLD (Layer 3) to reach the receiving host. As a result, only necessary traffic is forwarded through the network. This addresses, at least in part, the widely recognized technical challenge of how to achieve scalability in blockchain networks that require a very large number of transactions per second to be transmitted. Thus, blockchain-related methods and systems incorporating the use of MLD snooping facilitate or enable the construction of improved blockchain networks and blockchain-implemented applications.

[0080] As an example, consider an IPv6 multicast group consisting of two members, Alice and Bob, who want to participate in SPV verification. Assume one of them is a merchant and the other is a customer who wants to purchase goods or services from the merchant using Bitcoin. The use of MLD & MLD snooping significantly improves SPV transactions by enabling both Alice & Bob to receive Merkle routes in response to their submissions to nodes on the Bitcoin network. In some embodiments, some nodes on the blockchain network may offer this functionality as a subscription-based service. In other examples, applications and services may subscribe to a multicast group address to receive submitted blockchain transactions upstream from the blockchain nodes themselves. This is possible because transactions are public. This improved data flow allows blockchain transactions to be verified via Merkle proofs using their Merkle routes, rather than by traversing or iterating the blockchain ledger. Again, this provides a more efficient solution for building blockchain-related applications that need to interactively manipulate, use, or query blockchain-related data.

[0081] Advantageously, some embodiments of the present disclosure provide a solution for implementing memo pools or UTXO sets 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 group members using IPv6 multicast messages. The blockchain-related data may be or include at least one unconfirmed blockchain transaction or at least one unspent transaction output (UTXO). International Publication No. WO 2018 / 234987 discloses the use of multicast for the propagation of initial transactions through an overlay network of specialized nodes located on top of a blockchain network, but does not disclose the use of IPv6 multicast for use with (full) nodes on the blockchain network itself. Furthermore, it does not disclose the use of multicast for the propagation of unconfirmed transactions, such as those required for the implementation of memo pools. In fact, the Bitcoin network still does not use IPv6 for inter-node communication, and International Publication No. WO2018 / 234987 actively discloses the use of DHT instead of multicast, suggesting that the network does not have sufficient scalability to handle the increased transaction output that multicast distribution would bring along.

[0082] Anycast delivery using IPv6: Anycast is particularly well-suited when transmission speed is of particular concern. With regard to block propagation in a blockchain network, nodes want to receive a copy of a newly mined block as soon as possible. Once a node obtains a copy of a newly mined block, it may choose to join an anycast address, which essentially means assigning an anycast address to itself (i.e., its network interface). An anycast address is essentially a shared unicast address. Interested nodes can then send a request transmission to the anycast address indicating that they want a copy of the newly mined block and / or are requesting a copy of the newly mined block. The request transmission arrives at the topologically closest node to the anycast address. This closest node then sends a copy of the mined block (using unicast) directly to the node that requested it.

[0083] 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. After receiving and validating their copies of the mined block, they each assign themselves to anycast address 2001:db8: / 32. The shared understanding is that this anycast address represents that the recipient owns a copy of the newly mined block. Node 5 sends a request for a copy of the block to the anycast address, and the topologically closest node (among nodes 1, 2, and 3) is the one that receives the request.

[0084] In the case of Figure 12, the closest is node 1, which then, if it chooses, sends a copy of the block via unicast to node 5. If the closest node is chosen, this means that node 1 is more likely to receive a complete copy of the block more quickly.

[0085] Note, however, that the "closest" node depends on several factors other than geographic proximity. Latency and cost were listed as factors in the determination. If the channel to node 1 becomes overwhelmed with block transmissions and block requests, the "closest" calculation may, in some cases, select another node as the new closest node. This distributes the requests and block transmissions across the nodes that own the new block.

[0086] In the case of a block header transmission, the process may still operate as described above. In a preferred embodiment, a request for the block header of a newly mined block is performed through an anycast request. Once the closest node has been determined, a unicast transmission is sent from the requesting node (node ​​5) asking for any outstanding transactions from the closest node (node ​​1). Recall that outstanding transactions are transactions in the newly mined block that are not in the requesting node's member pool. These outstanding transactions are sent to the requesting node (node ​​5).

[0087] Delivery using multicast along with anycast and / or unicast Figure 13 is 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 transmitted from a source node (N1 in Layer 0 of Figure 13) to multicast-subscribed nodes (N2...N4 in Layer 1). Other interested nodes (N6, N7 in Layer 2) determine, via anycast query transmissions, which members of the multicast group (Layer 1) are their closest peers. These Layer 2 nodes then proceed to download the blocks from the closest Layer 1 nodes.

[0088] In Figure 13, node N1 is the first node 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 also expected to assign themselves an anycast address (a shared unicast address). Nodes sharing this address are expected to be the nodes with the 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 block and sends this block to N6. For N7's request, it goes to N4 (the nearest node). N4 sends the block to N7 via unicast transmission.

[0089] This may be implemented using a fixed anycast address as follows: This is provided for illustrative purposes only, some of the steps shown below may be omitted, the order presented below is not intended to be limiting, some steps may be performed in a different order than shown below, and the following list of steps is not intended to be exhaustive. i. A set of relevant (e.g., key stakeholder) nodes agree on shared obligations, responsibilities, or goals (e.g., delivering large blocks, or blocks according to a specific protocol, or according to the terms of an agreement). ii. These interested 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 determination party that sends the multicast address to the interested nodes. After subscribing to the address, these nodes now become multicast group members, i.e., they listen for communications from the multicast address. iii. Associated nodes advertise / publicize their services to the wider network, e.g. the Bitcoin network, or at least to local or designated communities or organizations within the network. iv. At least one of the involved nodes, or another party, advertises a shared multicast address to the wider (Bitcoin) network, or at least to their respective local or designated communities. Nodes that mine new blocks are asked to send their new blocks (or block headers and ordered lists of transactions) to this multicast address. v. At least one of the associated nodes, or another party, communicates the unique anycast address to the wider Bitcoin network, or at least to their respective local or designated communities. vi. Nodes (which may be affiliated or unaffiliated) mine new blocks. vii. Mining nodes, i.e., nodes that have mined a new block, send the new block (or block header and list of transactions) to a multicast address. viii. The block (or block header and transaction) is routed via IPv6 to all members of the multicast group, in other words, the data is sent via multicast transmission to the multicast address. ix. At least one, but preferably all, of the involved nodes perform the necessary checks to validate the legitimacy of the newly mined block. x. If a block header and list of transactions are sent rather than a full block: a. An involved node compares the transactions in the ordered list with the transactions it has in its own member pool. If it cannot match at least one transaction in the list with a transaction in its member pool, it sends a unicast request to the mining node for the outstanding transactions. b. The mining node sends the missing transaction to the key node via unicast transmission.

[0090] When anycast is used: 1. Unassociated 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. When an associated node (i.e., a receiving multicast group member) with an anycast address receives a request for a copy of a new block, it then sends a copy of the block (or block header and transaction list) via unicast to the requesting node (receiving a request via anycast means that the group member is closest in the group to the request-sending node). 3. If the block header and ordered list are sent to an unrelated node: a. The node checks its member pool for transactions in the ordered list, i.e., as described above, it examines its member pool and checks whether each transaction in the list is in its member pool; if any transaction in the list is not in its member pool, the node sends a unicast request to the relevant node for the outstanding (non-existent) transaction. b. The involved nodes send the missing transactions to the node via unicast transmission.

[0091] After a certain amount of time has passed or a criterion has been met (e.g., after a block has been sent by the associated node to at least 25 nodes), the associated node may deallocate itself from the anycast address and focus on listening for new blocks on the multicast address.

[0092] Please note the following: - A node can receive block requests and disseminate new blocks while simultaneously listening for new blocks on a multicast address. - A node can subscribe to multiple multicast addresses, i.e., listen for multiple different types of blocks on the Bitcoin network. - A node can remove itself from a multicast group or anycast address at its own choice.

[0093] Given the typical limit on the number of originating nodes in Bitcoin network implementations (eight for BSV), a node seeking fast propagation of newly mined blocks may find it worthwhile to carefully consider the maximum eight nodes it connects to. As an example, the eight nodes may be strategically selected based on geographic location, in that each node may be a high-capacity node concentrated within a geographic region. ("High capacity" includes factors such as bandwidth, low latency, computational power, and storage.) These eight nodes participate in multicast for new block propagation, i.e., listen for communications from a shared multicast address. A node mining a block would recognize that it is preferable to multicast to this set of eight centralized nodes, which would then communicate the block to other nodes within their respective geographic regions.

[0094] Consider Figure 14, which presents an example of blockchain-related data distribution using multicast and geographically-based anycast for block-related data. A block mined by node N1 in Canada is sent via multicast to key central nodes in Brazil (N2), Germany (N4), and Nigeria (N3). Node N5 in Australia sends a request for a new block to the shared anycast address of N2, N3, and N4. This request reaches node N3 in Nigeria (determined to be the closest), which then sends the new block to node N5 in Australia.

[0095] Note that the centralization of key nodes within the Bitcoin network cannot be directly mapped to a geographical location. These nodes may be "topologically concentrated" or have a high degree of centrality in emerging clusters / communities within the network. As an example, Tao et al.'s paper [Tao, B., Dai, HN, Wu, J., Ho, IWH, Zheng, Z., and Cheang, CF, 2021. Complex network analysis of the bitcoin transaction network. IEEE Transactions on Circuits and Systems II: Express Briefs, 69(3), pp. 1009-1013] demonstrates the existence of communities within the Bitcoin core network. The network in Figure 15 shows that node N1 broadcasts blocks via multicast to key "center" nodes (N2...N8) within the Bitcoin network. These receiving nodes can then distribute block-related data to other nodes within the community.

[0096] balancing As described above with respect to FIG. 5, packets of data may be transmitted to at least one multicast address, with one or more packets of data included in the transmission. The term packet of data may 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 including multiple transactions. The packets of data and the data therein may be, but are not necessarily, blockchain-related data. Thus, packets of data are propagated as described herein. Packets of data may include, for example, blockchain transactions, blockchain blocks, and block headers.

[0097] Multicast and its incorporation into the IPv6 protocol can provide greater efficiency in the transmission of packets of data over the Internet and less network congestion compared to other methods of transmitting / casting packets, such as unicast and broadcast.

[0098] As a complement to an efficient and scalable solution for transmitting data using IPv6, as taught herein, the propagation of packets of data can be balanced and improved using assigned addresses so that their associated resources are used during the propagation of packets of data within the network.

[0099] The assigned address is determined from the packet of data itself. Multiple multicast addresses are provided to enable propagation of all data packets, and one of the multiple addresses is selected based on the data packet being transmitted. This serves to balance or spread the transmission of packets of data within the network. Nodes and / or routers may be configured to sign up for or subscribe to one or more assigned addresses, e.g., a subset of multiple multicast addresses, thus enabling balancing of the transmission of packets of data across resources associated with the assigned addresses. Balancing can prevent bottlenecks in the transmission of packets of data, especially when the packets of data are large blocks that may result in delays for the nodes or routers, or when the packets of data are transactions and propagation in a generic manner would result in a volume of transactions that would flood the network.

[0100] Load balancing can be achieved through the assignment of propagation to assigned addresses. A resource, such as a transmitting and / or receiving resource, is configured to transmit and / or receive packets of data, such as records, and is adapted to generate, store, process, access, and / or maintain records of the packets of data. The packets of data can include blockchain-related data. The resource can determine an assigned address from the packets of data. The resource can then transmit, at least in part, a transmission of the packets of data from the transmitting resource to the assigned address over an electronic network. Additionally or alternatively, the resource can subscribe to a group, e.g., a multicast group, to receive transmissions sent to the assigned address, e.g., an assigned multicast address. Using the assigned address when transmitting and / or receiving packets of data, the selection of the assigned address can enable load balancing by distributing the distribution of the packets of data across each assigned address and their associated resources based on the packets of data. This results in several significant technical improvements, including increased resource and energy efficiency and utilization.

[0101] FIG. 16 shows transmission resource B transmitting data packets to four nodes N1 to N4. Each transmission is sent to a multicast group. Nodes N1 to N4 subscribe to a multicast address. However, node N1 subscribes to an assigned address, i.e., a multicast group for receiving packets of data transmitted to the assigned address, as indicated by the dashed line. Resource B determines the assigned address based on the packets of data. Thus, not all packets of data are transmitted to node N1; only data packets transmitted to the assigned address are transmitted to node N1. By subscribing to the assigned address, node N1 receives a subset of packets of data transmitted from resource B, the subset being determined from the packets of data themselves. In this way, node N1 receives only a subset of packets of data, e.g., transmissions of packets of data, transmitted to the assigned address.

[0102] In this example, nodes N2 through N4 subscribe to the multicast group and receive any packets of data regardless of the packets of data being sent, while node N1 is involved in receiving selected packets of data, said selection being made via a subscription to the multicast group of an assigned address. However, in practice, each of nodes N1 through N4 may subscribe to a multicast group for a different assigned address. For example, resource B may determine that packets of data are sent to one of four assigned addresses, and four subsets of the packets of data are determinable from the set of packets of data, with each of nodes N1 through N4 subscribe to the multicast group to receive a respective subset.

[0103] Through allocation and balancing, transmission of packets of data can at least one of improve efficiency, enable scalability, support resource balancing within the network, and mitigate bottlenecks. Additionally, allocation allows at least one of the processing, storage, and validation of information associated with packets of data, e.g., each UTXO and / or transaction, to be more efficiently managed, as described and taught in PCT International Application Nos. PCT / EP2022 / 080084 and PCT International Application No. PCT / EP2022 / 080081, which are incorporated herein by reference in their entireties.

[0104] Using a packet of data to determine at least one assigned address to which said packet of data is to be sent allows propagation of the packet of data on the network to be balanced, which may be achieved through distributing the propagated packet of data across a range of nodes and / or routers that selectively subscribe to an assigned multicast group and / or receive from a multicast address. The distribution of data packet propagation using assigned addresses as taught herein may be similar to and complementary to the distribution of data validation, and as such, the following present applications are hereby incorporated by reference in their entirety: PCT International Application No. PCT / EP2022 / 079825, PCT International Application No. PCT / EP2022 / 080084, PCT International Application No. PCT / EP2022 / 079830, PCT International Application No. PCT / EP2022 / 079447, PCT International Application No. PCT / EP2022 / 079837, PCT International Application No. PCT / EP2022 / 080014.

[0105] Thus, the assigned address may be a multicast address associated with a group of receiving resources, such as node N1 in Figure 16. By non-limiting example, the packet of data may include at least a portion of a transaction (Tx), e.g., a blockchain transaction. While the allocation methods taught herein may be applied to any packet of data, they are particularly well-suited and beneficial for blockchain-related applications that use blockchain-related data, e.g., blocks, block headers, etc.

[0106] Using a packet of data containing blockchain data as an example, for example, the packet of data may include UTXO data, and the packet of data may be assigned to, for example, one assigned address from a group of eight assignable addresses. FIG. 17(a) illustrates, using a non-limiting example, eight assigned addresses, each corresponding to a binary value that is derivable from the packet of data. For example, the binary value of the UTXO data in the packet of data starts with "110," and then the packet of data is sent to assigned address "7." The range of assigned addresses is scalable; for example, the total number of assigned addresses can be 16, 256, or 1024. Thus, each assigned address may be assigned a range of packets of data to send and / or receive, store, and / or maintain.

[0107] A Bitcoin node has 125 inputs and 8 outputs; therefore, FIG. 18 represents an arrangement in which resource B is a node on a blockchain network transmitting to eight assigned addresses through each of its dedicated outputs, e.g., a packet of data may be sent to one of eight nodes N1 through N8. This may be achieved, for example, using the table in FIG. 17(a). Each output from resource B may transmit to an assigned address, e.g., an assigned multicast address / group, according to the packet of data to be sent. Nodes N1 through N8 subscribe to their respective assigned multicast addresses. By subscribing to the assigned address, node N1 receives a subset of the packets of data transmitted from resource B, where the subset of data, e.g., the packets of data, is determined from the packets of data themselves. Using the example of FIG. 17(a), node N1 subscribes to receive all packets of data having binary values ​​starting with "000."

[0108] Determining the assigned address from the packet of data may include parsing the data therein. Again using the UTXO example, the unspent transaction output (UTXO) and / or a portion of the data from the transaction (Tx) containing the UTXO may be retrieved and / or received and parsed. Parsing is just one example of processing the packet of data to determine to which assigned address the packet of data is to be transmitted. The parsing may be performed by a transmitting resource, e.g., Node B in FIG. 16 or resource 501 in FIG. 5. After parsing, the packet of data is directed for transmission to the assigned address for reception by the multicast group.

[0109] In another example, the packet of data is a block, and the assigned address may be determined from processing the packet of data therein, for example, by processing the block header. Using the example of a block header, the block header may be parsed to determine which assigned address the block is to be transmitted to. The parsing may be performed by a transmission resource, for example, Node B in FIG. 16, or resource 501 in FIG. 5. After parsing, the packet of data is directed for transmission to the assigned address. Thus, transmissions of the block are distributed over the network and addresses, for example, multicast addresses, according to the packet of data itself.

[0110] The identification and / or assignment of addresses may be performed by nodes and / or switches, such as those described with respect to node "N" and router "R" shown in Figures 11 through 15. The nodes, switches, or routers function as transmitting and / or receiving resources within the network.

[0111] When an address assignment is determined, e.g., from the packets of data held, including packets of data with UTXO / Tx, the transmission resource can selectively transmit packets of data. Similarly, receivers of data within the network can subscribe to multicast groups dedicated to their assigned addresses. In this manner, transmissions and / or subscriptions by a resource can be dedicated to the packets of data it processes. As described herein, the packets of data determine the assigned address from data therein, which may include at least one of a UTXO identifier, a hash of the UTXO script, and a transaction identification (TXID).

[0112] The transmitting resource may maintain a data structure, e.g., a lookup table, that includes a set of assigned addresses associated with a corresponding set of keys. A packet of data may be processed to determine an associated key. The transmitting resource may use the determined key to identify an assigned address to which the packet of data should be transmitted. The receiving resource may use the set of keys to identify and subscribe to a group that receives data transmitted to a multicast address, the multicast address being an assigned address associated with the corresponding set of keys. Determining the assigned address may include parsing the packet of data to determine a key and selecting at least one address from the set of addresses using the key.

[0113] The packet of data is processed, e.g., parsed, to provide a key that corresponds to an assigned address, e.g., a multicast address, to which the packet of data is to be transmitted. The key derived from the packet of data may be determined directly by using a portion of the data, e.g., the key determines the assigned address, or may be determined indirectly by processing, e.g., hashing, a portion of the data such that the resulting hash determines the assigned address. At least one of the data, the key, and the resulting hash may include at least one of an alphanumeric character and a binary number. The number is used to determine the allocated resource from the data structure.

[0114] As a non-limiting example, a packet of data includes a portion of data containing an unspent transaction output (which may be a UTXO in some embodiments, but not in others, depending on the blockchain / protocol being used for a given implementation) and / or a transaction (Tx) containing the UTXO. Inputs to the transaction include a transaction ID, an output index (e.g., Vout) that identifies which UTXO for that transaction is being referenced, a script (e.g., scriptSig) that satisfies the condition placed on the output to unlock the UTXO, and a sequence number that references the transaction containing the UTXO being spent.

[0115] Potential recipients of any cryptocurrency associated with the output can verify, for example, whether there is a double spend. Thus, potential recipients subscribe to a group to receive data at a multicast address, e.g., node N1 in FIG. 16. A node, e.g., node B in FIG. 16, acts as a transmission resource, broadcasting the transaction as quickly, efficiently, and without delay or interruption as possible. Node B therefore processes the transaction directly or receives it from a third party and uses the transaction's data packet and a portion of the data from the UTXO and / or associated transaction information to determine an assigned address. This determination can use a portion of the data specific to the UTXO, such as a key, to determine which assigned address the associated information can be transmitted to.

[0116] 19 depicts a scenario in which resource A establishes a transaction with resource B. After receiving a packet of data for the transaction, said packet of data corresponding to the transaction, resource B can transmit the packet of data to the network to an assigned address defined by the packet of data. In this manner, the network, e.g., a blockchain network, is notified of the packet of data, e.g., the transaction, so that errors or problems, e.g., double spending, can be identified.

[0117] Using transaction identification (TxID) as a non-limiting example, the TxID is typically referenced in hexadecimal notation and can also be represented as a binary number. Figures 17(a) through 17(d) are data structures, e.g., tables, illustrating how a portion of data may be used to determine an assigned address. The portion of data, e.g., the TxID, may be parsed directly or processed, e.g., hashed. In Figure 17(a), the TxID is parsed such that the first three digits of the TxID in binary form are selected as a key, and an address assigned according to information associated with the TxID having a binary value, e.g., a binary number with "101" as the first three digits, is assigned for storage / processing at assigned address "6." While using the first three binary digits allows one of eight addresses to be determined, Figure 17(c) shows how taking the first four digits from the TxID in binary form supports assignment among 16 addresses, e.g., information associated with a TxID beginning with a binary number having "1011" as its first four digits is assigned for storage / processing at assigned address "12." Alternatively, hexadecimal values ​​for the TxID may be used as shown in Figure 17(b), where a single hexadecimal value is mapped to an address, e.g., "c" through "13," and in Figure 17(d), a range of hexadecimal values ​​are assigned to addresses, e.g., information associated with a TxID beginning with "76" is assigned to address "8."

[0118] Alternatively, the portion of the data may be processed, e.g., hashed, to generate a hexadecimal or binary number, so that the subsequent determination of the key to identify / assign the portion of the data and address is not limited to the TxID.

[0119] Portions of data selected from a transaction or its UTXO, or processed values, e.g., hash values, are pseudo-random. Allocation to addresses is load-balanced, i.e., portions of the data used to determine the key for allocating addresses are pseudo-random, distributing processing and / or storage among multiple transmission resources and / or groups subscribed to the multicast address. Propagation of packets of data, e.g., information associated with a transaction / UTXO, will be distributed across multiple addresses. Balancing allocation among addresses minimizes the risk of some processing resources being left idle while others become overloaded, thus reducing performance or even failing. Thus, network resilience, performance, and / or efficiency are improved.

[0120] The packet of data, and the data therein, may thus be used to (i) determine the assigned address for transmission and then (ii) provide a reference to identify the group and / or assigned address and / or information associated with the data within a resource, e.g., within a database.

[0121] The packet of data and portions of the data therein are then derived from the blockchain to determine keys and corresponding assigned addresses and / or resources that can receive and store information associated with the data, such as unspent transaction outputs (UTXOs) and / or information associated with transactions (Tx) containing UTXOs.

[0122] The packet of data may include, at least in part, at least one of: a Merkle tree for the block in which the transaction (Tx) is recorded; a Merkle root for the block in which the transaction (Tx) is recorded; a Merkle path that enables determining, from a hash of the transaction (Tx), the value of the Merkle root for the block in which the transaction (Tx) is recorded; a Merkle proof; a block identifier (block_ID) associated with the blockchain block; a transaction identifier (TxID) associated with the transaction (Tx) in multiple blockchain transactions within the blockchain block; a function of the block identifier (block_ID) and the transaction identifier (TxID); and a concatenation of the block identifier (block_ID) and the transaction identifier (TxID).

[0123] The sending resource may include a packet of data, e.g., information necessary to determine the validity of the data in the output / UTXO, and the packet of data. Additionally or alternatively, the sending resource may generate, either itself or through a validator, a packet of data that validates and / or corroborates the validity of the output / UTXO and / or indicates whether a double spend has occurred. The sending resource may at least one of: validate and / or verify the UTXO; perform at least a portion of a simplified payment verification (SPV) process on the UTXO; verify whether a given blockchain transaction (Tx) is contained within a blockchain block; generate at least one hash of the blockchain transaction and use the hash to construct a Merkle path and / or check whether the hash matches a transaction identifier (TxID) in a header of a blockchain block; and determine a Merkle proof for the UTXO.

[0124] By providing a means for identifying assigned addresses based on packets of data, for example from a UTXO / transaction, an improved means for transmitting packets of data can be achieved, thus improving efficiency and scalability.

[0125] While the transmitting resource and / or receiving resource are described with respect to a single packet of data, in addition to or alternatively, the transmitting resource and / or receiving resource may generate, store, process, access, and / or maintain, via a subscription, a block including multiple packets of data, each of the packets of data in the block including blockchain-related data. The transmitting resource and / or receiving resource may determine an assigned address for each packet of data in the block. The transmitting resource may send, at least in part, a transmission of each packet of data in the block from the transmitting resource to the respective assigned address over an electronic network.

[0126] When transmitting packets of data to their respective assigned addresses, the blocks may be divided into sub-blocks, and a transmission resource transmits each sub-block to a corresponding assigned address over the electronic network. Taking FIG. 18 as an example, multiple data packets may be divided into eight sub-blocks, and each sub-block may be transmitted to a corresponding assigned address, as represented by N1 through N8. For example, node B, acting as a transmission resource, may group all packets of data beginning with the binary value "000" into the assigned multicast address to which node N1 subscribes, as shown in FIG. 17(a).

[0127] FIG. 20 illustrates that Node B, which is a resource, can be a transmitting resource and a receiving resource. Node B subscribes to at least one receiving resource and / or at least one multicast group, as taught herein with reference to FIGS. 8 and 9 and the corresponding description as an example of a transmitting resource and / or a receiving resource. Packets of data are received from resources represented by Nodes C, D, and E. Obviously, a transmitting resource, e.g., Node B, additionally or alternatively operates as a receiving resource. Thus, Node B is configured to receive packets of data and / or multiple packets of data having packets of data. Node B can then relay packets of data, which may include blockchain-related data, to the assigned address or relay blocks including multiple packets of data to the respective assigned addresses.

[0128] Node B may additionally or alternatively operate to collect and / or merge at least one of a packet of data, multiple packets of data, and block of packets of data received from nodes C, D, and / or E. Node B may then relay the packet of data or block of packets of data to a corresponding assigned address. After collecting at least one of the packet of data, multiple packets of data, or block of data, node B may parse the or each packet of data therein to determine a respective key and use the key to relay the or each packet of data to at least one address from a set of addresses, e.g., relay the or each packet or block of data to a multicast address represented by nodes N1 through N8.

[0129] A transmitting or receiving resource, e.g., a Node B, subscribes to a multicast group serving as a multicast address configured to receive at least one packet of data assigned to said multicast address, said assignment being determined from the at least one packet of data, and subsequent processing of the packet of data, e.g., parsing, can determine to which assigned address the packet of data is to be transmitted.

[0130] A 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. A Node B can leave a group of receiving resources, preferably by ceasing to send signals to the network. In this manner, a Node B can "switch on" to assign itself to a group and then "switch off," thereby deallocating the transmitting resources from the transmitting address. The deallocation can be performed in response to a determination that a predetermined condition has been met, e.g., that blockchain-related data has been sent to a predetermined number of receiving resources and / or that a certain amount of time has elapsed or a given date and time has arrived.

[0131] The packets of data may include communications or alerts related to blockchain-related events or activities, such as notifications from members of a cryptocurrency group or notifications from any party already participating in the group who is interested in receiving such notifications. An alert may include a notification of a double spend or attempted double spend in the blockchain network issued by a receiving node, such as a mining node or service provider in a multicast group.

[0132] The sending and / or receiving resources may be arranged, configured, and / or operable to perform one or more of the following: functions specified by a blockchain protocol; computations or other operations related to mining or consensus functions specified in the blockchain protocol; Simple Payment Verification (SPV) operations; computing or verifying a Merkle path, Merkle proof, or the root of a Merkle path; validating a blockchain transaction before or after it has been written to the blockchain; searching the blockchain to identify, locate, and / or confirm the existence of a given transaction or block within the blockchain; generating blockchain transactions, writing transactions to the blockchain, and / or broadcasting transactions to a blockchain network.

[0133] The packet of data may further include at least a portion of a blockchain transaction, at least a portion of a blockchain block, at least a portion of a blockchain transaction script, a Merkle tree for the block in which the packet of data is recorded, a Merkle root for the block in which the packet of data is recorded, a Merkle path that enables determining, from a hash of the packet of data, a value for the Merkle root for the block in which the packet of data is recorded, a Merkle proof, a consensus mechanism for a blockchain network, a result of a proof-of-stake or proof-of-work operation, or data related to that operation; and at least one of a block identifier (block_ID) associated with the blockchain block, a transaction identifier (TxID) associated with a transaction (Tx) in multiple blockchain transactions within the blockchain block, a function of the block identifier (block_ID) and the transaction identifier (TxID), a concatenation of the block identifier (block_ID) and the transaction identifier (TxID), a digital signature, an authentication code, a signature message for determining a transaction state, protocol flags, a discretionary public key (DPK), and a discretionary transaction ID (DTxID). Such embodiments may utilize one or more features as disclosed in any one or more of PCT International Application Nos. PCT / IB2019 / 059807, PCT International Application No. PCT / IB2019 / 059808, PCT International Application No. PCT / IB2019 / 059809, PCT International Application No. PCT / IB2019 / 059793, PCT International Application No. PCT / IB2019 / 059795, PCT International Application No. PCT / IB2019 / 059791, PCT International Application No. PCT / IB2019 / 059803, and PCT International Application No. PCT / IB2019 / 060226, which are incorporated by reference herein in their entireties.

[0134] The sending and / or receiving resource may include at least one of a node in a blockchain network, a service provider configured to provide blockchain-related services, a computing resource associated with or controlled by a financial institution, a cryptocurrency exchange or a component thereof, a merchant resource or a component thereof, a digital wallet or a component thereof, a software component operable to perform or facilitate a simplified payment verification (SPV) operation or process the results of an SPV operation, an MLDv1 or MLDv2 host on the network, a network switch, or a router. We present several use cases for purposes of illustration and not limitation.

[0135] Controlled Access In addition to, or as an alternative to, transmitting packets of data using nodes and / or routers as taught herein to optimize resource spreading and / or balancing through management and / or allocation, Figures 21 through 23 illustrate an example of controlled access to packets of data using an exchange between receivers—in the example receivers nominally Alice "A," Charlie "C," or Dave "D"—and transmitting resources nominally Bob "B" or Charlie "C"—the exchange using a multicast group "MG," each group having its own respective multicast address. The senders, receivers, and multicast groups can be part of a network, e.g., nodes in a blockchain network, as taught herein.

[0136] In Figure 21, a transmitting resource represented by Bob B or Charlie C functions to perform at least one of generating, storing, processing, accessing, and / or maintaining packets of data. The packets of data may include blockchain-related data. Bob or Charlie sends, at least in part, transmissions of the packets of data to multicast groups MG1, MG2 over the electronic network. Bob represents the node from which the packets of data originate.

[0137] The multicast group makes packets of data available for an end user, nominally Alice A. Alice may be described as a consumer of packets of data, e.g., an end user. However, Charlie may also access and / or subscribe to multicast group MG1 and make said packets of data available to end user Alice directly or via a further multicast group MG2.

[0138] In one or more embodiments, access to the multicast group (and thus the data sent to the group's subscribers) may be controlled through the execution of a smart contract running in conjunction with a blockchain. This may be a blockchain implemented via the Ethereum blockchain, the Bitcoin blockchain, or any other blockchain protocol. For example, a user wishing to join the group may be required to satisfy one or more conditions specified in the smart contract and, after successfully satisfying the conditions, may be provided with the necessary information to be able to subscribe to the group and begin receiving packets of data from the multicast stream. For example, a user may be provided with a key or token or other resource that enables them to join the group. These conditions may include any suitable conditions, such as the payment of a joining fee or the provision of identity-related data for user identity verification. The same or additional smart contracts may control the user's continued access to the multicast group and the data packets disseminated to / over the multicast group. For example, the smart contract may require the user to periodically pay a fee, update identification documents, or perform some other action.

[0139] Hash lines are shown in FIG. 21 to indicate the optional transmission of packets of data between Bob and Alice, i.e., via Charlie. Alice can obtain packets of data from MG1, but for example, the data can be multimedia data, e.g., a live transmission of a football game. Alice may not be able to watch it live, so an intermediary, e.g., Charlie C, also subscribes to receive packets of data from MG1 and stores them to make them available to Alice independently of Bob's transmission. Charlie can transmit packets of data to Alice directly or via a further multicast group, MG2, at a different time than the original transmission.

[0140] In one example, Bob acts as a node and transmits packets of data to a multicast address, e.g., MG1. The transmission may 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 multiple receiving nodes, which may include Alice and Charlie. The or each node, i.e., at least one of the sending node and / or receiving node, may be a node on the blockchain network.

[0141] Referring to an intermediary, Charlie, a transmitting resource or node may additionally function as a receiving resource or node and may transmit, store, process, access, and / or maintain packets of data.

[0142] Packets of data are transmitted directly to multicast group MG1 and indirectly to multicast group MG2, and consumers and / or end users of the packets of data can obtain said packets by subscribing to the multicast group.

[0143] In view of the teachings and figures herein, it will be apparent that a transmitting resource, e.g., a node or router, may transmit multiple packets of data, and / or a receiving resource, e.g., a node, may receive multiple packets of data. As a non-limiting example, the packets of data may be a data stream, such as multimedia data, and at least a portion of a multimedia communication channel.

[0144] The multimedia data may be, for example, a football game, or a subportion thereof. The football game may be transmitted over a single channel including a combination of video and audio, but the football game footage may be provided in multiple portions, with one or more portions transmitted on different channels. For example, multiple video streams may be provided, with each stream supported by a different channel. For example, the portions may include different camera angles, goal-line camera views, commentary in different languages, replays, etc. Each of the channels may be transmitted with different packets of data to a respective multicast group.

[0145] Using Figure 22, for example, Node B transmits packets of data in six different streams to respective multicast groups MGa to MGf, the packets containing multimedia data of a live football match. Groups MGa and MGb receive packets of data containing visual camera angle data, the former following the game play and the latter showing exclusive goal-line activity. Groups MGc and MGd receive packets of data containing play-by-play commentary in different languages, the former English and the latter German. Groups MGe and MGf receive packets of data for optional extras, the former providing exclusive replay action and the latter providing footage from referee-worn body cameras.

[0146] During the match, Alice streams the match play and English commentary by accessing multicast groups MGa and MGc. Optionally, at the same time, Charlie at node C accesses and captures data packets from all multicast groups MGa through MGf. The captured data is collected and / or aggregated by Charlie at node C and made available separately and independently via multicast group MGm, which makes available all data packets transmitted from node B to multicast groups MGa through MGf, thus providing full match information, language, and camera views on demand. Alice can access group MGm to rewatch the match play or access additional information contained within the packets of data. An intermediary, such as Charlie, can operate to merge, e.g., pool, packets of data from one or more multicast groups for subsequent transmission to another multicast group.

[0147] A transmission resource, e.g., a Node B, can transmit multiple packets of data. Additionally or alternatively, the packets of data can have subcomponents for providing multiple data channels. The packets of data can be separable for independent transmission to multicast groups (i) according to channel capabilities, as described in the example above with respect to different aspects of a football game, and / or (ii) based on the packets of data themselves, as described in Section 9 and related discussion.

[0148] The teachings herein are not limited to football matches, and in other examples, the transmission of packets of data may be applied to delivery drivers, where a control room transmits packets of data relating to delivery addresses, driving routes, traffic information, weather information, and the like, which can be selectively received by delivery vehicles, the operation and / or coordination of drones, the management of warehouses and goods therein, and subscription media services such as Netflix™ or Sky™ television.

[0149] Packets of data and / or multicast groups may be secured, e.g., encrypted, or otherwise locked with an access key that must be applied when subscribing to a multicast group and / or used on packets of data to access the content therein. Separate access keys may be required to access different multicast groups and / or packets of data. For example, a first access key may be required to access packets of data, while a second access key may be required to access the multicast group, e.g., via a subscription.

[0150] A transmission resource can protect access to a multicast group and / or protect data by determining whether an access key is required to access packets of data. A transmission resource can manage subscriptions that manage access to a multicast group, e.g., require an access key. In an example, Bob B and Charlie C are transmission resources, each of which can protect packets of data they transmit and / or manage access to the multicast group to which they transmit. Alice can join a multicast group and access packets of data by subscribing to a service that provides an access key for 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, thereby allowing Alice to unlock protected packets of data.

[0151] A manager of transmission resources and / or multicast groups can generate access keys needed by an intermediary, e.g., Charlie C, that acts as an aggregator and pools packets of data for subsequent access by end users such as Alice, and / or by an end user, e.g., subscriber Alice A. The access keys are provided to Charlie and Alice, in one example.

[0152] The access key may be obtained by an intermediary or an end user, e.g., an aggregator or an end user, in a traditional exchange, i.e., providing the access key in exchange for payment. In light of the teachings herein, which use at least blockchain-related data and interactions between nodes on the blockchain network and blockchain transactions, at least one access key is provided to the intermediary or end user via a payment channel, see https: / / wiki.bitcoinsv.io / index.php / Payment_Channels.

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

[0154] Efficient access to secure packets of data using access keys can benefit from the use of payment channels, where each key can be used to subscribe to and / or unlock packets of data, for example, to trigger automatic payments to transmission resources, the transmission resources being the source of the packets of data. The access key can provide access to the multicast group and / or packets of data for at least one of: (i) a fixed period of time, and (ii) a fixed amount of data, (iii) a fixed number of units, (iv) a fixed number of packets of data, and (v) unlimited access.

[0155] A transmission resource, such as Bob or Charlie, can transmit packets of data to a large number of multicast groups. The scope of the IPv6 protocol and blockchain applications is such that the amount of packets of data transmitted can be significant, and the packets are transmitted to an equally significant number of multicast groups. This allows for a scalable and granular means of distributing packets of data, while reducing bottlenecks and balancing resource usage.

[0156] In addition to the transmission and / or subscription and / or access techniques taught herein, transmission resources can be assigned to packets of data to a multicast address, the multicast address being determined from at least one of the packets of data and an access key.

[0157] The allocation techniques taught with respect to features and embodiments of enumerated item set 9 and elsewhere herein can be applied to complement efficient and scalable solutions for transmitting data using IPv6, as taught herein. Balancing can mitigate bottlenecks in the transmission of packets of data, particularly when the packets of data are large blocks that may result in delays in nodes or routers, or when the packets of data are transactions whose propagation in a general manner would result in a volume of transactions that would flood the network.

[0158] The teachings herein may additionally or alternatively apply to a receiving resource, such as an end user or aggregator, e.g., Alice A or Charlie C, that can store, process, access, and / or maintain packets of data, the packets of data preferably including blockchain-related data. The receiving resource receives transmissions of packets of data, at least in part, via a multicast group that received the packets of data from an electronic network. The packets of data are consumed by an end user, such as Alice, and / or an aggregator, such as Charlie. As described above, Alice and / or Charlie can access the protected packets of data using an access key, and access to the packets of data and / or the multicast group is protected and accessible using the access key. The access key may be obtained via a payment channel established with at least one of the source of the packets of data, the transmitting resource, and the multicast group.

[0159] Figure 21 shows a further example of how a transmission resource, represented by node B, e.g., Bob, transmits packets of data to eight different multicast groups—nominally MGa to MGH. Bob functions as a blockchain node and therefore has eight outputs. Packets of data are transmitted to each multicast group based on the packet of data being transmitted, which can be used to determine an assigned address, i.e., multicast group. The allocation determination can be implemented, for example, using the teachings of item 9 herein and the data table of Figure 17(a).

[0160] Alternatively, the allocation may be determined using an access key and / or the content of the packets of data. For example, a multicast group—nominally MGa to MGH—may hold data associated with geographic locations received from transmissions from Node B, Bob, which is a transmission resource. Each geographic location may have its own access key, which may be obtained via a subscription.

[0161] In one example, a transmission resource transmits packets of data, e.g., maps and traffic information, associated with a city having eight districts. Six autonomous vehicles, e.g., taxis, operating in a drone-like manner, labeled D1 through D6, are needed to transport goods or residents within the city.

[0162] Each drone, D1 to D6, operating as a taxi, determines the start and end points for a given driving route, as well as the neighborhoods it needs to traverse. The drone then accesses corresponding packets of data related to those neighborhoods from the multicast groups associated with those neighborhoods, for example by subscribing.

[0163] Each district and / or drone may be licensed. Thus, for a drone to operate in one or more districts, it needs a license for each district, with the license providing an access key corresponding to packets of data associated with the licensed district. Alternatively, or in addition, each drone may obtain a license and corresponding access key by subscribing to the required multicast group from which it obtains the necessary license, map, and traffic data. Subscription may occur when needed and may be switched "on" or "off" depending on requirements. Subscribing to a multicast group to obtain packets of data for a licensed district may be time-based, unit-based, etc.

[0164] In the example of FIG. 23, drones D1, D2, D4, and D5 start and stop in the same district and switch on to receive or otherwise subscribe to multicast groups Mga and MGb, respectively. Drone D3, however, traverses three districts and accesses packets of data associated with districts MGa, MGb, and MGc. In contrast, drone D6 traverses six districts and accesses packets of data associated with districts MGc through Mgh. During normal operation, drone D6 operates only in the district supported by MGc and may need to move to other districts on demand. Thus, drone D6 may take out a yearly subscription to an access key for multicast group MGc and / or the data it provides, while subscribing to other multicast groups as needed when moving between other districts.

[0165] 21 through 23, and non-limiting examples, teach methods and associated system requirements for controlled transmission, dissemination, and / or access to packets of data. The packets of data may include information such as multimedia content, map data, or similar content. Access may be achieved, for example, through a subscription that can be paid for using payment channels supported by the blockchain nodes and the blockchain network. An exemplary application may be a "pay-per-view" or "pay-per-use" service. Embodiments may be particularly useful for applications where enhanced control is needed over data streamed from a source to multiple potential data consumers.

[0166] Accordingly, some examples provided herein relate to the transmission of packets of data using nodes and / or routers that optimize resource distribution and / or balancing through management and / or allocation, as summarized in each section. In particular, examples relate to controlled transmission and / or access to those packets of data. More particularly, contractual access, e.g., payment, to packets of data is presented. According to one possible aspect, the present invention may reside in a computer-implemented method that includes operating a transmission resource to generate, store, process, access, and / or maintain packets of data, the packets of data preferably including blockchain-related data. The transmission resource may be the origin, e.g., creator or producer, of the packets of data, or the transmission resource may be an operator, such as a distributor, that collates, aggregates, or pools packets of data for subsequent transmission, independent of the original transmission or creation of the data. The transmission resource may transmit, at least in part, transmissions of packets of data from the transmission resource to a multicast group (over an electronic network). The multicast group makes the packets of data available for access by end users.

[0167] Multiple packets of data may be transmitted and / or received. For example, rather than transmitting a movie in a large packet of data, the movie may be divided into multiple parts and each part may be transmitted as a single packet of data. The packets of data may be, at least in part, a data stream, such as a multimedia communication channel. The packets of data may have subcomponents to provide multiple data channels.

[0168] An end user may typically be a consumer, e.g., a subscriber, who accesses packets of data via a multicast group. The multicast group and / or packets of data are protected, and a recipient, e.g., an end user, may pay to obtain an access key to access the multicast group and / or packets of data. Multiple access keys may be provided. A first access key may be required to access the packets of data. A second access key may be required to access the multicast group.

[0169] The transmitting resource can generate an access key. The transmitting resource can transmit the necessary access key to the recipient of the packet of data and / or to the end user to access the packet of data. The access key can be provided during a transaction using a payment channel. Additionally or alternatively, in some embodiments, a smart contract can be used in conjunction with a blockchain to control a user's initial and / or ongoing access to a multicast group. When executed in conjunction with a blockchain, the smart contract can require a user to fulfill one or more conditions in order to subscribe to and / or remain a member of the group.

[0170] The access key may be configured to provide access to packets of data and / or simultaneously represent a license and / or access to a digital or physical asset protected with a digital lock. The access key may provide access to, for example, a multicast group and / or packets of data for at least one of: (i) a fixed period of time, (ii) a fixed amount of data, (iii) a fixed number of units, (iv) a fixed number of packets of data, and (v) unlimited access.

[0171] According to another example, a computer-implemented method includes operating a receiving resource to store, process, access, and / or maintain packets of data, the packets of data preferably including blockchain-related data. The method further includes receiving, at least in part, a transmission of the packets of data via a multicast group that received the packets of data from an electronic network, and consuming the packets of data as an end user. Access to the packets of data and / or the multicast group may be secured. The receiving resource may obtain access using an access key. The access key may be obtained via a payment channel.

[0172] The packet of data may include at least one of a portion of a transaction (Tx), an output (e.g., a UTXO) identifier, a hash of a script (e.g., a script associated with an output of a transaction), a transaction identifier (TXID), a blockchain block, and / or a block header.

[0173] Exemplary Use Case 1: Double Spending and Network Communications such as First Seen Rule, Network Notifications, etc.: It is well understood that communication over electronic networks of all types poses a variety of significant technical challenges. With respect to blockchain-related networks, in particular, there may be a further need to spread information and data as quickly and efficiently as possible to at least a set or subset of targeted recipients who may need to act on the information / data. Some embodiments of the present disclosure may use IPv6 multicast communications to achieve, or at least facilitate, the goal of delivering data / information as taught herein to a set of receiving resources that are subscribers to a multicast group. The multicast communication may be: Alert: A warning that a risk or potential event has been identified that may or may not occur, or that may be harmful to or otherwise relevant to at least part of a network / group, and that the recipient must take responsive action, the need for responsive action being indicated in the alert or made known to the recipient in some other way, for example, the responsive action may be to apply a security fix, a software upgrade, or to prohibit the processing / use / transfer of some cryptocurrency. Notifications: For example, informational messages, e.g., that an update is available for download, that an event may / will / has occurred, or any other news that may be relevant to the recipient. Instructions or triggers: For example, the message may contain executable code or data that 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 behavior of one or more recipients.

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

[0175] Embodiments of the present disclosure are advantageously utilized in the transmission of communications over an electronic network, such as the Internet, so that interested or potential interested parties can receive the data / information contained in those communications. Embodiments according to these exemplary use cases may have features substantially as described in the enumerated items provided herein, particularly with respect to item set 11.

[0176] In some embodiments, with respect to scenarios in which communications include blockchain protocol-level information / data that the transmitting resource desires or needs to share, subscribers to a multicast group may be limited to some type or form of receiving resource. For example, in some embodiments, the receiving resource may be a full node on the blockchain network, e.g., a miner. Additionally or alternatively, the receiving resource may include a non-mining node. In other examples, one or more of the receiving resources and / or the transmitting resource may be a vehicle or drone that is autonomous, semi-autonomous, or may be operated by a human operator. The following examples are not intended to be exclusive or exhaustive, and features of these examples may be used alone or in combination with each other.

[0177] Implementing a cryptocurrency alert key using IPv6 multicast In one example, an embodiment may implement an alert key mechanism for disseminating critical, urgent, or essential communications to entities on a network using IPv6 multicast communications. Embodiments of the present disclosure provide advantages for disseminating cryptocurrency-related communications, e.g., alerts and notifications, to interested parties, such as nodes on a blockchain network. According to the present disclosure, a blockchain / cryptocurrency alert system may be implemented in which network-related data may be broadcast to all or some nodes / receiving resources on the network via IPv6 multicast communications. Alerts may include data regarding at least one of, for example, security patches, fixes or updates for potential security weaknesses, updated versions of blockchain protocols, software updates, cryptocurrency double-spend attempts, legal (court-ordered) prohibitions, restrictions, or orders, access codes for alert keys, etc. Parties interested in a particular blockchain network / protocol may subscribe to a multicast group set up to communicate relevant information to such parties.

[0178] The alert may trigger or require a response by at least one recipient of the alert. For example, the response may include one or more of the following: "Freezing" or temporarily / permanently prohibiting the processing of at least one block, transaction, or transaction output. For example, this may include prohibiting the use of cryptocurrency or a portion of unspent outputs, or the validation of one or more (blockchain) transactions, or the inclusion of one or more transactions in a block for potential inclusion in a distributed ledger. A freeze / ban may include marking or identifying a portion of data, such as at least part of a transaction or block, as invalid, inpayable, rejected, or to be ignored. Forwarding (i.e., onward transmission) of the alert from at least one receiver to at least one further receiver. The at least one further receiver resource may include at least one further IPv6 multicast address. This allows communications to be sent from one multicast group to one or more further multicast groups, thus providing a fast and efficient mechanism for disseminating data such as time-critical updates, notifications, warnings, or security patches and solutions. Downloading, accessing, installing, and / or executing any portion of code or data on the receiving resource or one or more further resources. For example, the code or data may relate to at least one of the following: a security patch, a fix or update for a potential security weakness, an updated version of a blockchain protocol, a software update, a cryptocurrency double-spend attempt, or a legal (court-ordered) prohibition, restriction, or order.

[0179] Filtering IPv6 traffic into your network using codes, flags, markers, or other identifiers In another exemplary embodiment, the communication may include a code, flag, marker, or other identifier that acts as a filter.

[0180] The filters may be provided in a pre-specified arrangement and / or in a predetermined format in communication so that at least one or some of the receiving resources can identify, understand, and / or act upon the filters. In some embodiments, the filters may be provided in the control information (packet header) or user data payload of an IPv6 packet. In some embodiments, the filters may be hexadecimal or binary codes associated with or indicative of a predetermined signal, state, or meaning. Additionally or alternatively, the filters may be associated with or indicative of a type of intended recipient. Thus, filters can serve as a means for targeting communications to specific recipients or groups / subsets of recipients based on the content / type of the communication being sent and / or the intended or desired set of receiving resources.

[0181] For example, assume that a sending resource sends a communication to a group of receiving resources that are subscribed to a particular IPv6 multicast address that is set up to spread messages about 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 validation, SPV, and wallet-related services. Next, assume that the sending resource notices malicious activity that may affect the entire blockchain network and all parties that use and interact with it. The sending resource wants to alert all subscribers because all subscribers have an interest in that blockchain. Therefore, the sending resource generates and sends an IPv6 multicast communication to the group address, with information and / or instructions about the malicious activity included in the payload portion of the IPv6 packet. The packet may also include a flag indicating that the message is of interest to all subscribers. Thus, each subscribing interface detects and processes the packet sent to the group address. This may involve taking corrective action in response to the information conveyed in the communication, such as ignoring a particular block of a transaction or designating an output as already spent.

[0182] However, in other scenarios, a transmitting resource may wish to send communications relevant to only a subset of subscribed resources. For example, a mining node may need to install a software update if a protocol update occurs or a security vulnerability is detected. Such updates may not be relevant to other subscribers on the network who are not operating as full nodes, and it would therefore be inefficient to receive and process communications that are not necessary for operation. Therefore, to improve the efficiency and security of communications across the network, a transmitting resource may include a filter in its communications indicating that it is relevant only to some members. When a member sees an IPv6 packet, it can inspect the filter. If the filter indicates that the packet is relevant only to full nodes, the full node member interprets this accordingly, processes the data in the packet, and takes one or more appropriate courses of action, such as installing an update. However, non-mining nodes ignore the packet because the filter flags the content as not relevant. This saves energy, resources, and time for group members.

[0183] Furthermore, such a flagging mechanism allows different types of communications to be targeted to specific subgroups of members, thus providing an improved electronic communications solution across an entire blockchain-related group of members. Still further, this allows for the creation and transmission of a hierarchy of communications and alerts, as the filtering mechanism can provide complex structured forms to selectively target different types of communications to different members of one or more multicast groups.

[0184] In a preferred embodiment, some or all of the data in a communication may be encrypted or otherwise protected for privacy and security purposes. Thus, sensitive information or information intended only for specific recipients may be protected. For example, data in the payload of an IPv6 packet may be encrypted using a cryptographic key, masked, or encoded using some other security mechanism or algorithm. An authorized recipient may be provided with a means to unlock, e.g., decrypt, the protected data so that it may be properly read and used by the recipient. The unlocking mechanism may be, for example, a key, an access code, or some secret known to the recipient. This unlocking mechanism may be provided to the authorized recipient by the communication generator / sender or a trusted party associated with or acting on their behalf.

[0185] Additionally or alternatively, at least a portion of a communication may be marked in some way to allow a receiver to be confident that it was generated and / or sent from or on behalf of a particular entity. The entity may be known by the receiver as a legitimate or authorized source of communications and data. In some examples, the authenticity of a communication may be established by signing at least a portion of the communication using a secret or private key known to belong to a legitimate entity. In other examples, the communication may include a watermark, secret code, steganography, or message that can be used by the receiver to verify that the communication was sent from or on behalf of a legitimate source.

[0186] "First Seen Rule" and Double Spending Satoshi Nakamoto's white paper, "Bitcoin: A Peer-To-Peer Electronic Cash System," introduced the concept of a "first seen rule" regarding transactions and blocks on the Bitcoin network. This rule states that when a mining node is evaluating blocks according to the protocol, the first block it sees is the first valid block broadcast to the network and is the block furthest from the genesis block in the valid chain. This is important in terms of avoiding "double spend" scenarios.

[0187] As explained in the Bitcoin SV wiki (https: / / wiki.bitcoinsv.io / index.php / First_seen_rule): "If two blocks are competing in an orphan race, and a node is trying to build on one of the blocks when a new block is discovered on top of the competing block, the node stops working on the first seen block and moves up the longest chain...When receiving transactions, the first seen rule is applied to determine which transaction is valid in the case of a double spend. When a node detects a double spend, it always considers the first received transaction to be the valid spender of that coin." This rule has been further expanded to add that when blocks containing double-spending transactions are discovered, they should also be considered invalid and nodes should continue mining the block unless a second block is discovered on top of that block indicating that a majority of the network has determined that the other transaction was seen first."

[0188] Therefore, it is crucial to send communications out onto the network as fast as possible. Each "hop" that must be made from node to node to fully distribute information across the network takes time, thus reducing the security of the network. Currently, such communications are sent around the network using unicast transmissions, which means there is one sender and one receiver for each message, requiring multiple hops as information is relayed from node to node.

[0189] However, according to the present disclosure, communications such as notifications of double-spends (attempted / possible double-spends) are sent to mining nodes in a multicast group, allowing all involved nodes to simultaneously receive the alert as quickly as possible and take any necessary corrective action. There are no "hops" as the message is relayed from one node to another. Instead, each node that has joined the multicast group listens to the subscription stream and picks up the message itself. Such embodiments therefore provide improvements in processing, time, and security with respect to network communications and alerts.

[0190] In another exemplary application, a multicast group may include members who are not miners or full nodes on the network but who need to share blockchain-related information, such as transactions, blocks, or portions of blocks. For example, one, some, or all of the members may be merchants or other parties who wish to send, receive, or otherwise process blockchain transactions. In some cases, merchants may wish to perform SPV validation of transactions and need to share information about Merkle paths and block headers for use in SPV validation. Block discovery involves creating hash headers or block headers, which are sent to all SPV nodes. The use of multicast allows for near-instantaneous communication for this data delivery.

[0191] In another example, the sending resource may be an issuer of a digital currency, such as a central bank, and the receiving resource may be a bank or other financial institution that processes the digital currency. The central bank may, for example, issue a Central Bank Digital Currency (CBDC). With traditional cash, mints distribute physical notes and coins to individual banks by transporting them in vehicles. With digital cash, distribution is handled via a multicast group, whose members are banks to which the central bank wants to distribute funds.

[0192] Exemplary Use Case 2: Decentralized Blockchain Functionality: Embodiments may be used with any type of data, and the sending and / or receiving resources may be arranged, configured, or operable to perform any type of function. In one non-limiting example, data substantially related to a Merkle challenge, such as that described in International Publication No. PCT / EP2023 / 051529, may be transmitted to a multicast group. In such a scenario, assume that a resource wishes to delegate storage of a file or other resource to multiple storage providers, and therefore the transmitting resource generates a Merkle tree representing various segments of the file and transmits the file to one or more storage providers. Later, when the transmitting resource wishes to verify that the storage provider still has an unaltered copy of the transmitted data, the sender modifies the data in a particular way, recalculates a Merkle root for the tree, makes the same modifications to its copy, and asks the storage provider to transmit the recalculated Merkle root back. The resource can quickly verify whether the storage provider was able to provide the expected Merkle root. If the transmitted Merkle root does not match what the resource expects, the storage provider's copy must have been corrupted or tampered with in some way. When used in conjunction with the present disclosure, a resource may send separate portions of a file to different storage providers, each of which is a member of a given multicast group. When the integrity of the file needs to be verified or the constituent parts need to be reassembled, the resource requests this by polling the group.

[0193] In another exemplary use case, the data transmitted 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 lock or unlock script, or includes data related to a Merkle proof / route, or data used to implement a consensus mechanism, e.g., PoW or PoS-related data. Merkle proof data may include data related to a blockchain transaction and data for proving (or validating) that the transaction is contained within a particular block. Merkle proofs and their use to verify transactions within a block, along with related techniques such as Simple Payment Verification (SPV), are known in the art. Other non-limiting examples of blockchain-related data could include data for use with or associated with a blockchain network's consensus mechanism. For example, this could be data related to a proof-of-work PoW calculation or some other blockchain consensus mechanism. In one example, this could be data related to a PoW calculation as described in UK Patent Application No. GB2206634.4.

[0194] When used for blockchain-related purposes, at least one receiving resource in the group may be arranged, configured, and / or operable to do one or more of the following: Functionality specified and / or desired / required by the blockchain protocol; Computational or other operations related to mining or consensus functions specified in the blockchain protocol; Simplified Payment Validation (SPV) operations, Validating blockchain transactions before or after they are written to the blockchain; Searching the blockchain to identify, locate, and / or confirm the existence of a given transaction or block within the blockchain; Generating blockchain transactions, submitting transactions to the blockchain, and / or broadcasting transactions to the blockchain network.

[0195] Exemplary Use Case 3: Resolving Packet Loss In another example, a combination of multicast, anycast, and unicast transmissions may be advantageously used by members of a multicast group to ensure or achieve incomplete reception of data from a transmission resource. Consider a scenario in which a transmission resource wishes to send a portion of data to all members of a multicast group, but the receiving members of the group are unable to receive all of the transmitted data. This is a not uncommon problem in networking (see https: / / en.wikipedia.org / wiki / Packet_loss).

[0196] For example, suppose a multicast transmission containing 10 packets of data is sent to a multicast group, but a particular group member (called a receiving resource) receives only 8 of the 10 data packets sent. The receiving resource is missing packets 2 and 7. The receiving resource can obtain the missing data packets by requesting them from the nearest member of the multicast group using an anycast transmission. The receiving resource knows that all other group members will have received the data transmission because it was sent to the multicast group.

[0197] This solution is 1. Using multicast transmission, transmitting a portion of data (e.g., contained in multiple data packets) from a transmission 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 a complete portion of the data; 3. Sending an anycast transmission from the resource to the other nearest members of the multicast group, requesting missing subportions (packets) of data not received by the resource; and / or 4. Receiving, at the resource, the missing (dropped) subportion of data from the nearest other member of the multicast group, where the missing subportion of data may be provided to the resource from the nearest other member by any suitable method, such as unicast; It can be performed using a method including:

[0198] This provides a solution to the technical problem of how to resolve or address packet loss. The use of initial transmission via multicast, combined with recovery of dropped packets using anycast requests to the nearest member and unicast responses providing the dropped data, provides an efficient and fast approach. As with other example use cases and embodiments, this technique may be utilized with any type of data and by any type of resource, including, but not limited to, blockchain-related data / resources.

[0199] Exemplary Use Case 4: Efficient and cost-effective balanced delivery using assigned addresses. In another example, using the teachings herein, a resource B, as shown in FIGS. 16-20, nominally referred to as "Bob," operates as a node, e.g., node B, on a network, e.g., a blockchain network, as shown and described with respect to FIG. 5. Bob operates to forward or route data, packets of data, or other such packets of data on 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, can securely communicate with anyone else on the network in a peer-to-peer manner using the teachings of International Publication No. WO 2017 / 145016, the entirety of which is incorporated herein by reference.

[0200] Bob wants to ensure that information critical to the stability of a network, such as a blockchain network, is communicated across the network efficiently and without delay. An example of critical information could be new transactions - sharing transaction details across the network is important to prevent double-spending. As a result, Bob can share with the network transactions he originates and / or transactions he receives, for example, from Alice.

[0201] Bob shares any packets or blocks of data received from the network, including but not limited to sharing details of transactions he generated or received from Alice. In one example where Bob is a blockchain node, Bob has 125 inputs and 8 outputs. Thus, Bob can subscribe to receive data from multiple sources, e.g., multicast addresses, and transmit to multiple addresses, e.g., multicast addresses. Received and transmitted data can include, in a non-limiting example, packets of data described in Section 9.16 herein. However, one example uses data associated with the transaction for transmission and, optionally, validation, e.g., SPV, using Merkle proofs.

[0202] Transmitting packets of data, such as records or blocks of data, over a network takes time to propagate. Transmitting to a multicast address and / or receiving packets of data by subscribing to a multicast address or group improves transmission. However, to minimize propagation delays and / or bottlenecks, a set of packets of data, e.g., one packet of data, may be divided into subsets, with each subset assigned to a different address, e.g., a multicast address. For example, a block may be propagated according to a property of the packet of data or block that determines the assigned address, e.g., the assigned multicast group address to which it is transmitted. Additionally or alternatively, a block may be divided into several parts, and the packets of data therein may be separated and transmitted separately according to a "key" determined for each of the packets of data therein.

[0203] By assigning a subset of packets of data to addresses, transmission efficiency can be improved by reducing bottlenecks and balancing load across the network. The assignment is determined from the packets of data themselves; using the example of a transaction received from Alice, Bob can process Alice's transaction and transmit it to the assigned address. Alice's transaction can be parsed and / or hashed to generate a key. As shown and described with respect to Figures 17(a) through 17(d), the key can be derived from the binary or hexadecimal values ​​of the transaction data or hash, and the key can correspond to the assigned address.

[0204] Bob therefore acts as the source of packets of data transmitted over the network. Bob can be the originator of packets of data or can receive packets of data, such as transactions, directly from Alice. Rather than randomly sending packets of data over the network, Bob processes the packets of data to determine an assigned address to send the transmission to.

[0205] Additionally, Bob can combine packets of data and transmit them in blocks to assigned addresses, which can be determined from the packets of data and grouped according to a "key" used to determine the assigned addresses.

[0206] While Bob can generate transactions or receive transactions from Alice, Bob also operates to receive packets of data from other nodes in the network. After receiving a packet or block of packets of data, Bob: i. Merging packets of data sent to assigned addresses, e.g., multicast addresses to which Bob subscribes, and transmitting those packets of data to the corresponding assigned addresses; ii. amalgamating packets of data sent to assigned addresses, e.g., a multicast address to which Bob subscribes, and processing, e.g., parsing, the packets of data therein to determine an assigned address for each corresponding packet of data, and transmitting those packets of data individually or in blocks to their respective assigned addresses, said blocks holding packets of data that share the same assigned address; and iii. receiving packets of data sent to an assigned address, e.g., a multicast address to which Bob subscribes, processing the packets of data therein, e.g., parsing them to determine an assigned address for each corresponding packet of data, and transmitting those packets of data individually or in blocks to their respective assigned addresses, said blocks holding packets of data that share the same assigned address; At least one of the following can be performed.

[0207] Bob can "switch on" and "switch off" subscribing to a group of receiving resources by sending signals to the network or stopping sending signals to the network. In this way, Bob can regulate the amount of packets of data received and / or transmitted according to at least one of his capacity, a time frame, a contract period, network capacity, and a transmission level, e.g., a packet of data reaching a threshold number of nodes within a threshold period of time.

[0208] Enumerated items The items listed therein are provided for the purpose of illustrating some possible embodiments that may be provided in accordance with the present disclosure. The sets of items presented below are for illustrative purposes and should not be construed as limiting, exclusive, or exhaustive. Features described in one set of items may be utilized and incorporated in one or more of the other sets of items. In any one or more of the sets of items below, embodiments may provide computer-implemented methods and / or data distribution methods. Additionally or alternatively, embodiments may provide improved data transmission or exchange methods or improved electronic communications.

[0209] A computer-implemented data distribution method is disclosed. The method may include transmitting 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 being associated with a respective address, which may be a multicast address. In other words, groups of resources may be formed, and for each group, the resource subscribes to the members of the group, and all members are associated with an address that identifies the group. Embodiments of the present disclosure may include generating, creating, or providing an IPv6 multicast address. One, some, or all of the receiving resources may be full nodes 104 on the blockchain network, or nodes in an overlay network that reside on one or more full nodes on the blockchain network but communicate with one or more full nodes on the blockchain network. The sending resources may be full blockchain nodes 104, or nodes on a blockchain overlay network that reside on one or more full nodes on the blockchain network but communicate with one or more full nodes on the blockchain network. These features may apply to one or more of the set of items presented below.

[0210] Some embodiments may provide a solution for implementing member pools for a blockchain network.

[0211] Some embodiments may provide a solution for implementing UTXO sets for a blockchain network.

[0212] Also disclosed herein is a method for producing a medicament for the treatment of a pulmonary arthritis. - a computing device comprising a memory including one or more memory units and a processing device including one or more processing units, the memory storing code configured to be executed on the processing device, the code being configured, when on the processing device, to perform the method of any embodiment described or defined herein; and / or - a computer program embodied on a computer-readable storage and configured to, when executed on one or more processors, perform any of the methods described or defined in this specification.

[0213] Item Set 1: The following may be provided: Item 1.1 - A method comprising: A method comprising: sending a transmission from at least one transmitting resource to at least one receiving resource, wherein the transmitting and / or receiving resource may be a node on a network. The transmitting and / or receiving resources may be MLDv1 or MLDv2 hosts, network switches, or routers on the network. Transmissions may be sent by the transmitting resources according to a multicast forwarding table. Features described with respect to item set 8 may be incorporated into item set 1 or any other item set.

[0214] According to an alternative (but not exclusive) expression, a computer-implemented method may be provided, which The method includes transmitting a portion of the blockchain-related data from a transmitting resource over 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, and each group in the plurality of receiving resources is associated with a respective multicast address. In some embodiments, the blockchain-related data may be transmitted to one, some, or all of the groups. When transmitting to multiple groups, the data is transmitted to each of the respective multicast addresses for the groups to which the data is to be transmitted.

[0215] The network may be a peer-to-peer (P2P) network and / or a distributed network. It may be a blockchain network, where nodes on the blockchain network are operable to perform operations according to the blockchain's protocol. In other embodiments, the network may be the Internet or a LAN or a VLAN or a telecommunications network, or a packet-switched network 101.

[0216] The transmitting resource and / or at least one receiving resource may be arranged and configured to perform operations according to a protocol of a given blockchain. Additionally or alternatively, the transmitting 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 exemplary embodiments, the at least one receiving node may not be a node on the blockchain network, in other words, external to the blockchain network, and / or may not be arranged and configured to implement a blockchain protocol or perform consensus / protocol-related functions. Additionally or alternatively, in some exemplary embodiments, the transmitting resource is not a node on the blockchain network. Additionally or alternatively, the transmitting resource and / or at least one receiving resource may be a resource arranged and / or operable to process blockchain-related data, where the blockchain-related data is - 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, - a blockchain-related alert or signal, - a node on a blockchain network, and / or - Users of the blockchain network, such as exchanges, wallets, and providers of blockchain-related services Blockchain-related alerts or signals related to or available for use with some or all of the and data relating to one or more of:

[0217] The transmission is (at least) - one or more blockchain transactions, wherein the data may include at least one entire transaction and / or at least one portion of a transaction; - Blockchain transaction blocks, - at least one Merkle path and / or Merkle proof, where the Merkle path / proof data may include at least a portion of a Merkle tree associated with a block of transactions, which may be suitable for validation, e.g., SPV-style validation, or for confirming that a given node or root is within a given path or tree, or for any one or more other purposes; - Proof-of-work and / or proof-stake operations, or any other consensus-related operations performed by nodes on a blockchain network; - one or more blockchain mining operations, such as those performed by nodes on a blockchain network; - Blockchain-related alerts or signals, - a node on a blockchain network, and / or - Users of the blockchain network, e.g., exchanges, wallets, and providers of blockchain-related services, one or more nodes in an overlay network that is an overlay with respect to the blockchain network Blockchain-related alerts or signals relating to or available for use with some or all of the It may include data relating to.

[0218] At least one transmitting resource may send a transmission to at least one receiving resource in response to a request. The request may be sent by the at least one receiving resource or by an additional resource. The request may be received by the at least one transmitting resource from the at least one received request or an additional resource. The request may include a request for data. The request may include blockchain-related data, such as data related to one or more blockchain transactions or transaction IDs (TxIDs), one or more blockchain blocks or block headers, and / or at least a portion of a Merkle path or proof.

[0219] Data may be transmitted over an electronic network as / in the form of one or more packets of data ("data packets"). Preferably, these are IPv6 packets.

[0220] Item 1.2 The transmission is carried out over a public network such as the Internet, preferably The method according to item 1.1, wherein the transmission is an IPv6 transmission, an IPv4 transmission, an anycast transmission, or a multicast transmission. Section 1.3 The transmitting resource and / or at least one receiving resource: is a member of an anycast group, and / or The method of item 1.1 or 1.2, which is a member of a multicast group.

[0221] Item Set 2: Additionally or alternatively, one or more embodiments of the present disclosure may be defined according to the following items: Any of the items defined in item set 2 may be combined with one or more of the items of any other item set presented herein, or with any other feature disclosed herein.

[0222] Section 2.1. A method comprising: sending, by a receiving resource, a request for blockchain-related data to a sending address associated with a member of one of a plurality of groups of sending resources on the network; 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 a 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 an electronic communication method. Item 2.2. The method of item 2.1, wherein receiving the blockchain-related data includes receiving the blockchain-related data via unicast or multicast transmission from at least one transmitting resource. Item 2.3. The method of items 2.2 or 2.1, wherein receiving the blockchain-related data includes receiving the blockchain-related data via anycast transmission from at least one transmission resource. Item 2.4. The method of any one of items 2.1 to 2.3, wherein the received blockchain-related data includes one or more portions of blockchain-related data received from multiple members of the group. Item 2.5. The method of Item 2.4, wherein each portion of the blockchain-related data includes a hash of the respective portion. Item 2.6. The method of any one of items 2.1 to 2.5, including sending an anycast or multicast query transmission and receiving (from the nearest transmission resource) at least a portion of a blockchain block, blockchain transaction, and / or Merkle path in response to the anycast or multicast query transmission. Section 2.7. The method of any one of Sections 2.1 to 2.6, wherein the sending address is associated with a sending resource in possession of a complete copy of the blockchain block. Item 2.8. The method of item 2.7, including receiving an anycast or multicast query transmission from a (topologically) nearest receiving resource; and transmitting at least a portion of a blockchain block, blockchain transaction, and / or Merkle path to the (topologically) nearest receiving resource in response to the anycast or multicast query transmission. Item 2.9. A method (e.g., a computer-implemented data distribution method) that includes transmitting, by a sending resource, blockchain-related data to a receiving address associated with members of one group of a plurality of groups of receiving resources on a network, where the receiving address may be an anycast or multicast address. Item 2.10. The method of Item 2.9, wherein the blockchain-related data includes a hash of the data. Item 2.11 The method of items 2.9 or 2.10, including deallocating transmission resources from the transmission address. Section 2.12. The method of Section 2.12, wherein the deallocation is performed in response to a determination that a predetermined condition has been met, e.g., that the blockchain-related data has been transmitted to a predetermined number of receiving resources and / or that a certain amount of time has elapsed or a given date and time has arrived. Item 2.13. The method of item 2.12, wherein the de-allocation is performed in response to a determination that a preselected period of time has elapsed.

[0223] Item Set 3: Additionally or alternatively, one or more embodiments of the present disclosure may be defined according to the following items: Any of the items defined in item set 3 may be combined with one or more of the items of any other item set presented herein, or with any other feature disclosed herein.

[0224] Item 3.1. A computer-implemented data distribution method comprising: A computer-implemented data distribution method including transmitting a portion of blockchain-related data from a transmitting resource (or at least one transmitting resource) on a network to one or more groups of receiving resources on the network, each of the one or more groups being associated with a respective multicast address. The network may be the Internet. In a preferred embodiment, all receiving resources within each group share a common multicast address that is unique to that group, and each group of resources has a respective multicast address to which all members of the group subscribe to receive multicast transmissions sent to that group's shared multicast address.

[0225] At least one transmitting resource may transmit a portion of the data via transmission. The portion of the data may be transmitted to at least one group of receiving resources in response to or as part of a request. The request may include a request for data. The request may include blockchain-related data, such as data related to one or more blockchain transactions or transaction IDs (TxIDs), one or more blockchain blocks or block headers, and / or at least a portion of a Merkle path or proof. The data may be transmitted over the Internet.

[0226] Item 3.2. One, some, or all of the transmission and / or reception resources in at least one of the one or more groups are: a node in a network, which may be a blockchain network or the Internet or a telecommunications network, or a node of an overlay network, which is an overlay with respect to the (underlying) blockchain network; Computing resources associated with or controlled by a financial institution; Merchant Resources, Cryptocurrency exchanges, Computing resources arranged and configured to perform or facilitate SPV validation or use the results of SPV validation; Providers of blockchain-related services, and / or The method according to item 3.1, which is or includes a digital wallet. Item 3.3. Data are Any method described in Section 3.1 or Section 3.2, including communications or alerts related to blockchain-related events or activities. Item 3.4. The method described in Item 3.3, wherein the alert relates to a double spend or attempted double spend in the blockchain network. Section 3.5. Blockchain-related data 1) at least a portion of a blockchain transaction; ii) at least a portion of a blockchain block; iii) at least a portion of the blockchain transaction script; iv) at least a portion of a Merkle path, Merkle tree, or Merkle proof; v) Data for use with or associated with the consensus mechanism of the blockchain network; vi) the result of a proof-of-stake or proof-of-work operation; vi) the results of a validation operation, including validation of a blockchain block or SPV validation. Item 3.6. The method of any one of items 3.1 to 3.5, wherein the blockchain-related data is transmitted by a sending resource to one or more groups of receiving resources using multicast communication. Section 3.7. i) The multicast address is an IP multicast address, and / or ii) the multicast address is an IPv6 multicast address, and / or iii) The method according to any one of clauses 3.1 to 3.6, wherein the blockchain-related data is transmitted over the Internet to one or more groups of receiving resources. Item 3.8. One or more groups of receiving hosts each include one or more receiving resources, and / or The method of any one of clauses 3.1 to 3.7, wherein each receiving peer in a given group of receiving resources is operable to receive data sent to a multicast address of the particular group of receiving resources. Item 3.9. Subscribing by a resource to a group of receiving resources, preferably by transmitting a signal to a network (which may be the Internet); The method of any one of clauses 3.1 to 3.8, comprising a step of leaving, by the resource, the group of receiving resources, preferably by the resource ceasing to transmit signals to the network. Item 3.10. The transmitting resources and / or at least one receiving resource in at least one or more groups of receiving resources are the functionality specified by the blockchain protocol, Computational or other operations related to mining or consensus functions specified in the blockchain protocol; Simplified Payment Validation (SPV) operations, Computing or verifying a Merkle route, Merkle proof, or the root of a Merkle route; Validating blockchain transactions before or after they are written to the blockchain; performing one or more of a lookup of the blockchain to identify, locate, and / or confirm the existence of a given transaction or block within the blockchain; 10. The method of any one of clauses 3.1 to 3.9, wherein the method is arranged, configured, and / or operable to generate blockchain transactions, write transactions to the blockchain, and / or broadcast transactions to a blockchain network. Item 3.11. The method of any one of items 3.1 to 3.10, including polling each of the one or more groups for a target response by sending a portion of the blockchain-related data from a sending resource to one or more groups of receiving resources. Item 3.12. A computer-implemented method comprising: 1. A computer-implemented method comprising sending a multicast communication to a group of resources on a blockchain network. Item 3.13. i) Communications are transmitted from a transmitting resource to a group of resources; ii) the group of resources is a multicast group, and one or some of the resources in the group of resources are receiving resources of the multicast group; iii) the communication relates to a duplicate spend or attempted duplicate spend within the network; iv) the communication is an alert. Item 3.14. Computer equipment, a memory including one or more memory units; 10. A computing device comprising: a processing device including one or more processing units, wherein a memory stores code configured to run on the processing device, the code configured to perform the method of any one of clauses 3.1 to 3.13 when on the processing device. Item 3.15. A computer program embodied on computer-readable storage and configured to, when executed on one or more processors, perform the method of any one of items 3.1 to 3.13.

[0227] Item Set 4: Additionally or alternatively, one or more embodiments of the present disclosure may be defined according to the following items: Any of the items defined in item set 4 may be combined with one or more of the items of any other item set presented herein, or with any other feature disclosed herein.

[0228] Item 4.1. A method comprising: transmitting a multicast communication from a transmission resource to at least one group of resources, preferably i) the transmission resource and / or at least one resource in at least one group is a node on a blockchain network, and / or Digital wallets or digital wallet providers, and / or Cryptocurrency exchanges, and / or Resources associated with one or more blockchain mining nodes, and / or A method comprising the steps of being or including a service provider arranged to provide blockchain-related services to one or more users. Section 4.2. i) The communication is transmitted over a public network, preferably the Internet, and / or ii) at least one group of resources is a multicast group including member resources arranged or operable to receive communications sent to a (multicast) address associated with the multicast group; and / or iii) the communication relates to a duplicate spend or attempted duplicate spend within the network; and / or iv) The method described in Section 4.1, wherein the communication is an alert or other communication that includes blockchain-related data.

[0229] Item Set 5: Additionally or alternatively, one or more embodiments of the present disclosure may be defined according to the following items: Any of the items defined in item set 5 may be combined with one or more of the items of any other item set presented herein, or with any other feature disclosed herein.

[0230]

[0003] Embodiments disclosed herein may provide methods and techniques for improved electronic communication between resources over a network. These embodiments may be arranged to ensure or improve reliability of data exchange between parties or transfer from one party to another. In one possible form, such embodiments may include a method including one, some, or all of the following steps:

[0231] Transmitting at least one data packet from one or more transmission resources to one or more receiving resources over an electronic network. 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, and in some cases, one or more transmission resources may also be associated with a shared multicast and / or anycast address, and at least one data packet may be transmitted to the shared multicast address. At least one data packet may be received by at least one of the receiving resources. This method is - determining by the at least one reception resource and upon reception of the at least one data packet whether at least one further data packet should (or is needed) be received by the at least one reception resource; - transmitting a request for at least one further data packet from the at least one receiving resource to the at least one further resource, preferably - at least one further resource is a member of a multicast group, and / or - at least one further resource is a member of an anycast group, and / or - determining whether the request is to be transmitted using multicast transmission, anycast transmission, or unicast transmission; - receiving a request for at least one further data packet from the at least one receiving resource by the at least one further resource; - transmitting 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 transmitted to the at least one receiving resource using unicast transmission.

[0232] In an alternative form of expression, such an embodiment may be described as presented in the following paragraphs: Features from the preceding method may be included in any of the following paragraphs, and vice versa.

[0233] Item 5.1. A method comprising: transmitting a request from a (requesting) sending resource that is a member of a resource group to at least one further resource that is a member of the resource group, preferably i) the request includes a request for one or more packets of data; and / or ii) the request is sent as a result of incomplete reception of a data transmission sent to the transmission resource, preferably the incomplete data transmission having been sent to the transmission resource and / or at least one further resource via or by a multicast transmission sent to a resource group; and / or iii) the request is sent as an arbitrary anycast transmission to the (topologically) closest resource in the resource group in terms of transmission resources, and / or iv) the request is sent as an optional multicast transmission to the (topologically) closest resource in the resource group, and / or v) The method, wherein the request is transmitted as a result of incomplete reception (by the transmission resource) of a data transmission transmitted (by the data transmission resource) to the (requesting) transmission resource, and preferably the request includes a request for at least one portion (e.g., packet) of data that the (requesting) transmission resource failed to receive as a result of the incomplete reception of the data transmission. Item 5.2. The transmission resource and / or at least one further resource is a node on a blockchain network, and / or Digital wallets or digital wallet providers, and / or Cryptocurrency exchanges or components thereof; and / or Resources associated with or in communication with one or more blockchain mining nodes; and / or a service provider arranged and configured to provide blockchain-related services to one or more users; and / or The method of claim 5.1, which is or includes a resource that is configured to perform SPV verification, facilitate SPV verification, or use the results of SPV verification, and may include software operable to perform or facilitate a simplified payment verification (SPV) operation or process the results of an SPV operation. Section 5.3. i) The communication is transmitted over a public network, preferably the Internet, and / or ii) at least one group of resources is a multicast group including member resources arranged or operable to receive communications sent to a (multicast) address associated with the multicast group; and / or iii) the communication relates to a duplicate spend or attempted duplicate spend within the network; and / or iv) the communication is an alert or other communication that contains blockchain-related data; and / or v) the communication includes blockchain-related data and / or at least a portion of a Merkle path or Merkle tree; and / or vi) A method as described in Section 5.1 or 5.2, including data for performing or facilitating SPV-style verification. Item 5.4. The method of items 5.1, 5.2, or 5.3, including providing one or more portions of data from the further resource to the (requesting) sending resource.

[0234] Also, according to one or more embodiments, a method may be provided, comprising: providing at least one portion of data to the (requesting) transmission resource in response to a request from the (requesting) transmission resource, preferably the (requesting) transmission resource being a member of a resource group, and wherein the at least one portion of data is provided to the transmission resource by or from a further resource that is a member of the resource group; Preferably, i) the request includes a request for one or more packets of data; and / or ii) the request is sent to a further resource as a result of an incomplete reception of a data transmission sent to a transmission resource, preferably the incomplete data transmission having been sent to the (requesting) transmission resource and / or at least one further resource via or by a multicast transmission sent to a resource group; and / or iii) the request is sent as an arbitrary anycast transmission to the (topologically) closest resource in the resource group in terms of transmission resources, and / or iv) the request is sent as an optional multicast transmission to the (topologically) closest resource in the resource group, and / or v) The request is sent as a result of incomplete reception (by the transmission resource) of a data transmission sent (by the data transmission resource) to the (requesting) transmission resource, and preferably the request includes a request for at least one portion (e.g., packet) of data that the (requesting) transmission resource failed to receive as a result of the incomplete reception of the data transmission.

[0235] Item Set 6: Additionally or alternatively, one or more embodiments of the present disclosure may be defined according to the following items: Any of the items defined in item set 6 may be combined with one or more of the items in other item sets presented herein, or with any other feature disclosed herein.

[0236] Item 6.1. A method comprising: 1. forming or providing a group (set) of network nodes; 2. Associating a group of nodes with a multicast address, These nodes are now multicast group members, i.e., they listen for communications from the multicast address; In another form of expression, steps 1 and 2 can be expressed as one or more nodes joining a multicast group. 3. A step of advertising / advertising / communicating available services and / or resources, where the advertising / advertising / communication of the services is performed by one or more nodes / members of the group to one or more recipients on a network, which may or may not be a blockchain network, and where this communication may be or include an invitation to send data to group members via a multicast address; 4. Advertising / advertising / communicating by one or more nodes / members the group's shared multicast address to one or more receivers on the network, which in one or more embodiments may include inviting or requesting receivers to send (e.g., blockchain-related) data to group members at the group multicast address, e.g., inviting or requesting a blockchain mining node to send one or more new blocks, or transactions, Merkle trees, etc., or portions thereof, to the group's shared multicast address; In some embodiments, step 4 (i.e., sharing a multicast address) may be combined with step 3 (i.e., advertising the service to receivers on the network). 5. Advertising / advertising / communicating the unique anycast address to receivers in the network by one or more nodes / members of the group; 6. Mining new blocks or blockchain transactions by blockchain mining nodes; 7. Sending a new block from the mining node to the group's shared multicast address; Note: In other embodiments, the data requested by a group member and sent by a network receiver to the group member may not include or relate to blockchain data such as blocks or transactions; in some embodiments, the data may be any type of data, or may 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 verification, all or part of a Merkle tree / path, etc. 8. Routing data (e.g., a block or a portion of a block) to all members of a multicast group, which may be performed over the Internet using IPv6 transmission; 9. Intermittently sending requests from one or more nodes / members to the anycast address of the multicast group, preferably the requests including the unicast address of the sending node; 10. Associating nodes (members) with previously advertised anycast addresses, preferably performed upon receipt of new blocks or other types of data; 11. Sending a copy of data (e.g., a block or part of a block) by a node / member to a requesting node via unicast transmission, which may be performed when a node with an anycast address (multicast group member) receives a request for a copy of a new block; 12. De-assigning the node / group member from the anycast address, which in some examples is performed after a predetermined time has elapsed or after determining that predetermined criteria have been met; 13. Listening by the node / group member for new data transmissions to be sent to the group's multicast address.

[0237] One or more of the above steps may be omitted, may be performed in a different order than that shown above, or may be combined with one or more other steps.

[0238] Item Set 7: Additionally or alternatively, one or more embodiments of the present disclosure may be defined according to the following items: Any of the items defined in item set 7 may be combined with one or more of the items of any other item set presented herein, or with any other feature disclosed herein.

[0239] A method according to this embodiment may be substantially as described herein, particularly with respect to block header propagation. According to one possible form of expression, such an embodiment may include a computer-implemented method including transmitting data from a sending node to multiple receiving nodes. Preferably, each of the receiving nodes is associated with an IPv6 multicast address. The data may include at least a portion of a block header of (for) the blockchain block and a list of one or more blockchain transactions included in the blockchain block to which the header is associated.

[0240] The method may further include using the data, by at least one of the receiving nodes, to identify at least one additional blockchain transaction (i.e., at least one "missing" transaction) that the at least one receiving node needs to generate the blockchain block. In other words, the at least one receiving node can only generate a complete, full version or copy of a blockchain block if it has a) the blockchain header and b) the complete list of transactions included in that block. Thus, the at least one receiving node may perform a check to identify any additional transactions it needs that were not included in the list sent by the sending node. Identifying the at least one additional blockchain transaction may include searching for the at least one additional blockchain transaction within a stored set of blockchain transactions. The stored set of transactions may be maintained by the at least one receiving node. Additionally or alternatively, it may be accessible to or available for access by the at least one receiving node.

[0241] The method may include obtaining at least one further (missing) transaction from the stored set of blockchain transactions, and generating a blockchain block using the at least one further transaction and the list of blockchain transactions.

[0242] However, if the at least one additional transaction is not found in the set of stored transactions, the method may include sending a request for at least one additional blockchain transaction from the at least one receiving node to the sending node, or to an IPv6 multicast address, or to one or more of the one or more additional nodes. The method may include receiving a 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 including the at least one additional blockchain transaction. The transmission may be a unicast transmission.

[0243] Additionally or alternatively, embodiments may be described in the following sections: Any feature included in any of these sections may be incorporated into or combined with the preceding method step, and vice versa.

[0244] Item 7.1 A computer-implemented method comprising: transmitting, from a sending node to a multicast address, a block header and (at least a portion of) a list of one or more blockchain transactions and / or blockchain transaction identifiers (TxIDs); Preferably, the (IPv6) multicast address is subscribed to by multiple receiving (i.e. subscribing) nodes. In some embodiments, at least one of the sending node and / or the receiving node is a node on a blockchain network. Preferably, the multicast address is an IPv6 multicast address. Item 7.2: Using the received information by at least one receiving node, but preferably all of the receiving nodes, to identify any missing transactions that the at least one receiving node needs to generate a complete block with a block header; Preferably, a transaction is a missing transaction if it is in one or more lists of transactions but is not included in a set of transactions, e.g., a member pool, maintained by and / or accessible by at least one receiving node. Item 7.3: If the receiving node identifies any missing transactions, sending a request for the missing transactions or transaction identifiers from at least one receiving node to a sending node (preferably via unicast transmission) or a multicast group (preferably via multicast or anycast transmission); Preferably, the request includes respective transaction identifiers (TxIDs) for the requested missing transactions. Item 7.4: The method of items 7.1, 7.2, and / or 7.3, including receiving a request from a receiving node by the sending node. Item 7.5: Sending a transmission from the sending node to the receiving node, the transmission including the requested missing transaction and / or transaction identifier; Preferably, the transmission is a unicast transmission, and the unicast transmission is preferably sent only to the individual receiving node that sent the request.

[0245] The method may further include generating a blockchain block including a block header using the list of one or more transactions / TxIDs and at least one requested missing transaction and / or transaction identifier. This may be performed upon receipt of the transmission by a receiving node. The receiving node may then perform one or more blockchain-related operations, such as a verification or validation operation.

[0246] Item Set 8: Additionally or alternatively, one or more embodiments of the present disclosure may be defined according to the following items: Any of the items defined in item set 8 may be combined with one or more of the items of any other item set presented herein, or with any other feature disclosed herein.

[0247] 8.1 A method comprising: sending a transmission from a transmission resource having enabled Multicast Listener Device (MLD) snooping to a multicast address over an electronic network; i) the transmission contains blockchain-related data; and / or ii) The multicast address is a node in a network, which may be a blockchain network or the Internet or a telecommunications network; Computing resources associated with or controlled by a financial institution; merchant-controlled resources, Cryptocurrency exchanges or components thereof; Computing resources arranged and configured to perform or facilitate SPV validation or use the results of SPV validation; Providers of blockchain-related services, and / or Digital wallets or components thereof; and / or associated with at least one receiving resource that is a resource including software operable to perform or facilitate a simplified payment verification (SPV) operation or to process the results of an SPV operation; iii) the transmission is or includes data relating to an alert, preferably an alert associated with, relating to, or arranged to be made available by, one or more nodes on the blockchain network; and / or iv) The transmission is Blockchain-related data and / or at least a portion of a Merkle path or Merkle tree; and / or A method, including data for performing or facilitating an SPV-style verification or using the results of an SPV verification.

[0248] One or more receiving resources may be associated with a multicast address. In other words, at least one receiving resource may be subscribed (i.e., listening) to the multicast address. The receiving resource may be referred to as a multicast group. The multicast address may be an IPv6 address. The transmitting resource and / or the receiving resource may be a device or system on a network. This may be a physical network or a logical network. This may be a VLAN. The transmitting resource may be a multicast router.

[0249] Item 8.2. The method of item 8.1, wherein the transmitting resource is operable to transmit the transmission to a list of one or more device ports on the electronic network that have indicated or signaled an interest or intent to receive the transmission. This list may be an IPv6 multicast forwarding table or database. Section 8.3 i. The transmitting resource is configured and / or operable to monitor MLD messages between the receiving resource and / or the multicast router; and / or ii. The method of item 8.1 or 8.2, wherein the sending resource may examine or utilize (monitored) MLD messages to generate a list of IPv6 addresses and respective network interfaces connected to the receiving resource. Item 8.4 Sending resources are: i) Send transmissions only to network interfaces connected to each receiving resource associated with (subscribed to / listening for network traffic addressed to) the multicast address, and / or ii) The method according to any one of items 8.1 to 8.3 of item set 8, wherein the method is operable to not send a transmission if there are no receiving resources associated with the multicast address. Item 8.5: One or more of the receiving resources are operable to transmit a membership report including a list of source addresses. The membership report may be transmitted in INCLUDE mode or EXCLUDE mode. The method of any one of items 8.1 to 8.4 of item set 8.

[0250] The transmitting and / or receiving resources may be operable to implement MLD snooping substantially as technically described at https: / / www.juniper.net / documentation / us / en / software / junos / multicast / topics / concept / mld-snooping-overview-l2.html.

[0251] Item Set 9: Additionally or alternatively, one or more embodiments of the present disclosure may be defined according to the following items: Any of the items defined in any one of item sets 1 to 8 may be combined with one or more of the items in any other item set presented herein, or with any other feature disclosed herein.

[0252] Item 9.1. A computer-implemented method, the computer-implemented method including: operating a sending and / or receiving resource to generate, store, process, access, and / or maintain packets of data, the packets of data preferably including blockchain-related data; determining an assigned address from the packets of data; and sending, at least in part, a transmission of the packets of data from the sending resource over an electronic network to the assigned address. Item 9.2. The method of Item 9.1, wherein the assigned address is a multicast address associated with a group of receiving resources. Section 9.3. The record 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 an identifier associated with an output in the blockchain transaction (Tx). For example, it may be a UTXO identifier. The hash of the script may be a hash of a script (e.g., a UTXO script) associated with the output of the transaction (Tx). The method of any one of Sections 9.1 and 9.2. Item 9.4. The method of any one of items 9.1 to 9.3, wherein determining the assigned address includes processing the packet of data to determine a key and selecting at least one address from the set of addresses using the key, the processing preferably including parsing the packet of data. Section 9.5. The method of any one of sections 9.1 to 9.4, wherein the sending resource maintains, provides, or includes a data structure including a set of assigned addresses associated with a corresponding set of keys. Section 9.6. The method of any one of Sections 9.1 through 9.5, wherein the sending resource generates, stores, processes, accesses, and / or maintains (blockchain) blocks (of zero or more blockchain transactions) that include multiple packets of data, each of the packets of data in the block including blockchain-related data.

[0253] The method may include determining an assigned address from each packet of data in the block, and sending, at least in part, a transmission of each packet of data in the block from a transmission resource over an electronic network to the respective assigned address. Item 9.7. The method of item 9.6, wherein the block is divided into sub-blocks, and transmission resources transmit each sub-block to a corresponding assigned address over the electronic network. Item 9.8. The method of Item 9.6 or 9.7, wherein the packets of data are divided into eight sub-blocks, and each sub-block is sent to a corresponding assigned address. Item 9.9. The transmitting resource additionally or alternatively operates as a receiving resource, and the method further includes at least one of receiving a packet of data and / or a plurality of packets of data, and propagating the packet of data to the assigned address. Preferably, the method of any one of items 9.1 to 9.8, wherein propagating the block includes transmitting a plurality of packets of data to respective assigned addresses, merging the blocks, and / or transmitting a plurality of packets of data for propagation to corresponding assigned addresses. Additionally or alternatively, the method may include collecting a packet of data, multiple packets of data or blocks, then parsing each packet of data to determine a key, and using the key to propagate each packet of data to at least one address from a set of addresses. Item 9.10. The method of any one of items 9.1 to 9.9, wherein a transmitting or receiving resource subscribes to at least one receiving resource and / or at least one multicast group. Item 9.11. The method of item 9.10, wherein a transmitting or receiving resource subscribes to a multicast address configured to receive at least one packet of data assigned to the multicast address, preferably wherein the assignment is determined from at least one packet of data. Item 9.12. The method of Items 9.10 or 9.11, further including a sending resource subscribing to and / or leaving a group of receiving resources by sending a signal to a network, such as the Internet and / or a blockchain network, preferably where the resource leaves the group by ceasing to send signals to the network. The embodiment of Item 9 can be combined with Item 9.2. Section 9.13. The method of any one of Sections 9.1 through 9.12, wherein the packet of data includes a communication, notification, message, or alert regarding a blockchain-related event or activity. Section 9.14. Alerting the method described in any one of Sections 9.1 through 9.13 regarding a double spend or attempted double spend in the blockchain network. Item 9.15. Sending and / or receiving resources are the functionality specified by the blockchain protocol, Computational or other operations related to mining or consensus functions specified in the blockchain protocol; Simplified Payment Validation (SPV) operations, Computing or verifying a Merkle route, Merkle proof, or the root of a Merkle route; Validating blockchain transactions before or after they are written to the blockchain; a search of the blockchain to identify, locate, and / or confirm the existence of a given transaction or block within the blockchain; 9.15. The method of any one of clauses 9.1 to 9.14, wherein the method is arranged, configured, and / or operable to generate a blockchain transaction, write the transaction to the blockchain, and / or broadcast the transaction to a blockchain network. Item 9.16. Packets of data are At least a portion of the blockchain transaction, At least a portion of the blockchain blocks, At least a portion of the blockchain transaction script; a Merkle tree of blocks in which said packets of data are recorded; the Merkle root of the block in which said packet of data is recorded; a Merkle path that enables determining, from a hash of said packet of data, a value for a Merkle root for a block in which said packet of data is recorded; Merkle proof, Data for use with or associated with the consensus mechanism of a blockchain network; the results of or data relating to any proof-of-stake or proof-of-work operation; The block identifier (block_ID) associated with the blockchain block, A transaction identifier (TxID) associated with a transaction (Tx) among multiple blockchain transactions in a blockchain block; Block identifier (block_ID) and transaction identifier (TxID) functions, A concatenation of a block identifier (block_ID) and a transaction identifier (TxID), digital signature, Authentication code, A signature message to determine the transaction state; protocol flags, a discretionary public key (DPK), and Optional Transaction ID (DTxID). Item 9.17. Sending and / or receiving resources are Nodes in a blockchain network, service providers arranged and configured to provide blockchain-related services; Computing resources associated with or controlled by a financial institution; Cryptocurrency exchanges or components thereof; Merchant Resources or any component thereof; Digital wallets or components thereof; a software component operable to perform or facilitate a simplified payment verification (SPV) operation or to process the results of an SPV operation; The method of any one of items 9.1 to 9.16, including an MLDv1 host or MLDv2 host, a network switch, or a router on the network. Item 9.18. Computer equipment, a memory including one or more memory units; 12. A computing device comprising: a processing device including one or more processing units, wherein a memory stores code configured to run on the processing device, the code configured to perform the method of any one of clauses 9.1 to 9.17 when on the processing device. Item 9.19. A computer program embodied on computer-readable storage and configured to, when executed on one or more processors, perform the method of any one of items 9.1 to 9.17.

[0254] Item Set 10: Additionally or alternatively, one or more embodiments of the present disclosure may be defined according to the following items: Any of the items defined in any one of item sets 1 to 9 may be combined with one or more of the items in any other item set presented herein, or with any other feature disclosed herein.

[0255] Item 10.1: A computer-implemented method including operating a transmission resource to generate, store, process, access, and / or maintain packets of data, the packets of data preferably including blockchain-related data, and transmitting, at least in part, transmissions of the packets of data from the transmission resource to a multicast group over an electronic network, the multicast group making the packets of data available for end users. The packets of data may be made available through controlled access. The controlled access may be managed (i) via controlled access of the multicast group, e.g., via a subscription, and / or (ii) via controlled access to the packets of data. The computer-implemented method may include configuring the controlled access by a sender source, e.g., by implementing controlled access to the multicast group and / or by protecting the packets of data prior to transmission. Item 10.2. The method of Item 10.1, further including operating a receiving resource to store, process, access, and / or maintain the packets of data. Item 10.3. The method of Item 10.2, wherein the receiving resource subscribes to the multicast group or another multicast group to receive the packet of data or another packet of data. Item 10.4. The method of any one of items 10.1 to 10.3, wherein the transmitting resource transmits multiple packets of data and / or the receiving resource receives multiple packets of data. Item 10.5. The method of any one of items 10.1 to 10.4, wherein the packets of data are at least in part a data stream, such as a multimedia communication channel. Item 10.6. The method of any one of items 10.1 to 10.5, wherein the packet of data has subcomponents for providing multiple data channels. Section 10.7. The method of any one of Sections 10.1 to 10.6, wherein access to the packets of data and / or multicast group is protected and accessible using an access key and / or a smart contract. Item 10.8. The method of Item 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. Item 10.9. The method of Item 10.7 or 10.8, wherein the transmitting resource generates an access key and transmits the necessary access key to at least one of a recipient of the packet of data and an end user to access the packet of data. Item 10.10. The method described in Item 10.9, where the access key is provided at the time of exchange using a payment channel and / or a smart contract. Item 10.11. The method of any one of Items 10.7 to 10.10, wherein the access key provides access to the multicast group and / or packets of data for at least one of: (i) a fixed period of time; (ii) a fixed amount of data; (iii) a fixed number of units; (iv) a fixed number of packets of data; and (v) unlimited access. Item 10.12. The method of any one of items 10.4 to 10.11, wherein the transmitting resource transmits multiple packets of data to respective assigned addresses, the assigned addresses being determined from each packet of data or the access key, and / or the receiving resource receives multiple packets of data from at least one multicast group and aggregates the packets of data. Item 10.13. The method of Item 10.12, wherein the assigned address is a multicast address associated with a group of receiving resources. Item 10.14. A computer-implemented method, the method including: operating a receiving resource to store, process, access, and / or maintain packets of data, the packets of data preferably including blockchain-related data; and receiving, at least in part, a transmission of the packets of data via a multicast group that received the packets of data from an electronic network; and consuming the packets of data as an end user. Item 10.15. The method according to item 10.14, wherein access to the packets of data and / or the multicast group is protected and accessible using an access key, preferably obtained via a payment channel. Item 10.16. 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 method of any one of items 10.1 to 10.15, wherein the script may be associated with an output provided in a blockchain transaction. Item 10.17. Packets of data are At least a portion of the blockchain transaction, At least a portion of the blockchain blocks, At least a portion of the blockchain transaction script; a Merkle tree of blocks in which said packets of data are recorded; the Merkle root of the block in which said packet of data is recorded; a Merkle path that enables determining, from a hash of said packet of data, a value for a Merkle root for a block in which said packet of data is recorded; Merkle proof, Data for use with or associated with the consensus mechanism of a blockchain network; the results of or data relating to any proof-of-stake or proof-of-work operation; The block identifier (block_ID) associated with the blockchain block, A transaction identifier (TxID) associated with a transaction (Tx) among multiple blockchain transactions in a blockchain block; Block identifier (block_ID) and transaction identifier (TxID) functions, A concatenation of a block identifier (block_ID) and a transaction identifier (TxID), digital signature, Authentication code, A signature message to determine the transaction state; protocol flags, a discretionary public key (DPK), and Optional Transaction ID (DTxID). Item 10.18. Sending and / or receiving resources are Nodes in a blockchain network, service providers arranged and configured to provide blockchain-related services; Computing resources associated with or controlled by a financial institution; Cryptocurrency exchanges or components thereof; Merchant Resources or any component thereof; Digital wallets or components thereof; a software component operable to perform or facilitate a simplified payment verification (SPV) operation or to process the results of an SPV operation; The method of any one of items 10.1 to 10.17, including an MLDv1 host or MLDv2 host, a network switch, or a router on the network. Item 10.19. A computing device comprising: a memory including one or more memory units; and a processing device including one or more processing units, the memory storing code configured to run on the processing device, the code configured, when on the processing device, to perform the method of any one of items 10.1 to 10.18. Item 10.20. A computer program embodied on computer-readable storage and configured to, when executed on one or more processors, perform the method of any one of items 10.1 to 10.18.

[0256] Item Set 11: Additionally or alternatively, one or more embodiments of the present disclosure may be defined according to the following items: Any of the items defined in item set 11 may be combined with one or more of the items of any other item set presented herein, or with any other feature disclosed herein. The method may be described as a network security solution and / or an (electronic) communication or data transfer solution.

[0257] 11.1 A computer-implemented method comprising: transmitting, by a sending resource, a blockchain or cryptocurrency-related communication to an IPv6 multicast address for reception 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. 11. A computer-implemented method comprising: 11.2. The method described in Section 11.1, wherein the communication is or includes a blockchain and / or cryptocurrency related alert, a blockchain or cryptocurrency related software update, a blockchain or cryptocurrency related notice, or other blockchain or cryptocurrency related communication. 11.3. The method described in Section 11.1 or 11.2, wherein the IPv6 multicast address is associated with communications regarding a particular blockchain network or cryptocurrency. 11.4. The method of any one of clauses 11.1 to 11.3, wherein at least one receiving resource includes one or more of a mining, validation, wallet and / or servicing resource arranged to operate on or in conjunction with a blockchain network. 11.5. taking, by the at least one receiving resource, at least one responsive action in response to the blockchain or cryptocurrency related communication, the at least one responsive action comprising: i) sending the communication to one or more recipients; ii) accessing, installing, and / or executing a portion of the data, optionally the portion of the data including one or more machine-executable instructions; iii) marking or identifying at least one transaction output, transaction or transaction block, or portion of cryptocurrency as invalid, unpayable, rejected, or to be ignored; 11. The method according to any one of items 11.1 to 11.4. 11.6. forwarding the communication by at least one of the receiving resources to at least one further receiving resource; Optionally, the at least one further receiving resource includes at least one further IPv6 multicast address. 11.7. i) Blockchain or cryptocurrency-related communications are signed, marked, or otherwise authenticated by the generating resource designated as the legitimate originator or provider of the communications; and / or ii) The method of any one of clauses 11.1 to 11.6, wherein the blockchain or cryptocurrency related communication is encoded or otherwise protected such that the content of the blockchain or cryptocurrency related communication can only be accessed, decrypted, read, executed or processed by using at least one unlocking mechanism such as a key, access code or secret. 11.8. The method of item 11.7, including providing at least one key, access code, or secret to at least one receiving resource or another resource authorized to access, decrypt, read, execute, or process the content of the blockchain or cryptocurrency-related communication. 11.9. Blockchain or cryptocurrency related communications may contain filter codes, flags, markers, or other identifiers, preferably The filter targets / identifies blockchain or cryptocurrency related communications to one or more receiving resources of the at least one receiving resource. the content or type of blockchain or cryptocurrency related communications transmitted; and / or The method of any one of clauses 11.1 to 11.8, arranged to act as a means for doing so based on an intended, selected or desired set of reception resources. 11.10. The method according to item 11.9, wherein the filters are provided in a blockchain or cryptocurrency-related communication in a pre-specified arrangement and / or in a pre-defined format. 11.11. How to The method of any one of items 11.9 and 11.10, including processing or ignoring the blockchain or cryptocurrency related communication by at least one receiving resource based on a filter. 11.12. A computing device comprising: a memory including one or more memory units; and a processing device including one or more processing units, the memory storing code configured to be executed on the processing device, the code configured, when on the processing device, to perform the method of any one of items 11.1 to 11.11. 11.13. A computer program embodied on a computer-readable storage and configured to, when executed on one or more processors, perform the method of any one of clauses 11.1 to 11.11.

[0258] Item Set 12 Additionally or alternatively, one or more embodiments of the present disclosure may be defined according to the following items: Any of the items defined in item set 12 may be combined with one or more of the items of any other item set presented herein, or with any other feature disclosed herein.

[0259] However, in one or more embodiments, one or some or all of the sending and / or receiving nodes in the group may be full nodes on the blockchain network or nodes on an overlay network, and the data may include (data related to) unconfirmed transactions that have been validated but not yet written to the blockchain ledger. In such embodiments, systems and methods may be provided for implementing a member pool (also referred to 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 / Mining, "a member pool is a temporary transaction store that may be used to hold transactions grouped in different ways, such as transactions to be mined in the next block, transactions to be monitored, or transactions that cannot be mined due to nLocktime / nSequence locks." Without being limited thereto, the term member pool as used herein may include this definition.

[0260] In other embodiments, systems and methods for implementing UTXO sets may be provided.

[0261] Thus, the following may be provided: Item 12.1. A method for implementing a memory pool or UTXO set in a blockchain network, comprising: transmitting a transmission from a transmitting resource to at least one receiving resource or receiving a transmission from a transmitting resource by at least one receiving resource; the transmitting resource and / or at least the receiving resource are nodes on the network; The method, wherein the transmission is sent using IPv6 multicast and includes at least a portion of a blockchain transaction. In some embodiments, at least a portion of a blockchain transaction may include an entire blockchain transaction. The transaction may have been validated (verified) by a validating entity operable to verify the transaction according to the blockchain protocol. The transaction may be unconfirmed, awaiting successful mining into a block on a blockchain ledger associated with the blockchain protocol.

[0262] In some embodiments, at least a portion of a blockchain transaction may include a UTXO.

[0263] Section 12.2 i) The sending resource and / or at least one receiving resource is a full node or lightweight node on the blockchain network, or ii) The method described in Item 12.1, wherein the sending resource and / or at least one receiving resource is a node on a blockchain overlay network.

[0264] Exemplary System Overview For illustrative purposes only, and with reference to Figures 1-4, we now present an example of a computing environment in which one or more embodiments of the present disclosure may be implemented. Reference numbers referenced below refer to Figures 1-4.

[0265] 1 illustrates an exemplary 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 includes 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. Although not illustrated, the blockchain nodes 104 may be arranged as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0266] Each blockchain node 104 includes a peer computer device, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 includes a processing unit including 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 devices such as application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may include one or more memory units employing one or more memory media, e.g., magnetic media such as a hard disk, electronic media such as a solid-state drive (SSD), flash memory, or EEPROM, and / or optical media such as an optical disk drive.

[0267] A blockchain 150 includes a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 within a distributed or blockchain network 106. As noted above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned so long as each blockchain node 150 stores the block header (described below) of each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 includes at least one input and at least one output. Each output specifies 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 that user's signature or other solution to unlock it and thereby be redeemed or spent). Each input points back to the output of a preceding transaction 152, thereby linking the transactions.

[0268] Each block 151 also contains a block pointer 155 that points back to a previously created block 151 in the chain, defining an order for the blocks 151. Each transaction 152 (other than a coinbase transaction) contains a pointer that points back to a previous transaction, defining an order for the sequence of transactions (note: the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 stretches 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 in the chain 150 pointed to the genesis block 153 rather than to a preceding transaction.

[0269] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in its memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "member pool." This term herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid, for which the node 104 is obligated not to accept any other transactions attempting to consume the same output.

[0270] For a given current transaction 152j, its (or each) input includes a pointer that references the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "consumed" in the current transaction 152j. In general, a preceding transaction can be any transaction in the ordered set 154 or any block 151. A preceding transaction 152i does not necessarily have to exist at the time the current transaction 152j is created or even transmitted to the network 106, but the preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" herein refers to a preceding element in a logical sequence linked by a pointer, not necessarily at the time of creation or transmission in the temporal sequence, and thus does not necessarily exclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). A preceding transaction 152i can equally be referred to as a previous transaction or a preceding transaction.

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

[0272] According to output-based transaction protocols such as Bitcoin, when a party 103, such as an individual user or an organization, wishes to establish a new transaction 152j (either manually or through an automated process employed by the party), the establishing party transmits the new transaction from its computer terminal 102 to a recipient. The establishing party or recipient ultimately transmits this transaction to one or more blockchain nodes 104 of the network 106 (currently typically a server or data center, but in principle could be other user terminals). It is also not excluded that the party 103 establishing a new transaction 152j transmits this transaction directly to one or more blockchain nodes 104 and, in some instances, does not transmit it to a recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied at each of the blockchain nodes 104. The blockchain node protocol typically requires the blockchain nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may involve checking that the cryptographic signature or other authorization of a party 103 included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 152i that the new transaction assigns, which condition typically involves at least checking whether the cryptographic signature or other authorization 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. This condition may be defined at least in part by a script included in the output of the previous transaction 152i. Alternatively, it may be fixed simply by the blockchain node protocol, or result from a combination thereof.In any case, 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, following the same blockchain node protocol and applying the same tests, forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0273] In the output-based model, the definition of whether a given output (e.g., UTXO) has been allocated (e.g., spent) is whether it has yet been validly redeemed by the input of another, forward 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 it attempts to redeem has not yet been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not propagated (unless it is flagged as invalid and propagated due to a warning) or recorded in the blockchain 150. This protects against double-spending, where a transactor attempts to allocate the same transaction output multiple times. On the other hand, the account-based model prevents double-spending by maintaining an account balance. Again, because there is a defined order of transactions, the account balance has a single defined state at any given time.

[0274] In addition to validating transactions, blockchain nodes 104 compete to be the first to create a block of transactions in a process commonly referred to as mining, supported by "proof of work." Blockchain nodes 104 add new transactions to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. Blockchain nodes then compete 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 involves searching for a "nonce" such that when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition could be that the hash output has a certain predefined number of leading zeros. This is just one particular type of proof-of-work puzzle; others are not excluded. A property of a hash function is that it has an unpredictable output given an input. Therefore, this search can only be performed by brute force, thus consuming a substantial amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0275] The first blockchain node 104 to solve the puzzle publishes it to the network 106, providing the solution as a proof that can be easily checked by other blockchain nodes 104 in the network (given the hash solution, it is easy to check that it matches the hash output). The first blockchain node 104 propagates the block to a threshold consensus of other nodes, who accept the block, thus enforcing 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 to the previously created block 151n-1 in the chain. The significant amount of effort required to create the proof-of-work solution, e.g., in the form of a hash, signals the first node 104's willingness to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction, otherwise known as a double-spend. Once created, blocks 151 cannot be modified because they are known and maintained by each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose an order on the blocks 151. Transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, thus providing an immutable public ledger of transactions.

[0276] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may do so based on different snapshots of the pool of transactions 154 that have not yet been published at any given time, depending on when they began searching for a solution or the order in which transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool 154 of unpublished transactions is updated. Blockchain nodes 104 then compete to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. There is also a protocol for resolving any "forks" that may occur, which is when two blockchain nodes 104 solve the puzzle within such a short time of each other that opposing views of the blockchain are propagated between the nodes 104. In essence, whichever branch of the fork grows the longest becomes the definitive blockchain 150. Note that this should not affect users or agents of the network when the same transaction appears in both forks.

[0277] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate the additional accepted amount of digital assets in a new special type of transaction that distributes an additional defined amount of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers a certain amount of digital assets from one agent or user to another). This special type of transaction is commonly referred to as a “coinbase transaction,” but may also be called an “initiation transaction” or “generation transaction.” It typically forms the first transaction of a new block 151n. The proof of work signals the node constructing the new block’s intention to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a redemption period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a regular (non-generation) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is commonly referred to as a "transaction fee" and is explained below.

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

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

[0280] Also connected to the network 101 are computing devices 102 for each of a number of participants 103 who act as 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 receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some participants may act as storage entities that store copies of the blockchain 150 (e.g., obtaining copies of the blockchain from blockchain nodes 104).

[0281] Some or all of the participants 103 may be connected as part of a different network, for example, a network overlaid on 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, but these users are not blockchain nodes 104 because they do not perform the necessary roles of blockchain nodes. Instead, each participant 103 interacts with the blockchain network 106 by connecting to (i.e., communicating with) a blockchain node 106, thereby utilizing the blockchain 150. Two participants 103 and their respective devices 102 are shown for illustrative purposes: a first participant 103a and its respective computing device 102a, and a second participant 103b and its respective computing device 102b. It will be understood that many more such participants 103 and their respective computing devices 102 may exist and participate in the system 100, but are not illustrated for convenience. Each participant 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, although it will be understood that this is not limiting and that references herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0282] The computing device 102 of each participant 103 comprises a respective processing device including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing device 102 of each participant 103 further includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. This memory may include one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computing device 102 of each participant 103 stores software including a respective instance of at least one client application 105 configured to execute on the processing device. It will be understood that any activity attributed to a given participant 103 herein may be performed using software executing on the processing device of the respective computing device 102. The computing device 102 of each participant 103 includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing equipment 102 of a given participant 103 may also include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

[0283] The client application 105 may be initially provided to the computing equipment 102 of any given participant 103 on a suitable computer-readable storage medium, for example downloaded from a server, or may be 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, an optical disk such as a CD or DVD ROM, or a removable optical drive, etc.

[0284] The client application 105 has at least a "wallet" function. It has two main functionalities. One of these is to allow each party 103 to create, authorize (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104, which then propagate throughout the network of blockchain nodes 104 and thereby be included in the blockchain 150. The other is to report back to each party the amount of digital assets they currently own. In an output-based system, this second function involves reconciling the amounts belonging to the party of interest as determined in the outputs of various transactions 152 scattered throughout the blockchain 150.

[0285] NOTE: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting; instead, any client function described herein may instead be implemented as a set of two or more different applications, for example, interfaced via an API or plugging one into the other. More generally, client functions may also be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following description will be given with respect to client application 105, it will be understood that this is not limiting.

[0286] An instance of a client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or indeed to inspect the transactions of other parties in the blockchain 150, since in embodiments the blockchain 150 is a public facility that provides trust in transactions, in part through its public visibility). The wallet functionality on each computing device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As noted above, each blockchain node 104 executes software configured to validate transactions 152 according to a blockchain node protocol and forward the transactions 152 for propagation throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other; a given transaction protocol goes with a given node protocol and together implement 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 nodes 104 in the network 106.

[0287] When a given party 103, such as Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, Alice formulates the new transaction (using the wallet functionality of Alice's client application 105) according to the associated transaction protocol. Alice then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this could be the blockchain nodes 104 most connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j meets certain conditions for being "valid," examples of which will be described in more detail shortly. In some transaction protocols, the conditions for validation may be configurable on a per-transaction basis by a script included in the transaction 152. Alternatively, this 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.

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

[0289] After being admitted into the ordered pool of pending transactions 154 maintained by a given blockchain node 104, that blockchain node 104 begins a race to solve a proof-of-work puzzle with the latest version of each pool 154 that contains the new transaction 152. (Remember, other blockchain nodes 104 may be trying to solve the puzzle based on different pools of transactions 154, but whoever gets there first defines the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 will have solved the puzzle for the part of the ordered pool 154 that contains Alice's transaction 152j.) After proof-of-work has been done for the pool 154 containing the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Each transaction 152 contains a pointer back to previous transactions; therefore, the order of transactions is also immutably recorded.

[0290] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views about which instance is "valid," with one instance being published in a new block 151, before 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, it must accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the one not published in block 151).

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

[0292] UTXO-based model Figure 2 illustrates an example transaction protocol. This is an example of a UTXO-based protocol. Transactions 152 (abbreviated as "Tx") are the fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. Note that the exemplary UTXO-based protocol is described with reference to Bitcoin, but could equally be implemented on other exemplary blockchain networks.

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

[0294] For example, Alice 103a wants to create transaction 152j to transfer an amount of digital assets of interest to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes the amount of digital assets locked for Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 could also point back to any previous (i.e., previous) transaction that still has unspent outputs 203 locked for Alice.

[0295] The preceding transaction Tx0 may already be validated and included in a block 151 of the blockchain 150 by the time Alice creates, or at least submits, the new transaction Tx1 to the network 106. It may already be included in one of the blocks 151 at that time or may still be waiting in the ordered set 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 could be created and submitted to the network 106 together, or Tx0 could even be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “preceding” and “subsequent,” as used herein in the context of a sequence of transactions, refer to the order of the transactions in the sequence as defined by the transaction pointers specified in the transactions (e.g., which transactions point back to which other transactions). These could equally be interchanged with “predecessor” and “successor,” or “predecessor” and “descendant,” “parent” and “child,” or the like. This does not necessarily imply the order in which they are created, transmitted to the network 106, or arrive at any given blockchain node 104. Nevertheless, subsequent transactions (descendant transactions or "children") that point to a preceding transaction (previous transaction or "parent") are not 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 period of time to await its parent, depending on the node protocol and / or node behavior.

[0296] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, here labeled UTXO0. Each UTXO includes a value specifying the amount of the digital asset represented by the UTXO and a locking script that defines the conditions that must be met by the unlocking script of the input 202 of the subsequent transaction for the subsequent transaction to be validated and therefore 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). That is, the locking script typically defines unlocking conditions, including a condition that the unlocking script in the input of the subsequent transaction include the cryptographic signature of the party to whom the preceding transaction is locked.

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

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

[0299] When new transaction Tx1 arrives at blockchain node 104, the node applies its node protocol, which involves running the lock script and unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (where the conditions may include one or more criteria). In an embodiment, this involves concatenating the two scripts as follows: <Sig P A > <P A > || [Checksig P A ] where "||" denotes concatenation, "<...>" means putting data on the stack, and "[...]" is a function composed by the lock script (a stack-based language in this example). Equivalently, the scripts could be executed one after the other, with a common stack, rather than concatenating the scripts. Either way, when executed together, the scripts will create a lock script containing Alice's public key P as contained in the lock script in the output of Tx0. Athat the unlock script in Tx1's input contains Alice's signature, which signs the expected portion of the data. To perform this authentication, the expected portion of the data itself (the "message") must also be included. In an embodiment, the signed data includes Tx1 in its entirety (and thus there is no need to include a separate element specifying the signed portion of the data in plaintext, as it is already inherently present).

[0300] The details of authentication via public-private cryptography will be familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then, given Alice's public key and the plaintext message, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature with the message, so that anyone holding the public key can authenticate the signature. Thus, it should be noted that references herein to signing a particular data portion, transaction portion, etc., can, in embodiments, mean signing a hash of that data portion or transaction portion.

[0301] If the unlock script of Tx1 satisfies one or more conditions specified in the lock script of Tx0 (thus, in the illustrated example, if Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of pending transactions 154. The blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106, thereby propagating throughout the network 106. After Tx1 is validated and entered into the blockchain 150, it defines Tx0 to UTXO0 as spent. Note that Tx1 can only be valid if it consumes an unspent transaction output 203. If it attempts to consume an output that has already been consumed by another transaction 152, Tx1 becomes invalid even if all other conditions are met. Therefore, a blockchain node 104 also needs to check whether the UTXO referenced in the preceding transaction Tx0 has already been spent (i.e., whether it already forms 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 transactions 152. Indeed, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 have been spent in which transactions 152, but what ultimately defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in the blockchain 150.

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

[0303] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. A small portion of the amount defined in the UTXO cannot be "left" as spent while another small portion is spent. However, the amount from a UTXO can be split among multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use the remainder to give herself change in the second output of Tx1 or to pay other parties.

[0304] In practice, Alice is typically required to include a fee for any Bitcoin node 104 that successfully includes her transaction 104 in block 151. If Alice does not include such a fee, Tx0 will be rejected by the blockchain node 104 and, thus, while technically valid, will not be propagated and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept the transaction 152 if they do not wish to do so). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, any difference between the total amount pointed to by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, a pointer to UTXO0 is the only input to Tx1, which has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by the node 104 that won the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively, or in addition, be explicitly specified in one of transaction 152's UTXOs 203 itself.

[0305] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party 103's assets are scattered throughout the UTXOs of various transactions 152 throughout the blockchain 150. There is no single number stored anywhere in the blockchain 150 that defines a given party's 103 total balance. It is the responsibility of the wallet function within the client application 105 to collate together the values ​​of all the various UTXOs locked to each party that have not yet been spent in another forward transaction. This can be done by querying a copy of the blockchain 150, such as that stored in one of the Bitcoin nodes 104.

[0306] Note that script code is often expressed generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to express a particular function. "OP_..." refers to a particular opcode in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of a lock script, creates a non-consumable output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include a document that is desired to be stored in the blockchain.

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

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

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

[0310] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively, or in addition, the side channel 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or even over a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, a side channel 107 referenced anywhere herein may include any one or more links over one or more network technologies or communication media for exchanging data “off-chain,” i.e., separate from the blockchain network 106. When multiple links are used, the bundle or collection of off-chain links may be referred to as a side channel 107 as a whole. Thus, it should be noted that when Alice and Bob are said to exchange some information or data or the like over a side channel 107, this does not necessarily imply that all pieces of this data must be transmitted over the exact same link or the same type of network.

[0311] Client Software 3A illustrates an exemplary implementation of a client application 105 for implementing embodiments of the presently disclosed scheme. The client application 105 includes a transaction engine 401 and a user interface (UI) 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 via side channels 301, and / or send transactions to one or more nodes 104 for propagation through the blockchain network 106, according to the scheme set forth above and / or as will be described in more detail shortly.

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

[0313] Note: Although various functions described herein may be described as being integrated into the same client application 105, this is not necessarily limiting; instead, they may be implemented in a set of two or more different applications, for example, one plugging into the other or interfacing via an API (application programming interface). For example, the functionality of the transaction engine 401 may be implemented in a separate application from the UI layer 402, or the functionality of a given module, such as the transaction engine 401, may be split among multiple applications. It is also not excluded that some or all of the described functionality may be implemented, for example, in the operating system layer. Where reference is made anywhere in this specification to a single or given application 105, or the like, it will be understood that this is merely an example, and more generally, the described functionality may be implemented in any form of software.

[0314] 3B shows a mockup of an example user interface (UI) 500 that may be rendered by the UI layer 402 of the client application 105a on Alice's device 102a. It will be understood that a similar UI may be rendered by client 105b on Bob's device 102b, or on the device of another party.

[0315] 3B shows a UI 500 from Alice's perspective. The UI 500 may include one or more UI elements 501, 502, 502 that are rendered as different UI elements via user output means.

[0316] For example, the UI elements may include one or more user-selectable elements 501, which may be different on-screen buttons, or different options in a menu, or the like. User input means are arranged and configured to allow user 103 (in this case, Alice 103a) to select or otherwise manipulate one of those options, such as by clicking or touching the UI element on the screen or speaking the name of the desired option (Note: as used herein, the term "manual" is meant only in contrast to automatic and is not necessarily limited to the hand or use of the hand).

[0317] Alternatively or additionally, the UI elements may include one or more data entry fields 502. These data entry fields may be rendered via a user output means, e.g., on-screen, and data may be entered into the fields via a user input means, e.g., a keyboard or touch screen. Alternatively, data may be received verbally, e.g., based on voice recognition.

[0318] Alternatively or additionally, the UI elements may include one or more information elements 503 that are output to output information to the user, for example, this / these may be rendered on a screen or audibly.

[0319] It will be understood that the particular means of rendering the various UI elements, selecting options, and entering data is not important. The functionality of these UI elements will be described in more detail shortly. It will also be understood that the UI 500 shown in FIG. 3 is merely a schematic mockup and may, in fact, include one or more additional UI elements that are not illustrated for the sake of brevity.

[0320] Node Software FIG. 4 illustrates an example of node software 450 running on each blockchain node 104 of the network 106, using an example UTXO- or output-based model. Note that another entity may run the node software 450 without being classified as a node 104 on the network 106, i.e., without performing the required actions of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a scripting engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related function modules 455. Each node 104 may run node software including, but not limited to, all three of a consensus module 455C (e.g., proof-of-work), a propagation module 455P, and a storage module 455S (e.g., database). The protocol engine 451 is typically configured to recognize different fields of a transaction 152 and process them according to the node protocol. Another preceding transaction 152i (Tx m-1 ) output (e.g., UTXO) j ) is received, the protocol engine 451 j The protocol engine 451 identifies the unlock script in the Tx j Based on the pointer in the input of Tx i Identify and extract Tx i may be published on the blockchain 150, in which case the protocol engine derives Tx from a copy of block 151 of the blockchain 150 stored on the node 104. i Alternatively, Tx i may not yet have been published on the blockchain 150. In that case, the protocol engine 451 may select Tx from the ordered set of unpublished transactions 154 maintained by the node 104. i In any case, the script engine 451 may extract Txi and passes it to the script engine 452.

[0321] Therefore, the script engine 452 executes the Tx i Lock script and Tx j , and the corresponding inputs of the transaction. For example, transactions labeled Tx0 and Tx1 are illustrated in FIG. 2, but the same could apply to any pair of transactions. Script engine 452 executes the two scripts together as previously described, which includes placing data on and popping data from stack 453 according to the stack-based scripting language being used (e.g., Script).

[0322] By executing the scripts together, script engine 452 determines whether the unlock script satisfies one or more criteria defined in the lock script, i.e., whether to "unlock" the output that the lock script is included in. Script engine 452 returns the result of this determination to protocol engine 451. If script engine 452 determines that the unlock script satisfies one or more criteria specified in the corresponding lock script, it returns the result "true." Otherwise, it returns the result "false."

[0323] In the output-based model, a "true" result from the script engine 452 is one of the conditions for the validity of the transaction. Typically, there are also one or more further protocol-level conditions evaluated by the protocol engine 451 that must also be satisfied, thereby validating the Tx j The total amount of digital assets specified in the output of Tx does not exceed the total amount indicated by its input. iThe pointed-to output of has not already been consumed by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 together with one or more protocol-level conditions and executes transaction Tx only if they are all true. j The protocol engine 451 outputs an indication of whether the transaction is valid to the application level decision engine 454. Tx j is actually valid, the decision engine 454 controls both the consensus module 455C and the propagation module 455P to j This means that the consensus module 455C may choose to perform the respective blockchain-related functions with respect to Tx j to each ordered set of transactions 154 of the node, and the propagation module 455P j to another blockchain node 104 in the network 106. Optionally, in embodiments, the application-level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine may choose to only publish a transaction conditional on the transaction being valid and having sufficient remaining transaction fees.

[0324] Also, note that the terms "true" and "false" herein are not necessarily limited to returning a result expressed in the form of only a single binary digit (bit), although this is certainly one possible implementation. More generally, "true" can refer to any state that indicates a successful or positive outcome, and "false" can refer to any state that indicates an unsuccessful or non-positive outcome. For example, in an account-based model, a "true" outcome might be indicated by a combination of an implicit protocol-level approval of a signature and an additional positive output of a smart contract (with the overall result considered to indicate true if both individual outcomes are true). [Explanation of symbols]

[0325] 1 node 2 nodes 5 nodes 100 systems 101 Packet Switched Network 102 Computer terminals and computer equipment 102a, 120b Computer equipment 103 Users, Parties, and Agents 103a User, first participant, Alice 103b New User or Entity, Second Party, Bob 104 full blockchain nodes, Bitcoin nodes 105 Client Applications 105a Client Applications 105b Client 106 Peer-to-Peer (P2P) Networks 107 Side Channel 150 Blockchain 151 Blocks of Data 151n-1 Block 151n Block 152 transactions 152i Transactions 152j Transaction 153 Genesis Block (Gb) 154 Pool, Ordered Set 155 Block Pointer 201 Header 202 Input, input field 203 Output, Output Field 301 Side Channel 401 Transaction Engine 402 User Interface (UI) Layer 450 Node Software 451 Protocol Engine 452 Script Engine 453 stack 454 Application Level Decision Engine 455 Blockchain-related functional modules 455C Consensus Module 455P Propagation Module 455S Storage Module 500 User Interface (UI) 501 resources 501 User Selectable Elements 501, 502 UI elements 502 Data Entry Fields 502a multicast group "a" 502b multicast group "b" 502c multicast group "c" 503 Information Elements

Claims

1. transmitting, by a sending resource, the blockchain or cryptocurrency related communication to an IPv6 multicast address for reception by at least one receiving resource; and / or receiving, by at least one receiving resource, the blockchain or cryptocurrency-related communication sent by the sending resource to an IPv6 multicast address; 12. A computer-implemented communication method, comprising:

2. 2. The method of claim 1, wherein the communication is or includes a blockchain and / or cryptocurrency related alert, a blockchain or cryptocurrency related software update, a blockchain or cryptocurrency related notice, or other blockchain or cryptocurrency related communication.

3. The method of claim 1 or 2, wherein the IPv6 multicast address is associated with communications related to a particular blockchain network or cryptocurrency.

4. 4. The method of claim 1, wherein the at least one receiving resource comprises one or more of a mining, validation, wallet and / or servicing resource arranged to operate on or in conjunction with a blockchain network.

5. taking at least one responsive action by the at least one receiving resource in response to the blockchain or cryptocurrency related communication, optionally the at least one responsive action comprising: i) sending the communication to one or more recipients; ii) accessing, installing, and / or executing a portion of data, optionally said portion of data including one or more machine-executable instructions; iii) marking or identifying at least one transaction output, transaction or transaction block, or portion of cryptocurrency as invalid, non-payable, rejected, or to be disregarded; 5. The method according to any one of claims 1 to 4.

6. forwarding said communication by said at least one of said receiving resources to at least one further receiving resource; 6. The method of claim 1, wherein the at least one further receiving resource optionally comprises at least one further IPv6 multicast address.

7. i) the blockchain or cryptocurrency-related communication is signed, marked, or otherwise authenticated by a generating resource designated as the legitimate originator or provider of the communication; and / or ii) The method of any one of claims 1 to 6, wherein the blockchain or cryptocurrency related communication is encoded or otherwise protected such that the content of the blockchain or cryptocurrency related communication can only be accessed, decrypted, read, executed or processed by using at least one unlocking mechanism such as a key, access code or secret.

8. 8. The method of claim 7, comprising providing the at least one key, access code, or secret to the at least one receiving resource or another resource authorized to access, decrypt, read, execute, or process the content of the blockchain or cryptocurrency related communication.

9. The blockchain or cryptocurrency related communication may include a filter code, flag, marker, or other identifier, preferably The filter targets / identifies the blockchain or cryptocurrency related communication to one or more receiving resources of the at least one receiving resource. the content or type of blockchain or cryptocurrency related communications transmitted; and / or 9. A method as claimed in any preceding claim, arranged to act as a means for doing so based on an intended, selected or desired set of reception resources.

10. 10. The method of claim 9, wherein the filters are provided in the blockchain or cryptocurrency related communication in a pre-specified arrangement and / or in a pre-defined format.

11. The method comprises:

11. The method of claim 9 or 10, comprising processing or ignoring the blockchain or cryptocurrency related communication by the at least one receiving resource based on the filter.

12. 12. A computing device comprising: a memory including one or more memory units; and a processing device including one or more processing units, the memory storing code configured to be executed on the processing device, the code configured to perform the method of any one of claims 1 to 11 when present on the processing device.

13. 12. A computer program embodied on a computer readable storage and configured to, when executed on one or more processors, perform the method of any one of claims 1 to 11.

Images