Blockchain development topics (how Bitcoin networks are structured) __ Blockchain

Blockchain Enthusiast (qq:53016353)

The blockchain uses an Internet-based (Internet)-on-Peer (peer-to-peer) network architecture. Peer to peer refers to each computer located in the same network is equal to each other, each node provides network services together, there is no "special" node. Each network node is connected with a "flat (flat)" topology. There is no service-side (server), centralized service, and hierarchy in the peer-to network. Inter-peer network nodes interact and work together: each node provides services externally while also using services provided by other nodes in the network. The network is also reliable, centralized, and open-ended. The early Internet is one of the typical use cases of peer-to network architectures: Each node in the IP network is completely equal. Today's Internet architecture has a layered architecture, but the IP protocol still retains the structure of a flat topology. Beyond the blockchain, the largest and most successful peer-to technology application is in the area of file sharing: Napster is a pioneer in this field, and BitTorrent is the latest evolution of its architecture. The same-peer network architecture used in blockchain is more than simply choosing a topology. Blockchain is designed as a point-to-point digital cash system whose network architecture is both a reflection of this core feature and the cornerstone of this feature. Centralized control is the core principle of design, and it can only be achieved by maintaining a flat, centralized peer-to consensus network.
A "Blockchain Network" is a collection of nodes that are run according to the blockchain-to-peer protocol. In addition to the blockchain-to-peer protocol, other protocols are included in the blockchain network. For example, the stratum protocol is used in mining, as well as in lightweight or mobile blockchain wallets. Gateway routing servers provide these protocols, use blockchain-to-peer protocols to access the blockchain network, and extend the network to individual nodes running other protocols. For example, the stratum server connects all stratum mining nodes to the blockchain master network through the stratum protocol, and bridges the stratum protocol to the blockchain-to-peer protocol. We use the extended Blockchain network (extended Bitcoin networks) to refer to all the overall network structures that contain blockchain-to-peer protocols, mining pool mining protocols, stratum protocols, and other protocols that link blockchain system components.
6.2 Node types and division of labor
Although each node in a blockchain peer-to-peer network is mutually equivalent, each node may have a different division of labor depending on the functionality provided. Each blockchain node is a collection of functions for routing, blockchain databases, mining, and wallet services. A full node includes four features as shown in Figure 6-1:

Figure 6-1 A blockchain network node with four full functions: wallet, Miner, full blockchain, network routing node
Each node participates in a network-wide routing feature and may also contain additional functionality. Each node participates in the validation and propagation of transaction and chunk information, discovering and maintaining a connection to the peer node. In the full-node use case shown in Figure 6-1, the Orange circle named "Network Routing node" represents the routing feature.
Some nodes maintain a complete, up-to-date blockchain copy, which is called a "full node." The full node can independently validate all transactions without the need for any external references. In addition, some nodes retain only part of the blockchain, and they complete the transaction verification in a way called "Simple payment Verification (SPV)". Such nodes are called "SPV nodes", also called "Lightweight Nodes". In the full-node use case shown in the figure above, the blue circle called the full blockchain represents the full-node blockchain database function. In Figure 6-3, the SPV nodes do not have this blue circle to show that they do not have a full copy of the blockchain.
Mining nodes create new chunks in a competitive way by using a proof of effort (Proof-of-work) algorithm that runs on special hardware devices. Some mining nodes are also full-node, maintaining a full copy of the blockchain; some of the nodes that are involved in mine pool mining are lightweight nodes that have to rely on the full-node maintenance of the pool server to work. In the full-node use case, the mining function is shown in the black circle named "Miner" in the figure.
User wallets can also be part of a full node, which is common in desktop blockchain clients. At present, more and more user wallets are SPV nodes, especially the blockchain wallet applications running on resource-constrained devices such as smartphones, which are becoming more and more common. In Figure 6-1, the green circle named Wallet represents the wallet function.
In the blockchain-to-peer protocol, in addition to these major node types, some servers and nodes are also running other protocols, such as special mining Pool Mining Protocol, lightweight Client access protocol.
Figure 6-2 depicts the most common node types in an extended blockchain network.

Figure 6-2 Different node types for extended blockchain networks
6.3 Extending the Blockchain network
The Blockchain master network running the blockchain-to-peer protocol consists of about 7000-10000 monitoring nodes running different versions of the Blockchain core client (Bitcoin Core), and hundreds of applications running various blockchain-to-peer protocols (such as Bitcoinj, Libbitcoin, BTCD, etc.) are composed of nodes. A small subset of nodes in a blockchain is also a mining node that competes for mining, validates transactions, and creates new chunks. Many large companies connected to the blockchain network run a full-node client based on the Bitcoin core client, which has a full copy of the Blockchain and network nodes, but does not have mining and wallet functions. These nodes are edge routers in the network, through which they can build other services such as exchanges, wallets, block browsers, merchant payment processing (merchant payment processing), and so on.
As mentioned earlier, the extended blockchain network includes both the network that runs the blockchain-to-peer protocol and the network node that runs the special protocol. Many pool servers and protocol gateways are attached to the blockchain-to-peer network, which connects nodes that run other protocols. These nodes are usually mining pool mining nodes (see Chapter 8th) and lightweight wallet clients, which typically do not have a full blockchain backup.
Figure 6-3 depicts the extended blockchain network, which includes various types of nodes, gateway servers, edge routers, wallet clients, and the kinds of protocols they need to connect to each other.


Figure 6-3 Extended blockchain network with multiple node types, gateways, and protocols
6.4 Network Discovery
When a new network node is started, it must discover other blockchain nodes in the network in order to be able to participate in the cooperative operation. The new network node must discover the nodes that exist in at least one network and establish a connection. Because the topological structure of the blockchain network is not based on the geographic location between nodes, the geographic information between the nodes is completely irrelevant. When a new node is connected, it is possible to randomly select a blockchain node that exists in the network to connect to it.
Nodes typically use the TCP protocol, using port 8333 (the port number is typically used by the blockchain, except 8333 ports can also be specified using a different port) to establish a connection with a known peer node. When a connection is established, the node begins a "handshake" communication process by sending a version message containing the Basic authentication content (see Figure 6-4). This process includes the following:
▷protocol_version
Constants that define the version of the blockchain-to-peer protocol that the client "speaks" (for example: 70002).
▷nlocalservices
A list of local services supported by this node, currently supported only for Node_network
▷ntime
Current time
▷addryou
The IP address of the remote node visible to the current node
▷addrme
Native IP address discovered by local node
▷subver
A child version number indicating the type of software that the current node is running (for example: "/SATOSHI:0.9.2.1/")
▷baseheight
Block height of the current node block chain
(For specific use cases of version network messages, see GitHub)
The peer node in the network confirms the response to the Verack message and establishes a connection; sometimes, if the receiving node needs to interchange the connection and connect back to the starting node, it will also return the version message of that peer.
How the new node discovers the peer node in the network. Although there are no special nodes in the blockchain network, the client maintains a list of nodes that have long-running stability. Such a node is called a seed node (nodes). The new node does not necessarily need to establish a connection to the seed node, but the benefit of connecting to the seed node is that the seed node can be used to quickly discover other nodes in the network. In the blockchain core client, the use of seed nodes is controlled by "-dnsseed". By default, this option is set to 1, which means that the seed node is used. Alternatively, at the beginning, the IP address of at least one blockchain node is provided to the node that is being started (the node does not contain any of the blockchain network's constituent information). After that, the boot node can establish a new connection through subsequent instructions. The user can use the command line parameter "-seednode" to "referral" the boot node and connect to a node and use that node as a DNS seed. After the initial seed node is used to form the "referral" information, the client disconnects from it and communicates with the newly discovered peer node.

Figure 6-4 Initial "handshake" communication between peer nodes
When one or more connections are established, the new node sends a addr message with its own IP address to its neighboring nodes. The adjacent nodes then forwards this addr message to their respective neighboring nodes, which ensures that the new node information is received by multiple nodes and the connection is more stable. In addition, a newly-accessed node can send a GETADDR message to its neighboring nodes, requiring them to return a list of IP addresses of their known peer nodes. In this way, the node can find the peer node to which it needs to connect and publish its messages to the network for other nodes to find. Figure 6-5 depicts this address Discovery protocol.

Figure 6-5 Address broadcast and discovery
A node must be connected to several different peer nodes to establish a variety of paths (path) to the blockchain network in a blockchain network. Because nodes can join and leave at any time, the communication path is unreliable. Therefore, the node must continue to work on two tasks: Discovering a new node when it loses an existing connection, and providing it with help when the other node starts. A node only needs a connection when it starts, because the first node can refer it to its peer node, which in turn provides referrals. A node, if connected to a large number of other peer nodes, this is neither necessary, but also a waste of network resources. When the boot is complete, the node remembers the peer node that it recently successfully connected to, so when it restarts it can quickly reconnect to the previous peer node network. If the peer node of the previous network does not answer the connection request, the node can use the seed node to restart.
On the node running the Blockchain core client, you can use the Getpeerinfo command to list peer node connection information:
$ bitcoin-cli getpeerinfo[   {        "addr": "85.213.199.39:8333",         "Services": "00000001",         "lastsend": 1405634126,         "LASTRECV": 1405634127,         "bytessent": 23487651,         "BYTESRECV": 138679099,         "Conntime": 1405021768,         "Pingtime": 0.00000000,       &NB SP; " Version ": 70002,        " Subver ":"/SATOSHI:0.9.2.1/",        " Inbound ": false,         "startingheight": 310131,         "Banscore": 0,       &NB SP; " Syncnode ": True    },    {       " addr ":" 58.23.244.20:8333 ",     &NB Sp   "Services": "00000001",         "lastsend": 1405634127,         "LASTRECV": 1405634124,         "bytessent": 4460918,         "BYTESRECV": 8903575,         "Conntime": 1405559628,         "Pingtime": 0.00000000,         "version": 70001,         "Subver": "/satoshi:0.8.6/",         "Inbound": false,   &NBSP ;     "Startingheight": 311074,         "Banscore": 0,         "Syncnode": False    }]
Users can specify one or more IP addresses by providing the-connect= option to replicate the Automatic node management feature and specify the purpose of the IP address list. With this option, nodes connect only to these selected node IP addresses and do not automatically discover and maintain connections between peer nodes.
If an established connection does not have data traffic, the node on which it is located periodically sends information to maintain the connection. If a node persists for 90 minutes without any communication, it is considered to have been disconnected from the network and the network will start looking for a new peer node. Therefore, the blockchain network will be dynamically adjusted according to the changing nodes and network problems, without the need of centralized control to make the organic adjustment of scale increase and decrease.
6.5 Full Node
A full node is a node that maintains a complete blockchain that contains all the transaction information. More precisely, such a node should be called the full blockchain node. In the early stages of blockchain development, all nodes are full nodes, and the current blockchain core client is also the complete blockchain node. But in the past two years there have been many new clients that do not need to maintain a full blockchain, but rather run as a lightweight client. We'll cover these lightweight clients in more detail in the following sections.
The full Blockchain node maintains a complete, up-to-date block chain copy of all trading information, which can be independently built and validated, from the first block (Genesis Block) to the newest chunk in the network. The full blockchain node can independently verify any transaction information without resorting to any other node or other source of information. The full chunk node obtains a new chunk update containing the transaction information through the blockchain network and merges the update into the local blockchain copy after validation is correct.
Running a full blockchain node gives you a pure blockchain experience: All transaction information can be verified independently, without the need or trust of other systems. It's easy to tell if you're running a full node: just see if your permanent storage device (such as a hard disk) has more than 20GB of space to store the full blockchain. If you need a lot of disk space and a 2-3-day synchronization of the blockchain network, you're using the full node. This is the price to be paid to get rid of the centrality of management and to gain complete independent freedom.
Although there are some other full blockchain clients that use different programming languages and software architectures, the most common is still the blockchain core client, which is also known as the "Satoshi client". More than 90% of the nodes in the Blockchain network run various versions of the blockchain core client. As mentioned earlier, it can be identified by a version message sent between nodes, or by a "Satoshi" of the substring of the getpeerinfo command, such as/satoshi:0.8.6/.
6.6 Exchange "Inventory List"
Once a full node is connected to a peer node, the first thing to do is to build a complete blockchain. If the node is a new node, it does not contain any blockchain information, it knows only one chunk-the creation block statically implanted in the client software. The new node needs to download the entire contents of block hundreds of thousands of from block No. 0 (Genesis block) to synchronize with the network and rebuild the whole blockchain.
The process of synchronizing a blockchain starts with sending a version message because the Bestheight field contained in the message indicates the current blockchain height (number of chunks) for a node. A node can get version messages from its peer node to see how many chunks each side has, so that it can compare to the number of chunks owned by its own blockchain. Peer nodes exchange a getblocks message that contains the hash of the top chunk of their local blockchain. If a peer recognizes that the hash value it receives does not belong to the top chunk, but rather belongs to an old chunk of a non-top chunk, it can infer that its own local blockchain is longer than the blockchain of the other peers.
Peers with longer blockchain have more chunks than other nodes, and can identify which chunks are "complementary" to other nodes. It identifies the first 500 chunks that can be shared, propagating the hashes of these chunks by using Inv (inventory) messages. Nodes that are missing these chunks can request full block information through their respective GetData messages, and use the hash value contained in the Inv message to confirm that they are the correct requested chunk to read the missing chunks.
In the following example, we assume that a node contains only the Genesis block. It receives an INV message from the peer node, which contains the hashes of the latter 500 chunks in the blockchain. It then begins to request chunks to all of the peers that are connected to it and prevents a single peer node from being overwhelmed by the bulk request by allocating the workload. The node tracks the number of chunks that are "transmitting" on each peer node connection (that is, those that it has made a request but has not received), and checks that the number has exceeded the upper limit (max_blocks_in_transit_per_peer). In this way, if a node needs to update a large number of chunks, it will send a request for a new chunk after the last request has been completed, allowing the peer node to control the update speed and not overwhelm the network. Each chunk is added to the blockchain after it is received, as described in the 7th chapter. As the local blockchain is gradually established, more and more chunks are requested and received, and the entire process continues until the node is synchronized with the full network.
Whenever a node is offline, regardless of how long the offline time is, the process of comparing the local blockchain to the peer node and recovering the missing chunks is triggered. If a node is only offline for a few minutes, only a few chunks may be missing, and when it is offline for up to one months, thousands of chunks may be missing. In either case, it will start with sending a getblocks message, receive an inv response, and then start downloading the missing chunk inventory and block broadcast protocol as shown in Figure 6-6.

Figure 6-6 The node synchronizes the blockchain by reading chunks from the peer node
6.7 Simple Payment verification (SPV) node
Not all nodes have the ability to store full blockchain. Many blockchain clients are designed to run on space-and power-constrained devices such as smartphones, tablets, embedded systems, and so on. For such devices, the simplified payment verification (SPV) approach allows them to work without having to store a full blockchain. This type of guest is called a SPV client or a lightweight client. With the boom in the use of blockchain, the SPV node becomes the most common form of blockchain node (especially blockchain wallet).
The SPV node simply downloads the chunk header without downloading the transaction information contained in each chunk. The resulting blockchain, which does not contain transaction information, is only 1/1000 of the total blockchain size. SPV nodes cannot build the full picture of all the utxo that can be consumed, because they do not know the complete information of all transactions on the network. The method used by the SPV node to verify the transaction is slightly different, which relies on the peer node "on demand" to provide a partial view of the relevant part of the blockchain.
For example, each full node is like a tourist in a strange city, with a detailed map of every street and address. In contrast, the SPV node is like a tourist in this strange city who knows only the name of a main road, and randomly asks strangers in the city to get a sectional road indication. Although both visitors can verify the existence of a street through field trips, visitors without a map do not know which streets are in each alley and what other streets are nearby. Visitors without a map in front of "Church Street 23rd" do not know whether there are several other "Church Street 23rd" in the city, or whether this is the one you are looking for. The best way for him to do that is to ask enough people for directions and hope that some of them are not trying to rob him.
Simple payment validation is verified by referencing the depth of the transaction in the blockchain, rather than the height. A node with a full blockchain constructs a validation chain that is composed of thousands of blocks and transactions that follow the block chain in reverse chronological order, all the way back to the Genesis block. A SPV node verifies the chain of all blocks (but not all trades) and links the blockchain to the relevant transaction.
For example, a full node checks for a transaction in block No. 300, number No. 000, and it links all 300,000 blocks from that block to the creation block, and establishes a complete Utxo database to verify the validity of the transaction by confirming whether the Utxo has not yet been paid. The SPV node cannot verify whether the Utxo has not yet been paid. Instead, the SPV node establishes a link between the transaction information and its block using the Merkle path (see "7.7 Merkle Tree"). The SPV node then waits until six blocks of the ordinal number from 300,001 to 300,006 are stacked on top of the block of the exchange and verify the validity of the transaction by establishing the depth of the transaction under section 300,006-section 300,001. In fact, if the other nodes in the network accept block 300,000, and through enough work on the block and generate six more chunks, according to the Proxy gateway protocol, you can prove that the transaction is not a double payment.
If a transaction does not actually exist, the SPV node will not mistakenly assume that the transaction exists in a block. The SPV node confirms the existence of the transaction by requesting Merkle path proof and verifying the proof of work in the blockchain. However, the existence of a transaction is likely to "hide" the SPV node. The SPV node can no doubt confirm the existence of a transaction, but it cannot verify that a transaction (such as a double payment of the same utxo) does not exist because the SPV node does not have a record of all transactions. This vulnerability could be exploited by a denial-of-service attack or a dual-payment attack on a SPV node. To protect against these attacks, the SPV node needs to be randomly connected to multiple nodes to increase the probability of connecting with at least one reliable node. The requirement of this random connection means that the SPV node is also vulnerable to network partition attack or Sybil attack. In the latter case, the SPV node is connected to a false node or a false network, and there is no connection to a reliable node or a true blockchain network.
In the vast majority of practical situations, a well-connected SPV node is safe enough to maintain a proper balance between resource requirements, practicality and security. Of course, if you want to ensure foolproof security, the most reliable method is to run the full blockchain node.

The complete blockchain node is verified by checking the entire chain of thousands of blocks underneath it to ensure that the utxo is not paid. The SPV node verifies the transaction by checking the block above it and pressing it below the depth.
The SPV node uses a getheaders message instead of a getblocks message to get the chunk header. The peer node that responds will send up to 2000 chunk headers with a single headers message. This process is no different from the process of getting all the chunks in the whole node. The SPV node also sets a filter on the connection to the peer node to filter future chunks and transaction traffic from the peer node. Any target transaction is read by a GetData request. The peer node generates a TX message containing the transaction information as a response. The synchronization process for the chunk header is shown in Figure 6-7.

Figure 6-7 SPV node synchronization block head
Because the SPV node needs to read a specific transaction to selectively validate transactions, this creates a privacy risk. Unlike the full blockchain node that collects all the exchanges within each chunk, the SPV node's request for specific data may inadvertently reveal the address information in the wallet. For example, a third party monitoring the network can track all the transaction information requested by the wallet on a SPV node and use the transaction information to correlate the blockchain address with the user of the wallet, thereby compromising the user's privacy.
Shortly after the introduction of the SPV Node/lightweight node, the blockchain developer added a new feature: Bloom filter to address the privacy risk of SPV nodes. The Bloom filter allows the SPV node to receive only a subset of the transaction information through a filtering mechanism that employs a probability rather than a fixed pattern, and does not accurately disclose which addresses are of interest to them.
6.8 Bloom Filter
Bloom filter is a probability-based filtering method that allows users to describe a particular combination of keywords without having to be accurately expressed. It allows users to effectively search for keywords while protecting their privacy. In the SPV node, this method is used to send the transaction information query request to the peer node, and the transaction address will not be exposed.
In our previous example, a visitor with no map in hand needs to ask for directions to a particular place. If he asks a stranger, "where is 23rd Chapel Street", inadvertently, he exposes his destination. The Bloom filter asks, is there a street with a ' don ' in the vicinity? "Such a question contains a slightly smaller number of keywords than before. The visitor can choose how much information to include, such as "Street End" or "teaching" the beginning of the word. If he asks for less, gets more potential addresses, privacy is protected, but there are no unrelated results in the addresses, and if he asks very specifically, he has a more accurate result and exposes his privacy.
The Bloom filter allows the SPV node to specify the search mode for the transaction, which can be adjusted based on accuracy or privacy considerations. A very specific Bloom filter produces more accurate results, but it also displays the address used in the user's wallet, whereas if the filter contains only simple keywords, more of the corresponding transactions are searched, with a higher level of privacy in addition to a number of unrelated trades.
First, the SPV node Initializes a "blank" bloom filter that does not match any of the keywords. Next, the SPV node creates a list that contains all the address information in the wallet and creates a search pattern that matches the trade output of each address. Typically, this search pattern is a hash script that pays to the public key, which is a locking script that appears in each transaction that is paid to the public key hash address. If the SPV node needs to track the P2sh address balance, the search mode becomes the P2sh script. Then, the SPV node will add each search mode to the Bloom filter, so as long as the keyword appears in the transaction can be recognized by the filter. Finally, the peer node uses the received Bloom filter to match the transaction that is sent to the SPV node.
The implementation of the Bloom filter consists of a variable-length (n) binary array (n-bit binary number constituting a bit field) and a set of variable (M) hash functions. The output values of these hash functions are always between 1 and N, which corresponds to a binary array. And the function is deterministic, which means that any node that uses the same bloom filter can get the same result for a particular input through that function. The accuracy and privacy of the bloom filter is adjusted by varying the length (N) and the number of hash functions (M).
In Figure 6-8, we demonstrate the application principle of the Bloom filter using a small 16-bit array and three hash functions.


Figure 6-8 A simple bloom filter consisting of a 16-bit array and three hash functions
The initial value of each number in the Bloom filter array is zero. Keywords are added to the Bloom filter, and each hash function is sequentially calculated once. The input is calculated by the first hash function, and a number between 1 and N is obtained, which is set to 1 for the corresponding bit in the array (numbered 1 to N), and the output of the hash function is recorded. Then the next operation of the hash function, the other position is 1; When all m hash functions have been evaluated, the value of M bits has changed from 0 to 1, and this keyword has been "recorded" in the Bloom filter.
Figure 6-9 shows the Add keyword "A" to the simple Bloom filter in Figure 6-8.


Figure 6-9 Adding the keyword "A" to the simple Bloom filter
Adding a second key is simply repeating the previous steps. After the key words are calculated by each hash function, the corresponding bit becomes the 1,bloom filter and the keyword is recorded. It is important to note that when the keyword in the Bloom filter is incremented, the bit of the output value of one of its corresponding hash functions may already be 1, in which case the bit will not change again. That is, as more keywords point to duplicate bits, the bloom filter is saturated with a bit 1 increase, thus reducing the accuracy. This filter is based on probabilistic data structures, because the increase in keywords leads to lower accuracy. Accuracy depends on the number of keywords and the size of the array (N) and the number of hash functions (M). Larger arrays and more hash functions record more keywords to improve accuracy. Small arrays and limited hash functions can only record limited keywords to reduce accuracy.
Figure 6-10 shows the addition of the second keyword "B" to the simple Bloom filter.


Figure 6-10 Adding a second keyword "B" to the simple Bloom filter
To test whether a keyword is recorded in a bloom filter, we operate the keyword one-by-one into each hash function and compare the resulting result with the original array. If all the corresponding bits of the result are changed to 1, then it is possible that the keyword has been recorded by the filter. This conclusion is not certain because these byte 1 may also be overlapping results of other keyword operations. Simply put, the bloom filter is matched to represent "may be."
Figure 6-11 is a legend that verifies whether the keyword "X" is in the aforementioned Bloom filter. The corresponding bits are set to 1, so the keyword is likely to be matched.


Figure 6-11 verifies whether the keyword "X" exists in the Bloom filter. If the result is a contingent positive match, it indicates "may be."
On the other hand, if we substitute the keyword to calculate the result of a bit is 0, indicating that the keyword is not recorded in the filter. The result of a negative match is not possible, but necessarily. In other words, a negative match represents "must not be."
Figure 6-12 is a legend that verifies whether the keyword "Y" exists in the simple Bloom filter. A result field in the figure is 0, and the field must not be matched.


Figure 6-12 verifies that the keyword "Y" is present in the Bloom filter. If the result is an inevitable negative match, it means "certainly not."
The implementation of the Bloom filter has been described in BIP0037. See Appendix 2 or visit GitHub.
6.9 Bloom filters and inventory updates
The bloom filter is used to filter the transaction information received by the SPV node from the peer node. The SPV will create a filter that can only match the address of the SPV node wallet. The SPV node then sends a FILTERLOAD message to the peer node that contains the filter to be used in the connection. When the filter is built, the peer node validates the output value of each transaction into the filter. Those matching trades were sent back to the SPV node.
In response to the GetData information from the SPV node, the peer node emits a chunk header that contains only the chunks that match the filter and the Merkle tree that matches the transaction. This pair of nodes also emits a TX message that matches the transaction.
This node can send a FILTERADD message to its Bloom filter to add keywords, but also to send filterclear information to clear the entire filter. Because the keyword cannot be removed directly from the filter, if a keyword is no longer needed, the node must replace the original filter by clearing and adding.
6.10 Trading Pools
Almost every node in a blockchain network maintains a temporary list of unconfirmed transactions, known as a memory pool or a trading pool. Nodes use this pool to track transactions that are known to the network but not yet included in the blockchain. For example, a node that saves a user's wallet will use this trading pool to record pre-paid information that the network has received but not yet confirmed to belong to that user's wallet.
As transactions are received and validated, they are added to the trading pool and notified to neighboring nodes, thus propagating to the network.
Some implementations of the nodes also maintain a separate, orphaned trading pool. If the input of a transaction is related to an unknown transaction, such as a missing parent transaction, the orphaned transaction is temporarily stored in the orphaned pool until the parent transaction arrives.
When a transaction is added to the trading pool, the orphaned trading pool is also checked to see if an orphaned transaction refers to the output (sub-trade) of the transaction. Any matching orphan trade is verified. If the validation is valid, they are removed from the orphaned trading pool and added to the trading pool, making the chain that begins with its parent transaction complete. It is no longer an isolated transaction for a new trading pool. The aforementioned process repeats recursively searching for further offspring until all descendants are found. Through this process, the arrival of a parent transaction re-binds the orphaned transactions in the entire chain and their parent trades, triggering the cascade refactoring of the entire independent trading chain.
Trading pools and siloed trading pools (if implemented) are stored in local memory and are not stored on permanent storage devices such as hard drives. More precisely, they are populated dynamically with the messages that are passed into the network. When a node is started, two pools are idle, and two pools are gradually populated as new transactions in the network are received continuously.
Some blockchain client implementations also maintain a UTXO database, also known as the Utxo pool, which is the set of all unpaid transaction outputs in the blockchain. The name "Utxo pool" sounds similar to a trading pool, but it represents a different set of data. The Utxo pool is different from the trading pool and the orphaned trading pool where it is not empty at initialization, but contains millions of unpaid trade output entries, some of which can be traced back to the 2009. The Utxo pool may be placed in local memory or in a persistent storage device as a database table containing indexes.
A trading pool and an orphaned trading pool represent the local perspective of a single node. Depending on the start time or restart time of the node, the contents of the two pools of the nodes may vary greatly. On the contrary, the Utxo pool represents the obvious consensus of the network, so the content of the Utxo pool between different nodes is quite different. In addition, the trading pool and the orphaned trading pool contain only unconfirmed transactions, while the Utxo pool contains only confirmed transactions.
6.11 Warning Messages
Warning messages are not used frequently, but are available on most nodes. The warning message is the "Emergency Broadcast system" of the blockchain, which the blockchain core developers can use to send emergency text messages to all blockchain nodes. This feature is intended to allow the core development team to notify all blockchain users of serious problems with the blockchain network, such as a serious bug that requires the user to take action. The warning system has been used only a few times so far, the most severe of which was in 2013, when a key database flaw resulted in a multi-chunk fork in the blockchain blockchain.
The warning message is propagated through the alert message. The warning message contains several fields, including:
▷id
Warning message ordinal, for detecting duplicate warnings
▷expiration
Point in time at which the warning expires
▷relayuntil
After this point in time, the warning is no longer relayed
▷minver,maxver
The version range of the blockchain protocol to which this warning applies
▷subver
The client software version that this warning applies To
▷priority
Priority of the warning message (not currently used)
The warning is cryptographically signed with the public key. The corresponding private key is held by some specific members of the core development team. Such a digital signature ensures that false warnings are not propagated across the network.
The node that receives the warning message validates the message, checks whether it expires, and propagates it to all its peers, guaranteeing rapid propagation throughout the network. In addition to propagating warnings, a node may implement a user-level interface function that pushes a warning to the user.
In the blockchain core client, the warning is set with the command-line option alertnotify, which specifies the command to be executed when a warning is received. The warning message is passed as a parameter to the Alertnotify command. The most common application is that the Alertnotify command is set to generate an e-mail message containing the warning and send it to the node administrator. The warning is also displayed as a pop-up dialog box on the graphical user interface (if there is a run) (BITCOIN-QT).
Implementations of other blockchain protocols may handle warnings in different ways. Many hardware embedded blockchain mining systems have no user interface and do not implement the warning message feature. We strongly recommend that miners running this type of mining system subscribe to warning messages, either through a mining pool operator or by running a separate lightweight node for warning purposes.