Time for a serious look at Proof of Work change #12
Comments
|
Agree on the principle. We have different choice In an advent of a malicous miner takeover or wants to enforce his rules on the community:
The main issue with every change is, how do we switch while the blockchain keeps running? we could allow 2 PoW for a while and gradually reduce the amount of blocks the old one is allowed to mine. Slightly unrelated but we should also work on a p2pool like system to counter miner centralization, not sure how to make this scaleable tho as the variance in ordinary p2pool systems is hard to cope with for smaller miners. |
|
We've investigated this before, mostly around Cuckoo Cycle, and at some point it fell by the wayside. I support reopening this. I think that, at a minimum, we'd need to be able to provide:
Some urgency might not be a bad idea, as the window in which we can make such broad and sweeping changes is narrowing. |
|
What really matters is what we should call the legacy chain? |
|
This might be a bit too radical/off topic but I think one issue that might be important to consider in PoW is the competitive exclusion principle: http://en.wikipedia.org/wiki/Competitive_exclusion_principle "In ecology, the competitive exclusion principle... is a proposition... that two species competing for the same limiting resource cannot coexist at constant population values. When one species has even the slightest advantage over another, the one with the advantage will dominate in the long term. This leads either to the extinction of this competitor or to an evolutionary or behavioral shift toward a different ecological niche. The principle has been paraphrased in the maxim "complete competitors cannot coexist". I think that miners are equal to different species that are direct competitors for the limiting resource which is the block reward. If the competitive exclusion principle is correct and applicable here, I think miner centralization might prove inevitable unless you can make it where there is effectively several different resources. This may still result in miner centralization, but likely only for one specific resource and not all. If you imagine a coin that has multiple PoW algorithms: ones optimized for GPUs, CPU, ASIC1 type 1, ASIC type 2, etc it might result in a better distribution of miners: some would be botnets, some would be ASIC farms, and others consumer grade hardware. Another thought might be to try to make mining linked closely with a volatile resource. If electricity prices fluctuated wildly among populations, perhaps that could prove to be useful. An electricity intensive mining algorithm optimized for consumer hardware and a low electricity consumption ASICs might be less likely be owned/controlled by the same entities. |
|
Brainstorming and may be "forking" the main practical issue in hand, im am INTP can't help it... Do you think "tangle" type configuration (like IOTA) can be suitable and robust enough to fulfill the main function of Money- to be a storage of value that can be deferred through space/time? [https://www.youtube.com/watch?v=T2FJ9hH66b8]- being immutable, decentralized, widely connected enough, and attack proof? A meshnet network of small devices that do their own validation and PoW simultaneously with a micro ASIC. Decentralization could be forced as a function of being rewarded by being the farthest away from concentration of these micro meshnet ASICs, therefore also expanding network/signal coverage and harder to become fallible through centralization. edit: PS: this micro ASIC should be so simple to produce that you could massively 3D print it if you wanted to anywhere in the world with the bare minimum materials. |
|
Coincidentally, this paper came to my attention today - Proof of Work without all the Work Worth reading. |
|
One potential attack vector that opens up once you opt for "decentralization" is that the amount of hardware out there that can be put to use in attacking the network becomes a lot higher. If you optimize for gpu(s) the investment cost of attacking the network isn't lost if monero goes down. If you compare that with dedicated ASICS the investment cost of attacking is lost if the network is harmed (either they find something new to mine using the same ASIC hardware or they're stuck with a brick). |
|
Maybe this is a stupid idea but wouldn't a small reward paid for running a full node also prevent centralization? We run full nodes as a hobby and to verify blockchain's integrity but most people don't. |
|
Cuckoo can work with pool mining if a cuckoo round is at low enough difficulty. Worth reading: https://github.com/ignopeverell/grin/blob/master/doc/pow/pow.md |
|
@gegemos That may cause centralization, because people will put their node on services that guarantee the most uptime in order to maximize their rewards. |
|
Taking an opposite viewpoint, at Sia we've decided to embrace ASICs. Mining centralization is definitely an issue, but so is network security and making sure incentives are properly aligned across all users on the network. As we wrote in our blog post (https://blog.sia.tech/choosing-asics-for-sia-b318505b5b51), GPU mining is a "false panacea that ultimately leaves a cryptocurrency far more vulnerable to attack." One main issue is 51% attacks. On GPUs, that will always be a serious risk, as a few large Ethereum GPU pools could coordinate to attack Monero's network. Additionally, we don't know for sure how many millions of GPUs sit in the hands of private companies, research centers, and so on. There is also a question of whether any algorithm is truly ASIC-resistant. Another main issue is incentives – we believe it's more healthy if miners use ASICs that can only mine a single coin. That way, they can't simply switch back and forth on their GPUs to whatever coin is most profitable at the time, and are more invested in that coin's success. At Sia, we decided to start a subsidiary called Obelisk to build the first ASIC miners for Siacoin and raise money via a presale. The idea is that, if we can widely distribute the initial hashrate, that should give a good foundation to keep away centralization. Of course we will have to keep making better chips, but we would continue to widely distribute them via presales and do our best to stay ahead of the competition. This is of course going to be a huge decision for Monero, and I'd recommend that you observe how our Obelisk project at Sia goes over the next several months. We'll be shipping out ASIC miners by June 2018, so this group may be very interested in seeing how the switch goes. |
|
I kinda like the idea of tying mining more closely to a node, requiring blockchain lookups to crunch the PoW. Really, why are miners separate from nodes in the first place? Right now operating a node is a pure expense, totally uncompensated. It would make sense to get at least some kind of payment, periodically. Binding mining to nodes will raise the hardware requirements for mining, making it less feasible to integrate entirely in a single chip. It will also raise the CPU cost of running a node, making it too expensive to run 24/7 on the majority of cloud providers. |
|
Moderator note: deleted long off-topic garbage post from anonymint. |
|
I very much support bringing down the walls between "miners" and "users". All users should be miners and vice versa. I would like to suggest we consider biocryptics towards that goal. Basically, deriving keys from biometric information (nothing leaves your house though). The main benefit is that each human can run a single miner, not n miners where n is the number of cores they have access to. I do understand this approach can sound too wild, but let's give it a chance For more details, please check out the Cicada whitepaper .. I'm also quoting perhaps the most interesting bits below.
|
|
I wonder if it would be helpful to have a feature where all miners are not anonymous to the users/nodes such that a node may have a blacklist of miners (which would require miner identities I guess) to exclude one's Tx rewards going to "bad actors". This is a sort of voting power given to nodes. |
Is that the real issue? It seems to me that Monero is one of the few coins out there that is not just being mined with a GPU, but there are several people out there mining on CPUs, and they aren't even at a significant disadvantage. This is a very positive sign that the memory hardness of CryptoNight is working, and that ASICs would be uneconomical. Other poorly thought out PoW algorithms (I'm thinking of things like PrimeCoin, MemoryCoin, etc) got optimized to hell and left everyone else out in the dust. Monero is old enough and high profile enough that if building ASICs was economical, I think we would have seen movement in that direction by now. It clearly isn't as asymmetric as Bitcoin where even 90nm ASICs could blow GPUs out of the water. Remember that SHA256 was designed to be super cheap in hardware, it was one of NIST's requirements for the SHA competition, and CryptoNight was very much designed to be expensive in hardware. Of course someone could design CryptoNight ASICs, but I doubt they would be able to compete with the economies of scale we get from commodity GPUs. I'm a fan of algorithms like Yescrypt, Lyra2, Argon, etc, which have had a lot of work done on them in academia to show that they would be uneconomical to put into hardware, but weakening them to enable GPU mining would be really tricky and dangerous (look at the last couple Vertcoin PoW forks). I've been impressed with how well CryptoNight has held up to attempts to shortcut the algorithm, and I think that unless there is really solid evidence that someone magic'd up a way to do it super cheap in hardware, I think switching PoW would do more harm than good. |
That is not necessarily the case if that someone who had the deep pockets required was preferring to keep it secret so it can run Monero as a Sybil attacked honeypot. How would we know? I posited the only way we can know is to have transaction revenue much greater than block reward and observe if the orphan rate skyrockets. If not, the mining is 51% controlled—otherwise inconclusive. I’m not advocating running such a potentially self-destructive experiment.
Afaik, having the lowest hardware unit cost (due to high volume manufacturing) its amortization is largely irrelevant because it is a small component of the mining cost, which is dominated by electrical efficiency even though profitable lifespan is limited by Moore’s law. So the only economies-of-scale required is sufficient ROI on mining to payback the capital cost of the ASIC R&D and fab setup. This threshold may or may not have been met yet given Monero is not even a $billion market cap yet, and considering likely higher capital costs you allude to. Note that GPUs can be re-purposed to continue their utility beyond their mining profitability lifespan. |
|
No, don't fix what is not broken. go back to Litecoin. |
|
@zachherbert We don't know the makeup of those Ethereum pools, but aren't you assuming that the miners in those pools would want to be complicit in committing a 51% attack. How many of those pools are made up of individual miners as opposed to centralized datacenters controlled by a company or individual? |
Actually I thought of that conceptually before when I was trying to devise a solution for the liveness-gets-stuck issue that I mentioned about Byteball, but didn’t bother to fully develop the model, because it has a very obvious and fatal flaw because they ostensibly didn’t model the economics of it. Their model is the provability that it can’t be gamed algorithmically. But afaics, they didn’t model the economic ramifications of their algorithm. Their algorithm is essentially scaling the amount of PoW difficulty (that all mining node ID’s must have to survive a PoW challenge round) by the rate of changes to the ID set. So assuming there is no attacker, then everyone agrees to play nice then the difficulty remains low. But the specific flaw is its communism because it steals from those who have greater or low-cost hashrate and redistributes to the marginal miners, because every good or bad ID has the same weighted vote. Of course the same entity can create more than one ID to spread its hashrate, but this is attackable because if the threshold of their splits are exceeded by an attacker who issues too many ID joins/deletes per round, then the split IDs are deleted by the challenge round and amplify the attacker’s effect. So the economic implications are amplification instability else communism. We must understand the economics of decentralized consensus. Also it appears to me that it requires some trusted setup on the initial randomness to create a non-gamed ID member set for the committee which acts as the “server”. There may be other issues, as this is brand new so peer review is presumably lacking. |
|
Here's a quick pre-amble (3 brief points), then I'm going to comment on folks' individual responses. My entire point of view here is to look at decentralization and egalitarian mining as a matter of financial barriers to new users mining with a hashrate comparable to the current per-user hashrate, and a matter of long-term trends towards coalition mining. TLDR: lethos3 and pierce403, in my estimation, are correct. Disclaimer: I am happy to be wrong, and I would rather be corrected than to continue disseminating false information. So ask questions and call me out on my mistakes.
That is to say: CryptoNight was designed to force every user, GPU or ASIC or CPU, to utilize the slowest part of the computer in every hash computation. Moreover, all modern human computers will be vulnerable to this slowdown, and will continue being vulnerable to it until a major overhaul of computer architecture takes place. Take 1, 2, and 3 together and I don't see a rather elegant implementation of a decentralized mining process. IOW, I don't anticipate a long-term trend toward mining cartels due to PoW with Monero unless computer architecture starts to change. Now, in response to comments: shaolinfry: "I believe it's time to seriously review the proof of work algorithm used in Monero in light of the very serious consequences we have all witness with mining centralization in the Bitcoin community." The centralization of Bitcoin is directly due to ASICs and the impossibility for a CPU or even GPU miner to break even. "Miners can centralize the network simply by accumulating a majority of hashrate which may be easier to do when there is only specialized hardware from limited sources." In this case, the word 'simply' is tricky. Like saying "all we need for fusion is to simply get two protons very close together." Accumulating a majority of hashrate right now can only be accomplished by state actors or large botnets mining on equipment without the owner's consent. In the first case (state actors), I don't consider this a reasonable threat model for several reasons (I can elaborate). The second case, I think, is an inevitable consequence of egalitarian, decentralized mining. In fact, I think this is a value of decentralized computing: if many coalitions are capable of launching an attack but any one coalition needs more than 50% of the network to make such an attack, then any one coalition is less likely to succeed. "The second form of centralization is more insidious, which is also currently observed in the Bitcoin mining ecosystem where one company commands the monopoly on ASIC hardware supply." Disregarding the monopoly-ness, the sheer existence of specialized hardware that costs more than a CPU and is orders of magnitude more efficient leads to centralization. Add on top of that the idea that AMD might be the ones truly in control of a mining network... yeah. "It is unclear if the Monero proof of work can be optimized by specialized hardware." <--- Completely incorrect. See above. "If the proof of work is only viable on commodity hardware, such as GPU, it's much harder for a manufacture to dominate because GPUs have a wide range of applications and thus plenty GPUs available in the world from a diverse set." CPUs are also commodity hardware. Moreover, the hierarchy of minability goes like this: anything that can be mined on an ASIC can be mined on a GPU, and anything that can be mined on a GPU can be mined on a CPU. It's not really possible to construct a mining system that operates on a GPU but not a CPU or an ASIC. If you a computation can be efficiently performed with a GPU, an ASIC can usually be designed to do the same thing but more efficiently. If we design a mining game that is mine-able on GPUs much more efficiently than CPUs, and if Monero then sees a price increase, then ASICs would be just around the corner. "CPU only algos are obviously problematic due to botnets from hacked computers. " I think this is a natural and inevitable consequence of any egalitarian system that has no punishment associated with collusion. In particular, the problem with botnets is that user systems have been compromised, not that a large swarm of computers are validating transactions, or that a single entity is in control of the swarm. If we are concerned about a botnet controlled by a single entity coming in and rewriting our blockchain or selfishly mining, the solution is more competition between botnets, not less. othexmr: "Modify CryptoNight slightly - it uses 4 different hashing algos, we could replace or modify them slightly so break unflexible hardware, this should be easy to deal with for our own CPU and GPU mining software." If we are concerned about the hashing algorithms being gamed into greater efficiency, you are correct that swapping them around would break inflexible hardware. However, the bottleneck for CryptoNote mining is not in the four hashing algos that contribute to CryptoNight, the bottleneck is in the usage of the L3 cache. So a user who cleverly designs something that can handle the four hashing algorithms is still sunk in the water because his computer architecture is what's slowing him down, not computation of many hashes. "Switch to something really asic friendly like Blake, Skein or Keccak (which we use already), lowering the costs for asic miners to join the game and letting the market deal with it." If we want to put up a financial barrier to new users running a node while centralizing mining power with the richest of Monero miners, then sure. "Come up with system that makes ASICS harder to do, like using the blockchain as a scratchpad for calculations" <--- I don't know how you could use the blockchain as a scratchpad for calculations. But I know that CryptoNight is already more ASIC resistant than almost any other option around (short of designing our own hash functions). fluffypony: "I think that, at a minimum, we'd need to be able to provide: reasonable GPU mining kernels, fast validation to prevent DoS risk, use both as a mining PoW and as an on-handshake PoW." Providing a GPU miner that is markedly more efficient than the CPU is a centralization move. The short-term benefit would be more miners (for a time... until all the CPU miners are flushed out), but the long-term cost of this would be that no one will mine with CPUs anymore. CameronRuggles: Your observation about competitive exclusion between species is important. There is a behavioral version describing competitive exclusion between behavioral strategies and individuals deploying different strategies. The idea is not that only one species remains, but only one behavioral strategy remains. In our case, each miner is an individual, the resource being fought over is a nonce that makes a block's hash sufficiently small, and the strategy is the equipment they employ while mining. The competitive exclusion principle, then, implies that only one strategy for finding nonces (i.e. type of mining equipment) will remain after a sufficiently long period of time. I have some ideas of what it might look like to compete for many resources. As you say, a mining game using more than one cryptographic hash function could possibly work... but it would require some thought. I'm not convinced this would be the right approach, but I find the idea interesting. Makeone11: "If you optimize for gpu(s) the investment cost of attacking the network isn't lost if monero goes down. If you compare that with dedicated ASICS the investment cost of attacking is lost if the network is harmed (either they find something new to mine using the same ASIC hardware or they're stuck with a brick)." If a GPU can do it, an ASIC can do it better. gegemos: "Maybe this is a stupid idea but wouldn't a small reward paid for running a full node also prevent centralization? We run full nodes as a hobby and to verify blockchain's integrity but most people don't." <--- I think I fully support providing slightly larger block rewards to full nodes. As hyc points out, running a full node is pure expense. If we can come up with a way to offset the cost without rewarding users with enough personal resources to run a full node, I would support that, but I'm not convinced it's possible. Maybe we could have a a block reward bonus on top of the usual block reward, where the bonus is inversely proportional to the number of full nodes on the network. Fewer nodes -> bigger bonus -> more nodes -> lower bonus -> fewer nodes -> ... zachherbert: "Taking an opposite viewpoint, at Sia we've decided to embrace ASICs. Mining centralization is definitely an issue, but so is network security and making sure incentives are properly aligned across all users on the network." This is a logical way to go, maybe... except it puts up a barrier to an arbitrary user participating in the network, which in the end leads to fewer non-colluding users participating in the network, which risks all that netsec you were hoping for. After all, fewer coalitions mining means any one coalition has an easier time hitting 51%. Your idea about incentives and miners using ASICS that can only mine a single coin does the same thing, by reducing the total number of participating users and hence reducing the total number of coalitions. Having said that, I can't see the future of an ASIC-based POW system that doesn't resemble the current problem in the bitcoin universe. That doesn't mean it can't exist, it means I have a failure of imagination. kim0: "I would like to suggest we consider biocryptics towards that goal." Interesting idea. Identity-based encryption, where keys come from some arbitrary data like your e-mail address or a photograph of you (or a scan of your iris), has experienced some theoretical problems in the past and recently, where cryptanalysis is quite effective. Having said that, presuming we find a secure system... I'm not sure how you can verify that, say, an iris scan used to generate a pair of keys, actually came from a human instead of a random iris generator. If I can code up a piece of software that randomly generates realistic iris information, I can feed each randomly generated iris into the keygen and run as many bots as I like. As technology improves, we can also assume that arbitrarily realistic iris scans could be simulated by computers. In order to fix a problem like that, usually cryptographers introduce trusted third parties or certificate-based systems, where some authority determines if a real human is behind the iris. It's still an interesting idea. pierce403, lethos3: Agreed. shelby3: I am super happy to talk with you if you have a specific concrete proposal for POW. After all, in a high-txn-fee-with-respect-to-block-rewards environment, you are correct that PoW doesn't operate too well. I will also engage with you about your claimed honeypot situation if you identify all of your assumptions, fix the ones that are blatantly incorrect, and if you develop any verifiable concrete numbers on the complexity of solving the combinatorial problems associated with de-anonymizing a cryptonote blockchain. However, I will not engage with you if the conversation will resemble something like "Like it or not, you are going to use my solutions!!1 Checkmate, son!!112 Fluffypony is gestapo1l1khj." Your choice. |
|
@pierce403 can you elaborate on this:
for those of us who don't follow Vertcoin What happened there and what did you learn from it? |
|
Not sure how to take seriously any 'decentralize mining' proposal that would centralize mining in two US-based corporations subject to export regulations that already restrict the proliferation of high-end hardware along political lines. Keeping commodity CPUs and architectures such as ARM, POWER, and OpenRISC competitive with the most powerful chips is surely a better approach to 'decentralization'... |
|
Removed another derailing post. Just a reminder to anyone passing by that this is a moderated issue on the research repo, and requires serious and/or academic responses. Known contributors preferred, but this repo is open and input from anyone is welcome. That said, derailing and nonsense will be moderated in order to keep the conversation on-topic. |
|
Please use markdown when replying to people, especially in big blocks. Most notably, "quote" someone by beginning their quote on a new line with a leading "greater than sign" followed by a space. Otherwise this is super tedious to read. (A bit off topic but in the interest of the discussion... @fluffypony feel free to delete if you think too spammy.) |
|
Would it be possible to implement a cpu/gpu combination algorithm? Could this not mitigate the botnets since most infected computers probably don't have a dedicated gpu and igpus are not that powerful to begin with anyways? |
|
That would also eliminate a lot of non-PC devices (phones etc.) as they tend to have poor GPU driver support for OpenCL/generic compute. |
|
@b-g-goodell, referring to @fluffypony's point and your response:
I believe the point he was making is that if we switch PoW and we switch to something that can still be mined with a GPU, we should make sure we have mining software that has been relatively optimized, otherwise someone can take advantage with private mining software and that defeats the purpose of the switch. On the topic of CPU+GPU mineable algorithms, one thing I'd like to bring up here is that a consequence of the economics of Cryptonight mining being somewhat similar on both CPU and GPU is that this drives towards a state where GPU mining is actually not economical from an opportunity cost perspective, unless Monero's mining rewards are much greater than that of other coins that are only economical on GPUs. For example, today it might be profitable to mine ZEC, ETH, or XMR with a GPU. However, the fact that XMR is also profitable on CPU drives the reward per hash down relative to ZEC and ETH because CPUs can only mine XMR. As a result, anyone GPU mining XMR is incurring losses in terms of opportunity cost. If XMR rewards were much more valuable than everything else, this effect would lessen, as most hashrate would point to XMR regardless. But that's not the case today, nor likely in the near future, and therefore GPUs will tend towards those coins that are only GPU mineable. |
|
@senselt of course we’re aware that any system designed will have people able to eek a little more performance than the rest. The point is not wether someone can $2/hour more profitable than the next guy, but whether they are so massively more profitable that they cloud everyone else out. As an example, we know that botnets can mine Monero at effectively zero cost. However, the ease of access to equipment that GPU miners have, coupled with the usual murky nature of running botnets, means that botnets have never made up more than 10-15% of the network. Thus the network is broadly secured despite the fact that all professional Monero miners should be using botnets if they really wanted to be cost-effective. |
|
@senselt you have a very limited view of open source. Everything I write is open source. Only a tiny fraction of it has any bearing on my reputation or income. I'll stop here before digressing further. |
|
Riccardo is correct. The maximum GPU advantage over CPUs is approximately 5 orders of magnitude. ASICs is about 12. DRAM is about 2. It would behoove us to grasp the metrics and do that math. |
|
And how do you respond to a specific post on GitHub? This UI is atrocious. |
@DanielPlante It can be helpful to use Markup to quote specific people and @ to mention them, but there's no threaded conversations. |
|
Sorry, I don't know what "markup" means in this context. And does the "@" mean the same here as it does on twitter? Seriously folks, when did format dethrone content? It is, and has always been, just semantics trying to convey semantics. Embrace plain communication. That said, I will still try to find the time to reformat the tweet storm into the approved format. But you are free to surprise me by engaging with questions based on the original post. |
|
What would be the next step here? I just want to keep the topic alive :) Plus, I can chip in a little bit if there is some serious initiative to be funded. |
|
IMO there is no next step since first step was skipped: proving there is a problem to begin with :) Sure, someone can look into solutions ahead of time, but what problem is being solved again? I thought solution comes after the problem, and not the other way around. |
|
Sorry, I meant "syntax dethroning semantics". That said, JollyMort has a point: do we all perceive that there is a problem here in the first place? If you disagree, then why are you spending the effort to argue? Stick to the point you presumably want to address. I'm available to answer questions. Thank you all for your input. |
|
The two biggest practical problems I see with CryptoNight:
CryptoNight represents a lame approach to cryptosystems design. |
Geography doesn't really matter. Ownership is what matters. I created a definition of "centralization pressure" in my post here: https://np.reddit.com/r/Bitcoin/comments/74t4ua/an_explanation_of_why_the_block_size_debate_is/ Basically, centralization pressure is all about profit margins. The lower the profit margins, the higher the centralization pressure. Along with @CameronRuggles, I also worry that competitive pressure will inevitably centralize any static proof of work system. I liked Cameron's suggestion of having many algorithms that work alongside each other. This would prevent the system from being static, and would allow for an equilibrium state with at least 1 owner / strategy. If each algorithm had a completely separate difficulty, it would mean various types of miners could pop up and compete separately from other types of miners. Another thing that would keep the system from becoming static and tending toward centralization is to have the algorithm change over time. If there was some way to slowly mutate the algorithm to force miner strategies to change in unpredictable ways, it would ensure competition required innovation, which inevitably requires changes of the guard. Finally, I disagree with @fluffypony that the window for a PoW change is closing. I don't think we need to treat this with any major urgency. We don't want to rush into a minor PoW change. We should really think this through and make a breakthrough around this - something we can be far more confident will stand the test of time. As for the window closing, like someone else suggested, we can have multiple PoW algorithms active at the same time and slowly phase out the old one. This means there doesn't have to be any disruption to the network, no matter how big it is. |
|
Hi, @fluffypony - just a quick drive-by: Cryptonight is a quite solid algorithm from an ASIC perspective. It's designed very well to take advantage of three features that conventional CPUs have: (1) Built-in AES acceleration; (2) fast 64-bit multipliers; and (3) large caches. If you look at the architecture diagram: http://www.cs.cmu.edu/~dga/crypto/xmr/cryptonight.png and trace the critical path, you'll spot each of these features being used, and to quite good effect. I haven't attempted a really deep cryptanalysis of everything in the PoW, but as you know, I, er, worked rather hard to find any vulnerability I could in it, and didn't see anything I could exploit. I don't think there are subtle, hidden evilnesses in there -- whomever designed it had a good grasp of both modern CPU architecture and the design of mixing functions. The path to a cryptonight ASIC is fairly obvious: A small-ish chip with 2MB of SRAM for the scratchpad, an AES implementation, and a 64 bit multiplier. Maybe more AES for doing the initial scratchpad fill. Interestingly, this looks quite a bit like the CPU implementation, but an ASIC designer would have a few advantages: (1) Less area wasted on "other" functions that CPUs support; (2) Fixed function - no instruction decode overhead; (3) Better locality from the fixed-functions to the scratchpad (a large CPU has ~20MB of cache for 10 cores, so each core is a bit farther from L3 cache); and (4) Yield. By yield, I mean that the ASIC for this would be smaller than a modern CPU, and it's usually easier to produce smaller chips than absolutely massive ones like an Intel or Nvidia beast. You can fit them more effectively on the silicon wafer, and errors aren't as deadly. But even with those advantages, they're still going to take a lot of area, and area is the major determinant of cost -- a modern CPU devotes much of its die area to cache, for example. The other alternative is more AES/multipliers together with HBM -- high-bandwidth memory. This would look a lot like what Nvidia offers in the Volta. I suggested this as a path for running Cryptonight about three years ago: https://bitcointalk.org/index.php?topic=717267.msg8129454#msg8129454 but I think I was overly-optimistic about the progress people have made in getting HBM working. Nvidia took about two years more than planned to get it released, and the implementation isn't as technically nifty as some of the earlier plans had it looking. There will still be progress in this front. There's also the potential of trying a compute-in-memory architecture for Monero, but the AES and 64-bit multiply do make that a bit harder. And we're seeing GPUs with HBM right now, which should provide a pretty good boost to hashing speed - and steal a bit of the thunder from a potential HBM ASIC. I would never say that ASICs won't get a factor of ten or so on Cryptonight, but I believe the algorithm will continue to fare very well for a while to come. The price you'll pay for it, of course, is expensive verification, as you and others note already in this thread. Cuckoo Cycle and Equihash both have worse CPU/GPU ratios but offer faster verification, and now that xenoncat chipped in with a set of optimizations to Cuckoo Cycle, I'm feeling less paranoid about unanticipated speedups in that area -- though I retain some caution. Maybe in another year I'll believe it's not going to surprise us much more. :) @qertoip - you wrote "CryptoNight represents a lame approach to cryptosystems design." -- I actually suspect that the designer of CryptoNight was an expert, though operating in the shadows. I've examined a lot of proof-of-work functions, and CryptoNight is one of the few memory-bound ones that I haven't been able to find algorithmic improvements against (as opposed to implementation hacks). That's no guarantee there aren't gotchas, but it holds up well. If you want a second opinion - which is always a good idea - y'all might see if Solar Designer would consider providing an analysis, similar to what he did for Equihash. I've read his analysis of that one and it's solid. |
Why is expensive verification a problem? Is it because the expense is constant no matter how large of a miner you are? |
|
Verification cost has a few problems: (1) Time to synchronize a new node if you don't want to trust a snapshot (takes a lot of CPU to verify the blocks); (2) DoS resilience, if someone tries to mount an attack involving large floods of fake (invalid) blocks. For pools, for example, this opens an avenue for mounting a denial-of-CPU attack by submitting invalid shares. Pools and nodes have mechanisms to handle that, but the "perfect" PoW function (which may not exist...) would have nearly instant verification. |
|
(1) is a theoretical issue but in practice not much of one. First it is only an issue at all for SPV-type nodes, since the cost of verifying the actual transactions is a lot higher than the PoW. Even for SPV (1) is not a huge factor; on a shitty desktop it still only takes about 3 seconds to verify one day worth of PoW (so 20 seconds if catching up after a week offline). Mobile raises battery consumption issues but still not a huge issue unless doing a fresh sync from 0 (which can be done plugged in and/or shortcut with checkpoints). Agree of course about 'perfect PoW' in all respects (would be great, may not exist). Most of these concerns were thrown around when cryptonight first came on the scene with (artificially impaired) 1-2 H/s performance, and at that point they were serious issues indeed (many minutes to verify one day of chain, etc.). Once the function was properly optimized the issues are far less signfiicant in practice. |
|
There is another option I never see given which is to avoid the contribution to payout link. In other words:
Centralization is probably still possible using a method like this but would happen at a greatly reduced rate. It could likely be fiddled with (it's oversimplified in 3 bullet points) to find a sweet spot in terms of rate of centralization vs usability. I'm not sure centralization given the current concepts around mining is fully possible to avoid but it can be mitigated significantly and that's the point. It's theoretically possible to brute force wallet generation to find the private key for every bitcoin address for instance - except that also in theory it would take longer to solve than the age of the universe. One may not be able to fully prevent centralization but one might feasibly slow the rate at which it occurs by being clever and making the time it would take so long as to not matter. |
|
@induane Mining is the process by which its determined who gets to choose the transaction ordering for the next block. As long as miners mine a valid block, they can put anything in it they want to. If you want to reward all the miners that exceed a threshold, you still need one canonical block. That canonical block would have to contain a record of which other blocks reached the "hashrate threshold" and the addresses to send the mining reward to. Why would any miner voluntarily decide to give other miners a cut of their block reward by including them in their block? A block would have to be rejected by network rules in order to enforce this, but the question then becomes: "how do you determine canonically which threshold-reaching blocks the canonical next block should contain?" It seems like the idea is impossible to implement. You'll either have a nothing-at-stake problem like with PoS, or you simply have a system that gives miners no incentive to do anything differently than they're currently doing it. The only way to smooth out the time-variance of successfully mining a block is by reducing the block time. |
|
@fluffypony how are you feeling about changing monero PoW now? Apparently they were mining monero with asics when we were having this conversation. I still think multi-pow is the step in the right direction. Otherwise, next time, bitmain may just keep mining secretly. DGB had / has far fewer problems in changing their PoW than monero. When the change occurred, monero was at risk for being targeted by large GPU pools, where as, DGB will not be at risk (or at least no where near the same level of risk). |
|
And so this thread, and the promise of it, died not with a bang but a whimper. Thank you al for your time. Maybe there are other more productive avenues. |
|
@DanielPlante I don’t think the discussion is over, it’s just that these things move slowly in FOSS. In my mind the only three possible options are:
None of these are going to be pushed into production any time soon, as they all have time constraints. |
|
@fluffypony Cuckoo Cycle is not ASIC resistant. |
|
@DanielPlante the discussion didn't die, it just evolved from the realm of research into actual development. monero-project/monero#3545 We have (at least) two viable PoCs now. |
|
Sorry folks, I still can't see how to reply to a specific post with this UI, so this is directed at the last 3 responses: My underlying point was that the thinking on this issue seems to have become almost intractably moribund. I have seen no recognition that computational proof of work is simply one facet of a more general concept: shareable digital proof of the control and use/expentiture of a real world asset. If we step back and take in this wider view, we should see that there are other hard proof avenues besides simple computational power (and the implied energy burn - that's a real world resource and important too) that can anchor the virtual world to the physical, which is another way of describing the kind of proof regime we need. Seen in this light, what other approaches can we take advantage of? Well there is the DRAM based approach I mentioned, and that is a hard proof. 2nd-level storage such as hard disks/SSD's are an available avenue as well but the throughput time makes it impractical. I've tried to imagine a scheme that can link digital proof to gold and other non-computational assets but I think that's not possible. Maybe I should change gears myself on this issue, and pursue this issue in a different manner: Read my initial post. The original Nakamoto consensus proof approach was gamed by a trillion times - 12 orders of magnitude. You will not be able to economically game the approach I described by more than 1 order of magnitude. I will take the time to explain in detail why you are wrong, and hopefully a consensus about the technical nexus between the virtual world and the real world will emerge as a bonus. |
|
This might provide a bit more clarity: https://twitter.com/Daniel_Plante/status/1003419231352811520 |
|
So i know you guys probably wouldn't want to use monero as a proving ground for this either, but i developed a PoS protocol that I've calculated to be several orders of magnitude more secure (ie higher cost to attack) than PoW. But basically it uses 1 minter and many validators for each block to maximize the amount of stake needed for an attack. It also fines minters for minting too far on the wrong chain, which solves the nothing at stake problem while also solving PoW's latency-related centralization problem. This fine also doesn't require any coins to be locked, which minimizes the barriers to participate in the minting process - further increasing the security. It's in need of review: https://github.com/fresheneesz/ValidatedProofOfStake |
|
@DanielPlante DRAM-based approach is a fool's errand. Moore's Law still works as originally stated - number of transistors doubles every 18 months. DRAM density and capacity correspondingly doubles, so what constitutes a "hard limit" on DRAM is a continuously moving target. In contrast, CPU performance has plateaued, so computational hardness doesn't change much at all over time.
Fix your own assumptions first. |
|
@hyc nope. Read my thread. Tell me how you would game it by more than 1 order of magnitude. I described how the current paradigm failed. Give me capital cost and watt hours per found block. Be specific. |
|
Read my tweet thread. Attempt to explain to me why that approach isn't better than simple hashing. I will take the time and effort to explain where you went wrong, but to be frank you should have realized that for yourself if you honestly took the time and effort to understand what I was saying. I'm available. Up to you. |
and others
I believe it's time to seriously review the proof of work algorithm used in Monero in light of the very serious consequences we have all witness with mining centralization in the Bitcoin community.
Mining centralization takes some obvious and non obvious forms. Miners can centralize the network simply by accumulating a majority of hashrate which may be easier to do when there is only specialized hardware from limited sources.
The second form of centralization is more insidious, which is also currently observed in the Bitcoin mining ecosystem where one company commands the monopoly on ASIC hardware supply. This is detrimental to decentralization because the company is able to exert economic force against both competitors and it's own customers. Because they are the major supplier, new players can be quickly starved out of the market through anti-competitive pricing designed to suffocate a new company. In the case of customers, since there is an unlimited demand for mining, and a scarcity of equipment, mining equipment customers can be coerced economically with threats of ceasing new sales. All these things encourage and enforce a cartel that is both difficult to see, and difficult to tame.
It is unclear if the Monero proof of work can be optimized by specialized hardware.
Clearly the best defense against mining hardware monopoly is to make it uneconomical or impossible for specialist hardware to be created for Monero. If the proof of work is only viable on commodity hardware, such as GPU, it's much harder for a manufacture to dominate because GPUs have a wide range of applications and thus plenty GPUs available in the world from a diverse set. CPU only algos are obviously problematic due to botnets from hacked computers. GPUs don't suffer this problem since GPU hijack would be very obvious on PCs.
In any case, I believe Monero is in a precarious situation and given the clear lessons from Bitcoin, we should take proactive action to ensure Monero does not become the center of a similar situation.
The text was updated successfully, but these errors were encountered: