← BCH upgrade proposal: Use ASERT as the new DAA Abstract The current BCH difficulty… by @jtoomim
47 comments
Log in Invite-only for now. Someone already here has to let you in.
← BCH upgrade proposal: Use ASERT as the new DAA Abstract The current BCH difficulty… by @jtoomim
Log in Invite-only for now. Someone already here has to let you in.
Some questions to the list in the conclusion: > 1. It should be stable, and not prone to oscillations; Oscillations of what? Do you mean block interval variance or hashrate switching? Realizing these are distinct phenomena opens a wider realm of possible algorithms. We could design an algorithm with extremely low time variance that still incorporates hashrate switching (all miners jump into BCH for few seconds near the 10m target, mine a block, then leave). Is this desirable? Why? Why not? What about orphaning (low variance should increase it)? If desirable variance is not 0, then what is the best value? > 2. It should keep confirmation times low; What does it mean "low"? is it 10 minutes, 10 seconds? 1 second? PoW is inherently slow. If we're about to compete with credit cards then PoW is not good enough, whatever algoithm we choose. We should then focus on other solutions like PoS, double-spend proofs, Avalanche, Storm, etc. If any of these is a good solution, then maybe DAA research is all vain and pointless, because oscillations don't matter that much, current algo is good enough or totally the opposite - we have to slash PoW altogether? What does the confirmation time mean in the first place? What does it mean to be confirmed? Maybe we should start nuancing this and stop considering it a binary value but rather think about levels of confidence measured in electricity costs (see: https://www.crypto51.app/)? > 3. It should keep incentives for miners to perform hashrate shenanigans low; What do "hashrate shenanigans" mean exactly? > 4. It should keep incentives for miners to perform timestamp manipulation shenanigans low; This one is quite easy to define: a time diverging from the actual time of mining. But how to measure that? > 5. It should keep incentives for miners to perform selfish mining shenanigans low; Cool. > 6. Because of #3, #4, and #5, honest mining strategies with steady hashrate should get near-optimal income; What does "honest" mean? > 7. The chain should recover quickly after sudden changes in hashrate and/or exchange rate; How is "quickly" defined? > 8. The average block interval should be kept close to the target (e.g. 600 seconds); How is "close" defined? > 9. The algorithm should be mathematically simple and elegant; Why? > 10. The algorithm should be easily understood and analyzed; By who? Most people are incapable of matematical analysis, so it won't be easy for them no matter what. > 11. The algorithm should be easy to implement elegantly and simply; I agree, the ease of implementation means lesser risk of bugs and therefore accidental hard forks. 12. The algorithm should have few or no edge and corner cases. Same as above. In summary - despite a lot of interesting research, it still looks like we've not even defined the exact problem, it's just a gut feeling that something is not right with the mining and stuff.
> despite a lot of interesting research, it still looks like we've not even defined the exact problem That's because there isn't one exact problem. There are many exact problems -- roughly a dozen. A good DAA needs to solve all of them. It would be great if this problem could be distilled into a single simple definition of the problem. It would also be great if we had a grand unified theory of physics. The fact that we don't have a GUT for physics should not stop us from building automobiles. Like a good DAA, an automobile has to solve dozens of different problems simultaneously. It needs to be safe, efficient, fast, comfortable, beautiful, reliable, powerful, quiet, legal, maneuverable, good for hauling gear, good for towing, etc. If you try to "define the exact problem" that an automobile will need to solve, you're going to miss a lot of important stuff. > Oscillations of what? Do you mean block interval variance or hashrate switching? This is like asking of light: "Oscillations of what? Do you mean magnetic field, or electrical field?" They're different aspects of the same phenomenon. Hashrate switching causes hashrate changes, which cause the difficulty changes, which cause profitability changes, which cause hashrate switching, which causes difficulty changes, etc. Both block interval variance and (the large incentives for) hashrate switching cause problems. One causes problems in user experience in confirmation times. The other causes problems in mining fairness, decentralization, selfish mining resistance, and 51% attack susceptibility. We need to fix both problems. > What does it mean "low" [for confirmation times]? For a blockchain that targets 600 seconds between blocks using PoW (Poisson process), the theoretical time per confirmation should be 600 seconds. A good DAA will keep confirmation times close to this value. Better DAAs will be closer to 600 seconds than bad DAAs.
aserti3-416gets confirmation times down to about 660 seconds, whereascw-144gets confirmation times around 1200 seconds. 660 seconds is lower than 1200. > What does the confirmation time mean in the first place? That is the expected amount of time a transaction will need to wait until the first block is mined which could contain it, assuming that the transaction is issued at a uniformly distributed random time. > What do "hashrate shenanigans" mean exactly? Hashrate shenanigans means using changes in hashrate in a fashion intended to game the DAA to gain more profit than an honest miner applying steady hashrate would. > This one is quite easy to define: a time diverging from the actual time of mining. But how to measure that? We don't need to measure the actual frequency of timestamp shenanigans. We just need to measure the incentive for timestamp shenanigans. We can do that by using math and simulations to model how much profit an attacker can gain from a successful timestamp manipulation attack. > What does "honest" mean? Same as in Satoshi's Bitcoin white paper. It means a miner who always mines on the current valid chain tip, includes all transactions that pay a sufficient fee and that aren't double-spend attempts, and publishes their blocks immediately. > How is "quickly" defined? In the same way as "low" was earlier. Faster is better, ceteris paribus. A DAA has multiple opposing goals. Its ability to satisfy all requirements comes with trade-offs that need to be made between the different requirements. Speed of response is naturally in conflict with stability. How exactly to make that trade-off will always be a subjective judgment call. Some people are best served by a sports car, and others are better off with a minivan. We need to decide which algorithm is right for BCH specifically. > How is "close" defined? See above. That said, this particular requirement is easy to satisfy far more accurately than necessary, so the trade-offs aren't too relevant for this particular requirement. > Why [mathematical simplicity and elegance]? Because people will be working with this algorithm for years or decades. Building a system on an inelegant foundation slows everything else down, and makes the work prone to errors and unexpected behavior. > By who? By the people who need to validate it and review it, and ensure that it is not vulnerable to attacks. By the people who need to implement it. By the people who need to maintain it. By the people who need to explain it to newbies 20 years later about why they can trust that the system works and will continue to work. Obscurity is not security. You can't be sure that a system is resistant to attacks if nobody currently understands it well enough to be able to imagine an attack. P.S.: This comments section usually works better if you make multiple small comments rather than one large comment. The formatting and the edit windows on single large comments aren't great.> That's because there isn't one exact problem. ... It would be great if this problem could be distilled into a single simple definition of the problem. The goal of the difficulty algorithm is to estimate the current hashrate to set the difficulty so that the average solve and confirmation times are as close as possible to the block time, but random enough to prevent orphans. Assuming we want solve times to follow the exponential distribution it can almost be simplified to "Estimate the current hashrate." That is used to set the difficulty via target = 2^256 / HR / Block_time. But the hashrate depends on the exchange rate, fees, and on the difficulty itself, so the first definition is more complete. We have to use past difficulties to estimate what the hashrate was, but the difficulty we choose affects the hashrate. We could know what difficulty was needed more accurately if we knew the exchange rate and fees, but the difficulty does not have immediate access to fees and no access to exchange rate.
1) Oscillations in difficulty. We do not want low variance in block time because of orphaning 2) By "low confirmation time" he meant we want the average confirmation time to be as close as possible to avg block time. If it gets longer, it's evidence of switch mining causing delays. It's not possible to have confirmation time less than avg block time. To calculate confirmation time you pretend there is 1 tx per second. The avg confirmation time for blocks i=0 to N with a solvetimes "t_i" is then sum( t_i * (t_i+1)/2 ) / sum(t_i). 3) He meant on-off mining to get higher revenue than other miners. 4) Timestamp manipulations refer to using the MTP, FTL, and timespan limits to make the difficulty go high or low in a public or block withholding attack. ASERT his FTL=600 and the 3 other things I mentioned in my post above prevent all but one of the possible attacks. The remaining attack is not worth worrying about. 6) Honest means the miner obeys consensus rules and possible network-friendly less-formal suggestions. For example, honest miners agree to not collude to perform a 51% attack to exclude other miners, which they could do and it does not violate the consensus rules, but so far have not done so, possibly due to fear of community retribution and/or lost faith in the coin which hurts their long-term mining equipment investment. 7) "Quickly" means fast enough to respond to exchange rates. The main goal is to minimize switch-mining excess profits so that constant miners do not lose out. 8) Close means as small as possible. It turns out ASERT keeps it exactly at 600 seconds within less than 1/2 a second so it's good. 9) Because people could argue against arbitrary decisions. A simple calculation implies it is the most mathematically correct way to estimate network hashrate and thereby set difficulty. ASERT fits that description. Simple also means there's less likely to be a code error. Everyone I know of who is very knowledgeable about difficulty algorithms understand it and agree it is the best choice. 10) There are some algorithms that are ridiculously complicated for no apparent reason and don't work well. >despite a lot of interesting research, it still looks like we've not even defined the exact problem No, the problem is clear: It's to estimate the current hashrate and thereby set the difficulty so that the solve time will spread out and average 600 seconds.
> 2) By "low confirmation time" he meant we want the average confirmation time to be as close as possible to avg block time. ... It's not possible to have confirmation time less than avg block time. Actually, it is possible to have confirmation times be less than the average block solvetime. An RTT can achieve this. If every block takes exactly 10 minutes, then the average confirmation time will be 5 minutes. However, using RTTs to achieve exact block intervals like this will dramatically increase orphan rates, and is not a good idea at all. We're better off just reducing block intervals to get fast confirmations than to narrow the distribution of block intervals.
Bitcoin fan
Thanks for sharing this content.
@jtoomim I really wish there was a way I could help with your incredible efforts
Hello thank you for this info. I like trading in cryptocurrency. Even the market is very volitile and its hard to trade but still profitable and need to control greediness.
Thank this, I get some idea in your article, I like it
Good luck with your project sir. Getting better DAA for the Improvement of BCH. That's why I like reading articles when it comes to BCH. BCH for the Win!
I still don't know much about the technical side of how crypto work especially BCH, but I am interested by the fact that it shows a lot of information that could help me to understand more about BCH. Thank you for doing and sharing this article.
For my little knowledge about mining, I stick to not arguing about that topic and that those who know about it do so, since otherwise the lack of wisdom on the topic would result in the waste of ideas , and therefore of the bch, because mining is basic to the topic at hand.
Interesting article algorithm shows that BCH will be crucial without DAA
this is great. I really appreciate reading this
Pretty much sure bch price will grow more and more... Goodluck
really have no opinion other than to defer to those I believe are putting in the "quality" time and energy to make the BEST decisions for BCH .. once upon a time, I put my trust in the Bitcoin Legacy devs to do the right thing, but they chose to screw us ALL .. this time around, I'll at least "TRY" to follow and keep up with the protocol stuff.. very impressed with everything that you're doing .. whatever YOU decide will have my full support
Hi there, I wanted to point out you made a couple of mistakes with regards to the FTL: First you write that it is a node-policy, this is incorrect. It actually is part of the consensus rules. This can be observed by the fact that it was never in the policy.h in the Satoshi client. Your attack using the FTL seems to trip over itself. You give as an attack that a miner mines at the edge of the FTL and then continues mining on it in secret in order to give himself a benefit. If this is your attack then the FTL is irrelevant because he was not broadcasting his blocks, and without broadcasting his blocks he is not held to this rule. Maybe you were thinking that the miner instantly broadcasts his in-the-future block. In which case all miners benefit from this equally and this is really not an attack at all. Maybe the FTL would benefit from change, I don't know. Your attack scenario doesn't seem to give me the impression that it has to change. ps. FTL isn't Faster-Than-Light, in this context, it actually is used as Future-Time Limit.
You're right on the consensus/policy issue for FTL. OTOH, the ABC/BCHN policy is actually a policy, not a consensus rule. As for the mining strategies to exploit the FTL: the main one I referred to is a selfish mining variant. In selfish mining, the attacker will mine a chain which they keep secret as long as their chain is ahead of the honest chain in chainwork. As soon as the honest chain gets close, the attacker will publish their chain, thereby invalidating all of the work done by the honest miners, and capitalizing on any difficulty reduction they may have achieved in the interim. Mining blocks with timestamps near the FTL does indeed confer a benefit. Lowering the FTL reduces the magnitude of the benefit that can be achieved.
are they going to switch to some other algorithm in future or it is for life-long?
This article has added to the little knowledge I had about crypto. Thanks for this. Really informative
Thank you for this long but very informative article :)
Thanks for sharing..
Wow. Great article for sure. Deserve for the tips
Your clarity prevails. Such clarity is not observed elsewhere.
Amazing work. We are so lucky to have you.
I hope this DAA will fix the issue of the entire BCH problems. But I'm pretty sure that there is one proposal that can be used to execute those problems. But I hope social aspects such as norms and egos of the community will stop because it can't help to be honest.
Can't follow the technical details, but I just hope the new DAA (not Grasberg) finally solve the oscillation issue and we can move forward.
This is very helpful and informative article. Thanks for this my friend.
More comments