about k size

[JsBlueCat]

I have saw your wiki about plotting size k.
but I don't know is there any association between k size and win a block? I have checked in chiaexplorer .is there 32:9600 k33:300 to be reasonable?
and if i only contain k35or above there is any chance to win a block?

[SlugFiller]

I've asked this a while before, and was told the odds of winning with a k35 plot are not better than with a k32 plot.

While I can say much about winning, I am currently looking at pooling point, and while I'm still measuring, it looks like a k35 is earning the same amount of points as about 2-3 k32 plots, while taking as much space as 8 of them. So, from this aspect, it seems that the smaller the plots, the better.

[JsBlueCat]

the calculation seems to be expection = you_{k32}/mainnet_{k32} * per_{k32}/ 9806 + you_{k35}/mainnet_{k35} * per_{k35}/9806 since the daily out is fixed. so the expection seems to be same, whatever you plot k35 or k32

[SlugFiller]

I'm not sure what you punch into per_{k35} or per_{k32}, but the other parameters suggest that if everyone uses k35 plots, then you're way better off making a single k32 plot and be the only one on the network, then be yet another k35 plot.

Anyway, I've told you my findings so far. I'll have better measurements in about 48 hours, and will be able to confirm.

[mariano54]

If you have 5x the space, you will win 5x the rewards.
If you have the same space, you will win the same rewards.
It does not matter what k you use for your plots. The only thing that matters is how much space you are using in total, for all plots.

[mariano54]

Ah yes, for pooling, small farms of large k values can perform worse than k32s.

Each plot passes the filter approximately 19 times per day.

The issue is when the difficulty is so low, that you are basically finding a partial whenever you pass the plot filter. For example, with difficulty 1, a k32 will win 10 times per day.

a k33 should win 20 times, and a k35 should win 80 times, but that is not possible due to the plot filter.

If the difficulty is higher (like 100), then large plots should work fine. Therefore, you should check that your pool supports higher difficulty if you only have a small number of very large plots.

[SlugFiller]

@mariano54 Wouldn't it have been better to allow the farmer to submit proofs of arbitrary difficulty, and award points accordingly? Or does the challenge itself have to be crafted specifically for the difficulty? (I'm relying on PoW for reference, where difficulty is a factor of the result (number of 0s at start of hash) rather than the challenge)

If difficulty is tied to the challenge, then there'd be no alternative than letting farmers set their own difficulty. If not, it would be better to ignore the concept of minimal difficulty, and simply let the farmer send their own best partial proof.

[keliew]

Looking at the pool-reference, there isn't a hard limit for difficulty, so I guess if the pool follows the reference code, it should be ok.

@SlugFiller, difficulty is adjusted based on the submitted partials. See https://github.com/Chia-Network/pool-reference/blob/main/pool/difficulty_adjustment.py

[mariano54]

@SlugFiller A farmer submits all proofs that pass given a specific difficulty, but there needs to be a minimum, otherwise the farmer would be performing way too many pospace lookups, and there is no benefit to medium / large farmers to perform so many lookups.

The issue is not really with the difficulty, it's with the plot filter. Each plot only has 18 chances total per day, which means even if difficulty was smaller, you would not get more than 20 proofs per day for a k35. (and then k32s would struggle to get anything).

The difficulty is chosen by the pool. If you are someone who has k > 33 plots mostly, you should ask your pool to increase the difficulty for you, so you can get rewarded the same as k32 users.

[SlugFiller]

@keliew The difficulty adjustment is based on the number of partials received, not the quality. There's nothing in that code for detecting that a partial is valid for higher difficulty, and an under-performant k35 plot would actually prevent the difficulty from rising, rather than facilitate it.

@mariano54 Even if there are only 18 chances to pass the filter, shouldn't it be possible to either:

1. Deliver 2 or more proofs from the same plot for the same challenge, since it has more proofs within it
   or
2. Deliver a higher difficulty proof for the same challenge, gaining appropriate extra points.

Whether a plot delivers the expected point count for its size shouldn't rely on the pool manager's choice of difficulty. Obviously, a custom implementation can make the choice configurable via the farmer (e.g. using the Pool Login Link). But if possible, it would be better for the farmer to deliver the best/most proofs it has, even if the difficulty is set too low, and be awarded points accordingly.