Do not count silent nodes voting for new feature


#1

I propose to change the method of nodes’ voting by adding the opportunity to vote AGAINST besides the opportunity to vote FOR. Thus, all nodes that for some reason do not want to participate in the voting and do not write anything in the config file will not be taken into account when counting votes. It is fair and logical to exclude from the vote nodes irresponsibly related to events occurring on the platform.


#2

Agree. Awesome idea.


#3

It’s not a great idea, it makes node owners even lazier and care even less, because why should they change config, they vote for it anyway.

Also a while ago waves had feature 4 inside mainnet, but this couldnt be activated. So when everyone would automatically vote FOR something, errors and forks happen lot faster


#4

I do not understand you. What is the problem with voting AGAINST as like you vote FOR? Feature will not activated automatically because of many blocks signaling needed. If voting longs a week and only one node signaled FOR activation, but others didn’t signal anything, so it must be activated IMO. Do not forget that any new features are legit because of coming from official team.


#5

Totally supporting proposal. Not voting at all means you don’t care it’s like in usual housing business, where most of home owners does not care of the outcome and will follow the majority.
For the node owners to do the restart is no problem at all to add vote in favor or against the option, and only votes which are signed as favor or against are calculated and then required threshold checked.

Example, total blocks 10k, 6k votes in favor, 1k votes against, 3k didn’t vote, would mean that total amount of votes given is 7k and that would mean that 85,7% of votes were in favor and option is accepted. Presently in such situation it would be only 60% of votes in favor and feature wouln’t be accepted.

BIG PLUS


#6

I think, before voting for a new feature, it needs to be carefully studied. By default, voting for everything is a bad idea.


#7

The point of this proposal is to force pool owners THINK about new features. And mange the pool’s config. If people don’t like pool’s votes - call waves back from leasing and send to some more active pool.

By the way:

We invite all HODLERs to lease their Waves to us.
Briefly on the conditions:

100% of the fees for mining go into payments;

:gift: In addition to Waves and MRT we distribute a partner’s tokens equal $150. Sell it o HODL - you decide.

We have more than 80 000 Waves in the pool and we are keep growing up. Join today and get your WAVES, MRT (if someone will start to distribute them, huh?) and expensive liquid partner’s tokens. Best pool offer on the market.

https://www.tradisys.com/leasing


#8

Again. Who told about voting FOR by default? I suggested to not vote AGAINST by default. In your case now is the same situation - I doubt that every who voting FOR features now has studied it before.


#9

People can manage their waves between pools. This will show to some fat pools that people are not dumb. Community should vote by their waves, not lazy pools.


#10

Good idea. Lease your Waves to Progressive Nodes. Stop stagnation


#11

Totally agree. Monopoly and stagnation kill the network.


#12

Are talking here already about limiting time of the lease? :slight_smile:


#13

Поддерживаю данную инициативу!


#14

If you don’t vote for it you vote against it.
you got 2 options, support it or not support it.


#15

I think it might be a good idea to extend Waves Activation Protocol so that node owners have to [1] set JSON to participate in vote and [2] set JSON to Vote.

So in addition to ‘supported’ we could have ‘participate’.

Examples;

Nothing in conf or participate commented out > defaults to node not taking part in vote and not counted in total.

participate = [9,10]
(features 9 & 10 not voted for.)

participate = [9,10]
supported = [9,10]
(both features voted for)

participate = [9,10]
supported = [9]
(feature 9 voted for only)

And so on.


#17

It is actually true, because there are people who actually prefer to the previous versions of a feature. An upgrade of a new feature can actually disappoint them. And there should be an opportunity for those who are against the new feature, who actually stays silent than voting. It should definitely not count as a silent support for the new features,


#18

The idea was suggested in 2017, but now it’s 19, and still there’s no “against” function lol