eip-0038 Partial Voting

[WilfordGrimley]

No description provided.

[nitram147]

I just ran over your proposal (mainly over it's first part) by eyes, so I'm not going to comment on any implementation-specific details but will leave there my overall point of view.

Idea in general is good (motivation section), but I don't see a reason for any type of forking for achieving the results that you had outlined as the goal of your proposal in it's motivation section.

Here's my way of achieving nearly the same results without the need for any type of forking:

To my knowledge, the miner's voting data is part of a blockheader. Currently, mining pool send blockheader data together with probably some range of nonces to be tried [ I don't have any deep implementation details knowledge about the working of Stratum protocol ] to each of it's individual miners. Each of the miners tries all of the nonces from the specified range, and in case he find some "good enough" solutions (less difficult then required by consensus but still hard to find), he then send those so-called "shares" back to mining pool in order for pool to be able to deduce his hashrate without need to trust the miner.

Currently, when the mining pool is validating shares received from some of it's miners, pool checks whether these shares were calculated over the correct blockheader and whether miner tried nonces from the range he obtained from the mining pool via the stratum protocol.

If you want to empower individual miners mining in the mining pool with ability to vote for themself, there's only one simple thing which need to be changed - mining pool should allow miner's to send shares calculated for "almost the same" blockheader with only different value entered in it's votes section - this way would be almost more trust less because if miner find some block (where the coinbase transaction rewards go to pool address) it's in the pool best interest to relay this transaction into network (and in case the pool refuse, individual miner can do it itself). Mining pool which would refuse to accept shares with different setting in "votes" section than the pool's owner attitude would loose it's miners because they will just move to another pool which will accept their shares. So via introduction of this simply change in the shares validity verification procedure on the mining pool server part and small addition for ability to override blockheader votes section on miner's stratum client part we can achieve similar results as you've outlined in the motivation part without need for any type of forking.

Statistically speaking, any individual miner preference will be take into account overtime - yeah if single miner mining for some small pool will have be the only one trying to vote for yes, it would be with high probability not taken into account at all - but even if it was taken (in case of your hardfork solution) it would change nothing about the voting outcome. When there is a small but not negligible minority of miners voting for something, it would be based on static, surely be taken into account.

Using the solution I outlined in the lines above, there's no more need for any inner pool offchain voting - which would also be not trust less at all and will require mining pool to code some interface with solution for that inner pool voting...

[nitram147]

Please read my comment above and think about the requirement for forking when the same good idea which you've outlined in the motivation section of this proposal could be achieved without the need for any type of forking at all.

[WilfordGrimley]

Did you read the "no fork solution" section? Your solution seems like it would work well with SNISPs with the subpooling contracts configured as outlined in that section. The fact remains that the current method and any no fork solution censor minority voices by necessity: Miners with a minority voting preference still have incentive to pool their hashrate with others with similar views, the trouble is that the fixed voting epochs reduces the odds that their votes will be counted within the epoch when compared to majoroty voices. A fork solution allows mining pools to act apolitically; passing direct governance power onto their miners without requiring any of their minority voting miners to seek a pool with smaller hash. It does not force pools to act apolitically, just enables them to. Pools can still act as they do now: voting entirely for or against various changes, with or without the implicit consent of their miners. -------- Original Message --------

…

On Oct 17, 2022, 12:28 AM, Martin Eršek wrote: @nitram147 requested changes on this pull request. Please read my comment above and think about the requirement for forking when the same good idea which you've outlined in the motivation section of this proposal could be achieved without the need for any type of forking at all. — Reply to this email directly, [view it on GitHub](#81 (review)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AASJN2XPRQBAQV2JUY3RGB3WDTIVFANCNFSM6AAAAAARGSX2YU). You are receiving this because you authored the thread.Message ID: ***@***.***>