Method and system for improved communication on a blockchain network

Abstract

A computer-implemented data distribution method is disclosed. The method includes transmitting a portion of data from a transmitting resource on a network to one or more groups of receiving resources, each of the one or more groups being associated with a respective multicast address. Preferably, the portion of data includes blockchain-related data. Also disclosed is a computing device including a memory including one or more memory units and a processing device including one or more processing units, the memory storing code configured to execute on the processing device, the code configured to perform the method when on the processing device. Also disclosed is a computer program embodied on computer-readable storage and configured to perform the method when executed on one or more processors.

Description

[Technical Field]

[0001]

[0003] Embodiments disclosed herein relate to improvements to the transmission of data over computer-implemented networks. The embodiments are particularly, but not exclusively, suited for the transmission of blockchain-related data between parties wishing to receive, process, and / or store such data. [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 38The 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] Solutions have now been devised to address at least these and other technical problems.

[0010] 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.

[0011] 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.

[0012] 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.

[0013] 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]

[0014] [Patent Document 1] International Publication No. WO2018 / 234987 [Patent Document 2] International Patent Application No. PCT / EP2023 / 051529 [Patent Document 3] UK Patent Application No. GB2206634.4 [Patent Document 4] U.S. Patent Application Serial No. 16 / 625,641 [Patent Document 5] U.S. Patent Application Publication No. US2020 / 0162550 [Patent Document 6] International Patent Application No. PCT / IB2018 / 054501 [Non-patent literature]

[0015] [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]

[0016] 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.

[0017] 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.

[0018] 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.

[0019] 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.

[0020] 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.

[0021] 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.

[0022] 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.

[0023] 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.

[0024] 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.

[0025] 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.

[0026] 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.

[0027] 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."

[0028] 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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]

[0040] [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. DETAILED DESCRIPTION OF THE INVENTION

[0041] 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.

[0042] 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.

[0043] 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.

[0044] For comparison, an example IPv6 address is shown in hexadecimal notation in Figure 6b, where each hexadecimal character represents a sequence of four bits. The address is composed of eight 8-bit sections, each separated by a colon. Each 8-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.

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

[0046] [Table 1]

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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."

[0051] 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 created only upon arrival at RLocal. 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 with the expectation that it will forward any multicast messages to PC1 if it sees any of the multicast packets on the network. A router in the network (e.g., R2) will have been selected as the rendezvous point (RP) for the multicast 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 a join report to R2. When the rendezvous point receives the multicast packet, it forwards the packet to R1, which then passes the packet to RLocal, which then passes the packet to PC1.

[0052] 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.

[0053] 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.

[0054] 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.

[0055] 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.

[0056] 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).

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] In the Bitcoin network, each full 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.

[0065] 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.

[0066] 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.

[0067] 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.

[0068] - 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.

[0069] 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.

[0070] 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.

[0071] 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.

[0072] 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.

[0073] 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.

[0074] As an example, consider an IPv6 multicast group consisting of two members, Alice and Bob, who want to participate in SPV validation. 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 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.

[0075] 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.

[0076] 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.

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 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).

[0081] 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.

[0082] 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.

[0083] 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. 1. A set of relevant (e.g., key stakeholder) nodes agree on a shared obligation, responsibility, or goal (e.g., delivering large blocks, or blocks according to a specific protocol, or according to the terms of an agreement). 2. 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. 3. 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. 4. At least one of the involved nodes, or another party, advertises the 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. 5. At least one of the involved nodes, or another party, communicates the unique anycast address to the wider Bitcoin network, or at least to their respective local or designated communities. 6. Nodes (which may be affiliated or unaffiliated) mine new blocks. 7. The mining node, i.e. the node that mined the new block, sends the new block (or block header and list of transactions) to a multicast address. 8. 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. 9. At least one, but preferably all, of the involved nodes perform the necessary checks to validate the legitimacy of the newly mined block. 10. 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.

[0084] 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.

[0085] 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.

[0086] 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.

[0087] 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.

[0088] 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.

[0089] 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.

[0090] We present some use cases for illustrative purposes and not for limitation.

[0091] Exemplary Use Case 1: Double Spending, "First Seen Rule", Network Alert: 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.

[0092] 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 for 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."

[0093] 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.

[0094] However, in accordance with the present disclosure, double-spend alerts are sent to mining nodes in a multicast group, allowing all nodes to simultaneously receive the alert as quickly as possible and take any necessary corrective action. There is no "hop" from one node to another, as each node that joined the multicast group listens to the stream and picks up the message itself. Such embodiments therefore provide improvements in processing, time, and security with respect to network communications and alerts.

[0095] 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 transmitted to all SPV nodes. The use of multicast allows for near-instantaneous communication of this data.

[0096] 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.

[0097] 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 Patent Application No. PCT / EP2023 / 051529, may be transmitted to a multicast group. In such a scenario, a resource desires to delegate storage of a file or other resource to multiple storage providers, and the transmitting resource therefore 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 desires 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.

[0098] 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.

[0099] 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.

[0100] 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).

[0101] 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.

[0102] 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:

[0103] 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.

[0104] 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.

[0105] A computer-implemented data distribution method is disclosed. The method may include transmitting a portion of (e.g., blockchain-related) data from a transmitting resource to one or more groups of receiving resources, each of which is 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 identifying the group. 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 transmitting resource may be a full blockchain node 104, or a node 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 following sets of items:

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

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

[0108] 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.

[0109] 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.

[0110] 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.

[0111] The network may be a peer-to-peer (P2P) network and / or a distributed network. This may be a blockchain network in which nodes 104 on the blockchain network 106 are operable to perform operations according to the blockchain's protocols. 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.

[0112] 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:

[0113] 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 full nodes 104 on the blockchain network 106; - 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.

[0114] 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.

[0115] Data may be transmitted over an electronic network as / in the form of one or more packets of data ("data packets").

[0116] 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.

[0117] 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. 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.

[0118] 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.

[0119] 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.

[0120] 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.

[0121] 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.

[0122] 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.

[0123] 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 results 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.

[0124] 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.

[0125] 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.

[0126] 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.

[0127] 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.

[0128] 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.

[0129]

[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:

[0130] 1. Transmitting at least one data packet from one or more transmitting resources to one or more receiving resources over an electronic network. Here, one or more resources may be members of a multicast group, in other words, they may be subscribers of a common (shared) multicast address, and 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 transmitting 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. 1.1. At least one data packet may be received by at least one of the receiving resources; 1.2. determining, by the at least one receiving 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 receiving resource; 1.3. Sending a request for at least one further data packet from at least one receiving resource to 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; 1.4. receiving a request for at least one further data packet from the at least one receiving resource by the at least one further resource; 1.5. Transmitting at least one further data packet from the at least one further resource to 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.

[0131] 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.

[0132] 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 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.

[0133] 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.

[0134] 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.

[0135] 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 a predetermined criterion has been met; 13. Listening by the node / group member for new data transmissions to be sent to the group's multicast address.

[0136] 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.

[0137] 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.

[0138] 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.

[0139] 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.

[0140] 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.

[0141] 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.

[0142] 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.

[0143] 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 (TxTDs); 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.

[0144] 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.

[0145] 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.

[0146] Item 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.

[0147] 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.

[0148] 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.

[0149] 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.

[0150] 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 item set 9 may be combined with one or more of the items of any other item set presented herein, or with any other feature disclosed herein.

[0151] 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.

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

[0153] Thus, the following may be provided: Section 9.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.

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

[0155] Section 9.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 9.1, wherein the sending resource and / or at least one receiving resource is a node on a blockchain overlay network.

[0156] 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.

[0157] 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.

[0158] 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.

[0159] 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.

[0160] 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.

[0161] 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.

[0162] 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.

[0163] 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.

[0164] 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.

[0165] 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.

[0166] 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.

[0167] 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.

[0168] 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.

[0169] 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.

[0170] 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.

[0171] 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.

[0172] 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).

[0173] 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.

[0174] 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.

[0175] 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.

[0176] 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.

[0177] 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.

[0178] 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.

[0179] 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.

[0180] 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.

[0181] 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.

[0182] 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).

[0183] 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.

[0184] 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.

[0185] 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.

[0186] 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.

[0187] 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 full 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 full 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.

[0188] 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.

[0189] 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.

[0190] 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.

[0191] When new transaction Tx1 arrives at full 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).

[0192] 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.

[0193] 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.

[0194] 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.

[0195] 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.

[0196] 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.

[0197] 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.

[0198] 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.

[0199] 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).

[0200] 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.

[0201] 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.

[0202] 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.

[0203] 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.

[0204] 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.

[0205] 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.

[0206] 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.

[0207] 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.

[0208] 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).

[0209] Alternatively or additionally, the UI elements may include one or more data entry fields 502, through which a user can... 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 orally, e.g., based on voice recognition.

[0210] 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.

[0211] 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.

[0212] Node Software FIG. 4 illustrates an example of node software 450 running on each full 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 calculates 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.

[0213] 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).

[0214] 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."

[0215] 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 the 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 , which the consensus module 455C selects to perform respective blockchain-related functions on 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.

[0216] 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).

[0217] Disclaimer No admission is made that any reference cited or referred to herein constitutes prior art. The statements in such references state what their authors assert, and applicants reserve the right to challenge the accuracy and pertinence of the cited documents. A number of prior art documents are cited herein, and it will be expressly understood that such reference does not constitute an admission that any of these documents form part of the general knowledge in the art in the UK, the USA, or any other country.

[0218] U.S. Patent Application No. 16 / 625,641, published as U.S. Patent Application Publication No. US2020 / 0162550 and derived from International Patent Application No. PCT / IB2018 / 054501, is incorporated herein by reference. International Patent Application No. PCT / EP2023 / 051529 and its U.S.-filed derivative applications are also incorporated herein by reference. All references cited herein are incorporated by reference to the fullest extent permitted by law. The incorporation by reference of the above patent documents is limited so that no subject matter contrary to the express disclosure herein is incorporated. The incorporation by reference of the above patent documents is further limited so that no claims contained therein are incorporated herein by reference. The incorporation by reference of the above patent documents is further limited so that definitions provided in the patent documents are not incorporated herein by reference unless expressly included herein. [Explanation of symbols]

[0219] 1 node 2 nodes 4 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, blockchain 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. A computer-implemented data distribution method comprising: transmitting a portion of blockchain-related data from a sending resource over a network to a multicast address associated with a group of receiving resources.

2. One, some, or all of the transmission resources and / or the reception resources in the group are: Nodes in a blockchain network, a node in an overlay network that is an overlay with respect to the 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; 10. The method of claim 1, wherein the method is or includes an MLDv1 or MLDv2 host on a network, a network switch, or a router.

3. The data is 3. A method according to claim 1 or 2, comprising or relating to a communication or alert relating to a blockchain related event or activity, preferably the alert relating to a double spend or attempted double spend within a blockchain network.

4. 4. The method of claim 1, wherein the network is or includes the Internet.

5. Blockchain-related data is 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 results of or data relating to any proof-of-stake or proof-of-work operation; vi) results of a validation operation, including a validation of a blockchain block or a simplified payment verification (SPV) operation, or other data relating thereto.

6. The blockchain-related data is transmitted by the sending resource to the group of receiving resources, i) using multicast communication, and / or ii) according to the multicast forwarding table, 6. The method according to claim 1, wherein the first and second signals are transmitted.

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 blockchain-related data is transmitted over the Internet to the group of receiving resources; iv) the transmission resource is operable to enable Multicast Listener Discovery (MLD) snooping, preferably the method comprising the step of enabling MLD snooping by the transmission resource.

8. 8. A method according to any preceding claim, wherein each receiving resource in the group of receiving resources is operable to receive data transmitted to the multicast address of the group of receiving resources.

9. subscribing by a resource to a group of receiving resources, preferably by transmitting a signal to the network; A method according to any one of claims 1 to 8, comprising a step of leaving, by a resource, a group of receiving resources, preferably by said resource leaving said group by ceasing to transmit signals to the network.

10. At least one receiving resource in the group of receiving resources comprises: 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, said computing a Merkle path, a Merkle tree, or the root of a Merkle tree; 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; 10. The method of any one of claims 1 to 9, arranged, configured and / or operable to generate blockchain transactions, write transactions to the blockchain and / or broadcast transactions to a blockchain network.

11. The group of receiving resources is one of a plurality of groups of receiving resources, and the method further comprises:

11. The method of claim 1, further comprising transmitting the portion of blockchain-related data from the sending resource to a plurality of groups of receiving resources, thereby polling each of the plurality of groups for a target response.

12. transmitting a multicast communication from a transmission resource to at least one group of resources, wherein the transmission resource and / or at least one resource in the at least one group comprises: 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 one or more blockchain mining nodes, and / or a service provider or component thereof configured to provide at least one blockchain-related service to one or more users; being or including a merchant resource or component thereof that includes a digital wallet and / or is operable to communicate with a blockchain network; method.

13. i) said communication is transmitted over a public network, preferably the Internet; and / or ii) the 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 concerns a double-spend or attempted double-spend within the network; and / or iv) the communication is an alert or other communication that includes blockchain-related data; 13. The method of claim 12, wherein the communication includes at least a portion of blockchain-related data and / or a Merkle path or tree.

14. transmitting data from a sending node to a plurality of receiving nodes associated with a multicast address, said data comprising: At least a portion of the block header of the blockchain block; and a list of one or more blockchain transactions included in the blockchain block; A computer-implemented method.

15. using the data by at least one of the receiving nodes to identify at least one further blockchain transaction required by the at least one receiving node to generate the blockchain block; 15. The method of claim 14, wherein preferably identifying the at least one further blockchain transaction comprises searching for the at least one further blockchain transaction within a stored set of blockchain transactions maintained by and / or accessible to the at least one receiving node.

16. 16. The method of claim 15, comprising sending a request for the at least one further blockchain transaction from the at least one receiving node to the sending node, or to the multicast address, or to one or more further nodes.

17. receiving, by the sending node, the request from the at least one receiving node; sending a transmission from the sending node to the at least one receiving node, the transmission including at least one further blockchain transaction; 17. The method of claim 16, wherein the transmission is preferably a unicast transmission.

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

19. 18. 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 17.

Images