Since your ASIC/GPU does not claim to be unique, they can just cross check your answers, do replays of known results etc.
I think a variable rate difficulty based on farm size would work. For example, if I have 1TB, the pool sends me low difficulty challenges with an expectation that I should be able to have X verifiable proofs per hour or day.
Since the difficulty is a rate limiter, you could fluctuate it as needed until a farmer is getting X proofs per hour and use that to estimate their farm size to ensure theyâre not claiming something unreasonable.
Iâm not really sure how that would work without the pool server acting as a source of truth or by having a sub-blockchain comprised of the pool participants.
1 Like
That document says nothing about pooling. That is just how it handles challenges now. I was pointing it out because of the verifier/prover model. Just adding another check to the Prover responsibilities would answer all your concerns. Not a big deal.
1 Like
Which check? And what would be the cost on all parties involved?
Do you have a pointer to a good description of the relation between the difficulty and the Proof of Space?
Youâre want to reference pool-reference/pool.py at main ¡ Chia-Network/pool-reference ¡ GitHub to see how it all works. Each pool operator will have their own code and some may be open to various âgamingâ.
1 Like
No I donât. That was speculation based on my limited understanding of things.
Of course this would have to be in the software and since it doesnât exist yet, this is just my vision of how I think it would work.
On a scheduled interval, the farmer/harvester would look at its database of plots on file. Then run a scan of the folders it monitors and checks that the files really exist. Run some checksums against them to make sure they are real and arenât being faked in some way. Then report back to the pool of the farmâs current size.
This check could be done daily to reduce overhead.
This is tbh what I thought. It is the pool operators problem, unsolved.
I will not claim to be a Python expert, far from it. But at first glace this code just distributes fractional rewards based on âpointsâ, and says nothing about how to assign points to a farmer, which is exactly the premise of this thread: How can pool operators that want to distribute pool profits according to the degree of participation in the pool, verify that plots claimed by their pool participants actually exist as unique valid plots?
Chia is an open system. Anyone can write software that adheres to the protocol. Any external verifier should operate on the basis that my side of the network can not be trusted. You could go down the rabbit hole of Trusted Platform Modules, signed drivers and binaries etc. etc, but that would be completely and utterly antithetical to the whole idea of open distributed systems,
1 Like
Take a good second glance. Farmers submit partial proofs of space to the poolâs /submit_partial endpoint, that endpoint adds the partial proof to a queue, and then the partial proof is processed to make sure it was for the right pool, at the right time, etc for the blockchain. If all of that checks out then points are assigned.
At the end of the day, I trust that they are not going to release a pooling protocol that is broken. Wheither you or I understands every detail of it within one read through of the whitepaper and WIP sample code is not super relevant. If it was trivial chia wouldnât have taken years to develop.
1 Like
Then what about a random challenge presented by the pool to the member. A challenge similar to a normal proof challenge but it would just be to validate the plot (a random plot) still exists in the farm of that member. The only way to respond properly to the challenge would be to run a calculation against the plot itself. If they canât respond to the âFarm Sizeâ challenge, then they have to revalidate their farm.
1 Like
I have the same questions about pools verifying member plots. I canât imagine pools operating without some kind of member plot auditing system. itâs not enough to even just verify the plots are there, they need to know that all the plots shared are capable of passing challenges for them to be considered valid. The only way i see this happening is pools would have to create their own auditing software, but I guess this is why we are all waiting to see how the pool protocol works. I have a hunch a LOT of chia farmers are in for a rude wake up that they arenât farming properly since the default gui is almost useless for checking farming health.
Every protocol is broken. For some we just have not found the cracks yet.
I donât know⌠The BitTorrent protocol has been around a long time but as long as I have a well-implemented client I can trust with 100% certainty that it will accurately download the correct files from peers, even if there is a malicious peer on the tracker trying to send me bad data.
They arenât going to throw together something that isnât 100% provable, itâs just not how Bram and co do things.
1 Like
Disclaimer: I have not looked at the code at all, but this is how I assume it would work.
- You can already check your plots with
chia plots check -n. From what I understand, this works because the checker is issuing challenges to those plots that it knows that they should statistically be able to answer. - This same concept could be used by the pools. The pool could issue challenges to a farmer based on the plot idâs that the farmer claims to possess.
- The other concept is that it isnât important exactly how many plots the farmer has. I would assign points based on the difficulty of the challenges passed by the farmer. I would send a farmer challenges of increasing levels of difficulty until the farmer could no longer respond in a timely manner - at this point I can make an assumption of how many plots the farmer has. I can continue issuing these challenges as the farmer adds more plots, just like the difficulty of the challenges go up as the netspace total goes up.
It may not be exactly like this, but my guess is that concentrating on the number of plots the farmer has is probably wrong. Points are more likely based on statistical analysis of the answered challenges.
1 Like
Agreed. This would be a better way of assigning rewards. My biggest concern with pools is people joining with PBs of plots that canât pass any challenges. It comes down to pools having a way of actively auditing and even rejecting any plots in the pool.
1 Like
Skimming the init portion of that gives a hint IMO:
# TODO(pool): potentially tweak these numbers for security and performance
self.pool_url = "https://myreferencepool.com"
self.min_difficulty = uint64(10) # 10 difficulty is about 1 proof a day per plot
self.default_difficulty: uint64 = uint64(10)
Iâm not a Python programmer, so, totally speculating, Iâd say assuming the pool needs to be trusted makes the most sense, at least initially. If you treat the pool challenges and reward allocation as transient data that can be thrown away, it keeps things simple.
On a non-technical level, I think trusting pools to the point where users donât need to host a full node opens up a lot of potential use cases that wonât be possible otherwise. For example, I would really like to see a custom client and file protocol where I could point my farmer to a pool by clicking a button on a website.
Imagine a SaaS that provides pools where website operators could put a âPledge Plotsâ button on their website and users could click it to allocate their farm to that pool. As a casual farmer I can create value with $0 incremental cost and no taxable events if I donât receive any rewards.
Casual farmers allocating plots to their favorite creator, website, etc. could be a very big deal and have a large influence on the future of the web if the value of Chia holds up.
2 Likes
Iâve watched a part of the Zoom call and I think I understand the proposed solution now> Please correct me if Iâm wrong (trying to distill it to laymanâs understandable terms).
The Pool can assign a (much reduced compared to the actual mainnet) difficulty per pool participant. The poolâs objective is to adjust the difficulty so that the participant can provide challenge solutions at to the seeds coming of the official chain at that reduced challenge difficulty at a predicted (high) rate (default 300 per day).
The Pool does not actually know the plotspace of the farmer, it just knows that this farmer A can maintain my rate at difficulty X, whereas farmer B can only do it at rate Y<X.
It then can distribute the pool rewards based on the relative difficulties each farmer could maintain. Like mainnet, it doesnât know you actually have the plots, it just knows you win the (reduced) challenges which should be directly correlated with the number of real plots you have. (this will put more load on your harvester and disks you are farming from, but not enough to be a real hindrance)
Uniqueness is enforced not per plot but per farmer key, through a unique contract on the blockchain that signs the pool portion of the reward to the pool. While you can move pools, every unique farmer key (which is embedded in the farmerâs plots) can only be in one of these contracts at a time, and there is enough of an enforced switching delay so you canât quickly swap pools whenever you win a block and back.
Is this about right?
7 Likes
Nice! Sounds like my assumptions are kinda correct. Thanks for saving me from watching a Zoom call 
1 Like