Chia Network’s response to Chia pool exploit is disappointing, to say the least

So its been a day of talk about pool exploits for the Chia team, and I have to say their official stance has been disappointing at the very least, and possibly risky to their business at the worst case. The issue at hand is a Chia pool exploit that MaxioPool found in the farmer_api.py code that allows a malicious farmer to refuse to form blocks on behalf of their pool, thus reducing pool rewards for everyone, while continuing to submit partials and receive payouts.

First off, I have not seen evidence that this exploit has been used in the wild. MaxioPool thinks they were attacked, and they might have been – I have no reason to think they are lying. But I have not seen any evidence myself. That being said, I have seen working exploit code and its basically been confirmed by Chia Network as something they have known about for awhile and called a “dead weight” attack. However I cannot find any evidence that they disclosed this possible attack publicly prior to MaxioPool finding it. There is nothing in the Chia Blockchain Greenpaper about it either.

Secondly, I do not think this puts the on-chain pooling protocol at risk. It puts some small pools at risk from malicious actors but as pool size grows the impacts of something like this would shrink. The payment model also matters, as PPLNS pools, that pay out every block win based on your share portion, would be harder to notice something like this than a PPS model where every share gets paid regardless of block wins. In fact, it might make PPS non-viable in Chia because the cost of launching a Lazy Farmer attack is so low. It also is not a risk to individual farmers except for the possibility of slightly lower payouts. I think that’s the perspective

So why is their response disappointing? First, they dismissed this as me blowing it out of proportion because of an axe to grind. That is both untrue, and irrelevant. The only portion of my report they even challenged was the description of the issue as an exploit – which it is, unless this behaviour is intended. Then they dismissed MaxioPool and anyone today who expressed concern over this, and they put out this statement basically saying that it was the pool operators problem to solve.

I just want to sort of share our official position on this, aside from the advice and guidance a few folks like Gene have shared above in efforts to help, so the pool operator community knows where we officially stand on this topic.

Our system is designed a specific way with certain decisions made, and while a pool operator can choose to use it in ways it was not intended for their benefit (like, say FPPS), then they need to own that choice and protect themselves accordingly. (Though we will, and have, help you find those solutions if you want advice.)

Early in pool protocol design, the “dead weight” risk was openly discussed, and we understood this to be a potential risk. Unfortunately we had to make a hard choice between either giving Pools centralized control, or giving Farmers the benefit of the doubt and giving them full decentralization. Ultimately we decided to stick with our vision of true decentralization, and included 0.25 XCH + fees reward to farmers as a counter to this potential attack. In the end of the day, this was a hard decision to make, as every blockchain protocol needs to make a fundamental decision on these kinds of hard choice. Our hope was that most pools wouldn’t be inherently susceptible to this, and ones who were (like for example a FPPS pool), would be able to put the time and resources into developing their own additional controls as part of the their pooling.

We understand and empathize with Maxiopool’s frustration, but this is not a Chia bug or exploit. It is a fundamental piece of the blockchain code working as designed, after a deliberate series of choices were made, in a decision to help ensure full decentralization. Thus, we recommend no pool operator provide PPS payout, unless they are also willing to take on this risk or add monitoring and controls around it of their own design.

Look, saying an problem is core to the design and your users have to just live with it or work against it very bad business. It is very possible that at the end of the day it will always be a risk that a malicious farmer lies to the pool because of the “farmer signs blocks” design. However, they could own the issue a little and make the attack a little more difficult to pull off. I mean, its like a couple of keystrokes to comment out a function, without a single check anywhere else to make sure the client is behaving properly. You can’t say that the whole problem is the people running your code when your code does literally nothing to prevent this issue. Doesn’t even try.

Also, for such an open, decentralized system there are sure a lot of things you have to do exactly Chia’s way or you will have problems. Don’t do this, don’t say that, don’t run your pool this way, etc. I’ve been involved in open source for many, many years and this is not the way. I hope it never will be.

Good software developers don’t just handwave away issues, they don’t point the finger at everyone else for issues, and they don’t refuse to fix issues with their code. They take ownership of the issues, even if they aren’t easily solvable. That was not done here, and that’s why I’m disappointed. Come on guys, refusing to even call this an exploit is childish and silly.