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

Abstract

Methods and techniques are provided for coordinating and distributing tasks and / or processing requests among a group of resources on a network by employing multicast and anycast transmissions. In one embodiment, the group of resources may include nodes or other resources of a blockchain network that implement all or a portion of a particular blockchain protocol (e.g., the Bitcoin SV Protocol) and / or service providers that provide services to blockchain-related organizations, groups, or networks.

Description

[Technical Field]

[0001] The 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 resources / entities that 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 (or multicast transmission), 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 multicast, a packet is sent to a multicast address corresponding to a group of devices, and the packet is then routed for delivery to all of the devices in the group. IPv6 anycast transmission (or anycast transmission), on the other hand, allows a source resource to send a data packet to an anycast address corresponding to a group of devices, but the packet is routed for delivery to only one device in the group (the device topologically closest to the sender).

[0006] The incorporation of multicast and anycast into the IPv6 protocol leads to increased efficiency in transmitting 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 and anycast in IPv6 can provide a more efficient and scalable solution for transmitting data over the Internet.

[0007] Beyond the Internet, the need for efficient transport of data transmissions is also important for other data networks. For example, scalability is a key technical challenge for many distributed ledgers due to limitations on the maximum size of blocks they utilize (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 degrades 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 proof-of-stake mechanisms or that utilize an account-based model rather than a UTXO-based model are also within the scope of this disclosure. Also, note that "Bitcoin" is not limited to a specific Bitcoin-related protocol, and 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.

[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 operations, functions, or services performed in connection with, or for purposes of implementing, a blockchain protocol or blockchain-based application. Public, private, or permissioned blockchains also fall within the scope of this disclosure. [Prior art documents] [Patent documents]

[0014] [Patent Document 1] International Publication No. WO2018 / 234987 [Patent Document 2] PCT International Application No. PCT / EP2023 / 051529 [Patent Document 3] UK Patent Application No. GB2206634.4 [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 network. Preferably, - These solutions can use IPv6 data communications and / or - The data may be blockchain-related data, but is not limited to use solely in connection with blockchain and blockchain-related data; and / or - The network can be 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, network resources may be associated to form one or more multicast groups, each having its own respective multicast address. The multicast address is a logical, collective identifier for the network resources in the multicast group such that all network resources in the multicast group receive data packets sent from the sending resource via a multicast transmission addressed to the multicast address. In some embodiments, the multicast address may be an IPv6 multicast address or an IPv4 multicast address, and the data packets are sent and received over the Internet.

[0018] In one particularly advantageous example, the present disclosure may involve transmitting data from a transmitting resource to a multicast group of receiving resources. In a preferred embodiment, the data relates 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 receiving resources that should receive a copy, rather than multiple times to each individual receiving resource, 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 in each multicast group may be of various types, forms, configurations, or purposes, and the transmitting resources may be members of the multicast 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. However, in one or more embodiments, one or some or all of the transmitting and / or receiving nodes in a group may be full nodes on a blockchain network or nodes on an overlay network, and the data may include data related to unconfirmed transactions that have been verified but not yet written to the blockchain ledger. In such embodiments, systems and methods may be provided for implementing member pools within or associated with a blockchain network or an overlay network that interacts with a blockchain network.

[0021] Advantageous applications of the present disclosure may include, among other things, the ability to transmit data to a multicast group of network resources providing distributed and / or parallelized blockchain-related functionality, such as, for example, mining functionality, on-chain discovery functionality, validation functionality, computation providers such as service providers performing proof-of-work computations and outputs, or proof-of-stake related work, etc.

[0022] In another exemplary embodiment of the present disclosure, network resources may be associated to form one or more anycast groups, each having its own respective anycast address. The anycast address is a logical, collective identifier for the network resources in the anycast group such that one network resource in the anycast group (typically the network resource topologically closest to the transmission source) receives data packets sent from the transmission resource to the anycast address. In some embodiments, the anycast address may be an IPv6 anycast address, and data is sent and received over the Internet.

[0023] In one particularly advantageous example, the present disclosure may involve transmitting data from a transmitting resource to an anycast 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 transmits the data to the anycast address of the group, and a routing function routes the data to one network resource in the anycast group (typically the network resource topologically closest to the transmitting source) without the transmitting resource needing to determine or select individual receiving resources as in anycast. The receiving resources in the anycast group may be of various types, forms, configurations, or purposes, and the transmitting resources may be members of the anycast group or may be external to the anycast group. The present 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.

[0024] Advantageous applications of the present disclosure may include, among other things, the ability to transmit data to one or more anycast groups of network 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.

[0025] In embodiments, methods and techniques are provided for coordinating and distributing tasks and / or processing requests among a group of resources on a network by employing multicast and anycast transmissions. In one embodiment, the group of resources may include nodes or other resources of a blockchain network that implement all or part of a particular blockchain protocol (e.g., the Bitcoin SV protocol).

[0026] In embodiments, these methods and techniques may involve transmitting data (e.g., at least one data packet) over an electronic network from one or more transmitting resources to one or more receiving resources, where the one or more receiving resources are members of a multicast group associated with a particular multicast address, and in addition, one or more of the transmitting resources may be members of an anycast group associated with a particular anycast address.

[0027] In embodiments, these methods and techniques include: - associating a first group of resources with an anycast group having a particular anycast address; and / or - associating the second group of resources with a multicast group having a particular multicast address; and / or - transmitting an initial message (i.e., one or more data packets) from a transmission resource to a specific multicast address corresponding to a multicast group, the transmission resource may or may not belong to the anycast group, the initial message including i) the specific anycast address for the anycast group, and ii) data related to one or more tasks or processing requests; and / or - routing the initial message to each resource in the multicast group.

[0028] The phrase "assigning a group of resources to a multicast group" means that the resources subscribe to (or join) the multicast group as known in the art and as described herein.

[0029] In embodiments, the methods and techniques may further involve, in response to receiving the data (i.e., the initial message), at least one resource (receiving resource) belonging to the multicast group transmitting a response message (e.g., at least one data packet) to a particular anycast address corresponding to the anycast group, the response message communicating an intent or willingness to perform or fulfill one or more tasks or processing requests related to the received data (i.e., the initial message).

[0030] In embodiments, these methods and techniques include: - routing the response message to one resource in the anycast group that is topologically closest to the resource in the multicast group that sent this response message, and / or - determining, in response to receiving the response message, which resource (receiving resource) of the multicast group from which at least one resource of the anycast group sent a response message is topologically closest to the resource of the anycast group; and / or - determining which resource in the multicast group from which the resource in the anycast group sent the response message is topologically closest to the resource in use in the anycast group using a route discovery utility; and / or - enabling at least one resource of the anycast group to perform one or more tasks or processing requests related to the initial message and the response message in cooperation with such topologically closest resource (receiving resource) of the multicast group; and / or - configuring at least one resource (receiving resource) of the multicast group to decide not to respond to the initial message if it is busy or unable to perform or fulfill one or more tasks or processing requests associated with the initial message based on some criteria, and / or configuring at least one resource (receiving resource) of the multicast group to decide not to respond to the initial message if it is not willing to perform or fulfill one or more tasks or processing requests associated with the initial message based on other criteria.

[0031] In embodiments, the first group and / or second group of resources may include resources that validate one or more blockchain transactions, a miner pool or set of proof-of-work computation resources, resources that create blocks of transactions using proof-of-work or proof-of-stake consensus, or resources that process data in some manner for blockchain and / or cryptocurrency-related purposes.

[0032] In embodiments, one or more tasks or processing requests may relate to blockchain transactions or other blockchain data.

[0033] In an embodiment, one or more tasks or processing requests include: - Validating one or more blockchain transactions; - Mining blocks of transactions using proof-of-work computational resources or computation against other consensus mechanisms such as proof-of-stake; - Creating blocks of transactions using a proof-of-stake or proof-of-work consensus mechanism; - Processing or distributing data to one or more recipients, such as nodes in a network, where the data may be an alert, executable code, software update or installation, document or file, or another type of communication / data; - Instant payment verification, or - May involve processing data in any way for blockchain and / or cryptocurrency related purposes.

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

[0035] [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 anycast transmission in which a server sends a data packet to an anycast address, and the data packet is forwarded to the topologically closest resource (i.e., router / node) in the subscribed set of resources. [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 a node on a blockchain network broadcasting a block via multicast transmission to key nodes in the blockchain network. [Figure 16] 1 is a flowchart illustrating an exemplary method for coordinating and distributing tasks and / or processing requests among a group of resources on a network by employing multicast and anycast transmissions. [Figure 17A] 7 is a flowchart illustrating a portion of the method of FIG. 6 in terms of transmission resources belonging to an anycast group. [Figure 17B] 7 is a flowchart illustrating a portion of the method of FIG. 6 in terms of transmission resources belonging to an anycast group. [Figure 18A]17 is a flowchart illustrating a portion of the method of FIG. 16 from the perspective of receiving resources belonging to a multicast group. [Figure 18B] 17 is a flowchart illustrating a portion of the method of FIG. 16 from the perspective of receiving resources belonging to a multicast group. DETAILED DESCRIPTION OF THE INVENTION

[0036] FIG. 5 illustrates an embodiment in which network resources belonging to multiple groups communicate with each other to securely, efficiently, and quickly deliver electronic data. In this exemplary embodiment, three groups of network resources 501 are shown. 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, as described herein, is a group of resources addressable via a single multicast address. A resource 501 that transmits any type of data to another resource may be referred to herein as a transmitting resource, and a receiver of the data may be referred to as a receiving resource.

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

[0038] When using multicast transmission, resources in 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 all) resources that are members of the receiving multicast group receive the data.

[0039] When using anycast transmission, a transmission resource, e.g., a resource in group 502a, may transmit data by sending it in the form of a single transmission to an anycast address corresponding to the group of resources (e.g., group 502a or group 502b). The data packet is routed to the resource in the group associated with the anycast address determined to be topologically closest to the transmission resource. The receiving resource may process the data or forward the data to one or more of the other resources (e.g., to the resource in multicast group 502a, or to any other resource in one or more of the other groups, or even to any other resource that is not part of any group). In this way, only one data transmission is sent to a single receiving resource in a particular anycast transmission, and the data can then be spread to other members of the multicast 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.

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

[0041] When using anycast transmission, resources in a multicast group, e.g., group 502b, may transmit data, such as requested data in response to a received request, to group 502a by sending the data in the form of a single data transmission to a single anycast address corresponding to group 502a. The data is routed to the resource in group 502a determined to be topologically closest to the resource that transmitted the data. The receiving resource may then forward the data to other resources in group 502a using multicast transmission. In this way, only one data transmission instance is required for the data to arrive at group 502a, and the possibility that only one member resource of group 502a receives the data and only a subset of group 502a needs the data is addressed. Additionally or alternatively, the receiving resource may forward the data to another resource using unicast (direct) communication.

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

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

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

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

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

[0047] [Table 1]

[0048] Multicast: Multicast is a one-to-many network communication solution in which a sending resource transmits a single data packet addressed to a multicast address corresponding to a multicast group with multiple resources / destinations. The sending resource only sends one copy of the data to the multicast address. Resources subscribed to the multicast group 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 sending resource only sends one copy of the data even though all members of the multicast group receive a copy. This is in contrast to unicast, in which the sending resource establishes a connection with each intended receiver and sends a separate copy of the data to each.

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

[0050] Referring to Figure 7, the unicast communication 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.

[0051] For multicast transmission, 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 server join the multicast group of that multicast address; this is called a "subscription."

[0052] 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 transmission 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 multicasts to FF00: / 8. Knowing that the best path to R2 is through R1, RLocal sends a join report to R1 asking R1 to forward the request for the FF00: / 8 multicast transaction to the rendezvous point R2. R1 sends 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.

[0053] Anycast IPv6 anycast transmission can be used in networks where multiple resources / destinations 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.

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

[0055] Referring to Figure 9, which shows an anycast transmission from the server to router R3, we see that the packet is sent to the anycast address, 2001:db8: / 32, which is 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.

[0056] Illustrative Embodiments Next, referring to the description of exemplary embodiments of the present disclosure and referring to Figures 5 through 19, a solution utilizing these transmission technologies for fast, secure, and scalable data delivery over a 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.

[0057] Each group is associated with a respective group identifier that serves as a unique address to which data can be sent.

[0058] In multicast transmission, the group is a multicast group, and all resources in the multicast group are associated with the group's multicast address and can therefore receive data sent from a sender to that multicast group address. The multicast address may be an IPv6 multicast address or an IPv4 multicast address. Multicast addresses may be used to implement one-to-many communication because a sending resource need only send a packet of data once to the multicast address for each resource in the multicast group to receive, rather than sending to each and every resource in one-to-one communication (as is done in unicast transmission).

[0059] A receiving resource may subscribe, or join, a multicast group by sending a Multicast Listener Discovery (MLD) message announcing its intention to join. Advantageously, participating resources may 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 multicast group, it can receive multicast packets sent to that multicast address of the multicast group. Thus, a resource can dynamically join or leave a multicast group at any time by simply announcing its participation to the network or by ceasing to announce that multicast group to the network.

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

[0061] For anycast transmission, the group is an anycast group associated with an anycast address for that group. The anycast address is a logical, collective identifier for network resources in the anycast group, such that one resource in the anycast group (typically the resource topologically closest or nearest to the transmission source) receives a data packet sent from the transmission resource to the anycast address via the anycast transmission. In some embodiments, the anycast address may be an IPv6 anycast address, and data is sent and received over the Internet. Anycast group addresses may be used to efficiently implement one-to-many communications.

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

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

[0064] 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 a 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.

[0065] 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, mining pools, service providers that provide support functions to cryptocurrency or blockchain-related organizations, etc.

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

[0067] In the Bitcoin network, each full node 104 is expected to store an up-to-date copy of the blockchain / ledger, member pool (a data set of unconfirmed transactions), and UTXO set (a list of all unsent transaction outputs). Maintaining the most up-to-date versions of these data sets requires continuous communication between nodes, and validated transactions and blocks are 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 updates its private 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.

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

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

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

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

[0072] Data delivery using IPv6 multicast transmission: According to some embodiments, IPv6 communication of data packets may be advantageously employed for block distribution on or within a blockchain network. FIG. 11 illustrates an example of distribution of mined blocks from node 5 to a network of nodes using multicast transmission. 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 appropriate blocks to the multicast address. These may be full or partial blocks, and may be mined or pre-mined blocks.

[0073] In the example of Figure 11, blockchain node 4 receives Bitcoin transactions from PC1, PC2, and node 5, is able to successfully produce a mined block, and seeks to distribute it to a set of interested nodes as efficiently as possible. 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.

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

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

[0076] Using IPv6 multicast transmission, a transmitting resource can enable MLD snooping, allowing the transmitting resource to selectively send packets only to resources that have indicated an interest in receiving them. This means that transmissions of blockchain-related or related 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 the transmission of very large numbers of transactions per second. Therefore, blockchain-related methods and systems incorporating the use of MLD snooping facilitate or enable the construction of improved blockchain networks and blockchain-implemented applications.

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

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

[0079] Data delivery using IPv6 anycast transmission: Anycast transmissions are particularly suitable 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 group associated with an anycast address. This 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 that belongs to the anycast group associated with the anycast address. This closest node then sends a copy of the mined block (using unicast) directly to the node that requested it.

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

[0081] In the case of Figure 12, the closest is node 1, which then, if it chooses, sends a copy of the block to node 5 via unicast communication, meaning that node 1 is more likely to receive a complete copy of the block more quickly, assuming it is the closest node.

[0082] Note, however, that the "closest" node may depend on several factors other than geographic proximity. For example, latency and cost may be used 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 blocks.

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

[0084] Data distribution using multicast together with anycast and / or unicast Figure 13 illustrates the use of multicast transmissions along with anycast transmissions for block distribution. In such an embodiment, the previously described uses of multicast and anycast transmissions 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 their closest Layer 1 nodes.

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

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

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

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

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

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

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

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

[0093] For purposes of illustration and not limitation, we present some exemplary use cases.

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

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

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

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

[0098] 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 transmission allows for near-instantaneous communication of this data.

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

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

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

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

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

[0104] For example, suppose a multicast transmission containing 10 packets of data is sent to a multicast group, but a particular group member (which may be referred to as a receiving resource) receives only 8 of the 10 data packets sent. The receiving resource is missing packets 2 and 7. The receiving resource may 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.

[0105] This solution is 1. Using multicast transmission, transmitting a portion of data (a plurality of 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:

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

[0107] Coordination and distribution of execution of tasks and / or processing requests using multicast and anycast transmissions According to some embodiments, multicast and anycast transmissions may be employed to coordinate and distribute tasks and / or processing requests among a group of resources on a network. In one embodiment, the group of resources may include full (mining) nodes 104 running client software for a given protocol, or other resources in a blockchain network, such as lightweight nodes, that implement all or part of a particular blockchain protocol (e.g., the Bitcoin SV protocol). These may also include wallets. In some embodiments, the nodes may be nodes in, within, or on top of an overlay network built on top of the blockchain network. In such an example, the overlay nodes are not full mining nodes 104. For example, the group of resources may include a miner pool or a set of PoW computational resources, or resources that process data in some manner for blockchain and / or cryptocurrency-related purposes. These may include, for example, digital wallet providers, cryptocurrency exchanges, banks and financial institutions, decentralized validation providers, etc. In this embodiment, the tasks and / or processing requests may involve blockchain transactions or other blockchain data, such as validating one or more blockchain transactions, mining a block of transactions using proof-of-work computational resources, or creating a block of transactions using a proof-of-stake consensus mechanism, simplified payment verification, or processing data in some way for blockchain and / or cryptocurrency related purposes.

[0108] FIG. 16 illustrates a method for coordinating and distributing tasks and / or processing requests among a group of resources on a network using multicast and anycast transmissions.

[0109] The method begins at 1601 where multiple resources join (or are otherwise associated with) an anycast group, which is associated with an anycast address for the anycast group.

[0110] At 1603, one of the resources of the anycast group (or some other resource that need not be part of the anycast group) (i.e., a transmitting resource) sends an initial message to one or more multicast groups via multicast transmission. The initial message is represented by one or more data packets. The initial message is sent to a multicast address for each given multicast group. The initial message includes the anycast address for the anycast group and data related to one or more tasks or processing requests.

[0111] At 1605, resources belonging to the multicast group receive the initial message, and each respective resource in the multicast group determines whether it is willing or able to respond to the initial message to communicate a willingness, ability, or intention to perform or fulfill one or more tasks or processing requests associated with the initial message. A given resource in the multicast group may receive the initial message as follows: 1. is busy or unable, based on some criteria, to perform or fulfill one or more tasks or processing requests associated with the initial message; or 2. May ignore one or more tasks or processing requests associated with the initial message if it does not intend to perform or fulfill them based on other criteria. For example, the processing request may not comply with policies or rules implemented within or by the organization.

[0112] At 1607, each resource in the multicast group that wishes to respond to the initial message (e.g., a responding resource) sends a response message to the anycast group via anycast transmission. The response message is represented by one or more data packets. The response message is sent to the anycast address for the anycast group. The response message is routed to the resource in the anycast group that is topologically closest to the responding resource.

[0113] At 1609, one or more resources of the anycast group receive the one or more response messages, determine which responding resource of the multicast group that sent the response message is topologically closest to the resource of the anycast group, and then coordinate with such topologically closest responding resource to perform one or more tasks or processing requests associated with the initial message / response message. In an embodiment, the topologically closest responding resource may deliver a data packet containing results of performing the one or more tasks or processing requests to the anycast group by sending such data packet to the anycast address of the anycast group. The resource of the anycast group receiving such data packet may then forward such data to other resources in the anycast group using multicast transmission or, alternatively, using unicast (direct) transmission. This method enables the coordination and distribution of tasks and / or processing requests between two groups of resources (an anycast group and a multicast group) that are topologically closest to each other. This can be advantageous in a distributed environment where the speed of network communication (or minimization of network latency) between the two groups of resources can affect the operation, efficiency, and / or economic rewards awarded to the resources. For example, in a blockchain network where a group of resources includes a miner pool or a set of PoW computational resources operating as part of the blockchain network's consensus mechanism, the coordination and distribution of tasks and / or processing requests can minimize network latency between the resources, thereby improving the computational efficiency of the resources with the goal of maximizing the economic rewards awarded to the resources as part of the consensus mechanism (e.g., resources are rewarded for winning a race to assemble a new valid block of transactions by solving a cryptographic puzzle). 17A and 17B illustrate the operation of a receiving resource as part of the method of FIG. 16 that is configured to listen for and receive an initial message transmitted over a network using multicast transmission.

[0114] At 1701, a resource joins a multicast group of resources identified by a multicast address.

[0115] At 1703, the resource listens for an initial message to be sent to the multicast group address. At 1705, the resource receives an initial message from a sending resource (see 1603). The initial message is sent to a multicast address for a multicast group. The initial message includes an anycast address for a particular anycast group (used in response messages) and data related to one or more tasks or processing requests. At 1707, the resource determines whether it wishes to respond to the initial message to communicate a willingness, ability, or intention to perform or fulfill one or more tasks or processing requests associated with the initial message. The resource may respond to the initial message by: 1. is busy or unable, based on some criteria, to perform or fulfill one or more tasks or processing requests associated with the initial message; or 2. If, based on other criteria, you are not willing to perform or fulfill one or more tasks or processing requests associated with the Initial Message. It can be ignored.

[0116] If, at 1709, the resource decides to respond to the initial message, resource operation continues at 1711. Otherwise, resource operation returns to 1733 to listen for, receive, and process one or more other initial messages. At 1711, the resource acts as a replying resource and sends a reply message to the particular anycast group via anycast transmission (using the anycast address specified in the initial message). The reply message is sent to the anycast address (extracted and copied from the initial message) for the particular anycast group. The reply message is routed to the resource in the particular anycast group that is topologically closest to the replying resource.

[0117] At 1713, the resource (i.e., the responding resource) waits for further messages from the resources of the particular anycast group so that it can then perform one or more tasks or processing requests associated with the initial message / response message. The further messages may be sent from the anycast group member that is topologically closest to the responding resource. 18A and 18B illustrate the operation of a transmission resource as part of the method of FIG. 16 that is configured to generate and transmit an initial message that is transmitted over the network using multicast transmission. At 1801, multiple resources join (or are otherwise associated with) a particular anycast group, which is associated with a unique anycast address for that particular anycast group. At 1803, one of the resources of the particular anycast group (or another resource that need not be part of the particular anycast group) (i.e., a transmitting resource) generates an initial message to one or more multicast groups via multicast transmission. The initial message includes an anycast address for the particular anycast group (used in the response message) and data related to one or more tasks or processing requests. At 1805, the transmission resource sends the initial message to the multicast groups via a multicast transmission. The initial message is sent to a multicast address for each given multicast group. At 1807, resources in a particular anycast group wait to receive one or more response messages in response to the initial message. At 1809, when no response message is received from at least one resource of the multicast group within the predetermined time period, operations continue to 1811. Otherwise (when there is a response message received from at least one resource of the multicast group within the predetermined time period), operations continue to 1813. In 1811, one of the resources of the particular anycast group (or another resource that need not be part of the particular anycast group, e.g., the same or a different transmitting resource) generates a new initial message with updates to data related to one or more tasks or processing requests, and returns to operations 1805 through 1809, transmitting the new initial message via multicast transmission to one or more multicast groups, listening for and processing associated response messages. For example, a payment amount may be updated to increase the reward for performing a task, or a change to the original parameters or criteria included in the initial message.

[0118] At 1813, each given resource in a particular anycast group that received one or more response messages determines which resource in the multicast group that sent the response message is topologically closest to the given resource in the particular anycast group. Such an operation can employ a route discovery utility, which is a command-line utility available in almost all operating systems. This provides the complete route to the destination address, including the time (or delay) taken between intermediate routers in the route. The output of the route discovery represents the number of hops to the destination address and the delay in the route. This information can be collected for the route to each resource in the multicast group that sent the response message, and such information can be processed to determine which resource in the multicast group that sent the response message is topologically closest to the given resource in the particular anycast group. Additionally or alternatively, other suitable networking utilities can be used as well. At 1815, a given resource of a particular anycast group and the topologically closest resource of the multicast group as determined at 1813 cooperate to perform one or more tasks or processing requests related to the initial message / response message. In embodiments, the one or more tasks and / or processing requests may relate to blockchain transactions, blockchain blocks, or other blockchain data-related data that are configured for or associated with an operation such as validating one or more blockchain transactions, mining a block of transactions using proof-of-work computational resources, or creating a block of transactions using a proof-of-stake consensus mechanism, simplified payment verification, or processing data in some manner for blockchain and / or cryptocurrency-related purposes.

[0119] Enumerated items The items listed therein are provided as illustrative examples of 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.

[0120] A computer-implemented data distribution method is disclosed. The method may include transmitting a portion of (e.g., blockchain-related) data from a sending resource to one or more groups of receiving resources, each of the one or more groups being associated with a respective address, which may be a multicast address. Stated differently, groups of resources may be formed, where for each group, the resource subscribes to the members of the group, and all members are associated with an address that identifies the group.

[0121] In one possible form of expression, the method comprises: sending an initial message from a sending resource to a group of at least one receiving resource subscribed to the resource's multicast group, the initial message being sent to a multicast address associated with the resource's multicast group and including a unicast address associated with the resource's anycast group and data related to the task to be performed; receiving an initial message from the sending resource by a group of at least one receiving resource subscribed to the resource's multicast group, the initial message being sent to a multicast address associated with the resource's multicast group and including a unicast address associated with the resource's anycast group and data related to the task to be performed; sending each response message from at least one of the receiving resources to an anycast address; receiving a response message from at least one receiving resource in an anycast group of resources; determining, for each (respective) resource in the anycast group of resources, which of the at least one receiving resource that sent the response message is topologically closest to the (respective) resource in the anycast group; determining, based on the determination result of the previous step, which of the receiving resources is topologically closest to the (identified, particular member of) the anycast group of resources; sending a confirmation message from the (identified, specific) member of the anycast group to a receiving resource that is the topologically closest resource in the multicast group of resources, the confirmation message including data confirming the capability, willingness, or intent of the (identified, specific) resource in the anycast group of resources to coordinate with the topologically closest receiving resource to perform the task; receiving a confirmation message from the (identified, specific) member of the anycast group by a receiving resource that is a topologically closest resource in a multicast group of resources associated with the (identified, specific) member of the anycast group, the confirmation message including data confirming the capability, willingness, or intent of the (identified, specific) resource in the anycast group of resources to coordinate with the topologically closest receiving resource to perform a task; The method may include one, some, or all of the steps of: performing a task at, by, or on behalf of the topologically closest receiving resource.

[0122] One, some, or all of the receiving resources may be full nodes 104 on the blockchain network, or nodes in an overlay network that reside on one or more full nodes on the blockchain network but communicate with one or more full nodes on the blockchain network. The sending resources may be full blockchain nodes 104, or nodes on a blockchain overlay network that reside on one or more full nodes on the blockchain network but communicate with one or more full nodes on the blockchain network. These features may apply to one or more of the set of items presented below.

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

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

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

[0126] Item Set 1: Embodiments disclosed herein may provide methods and techniques for coordinating and distributing tasks and / or processing requests among a group of resources on a network by employing multicast and anycast transmissions. In one embodiment, the group of resources may include nodes or other resources of a blockchain network that implement all or part of a particular blockchain protocol (e.g., the Bitcoin SV protocol). These embodiments may be configured to minimize network latency between resources to improve the computational efficiency of the resources.

[0127] Item 1a: In one possible form of expression, such an embodiment may be: associating a first group of resources with an anycast group having a particular anycast address; transmitting an initial message from a transmission resource to a particular multicast address, the initial message including: i) a particular anycast address for an anycast group; and ii) data related to one or more tasks or processing requests; In response to receiving the initial message, at least one resource belonging to the multicast group sends a response message to a specific anycast address corresponding to the anycast group, the response message communicating acceptance of one or more tasks or processing requests associated with the initial message.

[0128] A multicast address corresponds to a multicast group (of computing resources) associated with a particular multicast address. The method may further include associating the second group of resources with a multicast group having a particular multicast address, which may include each member (i.e., resource) of the second group of resources subscribing to the multicast address. In other words, each member of the second group of resources joins the multicast group associated with the multicast address.

[0129] Accepting one or more tasks or processing requests may include communicating an ability, willingness, or intention to perform or fulfill one or more tasks or processing requests associated with the initial message. The initial message may include one or more of a description of at least one task or process to be performed, a payment or remuneration associated with performing the task or process, data, values, parameters, and / or metadata related to the task / process. The acceptance may include a request for further data related to at least one task or process.

[0130] Item 1b: In an alternative or additional form of expression, such an embodiment may be The method may include one, some, or all of the steps of: transmitting data (e.g., at least one data packet) from one or more transmitting resources to one or more receiving resources over an electronic network, where the one or more receiving resources are members of a multicast group associated with a particular multicast address, and in addition, one or more of the transmitting resources may be members of an anycast group associated with a particular anycast address.

[0131] Item 1c: In an alternative or additional form of expression, such an embodiment may be: By receiving resources that are members of a multicast group, i) transmitted from a transmission resource to a multicast address associated with a multicast group; ii) receiving an initial message including: a) an anycast address corresponding to an anycast group; and b) data related to one or more tasks or processing requests; The method may include one, some, or all of the steps of: sending, by the receiving resource, a response message to the anycast address in response to receiving the initial message, the response message communicating and / or including acceptance of one or more tasks or processing requests included in the initial message.

[0132] Any feature provided with respect to any of items 1a, 1b, and 1c may be used with respect to any of the other representations of item 1. In other words, the features in 1a, 1b, and 1c may be used interchangeably between representations of item 1. The following items may be derived from any representation of item 1 presented above.

[0133] 2. 2.1 Associating a first group of resources with an anycast group having a particular anycast address; and / or 2.2 Associating a second group of resources with a multicast group having a specific multicast address; and / or 2.3 transmitting an initial message (i.e., one or more data packets) from a transmission resource to a specific multicast address corresponding to a multicast group, where the transmission resource may or may not belong to the anycast group, the initial message including: i) the specific anycast address for the anycast group, and ii) data related to one or more tasks or processing requests; 2.4 The method of item 1, further comprising at least one of routing the initial message to each resource in the multicast group.

[0134] 3. The method of any one of items 1, 2.1, 2.2, 2.3, and 2.4, further comprising at least one resource (receiving resource) belonging to the multicast group sending a response message (e.g., at least one data packet) to a specific anycast address corresponding to the anycast group in response to receiving the data (i.e., the initial message), the response message conveying an intent or willingness to perform or fulfill one or more tasks or processing requests related to the received data (i.e., the initial message).

[0135] 4. 4.1 routing the response message to one resource in the anycast group that is topologically closest to the resource in the multicast group that sent this response message, and / or 4.2 in response to receiving the response message, at least one resource in the anycast group determines which resource in the multicast group (the receiving resource) that sent the response message is topologically closest to the resource in the anycast group; and / or 4.3 The resource in the anycast group uses a route discovery utility to determine which resource in the multicast group that sent the response message is topologically closest to the resource in use in the anycast group, and / or 4.4 enabling at least one resource of the anycast group to perform one or more tasks or processing requests related to the initial message and the response message in cooperation with such topologically closest resource (receiving resource) of the multicast group; and / or 4.5 The method of claim 3, further comprising at least one of: configuring at least one resource (receiving resource) of the multicast group to decide not to respond to the initial message if it is busy or unable to perform or fulfill one or more tasks or processing requests associated with the initial message based on some criteria; and / or configuring at least one resource (receiving resource) of the multicast group to decide not to respond to the initial message if it is not willing to perform or fulfill one or more tasks or processing requests associated with the initial message based on other criteria.

[0136] According to an additional or alternative form of expression, the method may include: determining, by each respective member of the anycast group, which responding member of the multicast group is topologically closest to it ("it" being each respective member of the anycast group); and / or This may include determining, based on the determinations made by all respective members of the anycast group, which of the receiving resources that sent the response message is topologically closest to the member of the anycast group. In other words, based on the determinations made by the individual members of the anycast group, the shortest route between the anycast group member and the responding multicast group member is determined. The topologically closest multicast group member is thus identified and becomes the resource with which the nearest anycast group member continues to communicate and cooperate in order to accomplish the task in the fastest and most efficient manner.

[0137] 5. The method of any one of paragraphs 1, 2.1, 2.2, 2.3 and 2.4, 3, 4.1, 4.2, 4.3, 4.4, and 4.5, wherein the first group and / or second group of resources can include resources that validate one or more blockchain transactions, a miner pool or set of proof-of-work computation resources, resources that create blocks of transactions using proof-of-work or proof-of-stake consensus, or resources that process data in some manner for blockchain and / or cryptocurrency-related purposes.

[0138] 6. The method of any one of paragraphs 1, 2.1, 2.2, 2.3 and 2.4, 3, 4.1, 4.2, 4.3, 4.4, 4.5, and 5, wherein the one or more tasks or processing requests relate to blockchain transactions, blockchain blocks, or other blockchain-related data.

[0139] 7. One or more tasks or processing requests may be: - Validating one or more blockchain transactions; - mining blocks of transactions using proof-of-work computational resources; - Creating blocks of transactions using a proof-of-stake consensus mechanism; - Instant payment verification, or - The methods described in any one of paragraphs 1, 2.1, 2.2, 2.3 and 2.4, 3, 4.1, 4.2, 4.3, 4.4, 4.5, 5 and 6 relating to processing data in any way for blockchain and / or cryptocurrency related purposes.

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

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

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

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

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

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

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

[0147] Item 3.13. A method comprising: i) the communication is transmitted from a transmission 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.

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

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

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

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

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

[0153]

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

[0154] Transmitting at least one data packet from one or more transmission resources to one or more receiving resources over an electronic network. One or more resources may be members of a multicast group. In other words, they may be subscribers to a common (shared) multicast address. Additionally or alternatively, one or more of the receiving resources may be associated with a shared anycast address, and in some cases, one or more transmission resources may also be associated with a shared multicast and / or anycast address, and at least one data packet may be transmitted to the shared multicast address. At least one data packet may be received by at least one of the receiving resources. This method is - determining by the at least one reception resource and upon reception of the at least one data packet whether at least one further data packet should (or is needed) be received by the at least one reception resource; - transmitting a request for at least one further data packet from the at least one receiving resource to the at least one further resource, preferably - at least one further resource is a member of a multicast group, and / or - at least one further resource is a member of an anycast group, and / or - determining whether the request is to be transmitted using multicast transmission, anycast transmission, or unicast transmission; - receiving a request for at least one further data packet from the at least one receiving resource by the at least one further resource; - transmitting at least one further data packet from the at least one further resource to the at least one receiving resource, preferably wherein the at least one data packet is transmitted to the at least one receiving resource using unicast transmission.

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

[0156] Item 5.1. A method comprising: transmitting a request from a (requesting) sending resource that is a member of a resource group to at least one further resource that is a member of the resource group, preferably i) the request includes a request for one or more packets of data; and / or ii) the request is sent as a result of incomplete reception of a data transmission sent to the transmission resource, preferably the incomplete data transmission having been sent to the transmission resource and / or at least one further resource via or by a multicast transmission sent to a resource group; and / or iii) the request is sent as an arbitrary anycast transmission to the (topologically) closest resource in the resource group in terms of transmission resources, and / or iv) the request is sent as an optional multicast transmission to the (topologically) closest resource in the resource group, and / or v) The method, wherein the request is transmitted as a result of incomplete reception (by the transmission resource) of a data transmission transmitted (by the data transmission resource) to the (requesting) transmission resource, and preferably the request includes a request for at least one portion (e.g., packet) of data that the (requesting) transmission resource failed to receive as a result of the incomplete reception of the data transmission. Item 5.2. The transmission resource and / or at least one further resource is a node on a blockchain network, and / or Digital wallets or digital wallet providers, and / or Cryptocurrency exchanges or components thereof; and / or Resources associated with or communicating 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 a resource arranged and configured to perform SPV verification, facilitate SPV verification, or use the results of SPV verification, which may include software operable to perform or facilitate a simplified payment verification (SPV) operation or process the results of an SPV operation; The method according to item 5.1, which is or comprises: 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0170] 8.1 A method comprising: sending a transmission from a Multicast Listener Device (MLD) snooping-enabled transmission resource over an electronic network to a multicast address; 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.

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

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

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

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

[0175] Item 9.1. A computer-implemented method, the method including: operating a sending and / or receiving resource to generate, store, process, access, and / or maintain packets of data, the packets of data preferably including blockchain-related data; determining an assigned address from the packets of data; and sending, at least in part, a transmission of the packets of data from the sending resource over an electronic network to the assigned address.

[0176] Additionally or alternatively, according to an alternative form of expression, embodiments of the present disclosure may provide a method for balancing transmissions of records of data within a network. The method may include using and / or providing resources for handling (e.g., generating, storing, processing, accessing, and / or maintaining) the records of data. The method may include determining an assigned address of the record by parsing / processing the record. The assigned address may correspond to a group of one or more resources, and the resources may subscribe and unsubscribe to the group. The transmission of the record may be sent from the resource to the assigned address. The assigned address may be determined from a designated portion of the data. The designated portion of the data may be part of a blockchain transaction or blockchain block. The designated portion of the data may be data or may include some or all of a transaction ID, a blockchain block ID, or part of metadata in a transaction output, etc. A predetermined number of digits from the designated portion of the data may be used as a means to identify a recipient, e.g., a machine processing the data record. The data may be transmitted over a network to a receiving resource or group of resources having an address corresponding to the designated portion of the data. For example, a data record containing a TX ID or metadata that includes the 8-bit pattern 01101110 (e.g., starts with, ends with, or includes 01101110) will be transmitted to a machine or group of machines identified by an address or identifier that includes 01101110.

[0177] Item 9.2. The method of Item 9.1, wherein the assigned address is a multicast address associated with a group of receiving resources. Section 9.3. The record includes at least one of a portion of a transaction (Tx), an output identifier, a hash of a script, a transaction identification (TXID), a blockchain block, and a block header. The output identifier may be an identifier associated with an output in the blockchain transaction (Tx). For example, it may be a UTXO identifier. The hash of the script may be a hash of a script (e.g., a UTXO script) associated with the output of the transaction (Tx). The method of any one of Sections 9.1 and 9.2. Item 9.4. The method of any one of items 9.1 to 9.3, wherein determining the assigned address includes processing the packet of data to determine a key and selecting at least one address from the set of addresses using the key, the processing preferably including parsing the packet of data. Section 9.5. The method of any one of sections 9.1 to 9.4, wherein the sending resource maintains, provides, or includes a data structure including a set of assigned addresses associated with a corresponding set of keys. Section 9.6. The method of any one of Sections 9.1 through 9.5, wherein the sending resource generates, stores, processes, accesses, and / or maintains (blockchain) blocks (of zero or more blockchain transactions) that include multiple packets of data, each of the packets of data in the block including blockchain-related data.

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

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

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

[0181] If the receiving resource is a vehicle or drone, the data may include or be one or more of traffic-related data, maps or geographic data, instructions to operate, control, command or influence the vehicle / drone or its behavior, alerts or notifications, music, video and / or voice communications such as messages and phone calls.

[0182] Item 10.19. A computing device comprising: a memory including one or more memory units; and a processing device including one or more processing units, the memory storing code configured to execute on the processing device, the code configured to execute the method of any one of items 10.1 to 10.18 when on the processing device. The computing device may include or form part of a vehicle or drone. Item 10.20. A computer program embodied on computer-readable storage and configured to, when executed on one or more processors, perform the method of any one of items 10.1 to 10.18.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0211] 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 transactions 152 for propagation throughout the blockchain network 106. Transaction protocols and node protocols correspond to one another; a given transaction protocol goes hand in hand 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0250] 1 node 2 nodes 5 nodes 100 systems 101 Packet Switched Network 102 Computer terminals and computer equipment 102a, 120b Computer equipment 103 Users, Parties, and Agents 103a User, first participant, Alice 103b New User or Entity, Second Party, Bob 104 full blockchain nodes, Bitcoin nodes, full mining nodes 105 Client Applications 105a Client Applications 105b Client 106 Peer-to-Peer (P2P) Networks 107 Side Channel 150 Blockchain 151 Blocks of Data 151n-1 Block 151n Block 152 transactions 152i Transactions 152j Transaction 153 Genesis Block (Gb) 154 Pool, Ordered Set 155 Block Pointer 201 Header 202 Input, input field 203 Output, Output Field 301 Side Channel 401 Transaction Engine 402 User Interface (UI) Layer 450 Node Software 451 Protocol Engine 452 Script Engine 453 stack 454 Application Level Decision Engine 455 Blockchain-related functional modules 455C Consensus Module 455P Propagation Module 455S Storage Module 500 User Interface (UI) 501 Network 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. associating a first group of resources with an anycast group having a particular anycast address; associating a second group of resources with a multicast group having a particular multicast address; transmitting an initial message from a transmission resource to the particular multicast address, the initial message including: i) the particular anycast address for the anycast group; and ii) data related to one or more tasks or processing requests; In response to receiving the initial message, at least one resource belonging to the multicast group sends a response message to the particular anycast address, the response message communicating acceptance of the one or more tasks or processing requests; A method comprising:

2. The method of claim 1 , wherein the transmission resource belongs to the anycast group.

3. i) the initial message is routed to each resource in the multicast group; and / or ii) The method according to claim 1 or claim 2, wherein the multicast address is an IPv6 multicast address.

4. 4. The method according to claim 1, wherein the response message is routed to one resource of the anycast group that is topologically closest to the resource of the multicast group that sent the response message.

5. 5. The method of claim 1, further comprising: in response to receiving a response message, determining which resource of the multicast group from which at least one resource of the anycast group sent a response message is topologically closest to the resource of the anycast group.

6. The step of determining which resource of the multicast group that sent the response message is topologically closest to the resource of the anycast group includes: i) using a route-finding utility; and / or ii) repeated with each resource in the first group of resources.

7. 6. The method of claim 5, further comprising the step of the at least one resource of the anycast group coordinating with such topologically closest resource to perform the one or more tasks or processing requests associated with the initial message and / or response message.

8. deciding not to respond to the initial message if at least one resource of the multicast group is busy or unable to perform or fulfill the one or more tasks or processing requests associated with the initial message based on some criteria; or 8. The method of claim 1, further comprising: deciding not to respond to the initial message if at least one resource of the multicast group is unwilling or unable to perform or fulfill the one or more tasks or processing requests associated with the initial message based on other criteria.

9. 9. The method of any one of claims 1 to 8, wherein the first group of resources and / or the second group of resources comprise resources that validate one or more blockchain transactions, a miner pool or set of proof-of-work computation resources, resources that create blocks of transactions using proof-of-stake consensus, or resources that process data in some manner for blockchain and / or cryptocurrency related purposes.

10. 10. The method of claim 1, wherein the one or more tasks or processes relate to blockchain transactions, blockchain blocks, or other blockchain-related data.

11. 11. The method of any one of claims 1 to 10, wherein the one or more tasks or processes relate to validating one or more blockchain transactions, mining a block of transactions using proof-of-work computational resources, creating a block of transactions using a proof-of-stake consensus mechanism, simplified payment verification, or processing data in any way for blockchain and / or cryptocurrency related purposes.

12. a memory including one or more memory units; a processing device including one or more processing units, the memory storing code configured to run on the processing device, the code configured to perform at least part of the method of any one of claims 1 to 11 when present on the processing device; A computer device comprising:

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

Images