CHIP suggestion

[lord-icon]

I have a CHIP suggestion.

If I have understood the procedure correctly, this must first be discussed in advance.

Preventing GPU plotting (compressed plots)

Preface: Since I lack the knowledge how the header+footer of a plot file looks like I can only make assumptions here.

The structure of Chia would have to be rebuilt.

• At startup, the header and the footer are read for each plot.
• Header and Footer must have an identical time specification.
• The time must be at least XX minutes old (e.g. 10min).
• Monitoring of the plots as long as CHIA is farming.

Background:
The GPU farmer would have to finalize all his plots once when starting CHIA.
This alone should discourage the use of compressed plots.

Monitoring of the plots:
By Linux: inotity-ttols or iWatch.
Windows: watchexec/watchman/Fileinfo/glob/

If a file change is detected, this plot must be subject to a lock. Say: Does not participate in the current challenge.

The lock also affects the start. If the plot has been completed "on the fly" it has a challenge lock per se.

Alternative idea:
The size adjustment. If CHIA starts then (I think) all plots are read in anyway. There should certainly be a suitable MB size available.
Compressed plots are not finalized until the challenge query.
Thus, the mere query whether plots are available should not generate a final completion. BUT: I have not yet dealt with GPU plotting. So a little bit of half-knowledge is included.

I find this idea (if you can be implemented so) also very useful for the future.
CHIA does not "violate" its own guidelines to be "green".
GPU plotting (complete plotting) should become official at some point.

[danieljperry]

Thanks for the suggestion. To clarify, the reference wallet that most people use for farming is only one of the possible wallets that could be created. When a wallet reads in plots, this is not done as part of the blockchain's consensus. If we were to change the rules at the reference wallet level (and not at the consensus level), there would be nothing stopping a new wallet from being developed with a different set of rules, while continuing to follow the blockchain's consensus.

As for the suggestion of requiring plots to be at least a certain age, what is stopping a computer from generating a plot that appears to be older than it actually is? For example, a plot could include a timestamp from 30 minutes ago.

Also, from your suggestion If a file change is detected, this plot must be subject to a lock., what issue is this attempting to solve?

[maxjay]

Just stop trying to prevent this. You're not going to prevent this.

[lord-icon]

@danieljperry
Wallet? I didn't talk about that at all. I had made a suggestion in the direction of "Harvester/Farmer". And that was to prevent GPU farming (NOT GPU plotting).

"As for the suggestion of requiring plots to be at least a certain age, what is stopping a computer from generating a plot that appears to be older than it actually is? For example, a plot could include a timestamp from 30 minutes ag"

You didn't read my suggestion.
In phase 1 (i.e. reading all plots) this scenario can happen. But for the CHIA-Farmer it has the bitter taste that all plots have to be plotted at every restart. A lot of power costs... only to be able to submit valid plots.

BUT: As I wrote CHIA has to monitor the plots for changes in phase 2. THAT is the pivot point. There are various system tools that already provide that. And they come from the system kernel. One would have to examine however, in how far one can manipulate that. Otherwise CHIA itself must write a test routine which ensures that.

The CHIA farmer can then certainly shift the timestamp of the plot backwards when generating. But step 2 should then prevent that this plot cannot participate in the current challenge (64-index).

Conclusion: If this can be implemented in this way, then "compressed plots" can never be used in the simplest way. They would simply not participate in any challenge.

@maxjay
Ever thought about the nonsense of "compressed plots"?
It's great that you can turn e.g. 5,000 plots into 6,500 plots without having to buy new HDDs. If the process then officially enters CHIA then almost everyone will probably have to switch. In other words, the difficulty will increase. If you have generated with 5K plots before (assumed) 1 - 1.25 CHIA in the week, then your 6.5K plots will generate later also only 1 - 1.25 CHIA. Only with the difference that you now have the additional electricity costs. Conclusion: Same income with more effort = i.e.: "compressed plots" is worse in terms of income.

Übersetzt mit www.DeepL.com/Translator

[danieljperry]

If you write a CHIP with the technical details of your suggestion, we will take a look at it. However, do keep in mind that use of the reference plotters (such as Bladebit) is not required. Other people can write, and have written, their own plotters. If we do accept a CHIP that prevents GPU farming by changing the plot format, you will have to ensure that other people cannot get around this new format by using their own plotter.

[lord-icon]

@danieljperry
While I'm glad to see you answering quickly....
but I am not completely happy with your answers.
It gives the impression that you just skim everything and nothing read (suspicion)

If you write a CHIP with the technical details of your proposal, we will take a look at it.

Already had. Sometimes 2 times. More technical details I can not submit as an end user. Although I am a programmer... But nothing what cryptography is concerned.
To be able to submit secured information here you would have to give me (best via PN) a Python code (or CLI if that works) which accomplishes the following:

• read current challenge hash + difficulty level
• read in a x-any plot
• = name as result, if this has been recognized as valid.

With this you can test how CHIA reacts to compressed plots. With it I could write then the extension with "was the Plots changed"-function and test it then whether this all grips.

BUT: Even if I am quite capable as a programmer, I see the "responsibility" here rather with the CHIA team.

Remember, however, that the use of reference plotters (like Bladebit) is not required.

And again. The proposal is 0% based on plotting. 100%on farming/harvester.
And that is subject to the CHIA code.

If we accept a CHIP that prevents GPU farming by changing the plot format, you need to make sure that other people can't circumvent this new format by using their own plotters.

Well... you didn't have to write that note if you had read my CHIP suggestion. Because that is not possible by GPU plotting.

[maxjay]

@maxjay Ever thought about the nonsense of "compressed plots"? It's great that you can turn e.g. 5,000 plots into 6,500 plots without having to buy new HDDs. If the process then officially enters CHIA then almost everyone will probably have to switch. In other words, the difficulty will increase. If you have generated with 5K plots before (assumed) 1 - 1.25 CHIA in the week, then your 6.5K plots will generate later also only 1 - 1.25 CHIA. Only with the difference that you now have the additional electricity costs. Conclusion: Same income with more effort = i.e.: "compressed plots" is worse in terms of income.

Follow your own logic. If chia doesn't do compressed plots, then there are people with an inherit advantage over other people, making it an unfair game. At least if everybody gets compressed plots, then nobody actually has compressed plots and its a zero sum game, if only a select few have the (NOSSD, MadMax GigaHorse), then they reap the benefits at the expense of everybody else.

The fundamental issue with this is that you can't verify that these plots have not been compressed because the consesus doesn't care. You're asking for a fundamental change to the underlying Proof of Space to make it care, but even then, how do you verify something is "compressed". We've already seen people create their own formats of chia plot files that aren't identical to chia's format but are accepted (MadMax's plots are slightly different than chia's even with the same seed/key/thing).

This isn't something you can do. Using your own "method", there is nothing stopping me from adding these fake timestamps after the fact.

[maxjay]

I'm going to address this particular point because I think this is OPs primary motivation:

CHIA does not "violate" its own guidelines to be "green".

Chia doesn't "violate" it owns guidelines to be "green" even with GPU farming.

• My farm is running off renewable energy, solar panels, but I cut down an entire forest for that. Does that make me "green"?
• My farm is running off coal, but completely uncompressed. I have a generator to which I throw in coal, incompletely combusts, and produces electricity for me to farm my uncompressed plots. Does that make me "green"?

You can't force people to make green choices. You can only educate them.

GPU farming may increase electricity costs, this may not be suitable for everybody. Most likely, only those with massive farms are likely to be GPU farming anyways, they have a real cost-benefit to them. At that scale, they'd probably be using renewable energy anyways (like massive bitcoin miners) because their own electricity would be cheaper.

I run my farm off a raspberry pi. I'm not going to be GPU farming any time soon because there's no point for me, the added benefit to the cost is marginal if not negative.

You can't prevent people from GPU farming if they would see a real benefit. But thankfully, its a choice at the end of the day.

We should encourage innovation within this space, not stifle it. Being open source, we should encourage people to find better solutions together, not out right banning choices that people can make.

[lord-icon]

Follow your own logic. If chia doesn't do compressed plots, then there are people with an inherit advantage over other people, making it an unfair game. At least if everybody gets compressed plots, then nobody actually has compressed plots and its a zero sum game, if only a select few have the (NOSSD, MadMax GigaHorse), then they reap the benefits at the expense of everybody else.

The fundamental issue with this is that you can't verify that these plots have not been compressed because the consesus doesn't care. You're asking for a fundamental change to the underlying Proof of Space to make it care, but even then, how do you verify something is "compressed". We've already seen people create their own formats of chia plot files that aren't identical to chia's format but are accepted (MadMax's plots are slightly different than chia's even with the same seed/key/thing).

This isn't something you can do. Using your own "method", there is nothing stopping me from adding these fake timestamps after the fact.

I think I'm talking to a tree or a refrigerator. Would someone have the goodness to READ my proposal?

Can not be so difficult. I write it already in your language (I speak German).

And now a 3rd time.
compressed plots are only finished when you pass a challenge.
But THAT represents a write access to the plot.
A completed plot on the other hand does not need a writing process but only a reading one.
Whether a write process to the plot takes place can be monitored quite easily. If a write process is detected, it is not considered for the current challenge.

[hoffmang9]

Follow your own logic. If chia doesn't do compressed plots, then there are people with an inherit advantage over other people, making it an unfair game. At least if everybody gets compressed plots, then nobody actually has compressed plots and its a zero sum game, if only a select few have the (NOSSD, MadMax GigaHorse), then they reap the benefits at the expense of everybody else.

The fundamental issue with this is that you can't verify that these plots have not been compressed because the consesus doesn't care. You're asking for a fundamental change to the underlying Proof of Space to make it care, but even then, how do you verify something is "compressed". We've already seen people create their own formats of chia plot files that aren't identical to chia's format but are accepted (MadMax's plots are slightly different than chia's even with the same seed/key/thing).

This isn't something you can do. Using your own "method", there is nothing stopping me from adding these fake timestamps after the fact.

I think I'm talking to a tree or a refrigerator. Would someone have the goodness to READ my proposal?

Can not be so difficult. I write it already in your language (I speak German).

And now a 3rd time.

compressed plots are only finished when you pass a challenge.

But THAT represents a write access to the plot.

A completed plot on the other hand does not need a writing process but only a reading one.

Whether a write process to the plot takes place can be monitored quite easily. If a write process is detected, it is not considered for the current challenge.

The client software could try to enforce unenforceable rules - sure. But the real issue is that the criteria to rule out a plot must be verifiable on computers that have absolutely no view of what happened on the block proposer's machine.

119,999 farmers can calculate whether the plot that a farmer is proposing to complete a block with correctly passed the filter. 0 farmers other than the farmer who made the block know anything about what happened on that farmers computer.

You are advocating for a security rule that can not be enforced by others. Those are the only security rules that matter.

[lord-icon]

na: Hallelujah.
Finally a suitable answer where you can actually assume that my proposal has been read. THANKS.

Ok. It is only a suggestion. This will be "checked" in advance and if feasible further discussed as a CHIP proposal.

BUT: I still see my proposal as quite feasible.

The client software could try to enforce unenforceable rules - sure. But the real issue is that the criteria to rule out a plot must be verifiable on computers that have absolutely no view of what happened on the block proposer's machine.

CHIA already has such checks/exclusions. Wrong key. Wrong plot. Duplicate plots etc.
These are already all exclusion criteria. What is the difference in adding a criterion to the check? And these are things that the client software does. These plots do not reach the pool server.

I already mentioned ready tools which work on kernel basis. A write access to a plot can be determined thus with board means. The further handling with it would have to determine then the CHIA makers.

[hoffmang9]

na: Hallelujah.

Finally a suitable answer where you can actually assume that my proposal has been read. THANKS.

Ok. It is only a suggestion. This will be "checked" in advance and if feasible further discussed as a CHIP proposal.

BUT: I still see my proposal as quite feasible.

The client software could try to enforce unenforceable rules - sure. But the real issue is that the criteria to rule out a plot must be verifiable on computers that have absolutely no view of what happened on the block proposer's machine.

CHIA already has such checks/exclusions. Wrong key. Wrong plot. Duplicate plots etc.

These are already all exclusion criteria. What is the difference in adding a criterion to the check? And these are things that the client software does. These plots do not reach the pool server.

I already mentioned ready tools which work on kernel basis. A write access to a plot can be determined thus with board means. The further handling with it would have to determine then the CHIA makers.

All every other node can validate is the proof of space and transactions that a farmer sends to the network. Nothing stops a farmer from modifying their own software to not do all of these client software only checks and then get an unfair advantage by sending out proofs that don't meet the local software's rules and will win because everyone else couldn't tell they are cheating.

[maxjay]

I think I'm talking to a tree or a refrigerator. Would someone have the goodness to READ my proposal?

Your proposal was read, just the changes that need to be done to even consider achieving what you want are in a much deeper level than you think.

I perfectly understood what you want, I'm saying the network currently can't see the difference (nor care) between compressed plots or uncompressed plots, and to change that would need changing at the consensus level (if such a change can even exist).

Christ its the exact same discussion around GPU Plotting and banning that, people always thinking "nobody is reading" their argument, when they just don't fully understand the scope of the change they're asking for.

And now a 3rd time.
compressed plots are only finished when you pass a challenge.
But THAT represents a write access to the plot.
A completed plot on the other hand does not need a writing process but only a reading one.
Whether a write process to the plot takes place can be monitored quite easily. If a write process is detected, it is not considered for the current challenge.

Also, I'm pretty sure not how compressed plots work. They're not expanded on challenges lol (how would that even make them compressed? how would you fill a disk with potentially expanding plots?). Compressed plots just don't complete all the steps, so you do the final step on the fly with a GPU, you're not 'finishing the plot', you're just getting the final answer and submitting that to the network, you're not modifying the plot file.

[maxjay]

CHIA already has such checks/exclusions. Wrong key. Wrong plot. Duplicate plots etc.
These are already all exclusion criteria. What is the difference in adding a criterion to the check? And these are things that the client software does. These plots do not reach the pool server.

This an exclusion for possible answers that obviously won't win. If somebody asks you "Whats 2+2=?", you're not going to reply with "orange" are you, but if you have like a math equation that could potentially equal "4", then that's something to be tried and tested.

These exclusions are happening client side only, the network can't see these exclusions, it just cares if an answer provided is right or wrong. Literally nothing stopping people creating their own clients to do something that is """banned""" on the official client. Then we have a problem of unfairness. (Which was my initial reply to your proposal which I supposedly "didn't read").

[lord-icon]

All every other node can validate is the proof of space and transactions that a farmer sends to the network. Nothing stops a farmer from modifying their own software to not do all of these client software only checks and then get an unfair advantage by sending out proofs that don't meet the local software's rules and will win because everyone else couldn't tell they are cheating.

@hoffmang9
But then that applies to CHIA in general.
The code of Chia is open source. I am pretty sure that there are some farmers who have made adjustments in the source code, so that the plots pass the challenge.
What I want to point out: This "fact" would always exist. Now as well as later with vlt. my proposal.

Also, I'm pretty sure not how compressed plots work. [..] Compressed plots just don't complete all the steps, so you do the final step on the fly with a GPU, you're not 'finishing the plot', you're just getting the final answer and submitting that to the network, you're not modifying the plot file.

@maxjay
IF this is actually so (I can not check, because my Rasb. has no GPU for com. plots). then my proposal would actually not work. I assumed that the plot is finished on the HDD (short term) and removed later.

Under the point of view then my suggestion would be of course invalid {cry}.

[hoffmang9]

All every other node can validate is the proof of space and transactions that a farmer sends to the network. Nothing stops a farmer from modifying their own software to not do all of these client software only checks and then get an unfair advantage by sending out proofs that don't meet the local software's rules and will win because everyone else couldn't tell they are cheating.

@hoffmang9

But then that applies to CHIA in general.

The code of Chia is open source. I am pretty sure that there are some farmers who have made adjustments in the source code, so that the plots pass the challenge.

What I want to point out: This "fact" would always exist. Now as well as later with vlt. my proposal.

Also, I'm pretty sure not how compressed plots work. [..] Compressed plots just don't complete all the steps, so you do the final step on the fly with a GPU, you're not 'finishing the plot', you're just getting the final answer and submitting that to the network, you're not modifying the plot file.

@maxjay

IF this is actually so (I can not check, because my Rasb. has no GPU for com. plots). then my proposal would actually not work. I assumed that the plot is finished on the HDD (short term) and removed later.

Under the point of view then my suggestion would be of course invalid {cry}.

A farmer can only make a plot appear to themselves to pass the plot filter. The entire point of the plot filter is that every other farmer who is running unmodified code will check that the supposedly winning plot does actually pass the plot filter and all of them will reject a plot that a rogue farmer tried to claim passes the filter but does not.

As a farmer you want to follow consensus rules - not because you can cheat but because everyone else will reject your attempts to cheat.