Proficiency in Bitcoin-the 6th bit currency network __blockchain

6.1 Peer-to-peer Network Architecture

Bitcoin uses a peer-to-peer (peer-to-peer) network architecture based on the Internet (Internet). Peer-to-peer means that each computer in the same network is equal to each other, each node provides a network service, and there is no "special" node. Each network node is interconnected with a "flat (flat)" topology. There is no server, centralized service, and hierarchy in Peer-to-peer networks. Peer-to-peer Network node Interaction between the operation, collaborative processing: Each node in the external provision of services at the same time also use the services provided by other nodes in the network. Peer-to-peer networks are therefore reliable, centralized, and open. The early internet is a typical use case of Peer-to-peer network architecture: Each node in an IP network is fully equal. Today's Internet architecture has a layered architecture, but IP protocol still retains the structure of a flat topology. Beyond Bitcoin, the largest and most successful Peer-to-peer technology application is in the area of file sharing: Napster is a pioneer in the field, and BitTorrent is the latest evolution of its architecture.

The Peer-to-peer network architecture used in Bitcoin is not just a simple choice of topology. Bitcoin is designed as a point-to-point digital cash system, and its network architecture is both a reflection of this core feature and a cornerstone of this feature. Central control is the core principle of design, it can only be achieved by maintaining a flat, centralized Peer-to-peer network.

A "Bitcoin network" is a collection of nodes that run according to a bit-currency peer-to-peer protocol. In addition to the bit-currency peer-to-peer protocol, the Bitcoin Network also contains other protocols. For example, the stratum protocol is used in mining, as well as lightweight or mobile coin purses. Gateway routing servers provide these protocols, use the Bitcoin Peer-to-peer protocol to access the Bitcoin network, and extend the network to nodes running other protocols. For example, the stratum server connects all stratum mining nodes to the bitcoin main network through the stratum protocol and bridges the stratum protocol to the Bitcoin Peer-to-peer protocol. We use the extended bitcoin network (extended Bitcoin network) to refer to all the overall network structures that contain the bit-currency peer-to-peer protocol, the mine-pit mining protocol, the Stratum protocol, and other protocols connected to the bit-currency system components. 6.2 node type and division of labor

Although each node in the Bitcoin Peer-to-peer Network is reciprocal, each node may have a different division of labor depending on the functionality provided. Each bitcoin node is a collection of functions for routing, block chain databases, mining, and wallet services. A full node includes four features as shown in Figure 6-1:

Figure 6-1 A bitcoin network node that contains four full functions: wallet, Miner, complete block chain, network routing node

Each node participates in a network-wide routing function and may also contain other features. Each node participates in validating and propagating transaction and block information, and discovers and maintains 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 retain a full, up-to-date copy of The Block chain, which is called a "full node." The entire node is able to independently validate all transactions without having to borrow any external references. In addition, some nodes retain only part of the block chain, which completes the transaction verification by means of a simple payment verification (SPV). Such nodes are called "SPV nodes", also known as "lightweight nodes". In the full-node use case shown above, the blue circle called the Complete block chain represents the function of the whole node block chain database. In Figure 6-3, the SPV node does not have this blue circle to show that they do not have a full copy of the block chain.

The mining node creates new blocks in a competitive way by means of a workload proof (proof-of-work) algorithm running on special hardware devices. Some of the mining nodes are also full nodes, retaining the full copy of the block chain; some of the nodes that are involved in mine-digging are lightweight nodes that must be dependent on the entire node maintained by the mining pool server. 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 more common in desktop Bitcoin clients. At present, more and more users ' wallets are SPV nodes, especially for Bitcoin wallet applications on resource-constrained devices such as smartphones, and this is becoming more common. In Figure 6-1, the green circle called "wallet" represents the wallet function.

In the bit-currency Peer-to-peer protocol, in addition to these main node types, there are also some servers and nodes running other protocols, such as special Mine Pit mining protocol, lightweight Client access Protocol, etc.

Figure 6-2 depicts the most common node types in the extended bitcoin network.

Figure 6-2 Different node types for the extended bitcoin network 6.3 expansion Bitcoin network

The Bitcoin primary network running the Bitcoin Peer-to-peer protocol consists of approximately 7000-10000 listening nodes running different versions of the Bitcoin core client (Bitcoin Core), and hundreds of applications running various bit-currency peer-to-peer protocols (such as Bitcoinj, Libbitcoin, BTCD, etc.) of the node composition. A small segment of the Peer-to-peer network is also a mining node that competes for mining, verifying transactions, and creating new blocks. Many large companies connected to the Bitcoin network run a full node client based on the Bitcoin core client, which has a full copy of the block chain and network nodes, but does not have a mining and wallet function. These nodes are network edge routers (Edge routers), through which they can build other services, such as exchanges, wallets, block browsers, merchant payment processing (merchant payment processing).

As mentioned earlier, the extended Bitcoin network includes both the network running the bit-currency Peer-to-peer protocol and the network node running the special protocol. The Bitcoin Peer-to-peer main network is connected to a number of mine pool servers and protocol gateways that connect nodes running other protocols. These nodes are usually mine-pit-digging nodes (see chap. 8th) and lightweight wallet clients, which typically do not have a full backup of the block chain.

Figure 6-3 depicts an extended Bitcoin network that includes various types of nodes, gateway servers, edge routers, wallet clients, and the various protocols they need to connect to each other.

Figure 6-3 Extended bitcoin network with multiple node types, gateways, and protocols 6.4 Network Discovery

When a new network node is started, it must discover other Bitcoin nodes in the network in order to be able to participate in the collaborative operation. The new network node must discover and establish a connection to at least one of the nodes in the network. Because the topology of the Bitcoin 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 the Bitcoin nodes that exist in the network to connect to them.

Nodes typically use the TCP protocol, using port 8333, which is typically used in Bitcoin, and can be specified using a different port in addition to 8333 ports to establish a connection with a known peer node. When a connection is established, the node begins the "handshake" communication process by sending a version message containing the Basic authentication content (see Figure 6-4). This process includes the following elements:

▷protocol_version
Constant that defines the version (for example: 70002) used by the client to "speak" the bit-currency peer-to-peer protocol.

▷nlocalservices
A list of local services supported by this node that currently supports only node_network

▷ntime
Current time

▷addryou
The IP address of the remote node that is visible to the current node

▷addrme
Native IP address found by the local node

▷subver
Indicates the version number of the software type that the current node is running (for example, "/SATOSHI:0.9.2.1/")

▷baseheight
The block height of the current node block chain
(For specific use cases for version network messages see GitHub)

Peer nodes in a network acknowledge and establish a connection by responding to a verack message; sometimes, if the receiving node needs to interchange the connection and connect back to the starting node, the peer node's version message is also returned.

How the new node discovers Peer-to-peer nodes in the network. Although there are no special nodes in the Bitcoin network, the client maintains a list of those nodes that are long-running and stable. Such a node is called the 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 it is possible to quickly discover other nodes in the network through the seed nodes. In the bitcoin core client, the use of seed nodes is controlled through "-dnsseed". By default, this option is set to 1, meaning that the seed node is used. Alternatively, at the beginning, the IP address of at least one Bitcoin node is provided to the node being started (the node does not contain the constituent information of any Bitcoin network). After that, the startup node can establish a new connection through subsequent instructions. The user can use the command-line argument "-seednode" to "referral" the startup node and connect to a node, using the node as the DNS seed. After the initial seed node is used to form "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 containing its own IP address to its neighboring nodes. The neighboring node then forwards the addr message to their neighboring nodes, which ensures that the new node information is received by multiple nodes and the connection is more stable. In addition, the newly accessed node can send GETADDR messages to its neighboring nodes, requiring them to return a list of the 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 message to the network for other nodes to find. Figure 6-5 depicts this address Discovery protocol.

Figure 6-5 Address broadcast and discovery

The node must be connected to several different peer nodes to establish a different kind of path (path) to the Bitcoin network in the Bitcoin network. Because the 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 assistance to other nodes when they are started. A node requires only one connection when it is started, because the first node can refer it to its peers, and these nodes provide further referrals. A node, if connected to a large number of other peer nodes, this is not necessary, but also a waste of network resources. After the startup completes, the node remembers the peer node it recently successfully connected to, so it can quickly re-establish the connection with the previous peer network when it restarts. If the peer node of the previous network does not answer the connection request, the node can be restarted using the seed node.

On the node that is running the bitcoin core client, you can use the Getpeerinfo command to list peer-to-peer node connection information:

 $ bitcoin-cli Getpeerinfo [{"Addr": "85.213.199.39:8333", "Services": "00000001", "LA
        Stsend ": 1405634126," lastrecv ": 1405634127," bytessent ": 23487651," bytesrecv ": 138679099, "Conntime": 1405021768, "Pingtime": 0.00000000, "version": 70002, "Subver": "/satoshi:0."
    9.2.1/"," inbound ": false," startingheight ": 310131," Banscore ": 0," Syncnode ": True
        }, {"addr": "58.23.244.20:8333", "Services": "00000001", "lastsend": 1405634127,
        "Lastrecv": 1405634124, "bytessent": 4460918, "bytesrecv": 8903575, "Conntime": 1405559628, "Pingtime": 0.00000000, "version": 70001, "Subver": "/satoshi:0.8.6/", "Inbound": Fals E, "startingheight": 311074, "Banscore": 0, "Syncnode": false}] 

Users can specify one or more IP addresses by providing the-CONNECT=<IP address > option, thereby achieving replication automatic node management functionality and specifying the IP address list for the purpose. With this option, nodes connect to only those selected node IP addresses and do not automatically discover and maintain connections between peer nodes.

If an established connection has no data communication, the node that is on the site periodically sends information to maintain the connection. If a node lasts for 90 minutes without any communication, it will be considered disconnected from the network and the network will start looking for a new peer node. Therefore, the Bitcoin network will be dynamically adjusted according to the changing nodes and network problems, and the organic adjustment of scale increase and decrease without the centralized control. 6.5 Full Node

A full node is a node that maintains a complete block chain containing all the transaction information. More precisely, such a node should be called a full block chain node. In the early days of bitcoin development, all nodes were full nodes, and the current Bitcoin core client was a complete block chain node. But over the past two years there have been a number of new clients that do not need to maintain a complete chunk chain but run as lightweight clients. These lightweight clients are described in detail in the following sections.

The complete block chain node maintains a complete and up-to-date copy of the Bitcoin block chain containing all the transaction information, which can be independently set up and validated in block chains, from the first block (Genesis Block) to the newest blocks in the network. A full block chain node can independently validate any transaction information without resorting to any other nodes or other sources of information. The full block node obtains a new block update containing the transaction information through the Bitcoin network and merges the update into the local block chain copy after the validation is correct.

Running a full block chain node gives you a pure bit-currency experience: All transaction information can be validated independently without the need or trust of other systems. It's easy to tell whether you're running a full node: just see if your permanent storage device (such as your hard disk) has more than 20GB of space to store the full block chain. If you need a lot of disk space and the synchronization Bitcoin network takes 2-3 days, you are using a full node. This is the price to be paid for getting rid of central management and for complete freedom of independence.

Although there are still other complete block chain clients that use different programming languages and software architectures, the most commonly used is the Bitcoin core client, also known as the "Satoshi client". More than 90% of the nodes in the Bitcoin network run each version of the Bitcoin core client. As mentioned earlier, it can be identified by the version message sent between nodes or by the Getpeerinfo string "Satoshi" obtained by the 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 block chain. If the node is a new node, it does not contain any chunk chain information, it knows only one block-the creation block, which is statically implanted in the client software. The new node needs to download the entire contents of the hundreds of thousands of blocks starting from block No. 0 (Genesis block) to synchronize with the network and rebuild the whole block chain.

The process of synchronizing a chunk chain begins with the sending of version messages because the Bestheight field contained in the message indicates the current block chain height (number of blocks) for a node. A node can obtain a version message from its peer node to see how many blocks each side has, so that it can be compared to the number of blocks owned by its own block chain. Peer nodes exchange a getblocks message that contains the top chunk hash value of their local block chain. If a peer recognizes that the hash value it receives does not belong to the top block, but belongs to an old block that is not a top block, it can infer that its own local block chain is longer than the other peer nodes ' block chains.

A Peer-to-peer node with a longer chunk chain has more chunks than other nodes and can identify which blocks are needed to be "replenished" by other nodes. It identifies the first 500 blocks that can be shared and propagates the hash values of these blocks using Inv (inventory) messages. Nodes that are missing from these blocks can then request full block information through the GetData messages they send, and use the hash value contained in the Inv message to confirm that the missing blocks are the correct requested chunks.

In the following example, we assume that a node contains only a Genesis block. It receives a INV message from the peer node that contains the hash value of the 500 blocks in the block chain. It then starts to request chunks to all of the peer nodes connected to it and prevents a single peer node from being crushed by a batch request by allocating workload. The node tracks the number of blocks on each peer connection that it has sent, but has not received it, and checks to see if the number exceeds the upper limit (max_blocks_in_transit_per_peer). In this way, if a node needs to update a large number of blocks, it will send a request to the new block after the last request completes, allowing the peer node to control the update speed without crushing the network. Each chunk is added to the block chain after it is received, as detailed in chapter 7th. With the gradual establishment of the local block chain, more and more blocks are requested and received, the whole process will continue until the node and the entire network complete synchronization.

Whenever a node is offline, regardless of how long the offline time is, the process of comparing the local block chain to the peer node and recovering the missing chunk is triggered. If a node is only offline for a few minutes, a few blocks may be missing, and when it is offline for up to one months, thousands of blocks may be missing. In either case, it starts by sending the getblocks message, receives a inv response, and then starts downloading the missing chunk inventory and the chunk broadcast protocol as shown in Figure 6-6.

Figure 6-6 The node synchronizes the block chain 6.7 Simple payment verification (SPV) nodes by reading chunks from the peer node

Not all nodes have the ability to store complete block chains. Many bitcoin clients are designed to run on space and power-constrained devices such as smartphones, tablets, and embedded systems. For such devices, the simplified payment validation (SPV) approach allows them to work without having to store a complete block chain. This type of client is called a SPV client or a lightweight customer. With the use of Bitcoin, the SPV nodes become the most common form of Bitcoin nodes (especially bitcoin wallets).

The SPV node simply downloads the block header without downloading the transaction information contained in each block. The resulting block chain, which contains no transaction information, is only 1/1000 of the total block chain. The SPV node cannot build all the utxo that can be used for consumption because they do not know the complete information of all transactions on the network. The SPV node verifies the transaction in a slightly different way, and this method relies on the peer node "on demand" to provide a partial view of the relevant part of the block chain.

For example, each full node is like a tourist in a strange city with a detailed map of each street and address. In contrast, the SPV node is like a tourist in this strange city who only knows the name of a main road, and randomly asks strangers in the city to get a section of road directions. Although both types of visitors can verify whether a street exists through field visits, visitors without maps do not know what streets are in each alley or what other streets are nearby. No map of the visitors in the "Church Street 23rd" in front, do not know whether there are several other "Church Street 23rd" in the city, do not know whether the front of this is the one to find. The best way for him is to ask enough people for directions and hopefully some of them aren't trying to rob him.

Simple payment validation is validated by reference to the depth of the transaction in the block chain, rather than the height. A node with a complete block chain constructs a validation chain that consists of thousands of blocks and transactions traced back to the Genesis block in chronological order along the block chain. A SPV node verifies the chain of all blocks (but not all transactions) and links the block chain to the related transactions.

For example, a whole node should check the No. 300, a transaction in block No. 000 that links all 300,000 blocks from the beginning of the block back to the Genesis Block and establishes a complete Utxo database confirming the validity of the transaction by confirming that the Utxo has not yet been paid. The SPV node cannot verify that Utxo has not yet been paid. Instead, the SPV node creates a link between the transaction information and its block by Merkle Path (see "7.7 Merkle Tree"). The SPV node then waits until the serial number of six blocks from 300,001 to 300,006 is stacked on top of the block of the exchange and verifies the validity of the transaction by establishing the depth of the transaction under Block 300,006, Block 300,001. In fact, if the other nodes in the network accept block 300,000 and generate six blocks on top of the block with enough work, the broker-Gateway protocol can prove that the transaction is not a double payment.

If a transaction does not actually exist, the SPV node does not mistakenly believe that the transaction exists in a block. The SPV node confirms the existence of the transaction by requesting the Merkle path proof and verifying the workload in the block chain. However, the existence of a transaction is likely to "hide" the SPV node. The SPV node can undoubtedly confirm the existence of a transaction, but it cannot verify that a transaction (for example, 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 against the SPV node. To protect against these attacks, the SPV node needs to be randomly connected to multiple nodes to increase the probability of connecting to at least one reliable node. The requirement of this kind of random connection means that the SPV node is 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 real bitcoin network.

In most practical situations, the SPV node with good connection is safe enough to maintain a proper balance between resource requirement, practicality and security. Of course, if you want to ensure foolproof security, the most reliable way is to run the entire block chain node.

The complete block chain node verifies the transaction by checking the entire chain of thousands of blocks below it to ensure that the utxo is not paid. The SPV node verifies the transaction by checking the depth at which it is pressed below.

The SPV node uses a getheaders message rather than a getblocks message to get the block header. The peer node that is responding sends up to 2000 chunk headers with a headers message. This process is no different from the whole node acquiring all the blocks. The SPV node also sets up a filter on the connection with the peer node to filter future blocks and transaction data streams from peer nodes. Any target transaction is read by a GetData request. The peer node generates a TX message containing transaction information as a response. The block header synchronization process is shown in Figure 6-7.

Figure 6-7 SPV node synchronization block header

Because the SPV node needs to read a particular transaction to selectively validate the transaction, it creates a privacy risk. With the whole block chain node collecting all the exchanges in each block, the SPV node's request for specific data may inadvertently disclose the address information in the wallet. For example, a third party monitoring the network can track all transaction information requested by a wallet on a SPV node and use the transaction information to correlate the Bitcoin address with the user of the wallet, thereby damaging the user's privacy.

Shortly after the introduction of the SPV Node/lightweight node, the bitcoin developer added a new feature: Bloom filters to address the privacy risks of the SPV node. The Bloom filter allows the SPV node to receive only a subset of the transaction information through a filtering mechanism using probability rather than a fixed pattern, while not accurately revealing which addresses are of interest to them. 6.8 Bloom Filter

Bloom Filter is a probabilistic filtering method that allows a user to describe a specific combination of keywords without having to express them accurately. 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, while 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 "23rd Church Street is", inadvertently, he exposes his destination. Bloom filters Ask, is there a street with the word ' don ' nearby? "Such a question contains a little less than the previous keyword. The visitor can choose how much information they contain, such as "The End of the street" or "the word ' teach '." If he asks less, gets more potential addresses, privacy is protected, but there are no unrelated results in these addresses, and if he is very specific, he exposes his privacy when he gets more accurate results.

The Bloom filter allows the SPV node to specify the search pattern for the transaction, which can be adjusted based on accuracy or privacy considerations. A very specific bloom filter will produce more accurate results, but it will also show the address used in the user's wallet; Conversely, if the filter contains only simple keywords, more of the corresponding trade fairs are searched out, including a number of unrelated transactions at the same time have a higher privacy.

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 transaction output corresponding to each address. Typically, this search pattern is a hash script that pays to the public key, which is a locked script that appears in each transaction that pays for the public key hash address. If the SPV node needs to track the P2sh address balance, the search pattern becomes the p2sh script. The SPV node then adds each search pattern to the Bloom filter, which can be identified by the filter as long as the keyword appears in the transaction. Finally, the peer node uses the received Bloom filter to match the transactions that are transmitted to the SPV node.

The implementation of the Bloom filter consists of a variable length (n) binary array (n-bit binary number consisting of a bit field) and a set of hash functions with a variable (M) quantity. The output values of these hash functions are always between 1 and N, which corresponds to the 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 properties of bloom filters are adjusted by changing the length (N) and the number of hash functions (M).

In Figure 6-8, we demonstrate the application of the Bloom filter with 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. Once the keyword is added to the Bloom filter, the hash function is followed by each operation. The input is given a number between 1 and N after the first hash function, and the corresponding bits in the array (numbered 1 to N) are set to 1 to record the output of the hash function. Then the next hash function is calculated, and the other position is 1; When all of the M hash functions have been worked out, a total of M single-digit values changed from 0 to 1, and the keyword was "recorded" in the Bloom filter.

Figure 6-9 shows a keyword "A" added to the simple Bloom filter in Figure 6-8.

Figure 6-9 Adding the keyword "A" to the simple Bloom filter

The second key to adding is simply to repeat the previous steps. After each hash function operation, the corresponding bit becomes 1,bloom filter, then the key word is recorded. It should be noted that when the keyword in the Bloom filter increases, it corresponds to a hash function of the output value of the bit may already be 1, in this case, the bit will not change again. That is, as more keywords point to repeated bits, the bloom filter is saturated with the increase in bit 1 and the accuracy is reduced. The filter is based on a probabilistic data structure, because the increase in keywords can lead to a reduction in 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 a limited number of keywords to reduce accuracy.

Figure 6-10 shows the addition of the second keyword "B" to the simple Bloom filter.

Figure 6-10 Add a second keyword "B" to the simple Bloom filter

To test whether a keyword is recorded in a bloom filter, we compute the keyword by generation into each hash function and compare the resulting result with the original array. If all the results correspond to a bit of 1, it means that the keyword may have been recorded by the filter. This conclusion is not certain because these byte 1 may also be overlapping results of other keyword operations. In short, the Bloom filter is matching the "may be".

Figure 6-11 is a legend that verifies that the keyword "X" is in the preceding Bloom filter. The corresponding bit bits are set to 1, so this keyword is likely to match.

Figure 6-11 verifies that the keyword "X" is present in the Bloom filter. If the result is a probable positive match, it means "may be".

On the other hand, if the result of a keyword calculation is 0, the keyword is not recorded in the filter. The result of a negative match is not possible, but certain. In other words, a negative match means "definitely not".

Figure 6-12 is a legend that verifies that the keyword "Y" exists in a 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" exists in the Bloom filter. If the result is an inevitable negative match, it means "definitely not".

BIP0037 has described the implementation of the Bloom filter. See Appendix 2 or visit GitHub. 6.9 Bloom Filter and Inventory update

Bloom filters are used to filter the transaction information received by the SPV node from the peer node. The SPV will create a filter that matches only the address in the SPV's wallet. The SPV node then sends a FILTERLOAD message to the peer node containing the filter to be used in the connection. When the filter is built, the peer node converts the output value of each transaction into the filter for validation. Those matching fairs were sent back to the SPV node.

In response to GetData information from the SPV node, the peer node emits a block header that contains only the blocks that match the filter, and a merkle tree that matches the transaction. This pair of nodes also emits a TX message for a matching transaction.

The node can add keywords to its bloom filter by sending a FILTERADD message, and can also send filterclear messages to clear the entire filter. Because the keyword cannot be deleted directly from the filter, if a keyword is no longer needed, the node must replace the original filter by clearing and adding it. 6.10 Trading Pool

Almost every node in the Bitcoin network maintains a temporary list of unacknowledged transactions called a memory pool or a trading pool. Nodes use the pool to track transactions that are known to the network but not yet included in the block chain. For example, the node that holds the user's wallet uses the transaction pool to record the pre payment information that the network has received but has not yet been confirmed to belong to the user's wallet.

As transactions are received and validated, they are added to the trading pool and notified to adjacent nodes to propagate to the network.

The implementation of some nodes also maintains a separate, isolated transaction pool. If the input of a transaction is related to an unknown transaction, if it is associated with a missing parent transaction, the isolated transaction is temporarily stored in the orphan pool until the information of the parent transaction arrives.

When a transaction is added to a trading pool, an isolated transaction pool is also checked to see if an isolated transaction refers to the output of the transaction (child transactions). Any matching orphan trade fair is validated. If validation is valid, they are removed from the orphaned trading pool and added to the transaction pool to make the chain that begins with its parent transaction complete. For new trading pools, it is no longer an isolated transaction. The preceding procedure repeats the recursive search for further offspring until all descendants are found. Through this process, the arrival of a parent transaction combines the isolated transaction in the whole chain with their parent transaction, triggering a cascade reconfiguration of the whole independent trading chain.

Trading pools and orphaned trading pools (if implemented) are stored in local memory and are not stored on permanent storage devices such as hard disks. More precisely, they are dynamically populated with messages that are passed in to 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 Bitcoin client implementations also maintain a UTXO database, also known as the Utxo Pool, as a collection of all outstanding transaction outputs in the block chain. The name "Utxo pool" sounds similar to a trading pool, but it represents a different set of data. The Utxo pool differs from a trading pool and an isolated trading pool in that it is not empty when initialized, but rather contains millions of unpaid transaction output entries, some of which can date back to 2009. The Utxo pool may be placed in local memory or as a database table containing indexes in a permanent storage device.

A trading pool and an orphaned trading pool represent the local perspective of a single node. Depending on the node's startup time or restart time, the contents of the two pools may differ significantly from node to site. Conversely, the Utxo pool represents the prominent consensus of the network, so the contents of the Utxo pool between different nodes are not very different. In addition, the trading pool and the orphaned trading pool contain only unacknowledged transactions, while the Utxo pool contains only confirmed transactions. 6.11 Warning Messages

Warning messages are not used frequently, but they are available on most nodes. The warning message is Bitcoin's "Emergency Broadcast System", which the Bitcoin core developer can use to send urgent text messages to all bitcoin nodes. This feature is designed to allow the core development team to notify all Bitcoin users of serious problems with the Bitcoin network, such as a serious bug that requires the user to take action. The warning system has so far been used only a few times, the most serious one in 2013, when a critical database flaw resulted in a multiple-chunk fork in the Bitcoin block chain.

Warning messages are propagated through alert messages. A warning message contains several fields, including:

▷id
Warning message sequence number, used to detect duplicate warnings

▷expiration
Point in time when a warning expires

▷relayuntil
After this point in time, the warning is no longer relayed

▷minver,maxver
The bit currency protocol version range that this warning applies To

▷subver
The client software version that this warning applies To

▷priority
Priority of warning messages (temporarily unused)

The warning is encrypted 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 verifies the message, checks whether it expires, and propagates it to all its peers, guaranteeing rapid propagation across the network. In addition to propagating warnings, nodes may implement a user-level interface function that pushes a warning to the user.

In the bitcoin 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 to the alertnotify command as a parameter. The most common application is that the Alertnotify command is set to generate an e-mail message that contains the warning message and send it to the node administrator. Warnings are also displayed in a pop-up dialog box on the graphical user interface (if it is running) (BITCOIN-QT).

Implementations of other bit-currency protocols may handle warnings in different ways. Many hardware embedded Bitcoin mining system has no user interface and does not implement the warning message function. We strongly recommend that miners running such mining systems subscribe to a warning message that can be subscribed either through a mining pool operator or by running a lightweight node that is intended to be used individually as a warning.