Introduce a new BSIP threshold

[sschiessl-bcp]

The current mechanisms to consider a BSIP as approved is as follows:

1. there is only one worker proposal. The BSIP is considered approved once the worker proposal becomes active, as in receive part of the daily BTS payout
2. there is a YES and a NO worker proposal. The BSIP is considered active when YES has more votes than NO. Now there is already debate here if the YES worker proposal ALSO needs to be active, as in receive part of the daily BTS payout. Either or, this should be defined in the corresponding BSIP

The committee is apparently seeking a third option to consider a BSIP as approved. A new threshold has been created 1.14.158 | threshold-bsip that has the intent to be the new barrier for when a BSIP is considered active. To make it clear, the above a) and b) would then be

1. there is only one worker proposal. The BSIP is considered approved once the worker proposal has more votes than 1.14.158 | threshold-bsip.
2. there is a YES and a NO worker proposal. The BSIP is considered active when YES has more votes than NO, and YES has more votes than 1.14.158 | threshold-bsip

Depending on how many votes 1.14.158 has the BSIP worker proposal may never receive part of the daily BTS payout and still be considered approved.

This issue is to discuss how to transition from the previous model to the new 1.14.158 | threshold-bsip. Discussion has arisen here which triggered me to open this issue. These new guidelines may be part of revision of BSIP-01.

In my opinion it is not enough that the committee simply creates the worker. This needs approval in the old way (i.e. a BSIP must be written that then is approved by becoming active, as in receives part of the daily BTS payout).

[bitcrab]

1.14.158 is a threshold, if we make it active it will mean that all BSIP need to be voted active then it can be above the threshold, what sense does that make?

1.14.158 is necessary as we need to just get the opinion of the community, without considering the budget.

if any party disagree one BSIP, they can create a NO poll WP for that, if the NO poll WP get higher votes than the YES WP the BSIP will be seen as unaccepted, simple, right?

[sschiessl-bcp]

1.14.158 is a threshold, if we make it active it will mean that all BSIP need to be voted active then it can be above the threshold, what sense does that make?

You would need to write a new BSIP and create a new worker proposal for it, and that BSIP would describe how 1.14.158 is established as the new threshold for BSIPs. I did not mean that you should vote the 1.14.158 threshold worker proposal active.

if any party disagree one BSIP, they can create a NO poll WP for that, if the NO poll WP get higher votes than the YES WP the BSIP will be seen as unaccepted, simple, right?

We have an establish procedure and should not deviate from it just because it makes it easier to pass new BSIPs. Any new procedure should be introduced and published to the community.

How many of the current holders do even know that 1.14.158 is supposed to be the new threshold? I have not seen any announcement, other than 1.14.158 appearing on the blockchain. Maybe the rule was intended as: You need to have double the votes of 1.14.158? Or just half of it? Do you need to just pass it for one maintence interval, or 10? I don't know, it is not specified. There is of course the obvious assumption of how it is intended. I don't want to base consensus on assumptions.

[bitcrab]

it's OK to establish/clarify a new procedure with a new BSIP, however I don't agree that this BSIP need to be voted active in the "old way"(get more than 717,690,101 votes), as it is just to get an opinion from the community without deciding any budget.

[sschiessl-bcp]

as it is just to get an opinion from the community without deciding any budget.

It's even more important than budget since it touches consensus, the very basis of our blockchain. Otherwise you could simply write another new BSIP that committee or whoever may now decide over reserve pool all by itself. And then? Suddenly it is about budget.

[bitcrab]

as it is just to get an opinion from the community without deciding any budget.

It's even more important than budget since it touches consensus, the very basis of our blockchain. Otherwise you could simply write another new BSIP that committee or whoever may now decide over reserve pool all by itself. And then? Suddenly it is about budget.

it's not about which is more important, but the 2 things are based on different logics, one important factor in budget deciding is that the daily budget is limited so if it is consumed by other worker proposals a new worker proposal can not get budget if it is not voted above the already active ones, even if there are very strong consensus on it. but what we want to do is to just get consensus from the community, even there are already billions of consensuses they will not hinder a new one. we just need to prove there are strong enough consensus there, no need to prove the consensus is stronger than refund400k.

[sschiessl-bcp]

we just need to prove there are strong enough consensus there, no need to prove the consensus is stronger than refund400k.

Given the implications what a BSIP can change in the backend, I still think the decision of having a separate BSIP threshold must be done by BTS holders with proper specifications on the new procedure.

[abitmore]

Duplicate of https://github.com/bitshares/bsips/issues/4?

[bangzi1001]

I agree to separate Approval of BSIP from Funding. Some developers willing to work voluntary to add new feature to Core because they are very keen on it. BAIP demonstrate a good way for community voting.

If the proposal requires BTS holders approval, the proposal is considered implemented only if BTS holders have approved a corresponding worker proposal. Two poll worker proposals will be created standing FOR and AGAINST. The proposal is considered approved by BTS holders when met these three criterias:

    FOR worker get more voting power than AGAINST worker.
    FOR worker get more voting power than BAIP-Threshold Worker.
    Both No.1 & 2 above last for three consecutive days.

Once a proposal approved by BTS Holders, new poll worker proposals are required to supersede existing approved proposal.

Regarding funding to develop new core feature based on BSIP, the developer should talk to Core Team or create a separate Worker Proposal to Get Paid. When community approve a BSIP does not mean they will approve the funding because sometimes the cost to develop new feature is much higher than how much it worth.

[bitcrab]

we just need to prove there are strong enough consensus there, no need to prove the consensus is stronger than refund400k.

Given the implications what a BSIP can change in the backend, I still think the decision of having a separate BSIP threshold must be done by BTS holders with proper specifications on the new procedure.

To finish the transition from the old model to the new one, I suggest to finish this new BSIP and create a YES worker proposal and a NO one for it.

the new model will be seen as approved if:

1. the YES WP get more votes than the NO one.

and

2. the YES WP get active by receiving daily payout.

or

3. the YES WP get more than 2 times votes than NO WP does.

[sschiessl-bcp]

Duplicate of #4?

Yes, described in more detail. Back then you could also vote against, so that option would need to be removed.

It also clearly states in #4 that any new procedure for finding consensus must be approved by BTS holders.

3. the YES WP get more than 2 times votes than NO WP does.

It must be approved by solely 1. and 2., otherwise you open all angles of attack and fud to any future consensus decision, especially if the decision might be seen as a controversial one.

[bitcrab]

1. the YES WP get more than 2 times votes than NO WP does.

It must be approved by solely 1. and 2., otherwise you open all angles of attack and fud to any future consensus decision, especially if the decision might be seen as a controversial one.

I don't think that, even now I don't get much attack or fud.

worker proposal is designed for budget, not for opinion. YES get more than 2 times votes than NO is also a strong enough consensus.

we need not to intentionally build barrier for BTS evolution.

[MichelSantos]

I appreciate these efforts to achieve some clarity.

A related topic is the timing of "passing" (whether passing is relative to a threshold or relative to the "opposite" BSIP or poll), and the longevity of "passing". For example, if a BSIP passes above the threshold for 50 days, but then drops below the threshold, what should that mean?

In my opinion these definitions should either be directly specified in a particular BSIP, or, if it is absent in a particular BSIP, should default to some general specifications that are defined in BSIP-01 or wherever else this issue might ultimately land after acceptance.

[shulthz]

Let's check what happened in BAIP-Threshold.

Now the cn-vote had controlled the BAIP-Threshold, they can pass any BAIP as they wish.

A very simple trick: hongcaibao111 can remove his vote from CN-VOTE, then vote for BAIP6.

This kind Threshold is very dangerous for community. Stolen the money become so easily.

https://user-images.githubusercontent.com/34892308/83644734-2cbe0a80-a5e4-11ea-904a-7db7ee42a9cd.jpg

……

I think we should avoid the threshold was controlled by a group of people easily.

Set the Threshold= 3/4 the worker which have the hightest votes.

~~example: The hightest votes is 824,511,284.0 So the Threshold=3/4 * 824,511,284.0=618,432,963.0~~

[shulthz]

I think we should remove all the BSIP/BAIP threshold from the vote system, we had a very clear guidline for the worker already, if the worker can get enough pay from the reserver pool, then it will be actived, and we can supervise and control the worker very easily.

Now we set a BSIP/BAIP threshold, a small group of people can control it very easily to spend the money of community.

BSIP still is a worker, we shouldn't let any threshold be easily controlled by a small group of people.

If a BSIP can get continuous seven days pay from the reserver pool，we can think it is actived.

If a NO BSIP worker proposal also get continuous seven days pay from the reserver pool, which got more votes and keep the higher vote than another in continuous seven days, and get continuous pay from the reserver pool in the competition process, then the worker can be considered approved.

I think this voting threshold mechanism should be voted by the holders of BTS，and get continuous 30 days pay from the reserver pool, then we can consider the voting threshold mechanism approved.

A voting mechanism should be a equilibrium strategies, shouldn't become a cheat, it shouldn't become a small game of a little big voting proxy, other holders shuld have the chance to vocie.

In other words, every threshold should get the fully day pay from the reserver pool every day, then we can think it is actived, but now what we have done?!!!!

---

For the onchain governace vote like BSIP/BAIP:

I suggest:

1. Every worker fund should come from the WPS pool(donation exception);

2. A BSIP worker should get continuous seven days pay from the reserver pool; If there have a YES/NO BSIP worker proposal, which got more votes and keep the higher vote than another in continuous seven days, and it shoud get continuous pay from the reserver pool in the competition process of keeping the higher vote than another in continuous seven days;

3. This day pay must be fully worker pay.

4. We must set a Threshold to make sure the vote can't be cheated and ensure the turnout

The Threshold must >=3/8 (the worker which have the hightest votes+the wittness which have the hightest votes) Example: The hightest worker votes is 675557848, the hightest wittness vote is 941299444 so the Threshold=3/8 * 1616857292=606,321,484.5

SO, a BSIP/BAIP want to be approved, must meet2，3，4.

5. This voting threshold mechanism should be voted by the holders of BTS，and get continuous 30 days pay from the reserver pool, then we can consider the voting threshold mechanism approved.

[shulthz]

Let's show how BAIP6 can cheat the community and the threshold.

It seems there have two committees involving, if it is right?

hongcaibao111 spring-team bitbts2020 anbi

[sschiessl-bcp]

Elaborate please

[shulthz]

Elaborate please

hongcaibao111 spring-team bitbts2020 anbi

They all set their proxy to CN-VOTE all the time before 06/03/2020.

The BAIP threshold was only maintained by CN-VOTE，B-DEX, openledger, blckchnd, only have less than 480,000,000 votes.

When BAIP6 came out, CN-VOTE support BAIP6 and hard to get enough votes to make BAIP6 above BAIP threshold, then they made a small private meeting and got out a cheat way, people will be hard to find out :

1. They removed their proxy from CN-VOTE around 06/03/2020, lower the BAIP threshold;

2. Support the BAIP6, higher BAIP6;

3. If didn't make BAIP6 above BAIP threshold, they will let more votes away from CN-VOTE and lower the BAIP threshold.

4. After they think BAIP6 was actived, then they reset their vote proxy to CN-VOTE in these days.

Ah, So smart, hard to find out, haha!