Monero network topology mapping method based on whitelist occupation

Abstract

The application discloses a kind of based on whitelist occupation monero network topology structure mapping method, the method includes: for each reachable node in monero network, the address in address set A is used to the white list of the reachable node is occupied, and after waiting for set time period, the white list of the reachable node is obtained;The address in the white list obtained is compared with address set A, and the first difference address set is obtained;According to the first difference address set, the outgoing connection node of the reachable node is determined;According to the outgoing connection node of each reachable node determined, the topology structure of the monero network mapped out is obtained.The application can not be necessary to send a large number of transactions to the network, avoid the invasiveness to network, and monero network topology structure can be accurately obtained at high speed.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method for mapping the topology of the Monero network based on whitelist occupation. Background Technology

[0002] Cryptocurrency systems, based on blockchain technology and peer-to-peer networks, are characterized by decentralized transactions, strong anonymity, and decentralization, making transactions difficult to trace and regulate. Current research on network layer transactions for cryptocurrency traceability and regulation primarily focuses on technologies for tracing cryptocurrency network layer transactions. Network layer transaction traceability technology refers to identifying the originating node of a transaction within a cryptocurrency network by analyzing network traffic. Measuring and constructing the entire Monero network topology facilitates network traffic analysis and the identification of the originating node of transactions within the cryptocurrency network.

[0003] Network topology measurement refers to obtaining the connectivity relationships between nodes in a network. Existing topology measurement methods for the Monero network are primarily based on topology measurement methods using specific transactions.

[0004] One existing topology measurement method based on special transactions uses double-spending transactions to infer network connectivity: an attacker establishes connections with all reachable nodes and sends different transactions that spend the same UTXO to all nodes except the target node. This method exploits the characteristic that nodes will reject double-spending transactions. These transactions do not propagate among nodes other than the target node; they only propagate from the target node's neighboring nodes to the target node, where they are accepted and stored. The attacker infers the target node's neighboring nodes by observing the transactions contained in the inv messages sent by the target node.

[0005] Another topology measurement method based on special transactions uses the txprobe technique to infer the network topology of Bitcoin public network nodes: an orphan transaction is a transaction received by a Bitcoin node that spends the output of a transaction not in the blockchain / node mempool. Nodes do not immediately forward orphan transactions to their neighbors. An attacker sends a parent transaction to the target node, using the invblock method to ensure that only the target node stores the parent transaction; then, the attacker sends a child transaction to the target node, which then sends the child transaction to its neighbors. Since the target node's neighbors do not store the parent transaction, they consider the child transaction an orphan transaction and do not propagate it to the network. The attacker sends inv messages containing the child transaction to all nodes in the network. Nodes that do not return getdata messages requesting transaction details are the target node's neighbors.

[0006] Another method for topology measurement based on specific transactions infers the Ethereum network topology by marking transactions.

[0007] In practical applications, the inventors of this invention have found that existing topology measurement methods based on special transactions require sending a large number of transactions into the network, which increases the burden on network nodes to verify transactions and is highly intrusive to the network. Therefore, it is necessary to provide a Monero network topology mapping method that does not require sending a large number of transactions into the network and avoids intrusiveness to the network. Summary of the Invention

[0008] In view of this, the purpose of this invention is to propose a method for mapping the topology of the Monero network based on whitelist occupation, which avoids sending a large number of transactions into the network, avoids intrusion into the network, and can obtain the topology of the Monero network at high speed and with high accuracy.

[0009] To achieve the above objectives, this invention provides a method for mapping the topology of the Monero network based on whitelist domination, comprising:

[0010] For each reachable node in the Monero network, use addresses from address set A to occupy the whitelist of that reachable node, and after waiting for a set time period, obtain the whitelist of that reachable node.

[0011] The addresses in the obtained whitelist are compared with the address set A to obtain the first set of differing addresses; based on the first set of differing addresses, the outgoing connection node of the reachable node is determined.

[0012] The topology of the Monero network is mapped based on the outgoing connection nodes of each reachable node.

[0013] Preferably, the set time period is between 20 and 40 seconds.

[0014] Preferably, the process of acquiring the whitelist of reachable nodes specifically includes:

[0015] By having 1000 controlled nodes simultaneously initiate handshake requests to the reachable node, the reachable node can fill in the addresses of these controlled nodes into its whitelist.

[0016] The address of the controlled node is contained in the address set A.

[0017] Furthermore, before comparing the addresses in the obtained whitelist with the address set A, the process also includes:

[0018] Obtain the addresses from the whitelist of the reachable node and form an address set S;

[0019] Compare the differences between set A and set S; if there are addresses in A that do not belong to set S, then use the controlled nodes corresponding to these addresses to initiate a handshake request to the reachable node again, so that the reachable node fills these addresses into the whitelist of the reachable node.

[0020] Furthermore, before determining the outgoing connection node of the reachable node, the method further includes:

[0021] Use the addresses in address set B to reclaim the whitelist of the reachable node, and wait for the set time period before obtaining the whitelist of the reachable node.

[0022] The addresses in the obtained whitelist are compared with the address set B to obtain the second set of differing addresses.

[0023] Preferably, the addresses contained in address set B are completely different from the addresses contained in address set A.

[0024] Preferably, determining the outgoing connection node of the reachable node specifically involves:

[0025] The intersection of the first set of differing addresses and the second set of differing addresses is used to obtain the final set of differing addresses.

[0026] Based on the final set of differing addresses, determine the outgoing connection node for that reachable node.

[0027] The present invention also provides a computer device, the computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method for mapping the topology of the Monero network based on whitelist occupation.

[0028] The present invention also provides a computer-readable storage medium storing a computer program that can be executed by at least one processor to cause the at least one processor to perform the steps of the above-described method for mapping the topology of the Monero network based on whitelist occupation.

[0029] In this invention, for each reachable node in the Monero network, addresses from address set A are used to claim a whitelist of that node. After a set time period, the whitelist of that node is retrieved. The addresses in the retrieved whitelist are compared with address set A to obtain a first set of differing addresses. Based on this first set of differing addresses, the outgoing connection nodes of that reachable node are determined. Based on the determined outgoing connection nodes of each reachable node, the topology of the Monero network is mapped. This process avoids sending a large number of transactions into the network, preventing network intrusion, and allows for high-speed and accurate acquisition of the Monero network topology.

[0030] In addition, this invention designs a noise address filtering method for two rounds of topology probing. Taking advantage of the fact that the noise addresses in the first round of topology probing and the second round of topology probing hardly overlap, the intersection of the whitelists obtained by the two rounds of topology probing is calculated to filter the noise addresses in the target node whitelist, so as to reduce false detections in the topology probing results.

[0031] Furthermore, considering that the whitelist filling speed and whitelist acquisition speed limit the time required to complete a round of topology probing, this invention has carefully designed a strategy of obtaining the whitelist after whitelist filling and comparing it with the address used for filling. If there is a difference, the whitelist is filled again to shorten the topology probing cycle and speed up the topology probing.

[0032] Furthermore, due to varying performance across nodes, the time it takes for different outgoing connections to send timed synchronization responses to the target node differs, resulting in variations in the time it takes for different nodes to complete timed synchronization. Since it's impossible to determine whether the target node has completed timed synchronization, obtaining the target node's whitelist before it has done so will lead to missed outgoing connection addresses for which timed synchronization has not been completed. Therefore, this invention, by evaluating the time required for each step in topology probing, designs a method to maximize the time the supervisor waits for the target node to complete timed synchronization to between 20 and 40 seconds, thereby minimizing missed detections during topology probing. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 This is a schematic diagram of a Monero network topology mapping method based on whitelist occupation provided in an embodiment of the present invention;

[0035] Figure 2 A flowchart of a method for mapping the topology of the Monero network based on whitelist occupation provided in an embodiment of the present invention;

[0036] Figure 3 This is a flowchart of the first round of topology exploration method provided in an embodiment of the present invention;

[0037] Figure 4 This is a frequency distribution diagram illustrating the number of requests required to obtain a whitelist, provided in an embodiment of the present invention.

[0038] Figure 5 This is a flowchart of the second round topology exploration method provided in an embodiment of the present invention;

[0039] Figure 6 This is a schematic diagram of a computer device hardware structure provided in an embodiment of the present invention. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to specific embodiments and accompanying drawings.

[0041] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this invention should have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains. The terms "first," "second," and similar terms used in this disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0042] The inventors of this invention analyzed the Monero network and found that there are three types of protocol messages used for interaction between Monero nodes: handshake messages, timed synchronization messages, and Ping (heartbeat) messages. All three types of messages follow a request-response pattern.

[0043] (1) Handshake message: The handshake message is used to establish an outgoing connection. During the handshake process, the node and the outgoing connection exchange each other's node configuration information and blockchain synchronization information, and the outgoing connection also provides a list of nodes that it has successfully connected to, which contains up to 250 addresses that it has actively and successfully connected to (i.e., addresses in the whitelist in Section 1.2).

[0044] (2) Scheduled Synchronization Messages: Every minute, a node sends a scheduled synchronization request message to all neighboring nodes to understand their status changes. During the scheduled synchronization process, nodes and neighboring nodes update each other's online status and blockchain synchronization information. The message responder provides a list of up to 250 nodes that have successfully connected but have not sent a message to the message requester. The scheduled synchronization message has a 120-second response timeout; if a neighboring node does not return a response message within 120 seconds, the connection is closed.

[0045] (3) Ping message: When a node receives a handshake request for a new incoming connection, it will proactively initiate a reverse TCP connection to the source address of that connection (i.e., the public IP address of the other node and the P2P port it is listening on). After establishing the reverse connection, the node will send a Ping request message to verify whether the other party can receive incoming connections. If the other party returns a Ping response message, it proves that the node can receive incoming connections, and the node will add its address to the whitelist. However, for internal network nodes behind NAT and public network nodes that are explicitly configured to reject incoming connections, their addresses will not be added to the whitelist because they cannot receive incoming connections.

[0046] Monero nodes use a node list to store known addresses. When a node restarts, it can read the historical node list from a local storage file. The node list consists of two lists: a gray list and a white list. The gray list stores addresses received by the node from other nodes but not yet attempted to connect; these are unverified addresses, with a maximum capacity of 5000. The white list stores addresses that the node has successfully connected to; these are verified addresses that can receive incoming connections, with a maximum capacity of 1000. Addresses from the white list are transmitted in the handshake response and timed synchronization response messages. Monero manages the node lists for IP addresses and onion addresses independently, meaning that the white / grey lists for IP addresses and onion addresses each have separate capacity limits of 1000 and 5000 addresses respectively.

[0047] The addresses in the gray list are sourced from the addresses in the handshake or timed synchronization response messages sent by neighboring nodes.

[0048] Address source for the whitelist: There are two ways to store addresses in the whitelist: one is for the node to move the address from the graylist to the whitelist, and the other is to add the address directly to the whitelist.

[0049] There are two opportunities for an address to be moved from the gray list to the white list: one is when a node establishes an outgoing connection handshake, and the other is when a node performs gray list housekeeping (state maintenance). If an outgoing connection is successfully established with an address in the gray list, it is moved from the gray list to the white list. The gray list housekeeping mechanism means that every minute, a node randomly selects an address from the gray list, checks its online status, and if it is online, moves it to the white list.

[0050] The following are the times when an address is directly added to the whitelist: For an incoming connection, the node will reverse connect to the incoming node and send a Ping request message. If the connection is successful and a Ping response message is received, it proves that the node can accept incoming connections, and the node will directly add it to the whitelist.

[0051] In addition, each node maintains a last_seen (most recently online) timestamp for each address in the whitelist to update the address's activity status. The update rules for the last_seen timestamp are as follows:

[0052] (1) When adding an address to the whitelist: When a node establishes an outgoing connection, performs gray list housekeeping, or makes a reverse connection to the open network, if it successfully connects to the address, it moves it from the gray list to the whitelist and sets its last_seen timestamp to the current time.

[0053] (2) During timed synchronization: The node updates the last_seen timestamp to the current time for the outgoing connection that returns the timed synchronization response message. It is worth noting that although the node performs timed synchronization with the incoming connection, it does not update the last_seen timestamp for it.

[0054] The address eviction mechanism for the node list is as follows: Since both the whitelist and graylist have capacity limits, when the capacity reaches the limit, the LRU (Least Recently Used) address eviction mechanism will be triggered. The whitelist and graylist use the same address eviction mechanism. Taking the whitelist as an example, when the whitelist reaches its capacity limit of 1000, the address with the oldest last_seen timestamp in the whitelist will be deleted.

[0055] Based on the analysis of the Monero network, the inventors of this invention considered that, due to the bidirectional symmetry of network connections, any outgoing connection from node B to node B necessarily corresponds to an incoming connection from node B. Therefore, unidirectional measurement of outgoing connections can obtain the directed topology of the entire Monero network. Based on this, this invention proposes a Monero network topology measurement method based on a differentiated update mechanism for whitelists after timed synchronization. This method maps the topology of the Monero public network by measuring the outgoing connections of public network nodes: The regulator first performs whitelist filling, filling the target node's whitelist with the regulator's address. When the target node completes its timed synchronization every minute, the target node only adds its own outgoing connection address to its own whitelist. At this time, the target node's whitelist contains the regulator's address and the target node's outgoing connection address. After the target node completes its timed synchronization, the regulator requests the target node's complete whitelist address. After filtering out the regulator's address, the target node's outgoing connection address can be obtained; thus, based on the outgoing connections of each node in the Monero network, the topology of the entire Monero network can be mapped.

[0056] In other words, the main idea of ​​this invention is as follows: For each reachable node in the Monero network, addresses from address set A are used to occupy the whitelist of that reachable node. After waiting for a set time period, the whitelist of that reachable node is obtained. The addresses in the obtained whitelist are compared with address set A to obtain a first set of differing addresses. Based on the first set of differing addresses, the outgoing connection nodes of that reachable node are determined. In this way, the outgoing connection nodes of each reachable node in the Monero network are determined, which is to say, the neighbor nodes of each reachable node in the Monero network are determined, thus completing the topology detection of the Monero network. Based on the determined outgoing connection nodes of each reachable node, the topology of the Monero network can be mapped. In this process, it is not necessary to send a large number of transactions into the network, avoiding intrusion into the network, and the topology of the Monero network can be obtained quickly and accurately. In this invention, nodes in the network that can respond to ICMPP Echo Request (Internet Control Message Protocol Echo Request) messages, i.e., ping request messages, and can return ICMPP Echo Reply (Internet Control Message Protocol Echo Reply), i.e. ping reply messages, are called reachable nodes; nodes that cannot respond to ping request messages or cannot return ping reply messages are called unreachable nodes; where reachable nodes represent nodes in public networks, and unreachable nodes represent nodes in private networks.

[0057] The inventors of this invention further considered that, based on the above main ideas, there are three technical challenges in implementing the technical solution of this invention: the topology mapping speed problem caused by the whitelist filling speed and the whitelist acquisition speed, the missed detection problem caused by the uncertainty of the completion time of the target node's timed synchronization, and the false detection problem caused by noisy addresses.

[0058] Regarding the issue of topology mapping speed, the inventors of this invention considered that the speed of whitelist filling and whitelist acquisition limits the time required to complete one round of topology probing. Therefore, this invention has carefully designed strategies for whitelist filling and whitelist acquisition to shorten the topology probing cycle and accelerate the topology probing speed.

[0059] Regarding the issue of missed detections, the inventors of this invention considered that due to the different performance of different nodes, the time it takes for different outgoing connections to send timed synchronization responses to the target node varies, resulting in differences in the time it takes for different nodes to complete timed synchronization. Since it is impossible to determine whether the target node has completed timed synchronization, obtaining the target node's whitelist before it has completed timed synchronization will lead to missed detections of outgoing connection addresses where the target node has not completed timed synchronization. Therefore, this invention, by evaluating the time required for each step in topology probing, designs a method to maximize the time the supervisor spends waiting for the target node to complete timed synchronization, thereby minimizing missed detections during topology probing.

[0060] To address the issue of false detections, the inventors of this invention considered that during topology probing, the target node's whitelist does not only contain the regulator's address and the target node's outgoing connection addresses, but also stores some noise addresses. These noise addresses include addresses moved to the whitelist when the target node performs greylist housekeeping and addresses of newly accepted incoming connections. The greylist housekeeping mechanism involves a node randomly selecting an address from the greylist every minute for online testing; if online, it is moved to the whitelist. These noise addresses can be falsely detected by the regulator as outgoing connections to the target address.

[0061] Therefore, this invention designs a noise address filtering method for two rounds of topology probing, such as... Figure 1 As shown, by taking advantage of the fact that the noise addresses in different rounds of topology probing hardly overlap, the intersection of the whitelists obtained from two rounds of topology probing is calculated to filter the noise addresses in the target node whitelist, thereby reducing false detections in the topology probing results.

[0062] The technical solutions of the embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0063] This invention provides a method for mapping the topology of the Monero network based on whitelist domination. The specific process is as follows: Figure 2As shown, it includes the following steps:

[0064] Step S201: Perform topology probing on the Monero network: For each reachable node in the Monero network, determine the outgoing connection nodes of that reachable node based on the whitelist occupation of that reachable node;

[0065] In this step, for each reachable node in the Monero network, the IP addresses in address set A are used to occupy the whitelist of that reachable node, and after waiting for a set time period, the whitelist of that reachable node is obtained; the IP addresses in the obtained whitelist are compared with address set A to obtain the first set of differing addresses; based on the first set of differing addresses, the outgoing connection nodes of that reachable node are determined; after determining the outgoing connection nodes of each reachable node, the topology probing of the Monero network is completed.

[0066] Considering the aforementioned noise addressing issue, as a better implementation method, this step can employ two rounds of topology probing: a first round of topology probing and a second round of topology probing.

[0067] In the first round of topology probing of the Monero network, for each reachable node in the Monero network, the outgoing connection nodes of that reachable node are determined as the result of the first round of topology probing. Specifically, the specific method and process for determining the first round of topology probing result for a particular reachable node in the first round of topology probing is as follows: Figure 3 As shown, it includes the following sub-steps:

[0068] Sub-step S301: Use the addresses in address set A to complete the capture of the reachable node from the whitelist;

[0069] The inventors of this invention considered that the technical difficulties of whitelist (filling) occupation for the purpose of topology detection are: 1) the filling speed cannot meet the speed requirements of topology mapping; 2) the robustness problem of the filling method, whether the whitelist filling is complete or not will affect the network mapping results.

[0070] To address the first challenge, this invention proposes a fast filling method that improves the whitelist filling speed through parallel handshakes. To address the second challenge, this invention proposes a filling retry mechanism to improve the robustness of the filling method.

[0071] Specifically, this invention improves whitelist filling speed through parallel filling. Serial filling refers to waiting for one IP address to successfully fill the target reachable node's whitelist via a reverse ping mechanism before another IP address initiates a handshake request; this process is repeated for 1000 IP addresses sequentially. The complete filling time for serial whitelist filling is approximately 2 minutes, which fails to meet the requirement of a minimum of 1 minute for topology mapping in the proposed method. Parallel filling, on the other hand, involves 1000 different controlled nodes simultaneously handshaking with the target reachable node, filling the reachable node's whitelist via a reverse ping mechanism. Parallel filling reduces the filling time to an average of approximately 5 seconds after each of the 1000 IP addresses performs a parallel handshake response with the target reachable node and is added to the whitelist. However, a single parallel handshake may not completely fill the whitelist due to the reachable node being busy; therefore, approximately 2-3 retry processes are required. The total complete filling time typically does not exceed 15 seconds, with an average time of 10 seconds. This speed fully meets the network mapping speed requirements of the proposed method.

[0072] Since the address of a controlled node may not be able to successfully enter the whitelist of the target reachable node after the controlled node sends a handshake request, this invention uses a filling retry mechanism to fill the whitelist in order to improve the robustness of the fast whitelist filling method.

[0073] There are two reasons why a regulator's address may not successfully enter the target node's whitelist after the regulator's controlled node sends a handshake request. The first reason is that the timeout control mechanism when Monero nodes send Ping messages may prevent the regulator's handshake request from successfully getting the target reachable node to send a Ping request message. The second reason is that after the target reachable node sends a Ping request message, it may not receive a Ping response due to reasons such as an unexpected connection loss, thus preventing the regulator's controlled node address from successfully entering the target reachable node's whitelist.

[0074] Timeout control mechanism when sending Ping messages: When sending a Ping request to establish a TCP connection, the node starts a timer to control connection timeout. If the connection is not successfully established within the set timeout period (2 seconds), the connection is closed. When sending a Ping request message, the node initiates a TCP (Transmission Control Protocol) connection operation via `async_connect`. `async_connect` is asynchronous; after a successful TCP connection, a callback function is called. This callback function attempts to cancel the timer to prevent the timer timeout callback from mistakenly closing a successfully established connection before sending the Ping request message again. In the scenario described in this invention, because the supervisor's controlled nodes simultaneously send 1000 handshake requests, the target reachable nodes need to send 1000 handshake responses and Ping requests, causing the target reachable nodes to be busy. Although the TCP connection for the Ping request is successfully established within the timeout period, due to the busy target reachable nodes, the connection success callback is not executed in time, and the timer is not canceled in time. The timeout timer callback executes before the timer cancellation operation, causing the node to mistakenly judge the TCP connection as timed out and thus close the TCP connection. Therefore, this timeout control mechanism can sometimes cause the target reachable node to fail to send a Ping request message.

[0075] This invention performs retrying by checking the target node whitelist, ensuring that the controlled node addresses of all regulators can be successfully added to the target node's whitelist.

[0076] Therefore, based on the above analysis steps, assuming the IP address set of the 1000 controlled nodes of the regulator is A, the parallel filling method adopted is as follows: the 1000 controlled nodes whose addresses are in the address set A simultaneously initiate handshake requests to the reachable node of the target, so that the reachable node fills the addresses of these controlled nodes into the whitelist of the reachable node; wherein, the IP addresses of the controlled nodes are included in the address set A.

[0077] More preferably, this sub-step can also robustly fill the whitelist of the reachable node based on a filling retry mechanism: obtain the IP addresses in the whitelist of the reachable node and form an address set S; compare the differences between set A and set S; if there are addresses in A that do not belong to set S, then use the controlled nodes corresponding to these addresses to initiate a handshake request to the reachable node again, so that the reachable node fills the addresses of these controlled nodes into the whitelist of the reachable node.

[0078] Comparing the effects and time required when using and not using whitelist filling retries: When the filling retry mechanism is not used, when performing whitelist filling 50 times on a controllable target reachable node, 1000 Ping request messages can be received from the target reachable node in 30 attempts, and less than 1000 Ping request messages can be received from the target reachable node in 20 attempts.

[0079] Sub-step S302: Wait for the reachable node to complete the timed synchronization;

[0080] In this sub-step, after completing the whitelist acquisition of the reachable node, a set time period is waited for the reachable node to complete the timed synchronization; preferably, the set time period can be between 20 seconds and 40 seconds.

[0081] Specifically, the inventors of this invention analyzed the changes in the whitelist before and after the execution of the timed synchronization mechanism at the target reachable node. They found that after the target reachable node executes the timed synchronization mechanism, the IP addresses of the outgoing connection nodes that were previously removed from the whitelist will be added back to the whitelist, and only the IP addresses of the outgoing connections of the target reachable node will be added.

[0082] When a node shakes hands with its outgoing connection nodes, the addresses of the outgoing connection nodes that successfully complete the handshake are added to a whitelist. When a node accepts an incoming connection handshake request, it adds the addresses of the incoming connection nodes that can receive the connection to the whitelist. However, when a node sends a timed synchronization request message to all its neighboring nodes (including incoming and outgoing connections) every minute, the handling of outgoing and incoming connections that return a timed synchronization response is different.

[0083] (1) Processing of the node's timed synchronization response message returned by the outgoing connection. If the outgoing connection address is already in the whitelist, its last_seen timestamp is updated to the current time; if the outgoing connection address is not in the whitelist, it is added to the whitelist and its last_seen timestamp is set to the current time.

[0084] (2) Node processing of timed synchronization response messages returned by the node for incoming connections. No whitelist-related operations are performed; the last_seen timestamp is neither updated nor re-added to the whitelist. This restriction on whitelist-related operations for incoming connections helps Monero nodes resist eclipse attacks based on incoming connections.

[0085] This differentiated whitelist update mechanism during timed synchronization is advantageous for the topology mapping method of this invention. Incoming connection addresses, once removed from the whitelist by the regulator, will not be added back to the whitelist, while outgoing connections, after being removed, will be added back to the whitelist. The regulator does not need to actively distinguish between outgoing and incoming connections of the target node.

[0086] Regulators can monitor whether a target node is performing a timed synchronization mechanism by deploying Monero probe nodes. The probe node connects to and maintains the connection with the target node. If the probe node receives a timed synchronization request from the target node, it can determine that the target node is performing timed synchronization. Regulators set the timed synchronization wait time to y seconds, waiting for the target node's outgoing connection to send a timed synchronization response, for the target node to re-add the outgoing connection to its whitelist, and then begin obtaining the target node's whitelist.

[0087] The process of a node returning to the whitelist after its outgoing connection address has been removed is as follows: The removed target node sends a timed synchronization request to its outgoing connection node. If the outgoing connection node returns a timed synchronization response message to the target node within 120 seconds, the target node adds the outgoing connection back to the whitelist upon receiving the response. If the outgoing connection does not return a timed synchronization response message to the target node within 120 seconds, the target node disconnects from the outgoing connection.

[0088] To evaluate the setting of time y, this invention measured the response time of all nodes in the Monero mainnet to timed synchronization request messages. A Python program was written to send timed synchronization request messages to all nodes in the Monero mainnet and receive the timed synchronization response messages returned by these nodes. The time required for each node in the Monero mainnet to respond to the timed synchronization request message was obtained by subtracting the timestamp of the timed synchronization request message sent by the program from the timestamp of the timed synchronization response message returned by the node. Considering that the performance of each node in responding to timed synchronization may fluctuate, this invention made multiple timed synchronization requests to each node. For example, this invention sent 5 timed synchronization request messages to each of the 3129 online nodes in the network, totaling 15645 timed synchronization request messages. The response status of these 15645 requests is shown in the table. The setting of time y requires a trade-off between the measurement speed of topology measurement and the missed detection rate.

[0089] Assume the time for one round of topology probing is T. The time for one round of topology probing consists of three parts: the time x for whitelist filling, the time y for waiting for the target node to complete timed synchronization, and the time z for obtaining the target node's whitelist. Therefore, T = x + y + z. Since the topology probing method of this invention relies on a timed synchronization mechanism once per minute, the fastest time to complete one round of topology probing is one minute, meaning T is at least 60 seconds, and T is a multiple of 60 seconds. When T is set to 60 seconds, the time y for waiting for the target node to complete timed synchronization is mainly to reduce the false negative rate. However, the response to timed synchronization requests shows that increasing y from 20 seconds to 40 seconds only increases the response rate by 0.8%, and the improvement in the false negative rate is not significant. Conversely, to complete topology probing more accurately, whitelist filling and whitelist acquisition need to be performed as completely as possible; therefore, more time needs to be allocated for these two steps. The time required for whitelist filling is usually no more than 15 seconds, with an average time of 10 seconds, and the average time for obtaining the complete whitelist is about 5 seconds, but in practice, it often exceeds the average time. Therefore, 1) when the regulator needs to measure the topology as quickly as possible and sets T to 60 seconds, it is more appropriate to set the waiting time y for the timed synchronization to be completed to 20 seconds. This allows for a sufficient 40 seconds for whitelist filling and whitelist acquisition, thereby improving detection accuracy; 2) when the regulator needs to ensure the lowest false negative rate, the waiting time y for the target node to complete the timed synchronization can be set to 120 seconds. At this time, the false negative rate is the lowest, and the corresponding total topology detection time T is 180 seconds.

[0090] Table 1

[0091]

[0092] Sub-step S303: Obtain the whitelist of reachable nodes;

[0093] In this sub-step, the regulator can obtain the addresses in the whitelist of the reachable node by continuously sending multiple timed synchronization requests from the controlled node to the reachable node.

[0094] In a more preferred implementation, after a controlled node continuously sends at least 60 timed synchronization requests to the reachable node, it receives the timed synchronization responses returned sequentially by the reachable node and obtains the node list addresses from the timed synchronization responses. In fact, experiments have shown that the node list addresses in the 60 timed synchronization responses can typically contain 1,000 different addresses, which can complete the acquisition of the whitelist of the reachable node.

[0095] Specifically, regulators can obtain a target node's whitelist by continuously sending multiple timed synchronization requests to that node. When a Monero node sends a timed synchronization response message, it randomly selects 250 whitelisted addresses, filters out addresses already sent to in the current connection, and only sends to addresses not previously sent to from those 250 addresses. Therefore, to ensure regulators can obtain the target node's complete whitelist, they can establish a new connection with the target node, ensuring that there is no history of the target node sending addresses to the regulator in that connection. By immediately sending several timed synchronization requests after establishing a connection with the target node, the complete whitelist of addresses can be obtained from the handshake and timed synchronization responses.

[0096] Monero nodes have a whitelist limit of 1000 addresses. When sending a timed synchronization response message, a node first randomly selects 250 addresses from the whitelist, and then only sends messages to addresses among these 250 that the node has not previously sent to that neighboring node. Therefore, this random address sending mechanism makes it impossible for regulators to know in advance how many timed synchronization requests will be needed to obtain the target node's whitelist.

[0097] There are two methods to obtain a Monero whitelist. The first method is to send timed synchronization request messages sequentially one by one, and the second method is to send timed synchronization request messages in batches.

[0098] (1) Sequential Requests: After sending a timed synchronization request to the target node, wait for the timed synchronization response, process the node list addresses in the timed synchronization response, and then send the next timed synchronization request. After receiving 1000 different addresses from the target node, stop sending timed synchronization requests and complete the acquisition of the whitelist.

[0099] (2) Batch Requests: Send n timed synchronization requests in batches, then read the timed synchronization responses in batches, and process the node list addresses in the timed synchronization responses. To statistically analyze the number of requests required for the regulator to obtain the complete whitelist of target nodes, this invention developed a Python script to simulate the target node address sending mechanism. This invention conducted 100,000 independent and repeated experiments, and statistically analyzed the frequency distribution of the number of requests required by the regulator, such as... Figure 4 As shown in the figure. Experimental results show that by having the target node perform 60 address transmissions, i.e., the supervisor sends 60 timed synchronization request messages, the complete whitelist of the target node can be obtained with a very high probability.

[0100] The sequential request method requires waiting for a timed synchronization response message before sending the next timed synchronization request message, but requires fewer requests. The batch request method does not require waiting for a timed synchronization response message before sending n timed synchronization request messages, but requires more requests. This invention experimentally evaluated the time required for these two methods to obtain the whitelist, demonstrating that the batch request method requires significantly less time than the sequential request method. For example, this invention used both methods to obtain the whitelist from 2907 nodes across the entire network and recorded the time required. The experimental results are shown in Table 2. The median time required for the sequential request method was 5.2 seconds, while the median time required for the batch request method was 0.8 seconds. The batch request method requires significantly less time than the sequential request method. Therefore, this invention uses the batch request method to obtain the node whitelist.

[0101] Table 2

[0102]

[0103] Sub-step S304: Compare the addresses in the obtained whitelist with the address set A to obtain the first set of differing addresses, which serves as the result of the first round of topology probing;

[0104] In this sub-step, the addresses in the obtained whitelist are compared with address set A. The addresses in the obtained whitelist that do not belong to address set A are formed into the first differential address set, which is used as the result of the first round of topology probing.

[0105] The inventors of this invention further discovered that after a round of topology probing, the target node's whitelist does not only contain the target node's outgoing connections and the regulator's address, but also some additional addresses. These additional addresses can affect the regulator's judgment of the target node's outgoing connections, and may be mistakenly identified as the target node's outgoing connections. Therefore, this invention refers to them as noise addresses. The sources of noise addresses are twofold: 1) addresses of nodes reachable when the target node executes the greylist housekeeping mechanism; 2) addresses of nodes reachable in newly accepted incoming connections to the target node.

[0106] Therefore, as a better implementation method, the present invention designs an iterative intersection denoising method. Taking advantage of the fact that the noise addresses in different rounds of topology probing hardly overlap, the intersection of the whitelists obtained by two rounds of topology probing is calculated to filter the noise addresses in the target node whitelist, so as to reduce false detections in the topology probing results.

[0107] Based on this, in step S201, during the second round of topology probing of the Monero network, for each reachable node in the Monero network, the outgoing connection node of that reachable node can be determined as the result of the second round of topology probing. The specific process of the second round of topology probing of the Monero network is as follows: Figure 5 As shown, it includes the following sub-steps:

[0108] Sub-step S501: For each reachable node in the Monero network, use the addresses in address set B to complete the occupation of that reachable node again;

[0109] In this sub-step, 1000 controlled nodes whose addresses are in address set B simultaneously initiate handshake requests to the target reachable node, causing the reachable node to fill the addresses of these controlled nodes into its whitelist; wherein, address set B contains the IP addresses of 1000 controlled nodes; in a preferred embodiment, the addresses contained in address set B are completely different from the addresses contained in address set A.

[0110] Specifically, the Monero network allows nodes to directly add incoming connections to a whitelist (via reverse new connections and Ping messages), and the default whitelist capacity is 1000. Therefore, regulators can organize 1000 nodes with independent IP addresses to simultaneously connect to the target node, quickly filling the target node's whitelist in parallel. However, continuous topology measurement requires multiple rounds of whitelist filling, and the IP resources required by regulators for multiple rounds of parallel whitelist filling differ from those for a single round. This is because parallel filling results in a different connection order between the regulator's IP address and the target node in each round. If the second round of filling still uses the same IP resources, the different connection order in each round may prevent the second round from achieving the goal of expelling the connection addresses and noisy addresses transmitted at the end of the previous round of topology probing. In multi-round parallel whitelist filling, 2000 IP addresses can guarantee successful whitelist filling in each round. The 2000 IP addresses are divided into two groups of 1000 each, and the two groups are used for whitelist filling in rotation.

[0111] In fact, the inventors of this invention, through experiments with only 1000 IPs and multiple rounds of filling processes, discovered that due to different connection orders, the second round of the parallel filling method could not completely fill the whitelist, as detailed below:

[0112] When an incoming connection address is added to the whitelist, if the address is already in the whitelist, the node will not update the last_seen timestamp of the incoming connection because the node considers the incoming connection an untrusted source.

[0113] 1) Initial whitelist filling. When the regulator only has 1000 IP addresses, after the regulator's address enters the target node's whitelist in the first round, the target node's whitelist only contains the regulator's address, and the regulator's address is in the same order as the 1000 regulator addresses, with the last_seen timestamp from oldest to newest.

[0114] 2) At the end of the first round of topology probing. When the first round of topology probing ends, the target node's 12 outgoing connection addresses and noisy addresses will remove some of the earliest connected addresses from the regulator's whitelist.

[0115] 3) Second Round of Whitelist Filling. It's necessary to distinguish between cases where the connection order is the same or different in the two rounds of whitelist filling by the regulator. When the connection order in the second round is the same as the first round (i.e., serial filling), at the beginning of each connection, the address of that connection has already been expelled from the whitelist by other addresses. Therefore, the address of that connection will be directly added to the whitelist, allowing all 1000 IP addresses of the regulator to be added. When the connection order in the second round is different from the first round (i.e., parallel filling), some addresses of the regulator may still exist in the whitelist. In these cases, other addresses will not be expelled from the whitelist, and the last_seen timestamp will not be updated. Ultimately, some outgoing connection addresses and noisy addresses from the previous round of topology probing will not be expelled.

[0116] To more clearly illustrate that the parallel filling method cannot completely fill the whitelist in the second round due to different connection order, this invention assumes that the target node's whitelist capacity is 10 and the maximum number of outgoing connections is 2 (for illustration only; actual values ​​may differ). Suppose the regulator has 10 addresses with the same capacity as the whitelist, numbered from IP (attacker1) to IP (attacker10).

[0117] 1) Initial Whitelist Population: Assuming that during the initial whitelist population, regulators control according to...

[0118] The target nodes are connected in the order of IP(attacker1)→IP(attacker10). When the regulator completes the first round of whitelist filling, the whitelist of the target nodes is sorted from oldest to newest by last_seen timestamp as [IP(attacker1)(oldest),,…,IP(attacker10)(newest)].

[0119] 2) At the end of the first round of topology probing: When the first round of topology probing is completed, the target node's whitelist may become [IP(attacker4)(oldest), ..., IP(attacker10), IP(noise), IP(out1), IP(out2)(newest)]. Among them, the noise address IP(noise) expelled IP(attacker1) from the whitelist; the target node's outgoing connection addresses IP(out1) and IP(out2) expelled IP(attacker2) and IP(attacker3) from the whitelist, respectively.

[0120] 3) Second round of whitelist filling:

[0121] ① If the connection order of the whitelist filling in the two rounds by the regulator is the same (serial filling): In the second round, the regulator still connects to the target node in the order of IP(attacker1)→IP(attacker10), which will trigger a chain of expulsions: IP(attacker1) expels IP(attacker4)→IP(attacker2) expels IP(attacker5)→…→

[0122] IP(attacker7) evicts IP(attacker10) → IP(attacker8) evicts IP(noise) → IP(attacker9) evicts IP(out1) → IP(attacker10) evicts IP(out2). The supervisor address can evict outgoing connection addresses and noise addresses from the previous round of topology probing from the target node's whitelist and complete the whitelist filling.

[0123] If the connection order of the whitelist filling in the two rounds by the regulator is different (parallel filling): when the connection order of the second round by the regulator is different from that of the first round, for example, connecting the target node in the order of IP (attacker10) → IP (attacker1).

[0124] Since the addresses of the first 7 connections (IP(attacker10)→IP(attacker4)) are already in the whitelist, these 7 addresses will not expel other addresses, and the whitelist will not update the last_seen timestamp for these 7 addresses. Therefore, after the first 7 connections, the whitelist is the same as at the end of the first round of topology probing, which is still [IP(attacker4)(oldest),……,IP(attacker10),IP(noise),IP(out1),IP(out2)(out2)(latest)].

[0125] After the regulator's last three connections (IP(attacker3) → IP(attacker1)) connect to the target node, IP(attacker3) evicts IP(attacker4) → IP(attacker2) evicts IP(attacker5) →

[0126] IP (attacker1) bans IP (attacker6), and the whitelist becomes [IP (attacker7) ~ (oldest),

[0127] [IP(attacker8), IP(attacker9), IP(attacker10), IP(noise), IP(out1), IP(out2), IP(attacker3), IP(attacker2), IP(attacker1)(latest)], the regulator has not completely removed outgoing connection addresses and noisy addresses (IP(noise), IP(out1), IP(out2)) from the end of the previous round of topology probing. In particular, the noisy address IP(noise) from the first round was not removed from the whitelist, which will prevent the regulator from completing the noisy address filtering.

[0128] Therefore, if the regulator only has 1000 IP addresses, it needs to ensure that the connection order for both rounds of whitelist filling is consistent (serial filling); otherwise, the second round of whitelist filling may not be completed. If the regulator has 2000 IP addresses, these 2000 IP addresses can be divided into two groups for parallel filling. The two groups of IP addresses can be used alternately to whitelist the target nodes, and the connection order does not need to be considered to ensure that both rounds of whitelist filling are successful.

[0129] Sub-step S502: Wait for the reachable node to complete the timed synchronization;

[0130] In this sub-step, after completing the second whitelist occupation of the reachable node, a set time period is waited for the reachable node to complete the timed synchronization; preferably, the set time period can be between 20 seconds and 40 seconds.

[0131] Sub-step S503: Obtain the whitelist of reachable nodes;

[0132] In this sub-step, the regulator can obtain the whitelist of reachable nodes by continuously sending multiple timed synchronization requests from the controlled node to the reachable node.

[0133] In a more preferred implementation, after a controlled node continuously sends at least 60 timed synchronization requests to the reachable node, it receives the timed synchronization responses returned sequentially by the reachable node. After confirming that the node list address in the received timed synchronization response contains 1,000 different addresses, the whitelist acquisition of the reachable node is completed.

[0134] Sub-step S504: Compare the addresses in the obtained whitelist with the address set B to obtain the second set of differing addresses, which serves as the result of the second round of topology probing;

[0135] In this sub-step, the addresses in the obtained whitelist are compared with address set B. Addresses in the obtained whitelist that do not belong to address set B are combined to form a second set of differential addresses, which serves as the result of the second round of topology probing.

[0136] Step S202: Based on the topology detection results, map the topology of the Monero network.

[0137] In this step, the topology of the Monero network is obtained by identifying the outgoing connections of each reachable node in the Monero network based on the topology detection results. In other words, by detecting the outgoing connections of each reachable node, the reachable nodes and their neighbor relationships are determined, thereby obtaining the detected topology of the Monero network. In other words, the topology of the Monero network can be mapped based on this.

[0138] As a better implementation, the final topology detection result can be obtained based on the results of two rounds of topology detection: For each reachable node in the Monero network, the intersection of the first round topology detection result and the second round topology detection result of the reachable node is taken, that is, the intersection of the first set of differences and the second set of differences of the reachable node is taken to obtain the final set of differences; based on the final set of differences, the address of the outgoing connection node of the reachable node is determined; thus, the outgoing connection node of the reachable node is finally determined.

[0139] Specifically, after the first round of topology probing, the target node's whitelist includes (the hunter's address A, the target node's outgoing connection address O, and the noise address set N1). After the hunter's second round of topology probing, the target node's whitelist includes (the hunter's address A, the target node's outgoing connection address O, and the noise address set N2). Analysis shows that the noise addresses from adjacent rounds of topology probing are almost non-overlapping (i.e., noise address set N1 ∩ noise address set N2). Therefore, by finding the intersection of the whitelists of the target nodes obtained from the two topology probes, most of the noisy addresses can be filtered out, and the regulator address A and the outgoing connection address O of the target node can be obtained.

[0140] The key to the effectiveness of the iterative intersection denoising method lies in the conclusion that noise addresses from adjacent rounds of topology probing are almost non-overlapping. This invention analyzes two noise sources to illustrate why this conclusion holds true. In this analysis, the topology probing of two adjacent rounds is referred to as the first round and the second round of topology probing. Table 3 shows the four types of noise address sources from adjacent rounds of topology probing. This invention needs to analyze that the addresses of the first round noise source type and the addresses of the second round noise source type are almost non-overlapping in these four cases.

[0141] Table 3

[0142]

[0143] When a node establishes a new (12th) outgoing connection, it will first select an address from its gray list for connection. Only after three failed attempts to connect to an address in its gray list will it select an address from its white list. Therefore, it is less likely to select an address in its white list for connection.

[0144] Scenario 1: In the first round of topology probing, the reachable node set H1 during greylist housekeeping will be moved from the greylist to the whitelist, meaning H1 is no longer in the greylist. In the second round of topology probing, since H1 is no longer in the greylist, it will not be selected by the greylist housekeeping mechanism. Therefore, the reachable node set H2 in the second round of greylist housekeeping will not contain any addresses of H1.

[0145] Scenario 2: In the first round of topology probing, after the target node performs a greylist housekeeping mechanism on the reachable node address set H1, the target node's address will be added to the whitelist of reachable node set H1 (due to the anti-ping mechanism). In the second round of topology probing, if the reachable node set H1 has no outgoing connections broken, it will not connect to the target node. If the reachable node set H1 has outgoing connections broken, it is less likely to choose a target node stored in its whitelist when selecting a new outgoing connection.

[0146] Scenario 3: The reachable node I1 in the new incoming connection during the first round of topology probing may not appear in the target node's gray list during the second round of topology probing. Even if it exists in the target node's gray list, there is only a 1 / 5000 probability that I1 will be selected.

[0147] Scenario 4: If an incoming connection remains open during both rounds of topology probing, according to the whitelist update mechanism during timed synchronization, the incoming connection address newly added to the whitelist in the first round will no longer appear in the target node's whitelist after the whitelist is filled in the second round of topology probing. If the connection between the new incoming connection I1 in the first round and the target node is broken, there is a low probability that a target node stored in its whitelist will be selected when choosing a new outgoing connection.

[0148] In this invention, for each reachable node in the Monero network, addresses from address set A are used to claim a whitelist of that node. After a set time period, the whitelist of that node is retrieved. The addresses in the retrieved whitelist are compared with address set A to obtain a first set of differing addresses. Based on this first set of differing addresses, the outgoing connection nodes of that reachable node are determined. Based on the determined outgoing connection nodes of each reachable node, the topology of the Monero network is mapped. This process avoids sending a large number of transactions into the network, preventing network intrusion, and allows for high-speed and accurate acquisition of the Monero network topology.

[0149] In addition, this invention designs a noise address filtering method for two rounds of topology probing. Taking advantage of the fact that the noise addresses in the first round of topology probing and the second round of topology probing hardly overlap, the intersection of the whitelists obtained by the two rounds of topology probing is calculated to filter the noise addresses in the target node whitelist, so as to reduce false detections in the topology probing results.

[0150] Furthermore, considering that the whitelist filling speed and whitelist acquisition speed limit the time required to complete a round of topology probing, this invention has carefully designed a strategy of obtaining the whitelist after whitelist filling and comparing it with the address used for filling. If there is a difference, the whitelist is filled again to shorten the topology probing cycle and speed up the topology probing.

[0151] Furthermore, due to varying performance across nodes, the time it takes for different outgoing connections to send timed synchronization responses to the target node differs, resulting in variations in the time it takes for different nodes to complete timed synchronization. Since it's impossible to determine whether the target node has completed timed synchronization, obtaining the target node's whitelist before it has done so will lead to missed outgoing connection addresses for which timed synchronization has not been completed. Therefore, this invention, by evaluating the time required for each step in topology probing, designs a method to maximize the time the supervisor waits for the target node to complete timed synchronization to between 20 and 40 seconds, thereby minimizing missed detections during topology probing.

[0152] Figure 6This illustration schematically shows the hardware architecture of a computer device 1300 for mapping the Monero network topology based on a whitelist-based occupation method according to an embodiment of this application. In this embodiment, the computer device 1300 is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. For example, it may be a smartphone, tablet, laptop, desktop computer, rack server, blade server, tower server, or cabinet server (including standalone servers or server clusters composed of multiple servers), etc. Figure 6 As shown, the computer device 1300 includes, but is not limited to, at least: a memory 1310, a processor 1320, and a network interface 1330 that can communicate with each other via a system bus. Wherein:

[0153] The memory 1310 includes at least one type of computer-readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 1310 may be an internal storage module of the computer device 1300, such as the hard disk or memory of the computer device 1300. In other embodiments, the memory 1310 may also be an external storage device of the computer device 1300, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. Of course, the memory 1310 may also include both the internal storage module and the external storage device of the computer device 1300. In this embodiment, the memory 1310 is typically used to store the operating system and various application software installed on the computer device 1300, such as the program code for a Monero network topology mapping method based on whitelist occupation. In addition, the memory 1310 can also be used to temporarily store various types of data that have been output or will be output.

[0154] In some embodiments, processor 1320 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip. Processor 1320 is typically used to control the overall operation of computer device 1300, such as performing control and processing related to data interaction or communication with computer device 1300. In this embodiment, processor 1320 is used to run program code stored in memory 1310 or process data.

[0155] Network interface 1330 may include a wireless network interface or a wired network interface, which is typically used to establish a communication link between computer device 1300 and other computer devices. For example, network interface 1330 is used to connect computer device 1300 to an external terminal via a network, establishing a data transmission channel and communication link between computer device 1300 and the external terminal. The network may be an intranet, the Internet, Global System for Mobile Communication (GSM), Wideband Code Division Multiple Access (WCDMA), 4G network, 5G network, Bluetooth, Wi-Fi, or other wireless or wired networks.

[0156] It should be pointed out that, Figure 6 Only a computer device with components 1310-1330 is shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0157] In this embodiment, the Monero network topology mapping method based on whitelist occupation stored in memory 1310 can be further divided into one or more program modules and executed by one or more processors (processor 1320 in this embodiment) to complete the embodiment of this application.

[0158] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0159] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this disclosure (including the claims) is limited to these examples; within the framework of this invention, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of the different aspects of the invention as described above, which are not provided in the details for the sake of brevity.

[0160] Additionally, to simplify the description and discussion, and to avoid obscuring the invention, the well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the invention, and this also takes into account the fact that the details of implementation of these block diagram apparatuses are highly dependent on the platform on which the invention will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) are set forth to describe exemplary embodiments of the invention, it will be apparent to those skilled in the art that the invention may be practiced without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0161] Although the invention has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0162] The embodiments of this invention are intended to cover all such substitutions, modifications, and variations falling within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for mapping the topology of the Monero network based on whitelist occupation, characterized in that, include: For each reachable node in the Monero network, use addresses from address set A to occupy the whitelist of that reachable node, and after waiting for a set time period, obtain the whitelist of that reachable node. The addresses in the obtained whitelist are compared with the address set A to obtain the first set of differing addresses; The address set B contains 1000 controlled nodes, which are then used to reclaim the whitelist of the reachable node. After waiting for a set period of time, the whitelist of the reachable node is obtained. The addresses in the obtained whitelist are compared with the address set B to obtain a second set of differing addresses. The intersection of the first set of differing addresses and the second set of differing addresses is used to obtain the final set of differing addresses. Based on the final set of differing addresses, determine the outgoing connection node for that reachable node; Based on the outgoing connection nodes of each reachable node, the topology of the Monero network is obtained. The addresses contained in address set B are completely different from those contained in address set A.

2. The method according to claim 1, characterized in that, The set time period is specifically between 20 and 40 seconds.

3. The method according to claim 1, characterized in that, The process of acquiring the whitelist of reachable nodes specifically includes: By having 1000 controlled nodes simultaneously initiate handshake requests to the reachable node, the reachable node can fill in the addresses of these controlled nodes into its whitelist. The address of the controlled node is contained in the address set A.

4. The method according to claim 3, characterized in that, Before comparing the addresses in the obtained whitelist with the address set A, the following steps are also included: Obtain the addresses from the whitelist of the reachable node and form an address set S; Compare the differences between set A and set S; if there are addresses in A that do not belong to set S, then use the controlled nodes corresponding to these addresses to initiate a handshake request to the reachable node again, so that the reachable node fills these addresses into the whitelist of the reachable node.

5. The method according to claim 1, characterized in that, Obtaining the whitelist of reachable nodes specifically includes: The controlled node continuously sends multiple timed synchronization requests to the reachable node to obtain addresses from the reachable node's whitelist.

6. A computer device, the computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it is used to implement the steps of the Monero network topology mapping method based on whitelist occupation as described in any one of claims 1 to 5.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that can be executed by at least one processor to cause the at least one processor to perform the steps of the Monero network topology mapping method based on whitelist occupation as described in any one of claims 1 to 5.

Images