CHIP-0033: Add additional partial headers

[felixbrucker]

This is the corresponding CHIP for https://github.com/Chia-Network/chia-blockchain/pull/17788

[BrandtH22]

I respectfully disagree

Agree to disagree, for me obfuscating the harvester id which is part of the pooling protocol and the json payload is out of scope for a pr adding additional headers.

What about default obfuscation for the farmer peer ID? Or the solution that @xearl4 provided where the information itself is just not sent by default?

[BrandtH22]

Regarding 2 and 3, I get the feeling that users at this level of concern about privacy would generally prefer not to send any new information to the pool, not even the obfuscated IDs which still leak information that was previously not visible (that a farmer is using multiple different farmer processes; even though no one has complained about this information leakage yet.) And this is the unnecessary effort I mentioned initially: why implement obfuscation and whatnot for something that no one will ever use or want to use? If the UX is going to be that we have to tell pool users who like to have this useful information to first enable config options anyway, I'd personally rather have two simple "include farmer peer id" (default false, because newly introduced privacy concern) and "include harvester stats" (default false, because newly introduced privacy concern) config options instead.

I think this is an excellent solution that allows for the best of both worlds (defaults to current security levels and allows for users to easily add the extra reporting with the seamless and direct farmer id to use for lookups)!

[danieljperry]

@felixbrucker given the latest feedback, would you like me to move the CHIP back into Review status in order to make updates? The other option is to let it finalize next week, but like I said earlier, it's unlikely that CNI would add the PR to its code base in its current form.

[felixbrucker]

I personally disagree with the default value being false for the peer id option Ofc this doesn't mean that others can't pick up the work and implement it the way they see fit, i just won't do it

[felixbrucker]

I will update the chip to reflect the new config options as that seems like a better solution than obfuscation

[danieljperry]

OK, then I will move the CHIP to Review in order to give others a chance to review it.

[danieljperry]

@felixbrucker has made some updates to this CHIP, so I am moving it back to Review. If you have commented on this CHIP before, please leave a new comment here regarding the updates. Is this something you would like to see implemented in its current form? Let's plan to make a new assessment as to this CHIP's status in about a week.

[felixbrucker]

It has been over a week, i'd like to see this implemented in it's current form

[danieljperry]

It has been over a week, i'd like to see this implemented in it's current form

I can put the CHIP into Last Call in its current form. However, do keep in mind that CNI will be highly reluctant to implement it in their client. To clarify, is this OK for you?

[felixbrucker]

Is this something you would like to see implemented in its current form? Let's plan to make a new assessment as to this CHIP's status in about a week.

I'm just responding to this, i don't know what the proper next state for this chip as nobody else commented

[danieljperry]

Is this something you would like to see implemented in its current form? Let's plan to make a new assessment as to this CHIP's status in about a week.

I'm just responding to this, i don't know what the proper next state for this chip as nobody else commented

Yup, I'll move it to Last Call.

[danieljperry]

This CHIP is now in Last Call. If no changes are made in the next two weeks, it will be moved to Final.

[danieljperry]

This CHIP is now Final. No further changes are allowed, other than adding errata.