Note: The original title is "Betterhash: Using New Hash Protocol, Decentralizing Bitcoin Mining With New Hashing Protocols" by StopAndDecrypt.
The following is a translation:
BetterHash is an alternative mining protocol currently being developed by Bitcoin developers. When it is completed, there will be enough miners willing to use this agreement to switch to a new pool, or an existing pool that is willing to serve both the old agreement and the new agreement, while the miners gradually Ready to switch. In either case, the initial conversion requires sufficient miner support to achieve profitability, otherwise the profit fluctuations will be too large. Ultimately, miners will need to understand why they switch and need forward-thinking tank operators (they don't want to control existing mines). This happens only when the problems and risks of the current system are properly understood and communicated. This is a prerequisite for the BetterHash mining protocol to be adopted.
So, what problems are currently encountered with Bitcoin mining?
Bitcoin mining has a proxy problem: the Bitcoin mine is not a miner, but the mine represents an inappropriate signal on behalf of the miner. The mine runs a node that is responsible for building blocks, selecting transactions, and representing which miner's power in the pool is used to support which fork chain. This creates some incentive problems and some rather unpopular political pressures. Betterhash's goal is to solve this problem by returning these responsibilities to individual miners and depriving the pool of the impact for the benefit of the network. With BetterHash, miners can control their own power, and the pool is only responsible for coordinating them and assigning rewards.
The distribution of the calculation of the mining pool VS Slush Pool miners distributed to each pool
Before we get started, let's briefly review the structural differences between existing protocols and what the BetterHash protocol will change.
Currently, many miners don't even run nodes, they just connect their ASIC miners to a pool using protocols such as Stratum. The miners run the nodes, select transactions, create a block that they want to mine, and then send the block to all miners who use their miners, and the miners begin hashing them. Once a miner successfully mines a block, it is sent back to the pool and then exported to the Bitcoin network.
With BetterHash, the miner will run his own node, select transactions, create a block, and then mine it. The block will be configured to cover the cost of the pool, just as with the Stratum protocol, these unsuccessful blocks (called “shares”) will be used by miners to prove that they have been mining the pool. By changing the participants who created the block template and then building a new protocol around this concept, BetterHash bypasses all the issues we're going to discuss.
For a more technical overview of the Betterhash protocol currently under development, this demo video by Matt Corallo should be sufficient:
It should be noted that the name "Betterhash" is already finalized, as already mentioned in the video.
The current status of Bitcoin mining
To understand why switching to Betterhash is so important, let's solve all the problems associated with the current lifestyle of miners, and if they use the BetterHash protocol, these problems will no longer exist.
In short, the rate of return of miners' own solo mining is extremely unstable, which is why the mine will be born in 2010. Critics will point out that the current distribution of the calculation of the mining pool makes Bitcoin mining central, although the rebuttal asserts that the miners can switch the pool they use, but the problem is not always that simple. . If you are a miner, then your choice is limited to a few miners, and each mine has some terms of service that you either accept or not accept. If the pool is too large, it will not be able to offer a variety of options.
In fact, you have no choice but to choose the mine that suits you best. If most or all of the mines decide decisions that you don't like or disagree with, then you have no real choice but to go. Deal with this problem because you build your own mine pool may not produce a steady stream of income. Those already existing mines will become larger, and by having a large number of miners under their umbrellas, the mines have the rights that miners do not have. We will discuss each one by one.
The mine pool can:
- Determine which transactions can be included in the block or not.
- Bribery and reorganization of blockchain under appropriate conditions;
- Backlog of trading mempool to increase transaction rates;
- Use the calculation power directly to dig up the competitive fork chain without the consent of the miners;
- Non-honest mining, the motivation for doing so should be ulterior motives;
- Use the miner's computing power to provide signal support for a proposal;
As mentioned earlier, all of these problems are basically the direct result of the mining pool building a bitcoin block rather than the miners building the block. With the use of the mining pool, third-party problems will follow. The pool can be hacked, and then the hacker can potentially perform these uses, or the pool can be attacked at the network level, and then the miners are busy solving problems or switching to another pool. After applying BetterHash, the mine hacker can't control the miner's computing power, and the network-level attack against the mine pool will not directly affect the miners who use the mine.
At the network level, an attacker can shoot down a lot of computing power or redirect as needed. BGP attacks are easy to accomplish, to say the least, the time and resources required to recover from them are relevant. To understand how an attacker steals a pot calculation and perform any exploits written in this article, watch the 3-minute demo below:
(Network-level attack discussion starts at 5:52 and ends at 9:00)
There is no doubt that the suitability of an agreement depends on whether these issues are urgently needed to be resolved.
However, the potential for these scenarios is not always a good indication of its necessity.
I want to reveal some hypothetical scenarios, as well as some scenarios that have occurred in some way, so that everyone can understand the need for Betterhash more easily. So let's take a closer look at what they are. (Note that some of them are hypothetical, they are unlikely to actually happen, others require very specific situations, while others have taken place in one form or another.)
1. The mine pool determines which transactions enter a block
When discussing the possibility of a 51% attack, there is often a question. If enough pools can be persuaded to blacklist the transaction type or address, or even a temporary blacklist, then the problem will arise. The reason for this may be that it is coerced, or it may be just an economic incentive, whether it is the mine pool itself or the outside is paying rewards.
Scenario 1: Reviewing a server's hot wallet
Imagine an exchange's hot wallet being blacklisted by 40% of the pool (possibly paid for by a competing exchange), then it won't stop the hot wallet from trading, but it will slow it down significantly. Transaction processing speed. As a miner, you may not think that this behavior is healthy for the ecosystem, but maybe you have no other choice because you have no say in it.
Scenario 2: Reviewing confidential transaction types
"Maybe developers are equally lazy", causing the code to ignore transactions of a secret type.
The above tweet finally proves (if we trust him), this example is non-malicious, but if you consider the situation is malicious, it is worth thinking about. Bitcoin currently has no confidential transactions and may never be owned, but it has many different transaction types. If a mine has reason to do this, then in theory they can ignore these transactions, so the backlog of certain types of transactions will increase, transaction costs will increase, and the speed of any service using these particular transactions may be reduced.
Related reading: ZCash confidential transaction review event: https://medium.com/@levdubinets/zcash-shielded-transaction-censorship-12098f21090b
2, can bribe the pool to reorganize the blockchain
Similar to the example above, the pool can decide which transactions they do not want to include in a particular version of the ledger and then attempt to make this decision. This situation is almost impossible to coordinate spontaneously or ex post, but if the mine has this tendency, and as long as a few such pools are willing to accept bribes and then take immediate action, the miners have no say in this.
If the mine is willing to share these bribes with the miners, the miners may accept it, but the higher the share of the mine to the miners, the less willing it will be. In addition, in the hacking scenario, hackers can anti-bribery the mine pool, making the situation more complicated.
This is a suggestion that was mentioned after an exchange was hacked. Although the mine pool is not prepared to do this, many people use it to argue that bitcoin mining is central. For more details on this topic, please listen to the podcast below, and note that if Betterhash is used, then the discussion Everything is not important, because when miners build blocks, not mines, these problems don't even need to be considered.
3. The mining pool can be backlogged to increase the transaction rate.
The pool not only blocks specific transactions, but also chooses to ignore all transactions below a certain rate, thereby increasing the cost of everyone trying to trade. Some people think this is a trivial problem, because smaller mines will take advantage of the opportunity to include these transactions, because for them, the return will be even greater, so this will reward the weak pool for a long time. I don't think this is trivial, because we have seen the impact of this behavior and how to lead the debate on the short-term cost increase in the political arena.
The cost market will exist sooner or later, but it should not be profitable by limiting network rules. Although there may be competition at the pool level to cope with this behavior, we still see some pools choose to empty the block. In some instances in the past, some specific pools only package transactions that are higher than 5 Cbytes per byte, even if there is room left in the block. This may require some coordination between the pools to produce results, but if the incentives are consistent, then coordination is not difficult or even unnecessary. Now, a small number of mine operators will have a value tool that no one else has.
The pool can also do this in secret. They don't need to create “non-full” blocks. Instead, they can fill these blocks with transactions that appear to be legal but unannounced, and then re-collect these transactions. Guide them to believe that the new "current rate" is true. Once the market begins to pay higher prices, the pool can realign their malicious transactions. In the time shown below, the bottom 50% of the Tx backlog is only 7% of the miner's charge. The return has a non-linear growth relationship with the intermediate rate in the backlog of the transaction. If there is a large enough pool to try this, then it will be profitable.
4. The mining pool can directly use the calculation power without the consent of the miners.
In fact, it is the chain that the mine is deciding to expand. The mine pool provides a block for the miners. In fact, it is only necessary to say "dig this block," and then the miners will dig this block until Someone found out, and then the mine pool gave the miners another block. Miners don't track their own branches, and miners usually assume that the pool is honest and will pick up the coins/chains that you want them to dig. Many miners do not run nodes, so they do not validate consensus rules. In the past, when the mines decided that they did not verify the blocks, but instead did “SPV mining” on the inactive blocks, this created problems. As a miner, you should understand the time and money you spend, not wasted because of the mine.
You are a miner and part of the _A, you contribute to the pool, and you will receive a steady stream of payments. You have completed the math calculations, then checked and this will never change.
The operator of the Pool_A decides to use your power to provide power (life) support for another chain at risk. And this chain may be something you don't care about, maybe it's something you don't like, or a competitor. The pool continues to pay for your calculations at the "market price", but in fact your calculations are not used on the chain you think.
Since there is now an entire mine pond digging a different chain, the block production speed of the network is slower (return less) (the market may be fooled, think that support for another chain will be more than actual support), which will reduce The potential value of the chain you support. As a miner, this may be a situation you want to avoid. Unfortunately, this has happened in the real world:
5. The mining pool can use the miner’s calculation power to conduct dishonest mining work.
Consider the above scenario, which is a best example of how this will happen: the mine pool candidly inform the miners of their intentions and at least try to make up for the miners. They told the miners that if you don't like it, you can leave. But what if the mine is dishonest?
If a mine indicates that they are digging two chains, the yellow chain accounts for 80% of the computing power, the green chain accounts for 20% of the computing power, and you are digging the green chain through them, how do you know that they are honest, only 20% The miners are supporting this chain, they can tell each miner separately, they are 20%, and they are the only ones who support this chain. Miners will have to coordinate on the side channels and then add their calculations to determine if they are being deceived. The main problem is that many miners are secretive, and many people want to stay private and should stay that way. Coordinating like this to avoid being deceived and manipulated is an unrealistic solution.
This type of false information not only allows the pool to fully utilize the combined computing power of all miners, but fraud can affect the market's valuation of each chain. Anyone who values the long-term health of the Bitcoin network wants to avoid this.
6, the mining pool can use your calculations to vote for the proposal
This operation does not even require actual chain splitting. Considering that the voting signal is not a financial commitment, the risk of doing so is small. If you want to try to turn the market in the direction you want, you just need to convince a few people running these tanks to temporarily send out support signals. If it fails, as we have seen NO2X, then this will not cause any loss to the mining pool. Regardless of the outcome, the power of each miner is being used normally.
Each column represents a mine pool. The top portion of each column represents the computing power owned by the pool, while the bottom portion represents the type of other miners using the pool.
No one wants another NO2X solution, and no one can “decide” what most people support if they really don’t support it. If BetterHash already existed a few years ago, the NO2X movement might not be necessary.
The miners did not vote for Segwit2X, but the mine is doing it.
Conclusion: Perspective issues
I expect people to have two different reactions when reading this article, both of which I got from a few people who read this article:
- "I don't know that the mine has such a big right."
- "This article gives the impression that the mine pool has more control than the actual."
Now, for the "yuan considerations", at first glance, people may think:
“The first person may not know much about the mine or bitcoin. The second person is a veteran. He fully understands the nuances to better measure these situations.”
Another possible view is:
“The first person provides a new, real perspective to learn the balance of power in this system, and the second person has been in the system for a while, becoming too comfortable with the status quo and potential threats of things. And not sensitive."
Both of these initial reactions are valid, and both of these considerations are also valid. If the pool is not going to abuse the way the system is currently set up, then there is no driving force to develop a better agreement, and you won't read this article. Conversely, if the pool poses a serious threat to Bitcoin, they will abuse their power in irreparable and destructive ways (see BCash).
In addition to these polarized views, this is what I hope you will harvest:
BetterHash should be implemented because, objectively, it is better than the protocol currently used by Bitcoin. Mine pool abuse and cyberattacks should not be feasible, we can alleviate these concerns by having miners run their own nodes so they can create their own blocks and use a better pool protocol, the structure of the protocol Around a simple but fundamental change. If we don't solve the problem we know how to solve in advance, there may always be serious problems, so let's solve it.
Bob McElrath: Decentralized Mining Pools for Bitcoin
Off Chain with Jimmy Song : How Mining Pools Work with Matt Corallo
What Bitcoin Did: Matt Corallo on How Bitcoin Works
Thanks to Jameson Lopp and Steve Lee