From dc48ea128e4d7a45089b39ba9953ecb789b26f46 Mon Sep 17 00:00:00 2001 From: KaKeimei Date: Mon, 3 Jun 2024 14:18:46 +0900 Subject: [PATCH] translate some mining articles --- .../mining/concepts/mining-reward-maturity.md | 51 +++ docs/mining/concepts/reorg-orphan-51attack.md | 169 ++++++++++ docs/mining/concepts/small-world-model.md | 116 ++++++- docs/mining/concepts/stratum-protocol.md | 311 +++++++++++++++++- docs/mining/concepts/supply-halving.md | 105 ++++++ 5 files changed, 750 insertions(+), 2 deletions(-) diff --git a/docs/mining/concepts/mining-reward-maturity.md b/docs/mining/concepts/mining-reward-maturity.md index a78f5fa..b63b1f2 100644 --- a/docs/mining/concepts/mining-reward-maturity.md +++ b/docs/mining/concepts/mining-reward-maturity.md @@ -3,3 +3,54 @@ sidebar_position: 6 --- # Mining Reward Maturity + +How long it takes to spend rewards after a block is mined. + +The MVC mining reward maturity period refers to the time that newly mined MVC must wait on the blockchain network before +it can be used for transactions or transfers. In the MVC network, this maturity period is typically 100 blocks. This +means that after a miner successfully mines a block and receives an MVC reward, they must wait for approximately 100 +blocks before these MVCs are considered mature and usable. + +The reasons for setting the maturity period in MVC, like in other POW blockchain networks, are mainly to maintain +network security and stability. + +## Why is there a Maturity Period + +The maturity period is established for the following reasons: + +1. **Network Security**: By setting a maturity period, it can prevent miners from executing double-spending attacks on + the network. If a miner tries to reorganize the blockchain (for example, attempting to reverse already confirmed + transactions), the maturity period makes such attacks more difficult because the attacker would need to re-mine a + large number of blocks. + +2. **Blockchain Stability**: The maturity period can increase the stability of the blockchain, preventing short-term + block reorganizations from affecting miner rewards and transaction confirmations. + +3. **Consistency**: During the maturity period, network nodes have time to confirm the legality of newly mined blocks + and transactions, ensuring consistency in the blockchain state across all nodes. + +## How to Calculate the Maturity Period + +Calculating the maturity period is relatively simple, involving the following basic steps: + +1. **Mine a New Block**: A miner successfully mines a new block and receives a reward, for example, at block height `n`. + +2. **Wait for 100 Blocks**: The miner needs to wait for 100 blocks to be mined after this block. This means that when + the blockchain reaches height `n+100`, the newly mined MVC rewards will mature and become usable. + +Assuming the MVC network mines a new block approximately every 10 minutes, the maturity period would be about 10 minutes +multiplied by 100, which is approximately 1000 minutes (about 16.67 hours). + +## Example Explanation + +If a miner mines a block at block height `70000` and receives a reward, these reward MVCs must wait until the block +height reaches `70100` before they can be used. During this period, the miner can see these rewards in their wallet but +cannot perform any transactions with them. + +Through this process, the MVC network ensures that newly mined MVCs have sufficient time to be confirmed by the network +before they are used, thereby maintaining network security and consistency. + +## Handling of the Maturity Period by MVCPool + +MVCPool will wait for the reward to mature before distributing it after the reward calculation is completed. During this +period, the confirmation number of the maturity period will be displayed. diff --git a/docs/mining/concepts/reorg-orphan-51attack.md b/docs/mining/concepts/reorg-orphan-51attack.md index be9616c..91ed24c 100644 --- a/docs/mining/concepts/reorg-orphan-51attack.md +++ b/docs/mining/concepts/reorg-orphan-51attack.md @@ -3,3 +3,172 @@ sidebar_position: 8 --- # Reorg, Orphan, and 51% Attack + +Key mechanisms for resolving conflicts and achieving consensus in POW. + +In the POW process, miners compete to solve a mathematical problem to receive mining rewards. The process of solving +this problem is random, so different miners might find different solutions simultaneously. When different miners find +different solutions at the same time, a fork occurs. + +To ensure the uniqueness of the blockchain, the consensus network will select one fork as the main chain and consider +the other forks as orphaned forks. + +## Block Reorganization + +Block reorganization (reorg) refers to the process where existing blocks in the blockchain are replaced by a new, longer +chain. This phenomenon occurs when two or more miners almost simultaneously mine valid blocks, and these blocks are +added to the end of the chain. However, due to network propagation delays, different nodes might receive different +blocks, temporarily creating multiple forked chains. + +POW follows the longest chain principle or the maximum work principle. Therefore, if multiple forks exist +simultaneously, the consensus network will choose the fork with the largest workload as the main chain, and the other +forks will be isolated, with all transactions in the isolated forks being rolled back (if a transaction exists in +multiple forks, it will only take effect once in the final accepted chain). + +### Why Block Reorganizations Occur + +Block reorganizations mainly occur due to the following reasons: + +1. **Simultaneous Discovery of New Blocks**: If two miners almost simultaneously find valid blocks, these blocks will be + added to the end of the chain. However, due to network propagation delays, some nodes will receive one block, while + other nodes will receive the other block, forming a temporary fork. + +2. **Network Delays**: Since the MVC network is distributed, network delays can cause different nodes to receive new + blocks at different times, leading to temporary forks. + +3. **Network Attacks**: In some cases, malicious miners may attempt to reorganize the blockchain to execute + double-spending attacks. The attacker will try to mine a forked chain and hope that this chain becomes longer than + the original chain, thus becoming the main chain. + +### Block Reorganization Process + +1. **Forming a Fork**: Suppose after block height `N`, miners A and B almost simultaneously find two new valid + blocks `N+1A` and `N+1B`. Some nodes will receive `N+1A`, while others will receive `N+1B`. + +2. **Propagation and Confirmation**: Over time, miners continue working and mining new blocks. Suppose miner C + finds `N+2A` based on `N+1A`, and miner D finds `N+2B` based on `N+1B`. + +3. **Selecting the Longest Chain (Maximum Workload)**: According to MVC protocol, nodes will select the longest received + chain as the main chain. If both `N+1A` and `N+1B` chains each generate a new block, both chains have the same length + with no priority. Until a new block, say `N+3A`, is found on the `N+1A` chain, making it longer, nodes will consider + the `N+1A` chain as the main chain. + +4. **Reorganization**: Once the `N+1A` chain is confirmed as the main chain, all nodes holding the `N+1B` chain will + discard `N+1B` and `N+2B` and accept the `N+1A` chain and its subsequent blocks. This process is known as block + reorganization. + +### Effects of Block Reorganization + +1. **Transaction Confirmation**: During reorganization, some transactions confirmed on the discarded chain may become + invalid. These transactions will return to the memory pool and await re-confirmation on the new chain. + +2. **Network Security**: Frequent block reorganizations can affect network stability. However, MVC network's difficulty + adjustment mechanism and mining reward maturity period help prevent frequent reorganizations and enhance network + security. + +In summary, block reorganization is part of the MVC network's normal operation. This mechanism helps the network +maintain final consistency and security in the face of temporary forks. + +## Orphan Blocks + +### What are Orphan Blocks + +Orphan blocks are blocks that are discarded by the blockchain. When a block is discarded, the transactions it contains +are also rolled back. These transactions may be repackaged into the main chain or discarded due to conflicts. + +Miners should avoid creating orphan blocks as they waste computational power and time. + +### Possible Causes of Orphan Blocks + +Due to MVC's unlimited block size, orphan blocks are unavoidable under poor network conditions. Possible causes include: + +1. **Miner Network Delays**: After finding a block, a miner may not be able to propagate it promptly due to network or + synchronization delays. +2. **Large Blocks**: Large blocks may prevent some miners from receiving them in time, resulting in orphan blocks. +3. **Inconsistent Memory Pool Fees**: Different miners use different fee strategies, leading to memory pool + synchronization inconsistencies, increasing the difficulty of synchronizing blocks and causing orphan blocks. + +### How to Avoid Orphan Blocks + +If miners or mining pools encounter orphan blocks, they can take the following steps to avoid them: + +1. **Enhance Connectivity**: Increase connections with other miners to reduce network delays. +2. **Increase Fee Rates**: Set higher packaging and relay fees to ensure transactions are more likely included in other + miners' memory pools. +3. **Reduce Transaction Size**: Minimize transaction size to reduce block size and improve propagation speed. + +### Double-Edged Sword + +While methods 2 and 3 reduce potential fee income for miners, only method 1 can balance network stability and miner +profitability. + +Therefore, orphan blocks are not just a network issue but also an incentive mechanism, encouraging miners to invest more +in connectivity to earn higher fee income. This leads to a more interconnected small-world network, enhancing overall +MVC network performance and throughput, supporting higher TPS and MVC's grand vision. + +## 51% Attack + +### What is a 51% Attack + +A 51% attack occurs when a miner or mining pool controls more than 50% of the computing power (hash rate) in the MVC +network, allowing them to manipulate the blockchain. By controlling the majority hash rate, attackers can execute +malicious actions on the blockchain. This threat exists in any POW blockchain network. + +### How to Execute a 51% Attack + +Steps to execute a 51% attack include: + +1. **Accumulate Computing Power**: Attackers need enough computing power to exceed 50% of the network's total hash rate, + requiring significant resources and hardware. +2. **Fork the Blockchain**: With majority hash rate control, attackers can mine an independent fork without broadcasting + new blocks to the network. +3. **Attack Moment**: When the attacker's fork becomes longer than the main chain, it is broadcast to the network. The + MVC network accepts the longest chain as valid, causing nodes to adopt the attacker's fork and discard the original + chain. + +In practice, attackers may need more than 50% hash rate (e.g., over 90%) for a successful attack. + +### Risks of a 51% Attack + +A 51% attack can cause double-spending and transaction rollbacks: + +1. **Double-Spending Attack**: Attackers can execute double-spending by making a transaction on the main chain and not + including it on their fork. When their fork becomes the main chain, the original transaction is reversed, allowing + attackers to spend the same funds again. +2. **Blocking Transaction Confirmation**: Attackers can prevent specific or all transactions from being confirmed by not + including them in blocks. +3. **Obstructing Other Miners**: Attackers can reject other miners' blocks, monopolizing block rewards. +4. **Undermining Network Trust**: Frequent 51% attacks erode user trust, causing price drops and user attrition. + +A 51% attack can only double-spend and rollback transactions, but cannot alter historical records, steal private keys, +or unauthorized assets. + +The primary targets of a 51% attack are exchanges and services sensitive to double-spending, such as asset bridges, +allowing attackers to fake deposits and withdraw funds. + +### How to Avoid a 51% Attack + +1. **Increase Network Hash Rate**: A higher total hash rate makes it harder and costlier to control 51%. Attracting more + miners enhances network security. +2. **Decentralize Mining Pools**: Encourage miners to use different pools to avoid centralization risks. +3. **Hard Fork and Consensus Mechanism Changes**: In extreme cases, developers and the community can hard fork or + implement new security measures. +4. **Economic Incentives**: Maintain healthy economic incentives to make attack costs higher than potential gains, + ensuring high MVC market value and transaction volume. +5. **Monitoring and Warning Systems**: Implement systems to monitor hash rate distribution and issue warnings if an + entity's hash rate approaches or exceeds 50%. +6. **Increase Confirmation Counts**: Services like exchanges can increase confirmation counts to raise double-spending + costs and reduce attack likelihood. + +In summary, while a 51% attack poses a significant threat, increasing network hash rate, decentralizing pools, adjusting +consensus mechanisms, and establishing monitoring systems can effectively reduce the risk. + +### Honest Miners + +During a 51% attack, the attacker struggles to maintain sustained high hash rates, usually resulting in a temporary +burst of power. If the MVC network suffers a severe double-spending attack, victims can join honest miners to mark the +attacker's blocks as invalid and persistently mine the un-double-spent chain. Over time, the cumulative workload will +surpass the attack fork, causing the attacker's fork to be reorganized, recovering losses. + +These miners are known as honest miners, who monitor double-spending transactions, mark potential double-spending risks, +and confirm double-spending transactions, effectively protecting MVC network security. diff --git a/docs/mining/concepts/small-world-model.md b/docs/mining/concepts/small-world-model.md index 55ce819..0f411bd 100644 --- a/docs/mining/concepts/small-world-model.md +++ b/docs/mining/concepts/small-world-model.md @@ -2,4 +2,118 @@ sidebar_position: 13 --- -# Little World Model +# Small-World Model + +Introduction to the Mandala Network and the Small-World Model - Theoretical Foundations for Infinite Scalability. + +## Network Structure + +Network structure studies how to connect nodes so they can communicate with each other, exploring the pros and cons of +different topologies and how to achieve efficient communication in various network structures. + +With the development of the MVC network and the increase in transaction volume, we need to theoretically demonstrate +what kind of network interface can meet future demands for infinite scalability and efficient communication. + +Network structures have wide applications in information technology, communications, social networks, etc. Common +network structures include: + +### Common Network Structures + +1. **Star Network**: Central node is directly connected to every other node. Advantages: easy to manage and isolate + faults; Disadvantages: failure of the central node causes the entire network to collapse. + +2. **Ring Network**: Each node connects to two adjacent nodes, forming a closed loop. Advantages: simple data + transmission, suitable for small networks; Disadvantages: failure of one node affects the entire network. + +3. **Bus Network**: All nodes share a common communication line. Advantages: easy to install and expand; Disadvantages: + any failure in the line affects the entire network, and data collisions are common. + +4. **Tree Network**: Nodes are hierarchically arranged, resembling a tree structure. Advantages: easy to expand and + manage; Disadvantages: failure of higher-level nodes affects their sub-nodes. + +5. **Mesh Network**: Each node connects to multiple other nodes directly. Advantages: high reliability and self-healing + capability; Disadvantages: complex structure and high cost. + +6. **Fully Connected Network**: Each node connects directly to all other nodes. Advantages: highest redundancy and + reliability; Disadvantages: high cost and complexity, suitable for small networks. + +Typical blockchain networks use a mesh network structure where each node connects to multiple other nodes directly to +achieve high reliability and decentralization. However, as the network scales, the mesh network structure faces +challenges like network delay and bandwidth consumption. + +Mesh network structure theoretically leads to the "impossible triangle," where decentralization, security, and +scalability cannot be achieved simultaneously. To address this, we need a new network structure that maintains +decentralization and security while achieving efficient communication and infinite scalability. + +## Mandala Network Configuration + +The Mandala Network Configuration is a hierarchical special network structure, often associated with the mandala symbol +in Buddhism and Hinduism. Its characteristics include: + +- **Layered Structure**: The network has multiple layers, with each layer’s nodes connected through central or + higher-level nodes. +- **Symmetry**: The network structure is highly symmetrical, similar to the geometric beauty of the mandala pattern. +- **Central Nodes**: Central nodes play a key role in connecting and coordinating different layers of nodes. + +In the MVC network topology, nodes with different roles can be distributed across different layers and connected based +on their functions and communication needs. For example: + +1. Mining or consensus nodes are in the innermost layer, with the tightest links, lowest latency, and highest bandwidth. +2. Verification nodes are in the middle layer, mainly for wallets and exchanges needing quick transaction verification. + They have moderate connectivity, latency, and bandwidth. +3. Storage nodes are in the outermost layer, mainly for blockchain application storage, with the sparsest links, highest + latency, lowest bandwidth, and lowest cost. + +## Small-World Model + +The Small-World Model is a network structure that lies between regular and random networks, characterized by high +clustering and short path lengths. Proposed by Watts and Strogatz in 1998, it transforms a regular network by turning a +small portion of edges into random edges, achieving high clustering and short average path lengths. + +![Small World Model](/img/small-world-model.jpg) + +The Small-World Model emphasizes full connectivity and short path lengths, ensuring efficient information spread while +maintaining high clustering, meaning nodes are more densely connected. + +Combining the Small-World Network and Mandala Network can create a complex network with hierarchical structure, high +symmetry, and short path lengths. This network offers efficient communication, strong fault tolerance, and good +management structure. Steps to integrate these two network structures include: + +### 1. **Define Network Hierarchical Structure** + +- **Core Layer**: Establish core nodes forming the center of the Mandala network. These nodes interconnect to form a + small-world network, ensuring fast communication and efficient data transfer. +- **Middle Layer**: Middle layer nodes connect to core nodes, forming small-world networks within this layer. These + nodes have high clustering coefficients and short path lengths. +- **Outer Layer**: Outer layer nodes connect to middle layer nodes and can form small-world networks among themselves. + +### 2. **Node Connection Strategy** + +- **Core Node Connections**: Core nodes form a small-world network, ensuring shortest path lengths and highest + clustering coefficients. +- **Inter-Layer Connections**: Middle and outer layer nodes connect to core nodes, creating the Mandala network’s + hierarchical structure. Each layer forms a small-world network for efficient intra-layer communication. +- **Cross-Layer Connections**: Add cross-layer connections, allowing outer layer nodes to connect directly to other + layers, further reducing path lengths and enhancing overall network efficiency and reliability. + +### 3. **Network Management and Control** + +- **Centralized Management**: Use the Mandala network’s hierarchical structure for centralized management and control, + ensuring network stability and efficient operation. +- **Distributed Control**: Leverage the small-world network’s distributed nature for self-organization and self-healing, + enhancing fault tolerance. + +## Advantages of Small-World and Mandala Networks + +1. **Efficient Communication**: Short path lengths and high clustering coefficients ensure rapid communication between + nodes. +2. **Reliability and Fault Tolerance**: The combination of hierarchical structure and distributed nature enhances fault + tolerance and self-healing capabilities. +3. **Flexibility and Scalability**: New nodes can seamlessly join the network, managed hierarchically and benefiting + from the small-world network’s connectivity. +4. **Optimized Management and Control**: The hierarchical structure aids centralized management, while distributed + features provide flexible management and self-organization. + +By combining the Small-World Network and Mandala Network, MVC can construct a highly efficient, reliable, and flexible +network system, supporting future infinite scalability and efficient communication. This approach provides theoretical +foundations and practical guidance for building such a network. diff --git a/docs/mining/concepts/stratum-protocol.md b/docs/mining/concepts/stratum-protocol.md index e3dfee6..146543e 100644 --- a/docs/mining/concepts/stratum-protocol.md +++ b/docs/mining/concepts/stratum-protocol.md @@ -2,4 +2,313 @@ sidebar_position: 10 --- -# Stratum Protocol +# Stratum Mining Protocol + +This article introduces the Stratum mining protocol, the current mainstream cryptocurrency mining protocol. + +## What is the Stratum Mining Protocol? + +The Stratum mining protocol is a protocol used for cryptocurrency mining, designed to optimize communication between +miners and mining pools. This protocol was introduced by Slush Pool in 2012, replacing the earlier HTTP mining protocol +and addressing issues of efficiency and scalability. + +Before the Stratum protocol, cryptocurrency mining primarily used [RPC mining protocols](../config/set-up-your-own.md), +such as `getwork` and `getblocktemplate`. These protocols were common in early Bitcoin mining, but as mining difficulty +and the number of miners increased, RPC protocols exposed several significant shortcomings. + +### Mining Methods and Drawbacks of RPC (or HTTP) Protocols + +#### Mining Process + +1. **Connecting to the Pool**: + - Miners connect to the pool's server via RPC, typically using standard RPC POST requests to obtain mining tasks. + +2. **Task Request**: + - Miners send a request containing their wallet address and other relevant information to the pool to request a + mining task. + - The pool returns a task containing information such as the block header and target difficulty. + +3. **Hash Calculation**: + - Miners start calculating hashes with the given data, trying to find a hash value that meets the target difficulty. + +4. **Submitting Results**: + - When miners find a valid hash value, they use an RPC POST request to submit the result to the pool. + - The pool verifies the result, and if valid, incorporates it into the blockchain. + +5. **Task Loop**: + - Since the RPC protocol is stateless, miners need to reconnect and request new tasks after each task completion. + +#### Drawbacks of RPC Protocols + +1. **High Connection Overhead**: + - The stateless nature of the RPC protocol requires miners to reconnect and establish a new connection for each task + request and result submission, increasing network overhead and latency. + - Frequent connection establishment and closure operations lead to resource wastage for both miners and pool + servers. + +2. **Poor Real-time Performance**: + - RPC protocols cannot push new tasks in real-time, causing miners to potentially perform invalid calculations due + to untimely task updates. + - Miners might waste computational resources during the task update process, reducing mining efficiency. + +3. **Latency Issues**: + - The need to reconnect for each task request and result submission significantly affects mining efficiency due to + network latency. + - In high-latency network environments, miners may miss valid tasks, reducing their earnings. + +4. **Poor Scalability**: + - Designed for web browsing, the RPC protocol was not intended for high-frequency task requests and result + submissions, making it unsuitable for the high concurrency demands of large-scale mining operations. + - As the number of miners increases, the pool server's load significantly increases, leading to performance + bottlenecks. + - As the number of blocks increases, the network bandwidth and computational resources required to generate a work + task also increase. + +5. **Low Fault Tolerance**: + - The RPC protocol lacks fault tolerance for connection interruptions, making miners susceptible to losing tasks or + results during network fluctuations, affecting mining stability. + - Communication between pools and miners is vulnerable to network failures and attacks. + +## Stratum Protocol Details + +The [Stratum](https://en.bitcoin.it/wiki/Stratum_mining_protocol) protocol addresses the shortcomings of RPC protocols +by optimizing communication between miners and pools, improving mining efficiency and stability. It uses a persistent +connection and communicates using the JSON-RPC format, offering real-time task updates, strong fault tolerance, and good +scalability. + +1. **Connection Establishment**: + - Miners connect to the pool's Stratum server via TCP and communicate using the JSON-RPC format. + - Upon successful connection, miners send a "mining.subscribe" request to subscribe to tasks. + +2. **Task Allocation**: + - After receiving the subscription request, the pool sends a "mining.notify" message containing detailed mining task + information, such as the block header and target difficulty. + - Miners start calculating hashes upon receiving the task, seeking solutions that meet the target difficulty. + +3. **Submitting Results**: + - When miners find a valid hash, they send a "mining.submit" message to the pool to submit their results. + - The pool verifies the results and incorporates them into the blockchain if valid. + +4. **Task Updates**: + - The pool periodically sends new tasks to miners, ensuring they always work on the latest tasks. + - Through "mining.notify" messages, the pool can dynamically adjust task parameters to improve mining efficiency. + +### Advantages of the Protocol + +1. **Efficient Communication**: + - The Stratum protocol uses a persistent connection, reducing the overhead of frequent connection establishment and + closure in the HTTP protocol. + - Using the lightweight JSON-RPC format makes message transmission more efficient. + +2. **Real-time Task Updates**: + - Pools can push new tasks to miners in real-time, ensuring they always work on the latest block data and avoid + invalid work. + - Dynamic difficulty adjustment improves mining efficiency and fairness. + +3. **Strong Fault Tolerance**: + - The Stratum protocol supports multiple attempts to submit results, offering strong fault tolerance and ensuring + miners' work is not lost due to occasional network fluctuations. + - Supports redundant servers, allowing miners to switch to backup servers in case of a primary server failure, + ensuring uninterrupted mining. + +4. **Good Scalability**: + - The simple design of the Stratum protocol makes it easy to extend, supporting various cryptocurrencies and + different mining algorithms. + - Pools can develop customized Stratum servers based on their needs to accommodate different miners and hardware + configurations. + +5. **Easy Task Division**: + - The Stratum protocol divides mining tasks into smaller tasks that miners can process in parallel, increasing + mining efficiency. Miners do not need to submit the entire block's proof of work but can submit proofs of work for + each small task. This allows lower hash rate miners to have a chance to earn mining rewards. + - Due to the properties of Merkle trees, the amount of data needed for mining is logarithmic rather than linear, + reducing bandwidth and load. + +6. **Support for AsicBoost**: + - The Stratum protocol supports AsicBoost technology, providing a more efficient mining method through protocol + extensions and message types. + - Pools can send AsicBoost-related configuration information to miners via the Stratum protocol, enabling more + efficient hash calculations. + +## Example of Stratum Interaction + +Here is a simple example of Stratum mining protocol interaction, including miner subscription, authorization, task push, +and result submission. + +All messages use \n as the line ending. + +---------- + +Miner subscription: + +```json +{ + "id": 1, + "method": "mining.subscribe", + "params": [] +} +``` + +Server response: + +```json +{ + "id": 1, + "result": [ + [ + [ + "mining.set_difficulty", + "b4b6693b72a50c7116db18d6497cac52" + ], + [ + "mining.notify", + "ae6812eb4cd7735a302a8a9dd95cf71f" + ] + ], + "08000002", + 4 + ], + "error": null +} +``` + +If this response is not received, possible reasons include: + +1. Not connected to a Stratum server. +2. Stratum server is malfunctioning. +3. Request message line ending is not \n. This can happen when pasting multi-line text into the terminal. In this case, + paste line by line and press Enter manually. + +---------- + +After successful subscription, miner proceeds with worker name authorization: + +```json +{ + "params": [ + "replace_with_your_real_worker_name", + "password" + ], + "id": 2, + "method": "mining.authorize" +} +``` + +Server response: + +```json +{ + "error": null, + "id": 2, + "result": true +} +``` + +If the response is not true, the result field contains the error information. +If no response is received, possible reasons include: + +1. Stratum Server malfunctioning. +2. Line ending issue. +3. Too long a gap between subscription and authorization, causing the server to abandon the miner's authorization. + +---------- + +Upon successful authorization, the Stratum Server will proactively push mining difficulty and task information to the +miner as follows: + +(Difficulty) + +```json +{ + "id": null, + "method": "mining.set_difficulty", + "params": [ + 16384 + ] +} +``` + +(Task) + +```json +{ + "params": [ + "0", + "4d16b6f85af6e2198f44ae2a6de67f78487ae5611b77c6c0440b921e00000000", + "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff20020862062f503253482f04b8864e5008", + "072f736c7573682f000000000100f2052a010000001976a914d23fcdf86f7e756a64a7a9688ef9903327048ed988ac00000000", + [], + "00000002", + "1c2ac4af", + "504e86b9", + false + ], + "id": null, + "method": "mining.notify" +} +``` + +If no difficulty push is received, it indicates the Stratum Server is malfunctioning. +If no task push is received, it indicates the Stratum Server might not have any tasks available for you at the moment. +For BTCPool, this could mean it has not read any tasks from Kafka, possibly due to jobmaker not generating corresponding +tasks or Kafka malfunctioning. Of course, the Stratum Server itself might also be malfunctioning. + +---------- + +When a miner finds a share that meets the pool's set difficulty, it will submit the share: + +```json +{ + "params": [ + "slush.miner1", + "0", + "00000001", + "504e86ed", + "b2957c02" + ], + "id": 4, + "method": "mining.submit" +} +``` + +Server response: + +```json +{ + "error": null, + "id": 4, + "result": true +} +``` + +If the result is not true, it will include the reason for rejecting the share. + +---------- + +Please note that not every submit will result in a mined block. For a normal mining pool, most of the miner's +submissions will not result in a mined block, but occasionally, some submissions will meet the network difficulty +requirements, thus resulting in a mined block. + +When a miner successfully mines a block, the submission action does not differ from usual. However, both miners and +pools can compare the share difficulty with the job's bits/target to discover if a share meets the network difficulty +requirement. + +The same applies to merged mining; it checks if the share difficulty meets the difficulty of the merged mining coins in +the job. If mining multiple coins simultaneously, it only needs to check if it meets the lowest difficulty. + +It is important to note that the difficulty of the merged mining coins might be higher or lower than the difficulty of +the main coin being mined. + +If the main coin (e.g., Bitcoin) has a higher difficulty, then finding a Bitcoin block will also satisfy the difficulty +for the merged mining coins. However, the reverse is not necessarily true. + +If the merged mining coins have a higher difficulty (e.g., Bitcoin Cash merged mining Namecoin), then finding a block +for the main coin does not necessarily mean a block for the merged mining coins has been found, but the reverse is +always true. + +## Summary + +The Stratum mining protocol enhances mining efficiency and system stability by optimizing communication between miners +and pools. Its efficient communication, real-time task updates, strong fault tolerance, and good scalability make it the +mainstream protocol for cryptocurrency mining today. As technology evolves, the Stratum protocol continues to advance, +further improving mining efficiency and security. diff --git a/docs/mining/concepts/supply-halving.md b/docs/mining/concepts/supply-halving.md index 5076ebc..4568a0b 100644 --- a/docs/mining/concepts/supply-halving.md +++ b/docs/mining/concepts/supply-halving.md @@ -1,5 +1,110 @@ --- sidebar_position: 4 --- + # Supply Halving +This article introduces the mining halving rules of the MVC blockchain. + +## What is Halving? + +Taking Bitcoin's halving as an example: + +Bitcoin mining rewards refer to the number of Bitcoins a miner receives when a block is mined (newly created Bitcoins, +not including transaction fees). Bitcoin's mining reward halving is designed to control the issuance rate of Bitcoin to +maintain its scarcity. As the issuance rate of Bitcoin halves exponentially, the total number of Bitcoins will gradually +approach 21 million. + +On the Bitcoin blockchain, every 210,000 blocks generated triggers a halving event in which the network's block reward +to miners is halved. This occurs approximately every four years. The halving event is intended to control the supply of +Bitcoin, making it gradually decrease to prevent inflation and increase scarcity. + +1. **Miner Rewards**: In the early days of the Bitcoin network, miners received 50 Bitcoins as a reward for each block. + After the first halving in 2012, the reward was reduced to 25 Bitcoins. The second halving in 2016 further reduced it + to 12.5 Bitcoins, and the third halving in 2020 brought it down to 6.25 Bitcoins. +2. **Time Interval**: A Bitcoin block is generated approximately every 10 minutes, so 210,000 blocks take about 4 years + to complete. +3. **Future Halving**: The halving event will continue until the block reward approaches zero. + +### Calculation of the 21 Million Limit + +Below is a detailed table of each halving stage for Bitcoin: + +| Stage | Block Reward (BTC) | Number of Blocks | Bitcoins Generated During Stage | +|----------|---------------------------------|------------------|---------------------------------| +| Stage 1 | 50 | 210,000 | 10,500,000 | +| Stage 2 | 25 | 210,000 | 5,250,000 | +| Stage 3 | 12.5 | 210,000 | 2,625,000 | +| Stage 4 | 6.25 | 210,000 | 1,312,500 | +| Stage 5 | 3.125 | 210,000 | 656,250 | +| Stage 6 | 1.5625 | 210,000 | 328,125 | +| Stage 7 | 0.78125 | 210,000 | 164,062.5 | +| Stage 8 | 0.390625 | 210,000 | 82,031.25 | +| Stage 9 | 0.1953125 | 210,000 | 41,015.625 | +| Stage 10 | 0.09765625 | 210,000 | 20,507.8125 | +| Stage 11 | 0.048828125 | 210,000 | 10,253.90625 | +| Stage 12 | 0.0244140625 | 210,000 | 5,126.953125 | +| Stage 13 | 0.01220703125 | 210,000 | 2,563.4765625 | +| Stage 14 | 0.006103515625 | 210,000 | 1,281.73828125 | +| Stage 15 | 0.0030517578125 | 210,000 | 640.869140625 | +| Stage 16 | 0.00152587890625 | 210,000 | 320.4345703125 | +| Stage 17 | 0.000762939453125 | 210,000 | 160.21728515625 | +| Stage 18 | 0.0003814697265625 | 210,000 | 80.108642578125 | +| Stage 19 | 0.00019073486328125 | 210,000 | 40.0543212890625 | +| ... | ... | ... | ... | +| Stage 29 | 0.000000186264514923095703125 | 210,000 | 0.03911554813385009765625 | +| Stage 30 | 0.0000000931322574615478515625 | 210,000 | 0.019557774066925048828125 | +| Stage 31 | 0.00000004656612873077392578125 | 210,000 | 0.0097788870334625244140625 | + +The total supply is: 21,000,000 Bitcoins. + +This demonstrates that the total supply of Bitcoin is indeed 21 million, achieved through the above halving mechanism. + +## MVC Blockchain Halving Rules + +Due to MVC adopting a POW+POB hybrid consensus mechanism, halving only applies to POW mining rewards (35%), while POB +rewards are not affected by halving. According to MVC's white-paper, the halving rules for MVC are as follows: + +| Rule | Description | +|----------------------------|-------------| +| Total POW Issuance | 7,350,000 | +| Halving Block Count | 147,000 | +| Estimated Halving Interval | 1,000 days | +| Initial Issuance Amount | 25 space | + +### MVC Halving Rule Calculation + +We can calculate the total production of Space using a method similar to Bitcoin. The initial reward for Space is 25, +halving every 147,000 blocks. + +### Calculation of Space Amount for Each Stage: + +Below is a detailed table of each halving stage for Space: + +| Stage | Block Reward (Space) | Number of Blocks | Space Generated During Stage | +|----------|----------------------------------|------------------|-------------------------------| +| Stage 1 | 25 | 147,000 | 3,675,000 | +| Stage 2 | 12.5 | 147,000 | 1,837,500 | +| Stage 3 | 6.25 | 147,000 | 918,750 | +| Stage 4 | 3.125 | 147,000 | 459,375 | +| Stage 5 | 1.5625 | 147,000 | 229,687.5 | +| Stage 6 | 0.78125 | 147,000 | 114,843.75 | +| Stage 7 | 0.390625 | 147,000 | 57,421.875 | +| Stage 8 | 0.1953125 | 147,000 | 28,710.9375 | +| Stage 9 | 0.09765625 | 147,000 | 14,355.46875 | +| Stage 10 | 0.048828125 | 147,000 | 7,177.734375 | +| Stage 11 | 0.0244140625 | 147,000 | 3,588.8671875 | +| Stage 12 | 0.01220703125 | 147,000 | 1,794.43359375 | +| Stage 13 | 0.006103515625 | 147,000 | 897.216796875 | +| Stage 14 | 0.0030517578125 | 147,000 | 448.6083984375 | +| Stage 15 | 0.00152587890625 | 147,000 | 224.30419921875 | +| Stage 16 | 0.000762939453125 | 147,000 | 112.152099609375 | +| Stage 17 | 0.0003814697265625 | 147,000 | 56.0760498046875 | +| Stage 18 | 0.00019073486328125 | 147,000 | 28.03802490234375 | +| ... | ... | ... | ... | +| Stage 28 | 0.000000186264514923095703125 | 147,000 | 0.027380883693695068359375 | +| Stage 29 | 0.0000000931322574615478515625 | 147,000 | 0.0136904418468475341796875 | +| Stage 30 | 0.00000004656612873077392578125 | 147,000 | 0.00684522092342376708984375 | +| Stage 31 | 0.000000023283064365386962890625 | 147,000 | 0.003422610461711883544921875 | + +The total supply is approximately: 7,350,000 Space.