New BSIP: voting with non-core asset, and asset-specific committee

[abitmore]

Currently only CORE can vote for certain things E.G. witnesses, workers and the committee.

It's been demanded by the community for a long time that, holders of other assets can vote with their assets, for things related to those assets.

Another thing is asset-specific committee. Currently it's able to set committee of an asset to top-N holders. I think it would be useful if the committee can be decided by voting.

Update:
Example of asset-specific committee with top-N holders: https://cryptofresh.com/u/stealth-mgmt

[ebit116]

support. DAC need this.

[bangzi1001]

Support! Very useful and very powerful feature.

[xeroc]

Would that be feasible computationally? It needs to go through all the holders of different assets and accumulate the respective stake.

[abitmore]

Would that be feasible computationally? It needs to go through all the holders of different assets and accumulate the respective stake.

Sure. There are fees related to balance the situation.

[abitmore]

Just think out loud: it's possible that the blockchain charge a maintenance fee from the asset's fee pool for every vote re-tallying, and the fee can be related to quantity of holders of the asset. If no enough BTS in the fee pool, deactivate voting feature for the asset, can even deduct some BTS from fee pool in this case for the efforts done. To be fair, the asset committee can decide when to re-tally votes, but not re-tally at every maintenance interval.

[shulthz]

maybe we need set a threshold for the DAC to open this function.

[TheTaconator]

Is the idea to permit bitCNY holders to be permitted to vote on what? The market fee for bitCNY?

If they are permitted to vote on witnesses, workers, and committee, how should the their holdings be valued relative to BTS stake held by others?

Does the idea permit holders of GATEWAY.BTC be permitted to vote on witnesses, workers, and committee?

[abitmore]

Witnesses, workers, and committee, global fee schedule and etc are CORE token's business, not others'.

This proposal is about UIA business. For example, OBITS holders may like to vote for the percentage market fee rate on OPEN.X assets.

[grctest]

I like the idea - could encourage UIA usage more 👍

[sschiessl-bcp]

This would come in handy with allowing users (for a hefty fee) to create accounts that have dynamic permissions like committee, but linked to an UIA. Thoughts?

[thontron]

This is a good way to make businesses more autonomous/limit trust in single party.

We should identify the resource costs and if a fee can offer value for both businesses and stakeholders.

[cloud-8]

So holders of a UIA could vote on the UIAs fees? UIAs have fees set by the issuer for a reason, often to pay for underlying infrastructure and now the control of this will not be with the issuer anymore. Voters have an incentive to always vote to set fees to 0 and yet that may not be viable for an issuer to support anymore. Dont agree with that at all.

[pmconrad]

So holders of a UIA could vote on the UIAs fees?

Not necessarily. The UIA issuer and the account controlled by UIA holders need not be identical.

[thontron]

So there is understandably some confusion about what specific authorities would be granted in a dynamic permission account. To me the value-add comes from allowing holders of a token to vote on transfers from a main account. E.g. holders of X token could elect to transfer BTS/gateway asset from X account to another.

[thontron]

Would that be feasible computationally? It needs to go through all the holders of different assets and accumulate the respective stake.

Is the resource demand significant here? It would be good to have many dynamic permission accounts operating at a given time.

To minimize resource demand, how about limiting the potential account balances through white-listing?

[cloud-8]

So there is understandably some confusion about what specific authorities would be granted in a dynamic permission account. To me the value-add comes from allowing holders of a token to vote on transfers from a main account. E.g. holders of X token could elect to transfer BTS/gateway asset from X account to another.

So holders of a token can vote to remove assets from the ownership of another account holder? This seems very dangerous and I dont see the practical use cases for such a setup. I havent seen any gateway actually demanding this and actually it would be to detriment to the gateway, they dont want users of their assets setting fees and such or theyd go out of business, the whole point of a gateway asset is that the solvency/security of the gateway is taken into consideration when pricing the asset.

[sschiessl-bcp]

Two factors

1. Asset owner
   The asset owner can have dynamic permissions (multi-sig) like the committee-account (by vote) or like the stealth-account (directly by stake). The asset ownership would allow governance of the asset in all aspects just like any normal user would be able to now

2. Voting of asset holders
   This new asset would receive it's own mechanism to conduct votes. This is possible in two ways: Opinion vote (say yes or no to a strategic decision) and Worker Proposal (instead of payout out from refund pool, the worker proposal would issue said UIA to the worker account).

On 1. Could be restricted in whatever way the initial asset owners decide (there likely must be a central ownership first, distribute initial amounts of tokens and then upgrade the asset to being self-governed, this way also existing UIA could be upgraded). So the discussion of what or what not should be possible is not necessary in here, as everything can be decided by whoever creates the asset (full flexibility).
On 2. This mimics essentially the governance system that BTS already has, just with a separate section for this UIA

[pmconrad]

First draft below. @ryanRfox please assign a number.

---

BSIP: 
Title: Elections based on non-core asset
Authors: Peter Conrad
Status: Draft
Type: Protocol
Created: 2019-10-12
Discussion: https://github.com/bitshares/bsips/issues/81

Abstract

From the beginning, the BitShares blockchain has offered the ability to vote with the core token, and to have elected accounts govern the blockchain.

For specific use-cases it can be desirable to have a similar mechanism for voting and elections where the votes are counted in relation not to BTS but to some other asset. An example might be a community of people who are interested in a specific topic.

This BSIP proposes changes that will enable elections based on dedicated assets.

Motivation

The feature has been requested from independent businesses as well as from within the community. In addition, it paves the way for a to-be-proposed change to BitAsset governance, i. e. the decoupling of BitAsset management from blockchain governance.

Rationale

There are fundamental differences between the mechanics proposed here and the mechanics already in place for BTS-based voting.

BTS balances are affected by almost every operation, due to transaction fees. The voting tokens will only be affected when they are being used.

BTS is used in a multitude of ways, e. g. as collateral, as the counterpart in most active markets, as payment for workers and witnesses, as cashback for fees and so on. Contrarily, it is assumed that the primary purpose of the voting tokens will be voting. They are unlikely to be used as collateral.

These differences allow for various simplifications and optimizations. In particular, we propose to allow only liquid balances for voting. Because these presumably change rarely in comparison to the number of distinct balances, it is more efficient to recalculate votes on the fly instead of once per maintenance interval (see STEEM for comparison).

Furthermore, we make no distinction between voting and elections. Voting (as in making a yes/no decision) can be emulated with an election where only the votes for two designated candidates are counted and compared to each other. Depending on voting rules (to be defined externally on a case-by-case basis), the one with more votes wins, or perhaps the one with an absolute majority of eligible votes.

Specifications

1. New asset flag "voting_allowed"

A new asset flag/permission "voting_allowed" will be introduced. At the time of the hardfork, all existing UIAs will have the corresponding permission set. Future assets can have the permission set only if they are UIAs not MPAs nor PMs.

As usual with flags, the flag can be changed only if the permission is set. The permission can be unset any time, but can be set only when supply is zero.

The flag must not be used before the time of the hardfork.

2. New operation "create_elected_authority"

Note 1: Since the overall computational overhead for this voting mechanism is significant, the height of the fee should reflect this.

Note 2: The new asset flag voting_allowed is only checked for this operation. If the flag is removed from an asset, any existing elected authorities are unaffected.

Fields:

• account_id_type creator - the account to pay the fee, also the only one who can delete the authority
• asset_id_type voting_asset - the asset on which to base the voting
• unsigned_int num_members - the number of authority members to vote on if fixed, or 0 otherwise
• unsigned_int min_members - the minimum number of authority members to elect, or 0 if fixed
• unsigned_int max_members - the maximum number of authority members that can be elected, or 0 if fixed
• flat_set<account_id_type> candidates - a list of candidates eligible for voting, or empty
• optional<asset_id_type> candidate_holders - and asset that candidates must hold to be eligible for voting
• bool proxy_allowed - indicates if proxy voting is allowed
• optional<time_point_sec> vote_until - an optional ending date after which voting slates are frozen

Validation:

The operation must not be used before the time of the hardfork.

• creator must exist, must have lifetime membership, and must have sufficient balance to pay the fee.
• voting_asset must exist and must have the voting_allowed flag set.
• If num_members is 0 then min_members and max_members must both be positive.
• If num_members is positive then both min_members and max_members must equal 0.
• If candidates is not empty then
  • Its size must be greater or equal to max(num_members,min_members).
  • candidate_holders must not be present.
• If candidate_holders is present the candidates must be empty.
• vote_until, if present, must be in the future

Evaluation:

A new object type elected_authority_object is introduced. The operation creates such an object using the fields from the operation.

A new, empty authority is created. The desired number of members for the authority is set to max(num_members,min_members).

Half of the operation fee is set aside and stored in the elected_authority_object.

3. New operation "delete_elected_authority"

Fields:

• account_id_type owner - the account to pay the fee, must have created the authority
• elected_authority_id_type authority - the authority to delete

Validation:

The operation must not be used before the time of the hardfork.

• authority must exist.
• owner == authority.creator

Evaluation:

• The fee stored in authority is returned to owner.
• The elected_authority_object is deleted.
• All related objects, including the authority as well as all user votes, are also deleted.

Note: Afterwards, accounts that have the authority still referenced in its owner authority will be unable to ever change their owner again. Accounts that have the authority referenced in their active authority will be usable only by their owner authority until the active authority has been changed.

4. New operation "update_asset_vote"

Fields:

• account_id_type voter - the voting account, also pays fee
• elected_authority_id_type authority - the authority on which to vote
• unsigned_int number - the number of members the authority should have, or 0 if it is fixed
• flat_set<account_id_type> votes_to_add - a list of accounts to add to the current voting slate
• flat_set<account_id_type> votes_to_remove - a list of accounts to remove from the current voting slate
• optional<account_id_type> proxy - an optional voting proxy

Validation:

The operation must not be used before the time of the hardfork.

• authority must exist.
• voter must exist and have sufficient balance to pay the fee.
• If authority.vote_until is present, then it must be in the future.
• If authority.num_members > 0 then number must equal 0.
• If authority.num_members == 0 then authority.min_members <= number <= authority.max_members.
• For all entries in votes_to_add:
  • must exist
  • must not be present in the user's voting slate on authority
  • if authority.candidates is not empty then it must be contained therein
  • if authority.candidate_holders is present then it must own tokens of the given type
• For all entries in votes_to_remove:
  • must be present in the user's voting slate on authority
• If both votes_to_add and votes_to_remove are empty then number must be different than the voter's previous choice for number, or the voter's proxy setting must change.
• If proxy is present then
  • authority.proxy_allowed must be true.
  • proxy account must exist and must have a voting slate for the authority.
  • number must equal 0 and both votes_to_add and votes_to_remove must be empty.

Evaluation:

• If proxy is not present but voter had set a proxy on this authority before
  • Subtract the voter's token balance from the old proxy's proxy token count and adjust vote tally accordingly.
  • Apply votes_to_add as described below.
• If proxy is present and voter had not set a proxy before
  • Remove all accounts from the user's own voting slate and adjust vote tally accordingly.
  • Set proxy in voting slate.
  • Add voter's balance to proxy's proxy token count and adjust vote tally accordingly.
• If proxy is present and voter had set a (different) proxy before
  • Remove old proxy and adjust vote tally accordingly (see above).
  • Set new proxy and adjust vote tally accordingly (see above).
• If proxy is not set
  • votes_to_add, votes_to_remove and number are applied to the user's voting slate.
  • Let voting_balance be the sum of the voter's token balance of the asset plus his proxy token balance.
  • The voting delta is the voting_balance for each vote to be added and for the new number, the negative voting_balance for each vote to be removed and the previous number.
  • The voting delta in votes is applied to the vote tally of authority.
  • The resulting differences in the election outcome (if any) are reflected in the respective authority object.

Note: the intent is to have vote tallying work in the same way it is currently performed when voting with BTS. The same goes for determining the number of accounts that make up the authority, unless it is fixed.

5. adjust_balance

The chain logic for adjusting account balances is modified as follows:

• For each voting slate of the balance's owner with the same asset type as is being updated:
  • If the voting slate points to a proxy, adjust the proxy's proxy token count according to the balance delta.
  • Apply the balance delta to the vote tally according to the user's (or proxy's if set) voting slate.
  • Reflect the resulting differences to the election outcome in the respective authority object.

6. account_update_operation

After the time of the hardfork, a new type of special_authority is allowed. This new type wraps an elected_authority_object.

Discussion

Risks

This BSIP has an impact on the performance of balance-changing operations. It is believed that the overall impact will be low, because only few assets will be affected.

Summary for Shareholders

This BSIP introduces new operations to allow voting and elections using other assets than BTS. Authorities based on election outcomes can be assigned to accounts. Proxy voting is not possible in these elections.

Copyright

This document is placed in the public domain.

[shulthz]

In addition, it paves the way for a to-be-proposed change to BitAsset governance, i. e. the decoupling of BitAsset management from blockchain governance

This describe is not suitable to this BSIP.

[pmconrad]

It is part of the motivation. I see no reason why this shouldn't be in there.

[shulthz]

It is part of the motivation. I see no reason why this shouldn't be in there.

This BSIP come from 26 May 2018, it is not part of the motiviton，this is for non-core asset and asset-specific committee.

the decoupling of BitAsset management from blockchain governance

This is another proposition which shouldn't be here, you can give other example simply.

[sschiessl-bcp]

Here are my thoughts:

1. num_members, min_members, max_members: Why three arguments? A fixed num_members could be reflected by min_members == max_members, couldn't it?

2. I assume creator must be voting_asset owner?

3. Can there be several elected_authoritys?

4. candidate_holders could be a amount object (asset_id and amount), which makes only holders of at least amount eligible

5. The current description is that the top X accounts (according to their votes) that hold the asset defined in candidate_holders are the multi-sig for the elected_authority authority? Weighted by their votes, or equal?

6. Can we also have the option to create an elected_authority that automatically uses the top X accounts according to their balance of the candidate_holders asset as the multi-sig? The number X could still be voted on.

7. Suggest to rename candidate_holders to candidates_are_holders_of. I know, long, but self-explanatory

8. Couldn't the elected_authority_object be simply an account with a special type (like STEALTH owner account)? That would facilitate the further use and open other use cases, also with the notion that it should have balances and such. The active authority could be defined like you describe above, and owner authority is the creator. If the asset owner wants to make this authority then permanent, he can remove the owner authority.

9. What is it that elected_authority_object can do to the voting_asset?

10. Why exclude PMs and MPAs?

[pmconrad]

This BSIP come from 26 May 2018, it is not part of the motiviton

The issue is from 2018. The BSIP was written a couple of days ago, with this specific application in mind.

This is another proposition which shouldn't be here, you can give other example simply.

I don't get why you insist on removing it. Mentioning it here does not create a dependency nor does it endorse BSIP 83.

[pmconrad]

num_members, min_members, max_members: Why three arguments? A fixed num_members could be reflected by min_members == max_members, couldn't it?

Yes, that would also be possible.

I assume creator must be voting_asset owner?

No. Anyone can create an authority.

Can there be several elected_authoritys?

Yes, there is no limit.

candidate_holders could be a amount object (asset_id and amount), which makes only holders of at least amount eligible

Hm, do you have a use-case for this in mind? My original thought was that through this mechanism candidates could either be appointed by giving them a specific token, or exclude themselves by burning the token.

The current description is that the top X accounts (according to their votes) that hold the asset defined in candidate_holders are the multi-sig for the elected_authority authority? Weighted by their votes, or equal?

Weighted by voting stake, just as with the current voting mechanism.
candidate_holders only affects the voting, not the vote tallying.

Suggest to rename candidate_holders to candidates_are_holders_of. I know, long, but self-explanatory

Makes sense.

Couldn't the elected_authority_object be simply an account with a special type (like STEALTH owner account)?

The idea is the the elected authority can be used in different ways, which IMO is more generic than making the elected authority an account in itself. Note that STEALTH is also just a normal account with a special "top holders" authority.

What is it that elected_authority_object can do to the voting_asset?

Nothing per se.

The elected authority is just an object that can be used e. g. as the active authority (or owner authority) of an account. If that account owns the voting_asset, then the elected authority can control the voting asset settings, otherwise it can't.

Another use-case is that the elected authority is not used as an authority, but that its member list can be assign other tasks, e. g. price feeding as proposed in BSIP-83.

Why exclude PMs and MPAs?

Because users can borrow tokens of these types from the blockchain, and vote with the borrowed tokens. I don't see where that would make sense.

[shulthz]

This BSIP come from 26 May 2018, it is not part of the motiviton

The issue is from 2018. The BSIP was written a couple of days ago, with this specific application in mind.

This is another proposition which shouldn't be here, you can give other example simply.

I don't get why you insist on removing it. Mentioning it here does not create a dependency nor does it endorse BSIP 83.

This BSIP should follow the underlying objective of this issue, don't mix something in it.
Give a example of Corporate Governance is very easy to understand for everybody.

You can quote this BSIP in the BSIP 83, but the intention of BSIP 83 should not appear in this BSIP for some purpose.
Personal understanding of BSIP is no need to appear in BSIP.

[shulthz]

Why exclude PMs and MPAs?

Because users can borrow tokens of these types from the blockchain, and vote with the borrowed tokens. I don't see where that would make sense.

I think you mix personal understanding in this.
You think the vote with the borrowed tokens is not make sense, but you can't deprive the right to choose of these PMs and MPAs, how to chose is their problem.
You forbid this vote in this DEX, how you can forbid the borrow in other DEX or CEX?

[sschiessl-bcp]

I assume creator must be voting_asset owner?

No. Anyone can create an authority.

candidate_holders could be a amount object (asset_id and amount), which makes only holders of at least amount eligible

Hm, do you have a use-case for this in mind? My original thought was that through this mechanism candidates could either be appointed by giving them a specific token, or exclude themselves by burning the token.

As a use case, if the authority targets a governance token, you can implement something similar to a 5% hurdle in order to be eligible in participation.

The current description is that the top X accounts (according to their votes) that hold the asset defined in candidate_holders are the multi-sig for the elected_authority authority? Weighted by their votes, or equal?

Weighted by voting stake, just as with the current voting mechanism.
candidate_holders only affects the voting, not the vote tallying.

Note that STEALTH is also just a normal account with a special "top holders" authority.

Can we make this special authority available as well to be created?

What is it that elected_authority_object can do to the voting_asset?

Nothing per se.

If the creator of the authority is voting_asset, we could allow a optional allowed_options argument, which allows the new authority to change certain settings of the voting_asset. Essentially, a built-in custom active granted to the elected_authority by the asset owner. Since comittee can't create generic custom active authorities, this would make sense for BitAssets.

The elected authority is just an object that can be used e. g. as the active authority (or owner authority) of an account. If that account owns the voting_asset, then the elected authority can control the voting asset settings, otherwise it can't.

Another use-case is that the elected authority is not used as an authority, but that its member list can be assign other tasks, e. g. price feeding as proposed in BSIP-83.

The idea is that you can define such an authority directly as the price-feed authority? Can it also be a white and blacklist authority?

Why exclude PMs and MPAs?

Because users can borrow tokens of these types from the blockchain, and vote with the borrowed tokens. I don't see where that would make sense.

As an example, you could create a multi-sig account that owns a BitAsset, jointly governed by BitAsset holders and committee defined list of price feeders

[sschiessl-bcp]

it allows the use-case of handing over an asset to an elected_authority, without the ability to influence said authority later on

An asset is not handed over to an elected authority. It is handed over to an account, and the account may or may not be controlled by an elected authority. If an account or an asset can be modified has nothing to do with elected authorities, it has to do with the asset's issuer account or the account's owner respectively, and is therefore out of scope of this BSIP.

Nitpicker :P

Of course I meant that. Let's assume account a owns asset A, furthermore another asset B exists.
Now a creates an elected_authority ea that includes holders of B. Account b is created with active and owner set to ea. Now a hands over ownership of A to b. If a can still delete ea, it has leverage it should not have anymore.

the accounts of the authority are the ones that hold candidate_are_holders_of, sorted and weighted by the balance of the candidate_are_holders_of

That's the same as the already existing top_holders authority, no?

Yes, with the addition of being able to adjust the number of holders.

Will this BSIP allow to create an elected_authority that mimics the existing top_holders? I think that would be nice.

[pmconrad]

Let's assume account a owns asset A, furthermore another asset B exists.
Now a creates an elected_authority ea that includes holders of B. Account b is created with active and owner set to ea. Now a hands over ownership of A to b. If a can still delete ea, it has leverage it should not have anymore.

This can be solved by a creating account b as the first step, then b creates ea and updates its active and owner authorities to ea. Finally, a hands over ownership of A to b.

Will this BSIP allow to create an elected_authority that mimics the existing top_holders?

No, I think this should be handled in a separate BSIP if desirable. (A top_holders authority can already specify the number of top holders to use in the authority, but this number is fixed instead of being voted on. Of course with this proposal people can put up a vote on the number to use, and then use a bot or a manual process for keeping the top_holders authority updated.)

[sschiessl-bcp]

What is the reason that BTS is excluded to be the voting_asset?

[pmconrad]

See https://github.com/bitshares/bsips/blob/master/bsip-0084.md#rationale

[sschiessl-bcp]

1. Can we reformulate this statement:
   Note: the intent is to have vote tallying work in the same way it is currently performed when voting with BTS
   I understood it as the votes are counted the same way (with collateral etc.).

2. While calculating votes on-the-fly is now possible due to reduction of computational effort, this is one of the design flaws in the current voting system. The instant shift (almost instant, currently every hour) of witness / worker / committee voting makes planning quite hard, and enables immediate blackmailing of witnesses. What do you think about letting the creator choose how often votes are recalculated? (e.g. every X maintenance interval/hour).

3. Even with the adjusted counting for votes, I don't see yet why BTS should be excluded. Simply to keep further voting / governance issues of bitassets away? I think the committee would be in charge of that decision (to not use BTS then), and the restriction seems unnecessary.

[pmconrad]

Can we reformulate this statement:
Note: the intent is to have vote tallying work in the same way it is currently performed when voting with BTS

Hm. I think the document is quite clear that only liquid balance are used here. "vote tallying" refers to the process of calculating the sums and selecting the "winners". The specification is clear on which numbers are summed up. Do you have a suggestion how to clarify the note?

What do you think about letting the creator choose how often votes are recalculated?

The processes for recalculating votes on the fly and recalculating them in intervals are completely different. Letting the creator choose would mean we have to implement two different mechanisms. IMO it makes more sense to go with one mechanism, and add the other one later if desired.

I don't see yet why BTS should be excluded

As the Rationale explains, BTS balances change with (almost) every operation, and often even more than once. Re-calculating BTS-based votes on the fly would mean a large computational overhead. This is typically not the case for other tokens. In order to avoid this overhead, BTS is excluded from this type of voting.

[sschiessl-bcp]

Let's assume someone builds a business using an asset that is used for voting as well, and all the customers use it to pay the network fees. Does the intended solution scale?

Also, why does the intended solution need instant tallying? BTS only has tallying during maintenance, and already this has been proven to be too frequent.

[pmconrad]

Let's assume someone builds a business using an asset that is used for voting as well, and all the customers use it to pay the network fees. Does the intended solution scale?

The proposed solution adds some overhead to balance modifications. The overhead is a constant factor, so it scales in the same way that the chain does anyway.

Also, why does the intended solution need instant tallying?

It doesn't need instant tallying. Instant tallying is more "natural". Depending on the numbers and usage patterns, instant tallying can be more efficient than tallying during maintenance (see Rationale).

BTS only has tallying during maintenance, and already this has been proven to be too frequent.

That's news to me. Why "too frequent"?

[sschiessl-bcp]

Let's assume someone builds a business using an asset that is used for voting as well, and all the customers use it to pay the network fees. Does the intended solution scale?

The proposed solution adds some overhead to balance modifications. The overhead is a constant factor, so it scales in the same way that the chain does anyway.

Also, why does the intended solution need instant tallying?

It doesn't need instant tallying. Instant tallying is more "natural". Depending on the numbers and usage patterns, instant tallying can be more efficient than tallying during maintenance (see Rationale).

Ok, makes sense.

BTS only has tallying during maintenance, and already this has been proven to be too frequent.

That's news to me. Why "too frequent"?

Sorry, I was unclear. It is certainly a tradeoff: Instant vote tallying gives ultimate protection against bad actors, whereas tallying every x gives the voted entities somewhat planning safety and reduces blackmailing possibilities. I personally think that the current voting period for witness, committeee and workers is too short, this is just a sidecomment to this BSIP though.

Do you see an easy to realize solution that would still do instant vote tallying, but the actual authority is only updated every x according to the pre-calculated voting tally? (x would be given by elected_authority_object creator)

[pmconrad]

Do you see an easy to realize solution that would still do instant vote tallying, but the actual authority is only updated every x according to the pre-calculated voting tally? (x would be given by elected_authority_object creator)

-> #251

[sschiessl-bcp]

Merged an ready to advance imo
https://github.com/bitshares/bsips/blob/master/bsip-0084.md

Who else can confirm?

[thul3]

The Title of this BSIP says

voting with non-core asset, and asset-specific committee

In addition, it paves the way for a to-be-proposed change to BitAsset governance, i. e. the decoupling of BitAsset management from blockchain governance.

So why is that comment needed ?

Why is the focus by some people realted to BSIP83 only and no other BSIP which is urgently needed for bitshares growth ?

Are we going to keep wasting more resources which won't bring any growth ?

Why don't i see any activity here where it's needed ?
#186

[pmconrad]

So why is that comment needed ?

It has already been removed.

Why is the focus by some people realted to BSIP83 only and no other BSIP which is urgently needed for bitshares growth ?

Because @abitmore has removed the core team's write access from this repo, which means at this time BSIP management is limited to very few people who receive no compensation for the job.

[thul3]

at this time BSIP management is limited to very few people who receive no compensation for the job.

And these few people keep focusing on this crap instead of real issues we have?
When people asked to be more effective and more business oriented i'm pretty sure they didn't mean this BSIP to work on

[abitmore]

The proposed solution adds some overhead to balance modifications. The overhead is a constant factor, so it scales in the same way that the chain does anyway.

No, it's not constant. There could be many elected_authority objects and corresponding elected_authority_vote objects attached to each asset and each account, so the computation resources needed to look up and update them is unbounded. The same applies to the existing special_authorities feature which is already significantly impacting chain performance.
According to the profiling data in bitshares/bitshares-core#1083, balance updating is a major factor impacting performance, IMO we should be serious when evaluating any new features that need to add complexities to balance updating.

[pmconrad]

The "constant factor" was in answer to the specific question about "someone builds a business using an asset that is used for voting as well, and all the customers use it to pay the network fees.". The overhead per fee payment is a constant factor because it doesn't change the voting slate.

Okay, I see where that is misleading. The factor is of course not constant with regard to the number of votes and elected authorities. I agree that the overhead from a large number of elected authorities is significant, which is why the BSIP recommends setting a high fee for creating an elected_authority.

Perhaps also add a committee-configurable limit on the number of votes per account and elected_authority, default 30?

The high runtime impact of balance updates is IMO caused mostly by fee payments, which happens for every operation, but typically in BTS. BTS is explicitly excluded from voting and will therefore not carry voting overhead in balance updates.

[abitmore]

Perhaps also add a committee-configurable limit on the number of votes per account and elected_authority, default 30?

A committee-configurable limitation makes sense for concerns related to performance. However, even with the limitation, I don't think it would scale well, since it's only one factor. The complexity of the whole feature is number of authorities * number of candidates * number of voters * how frequently the balances change. The first factor is expected to be addressed by fees, the second factor is discussed above, but there is no hard limitation on the third and the fourth factors so far. I suggest that we design the fee structure and/or the functionality with all the factors in consideration, for example, have a number max_tally_count in the operation which creates an elected authority object, and freeze the authority when the count exceeds, which means the businesses relying on the feature would have to pay more fees over time to keep the business operational.

On the other hand, the creators of the elected authorities may want to specify how many candidates each account should vote E.G. a fixed number or a range.

By the way, why there is no elected_authority_update operation?

[pmconrad]

The complexity of the whole feature is number of authorities * number of candidates * number of voters * how frequently the balances change.

The computational complexity per balance change is O(number of votes of the balance owner), which would be capped at (number of authorities)*(limit of votes per account and authority).

Balance changes are not free but always the result of an operation that carries a fee, so the frequency is already addressed. The (votes per account and authority) would be limited, and the (number of authorities) is addressed by the authority creation fee.

The RAM cost would be O(total number of votes). I think this is acceptable in practice. (Note that we have other features with potentially unlimited RAM cost.)

have a number max_tally_count in the operation which creates an elected authority object, and freeze the authority when the count exceeds,

That would open up a DOS attack against an authority.

Why there is no elected_authority_update operation?

Because it is usually not advisable nor desirable to change the terms of an ongoing election. It would be better to create a new authority in that case. (Should add this explanation to Rationale.)

[abitmore]

have a number max_tally_count in the operation which creates an elected authority object, and freeze the authority when the count exceeds,

That would open up a DOS attack against an authority.

It's actually the intention. To avoid DoS attacks, the creator of an authority should consider carefully and have plan in advance. Anyway it's an advanced feature but not a toy. In the worst case, a DoS attack against an authority is still better than an attack against the whole chain.

[abitmore]

always the result of an operation that carries a fee

Usually the operation fees don't justify the additional complexity introduced by this feature, also not all operations carry the same additional resource consumption but only the assets with at least an elected authority installed. From this perspective, I'd rather degrade this feature than degrading other operations.

[sschiessl-bcp]

have a number max_tally_count in the operation which creates an elected authority object, and freeze the authority when the count exceeds,

That would open up a DOS attack against an authority.

Taking the idea further: As I understand, businesses using that feature should pay for keeping it active due to its complexity. We could make the creator of the authority pay for each time the actual accounts change for the authority. When the authorities change according to retally_interval, a fee is taken from the reserved fee that is already stored in elected_authority_object. If it doesn't contain enough, the authority is rendered inoperable. When retally_interval hits again, and enough balance is available, it is re-activated according to the current voting slates. This fee may depend on the number of candidates, or number of voters, and retally_interval, and of course the authority creator will require an operation to refill.

I am not familiar enough with the complexities of the backend, apologies if that idea is not helpful.

[abitmore]

@sschiessl-bcp thanks for the elaboration, that's exactly what I thought.

[pmconrad]

It's actually the intention. To avoid DoS attacks, the creator of an authority should consider carefully and have plan in advance.

Opening up a DOS attack would render the feature useless. The creator can't "plan in advance" because he doesn't have the means to avoid it.

As I understand, businesses using that feature should pay for keeping it active due to its complexity. [...] When retally_interval hits again, and enough balance is available, it is re-activated according to the current voting slates.

The problem with this suggestion is that it doesn't work with the on-the-fly tallying. If you stop the tallying, you can't simple resume at a later point, because then you missed all the balance changes in between.

A slightly different option would be to remove all votes if the fee pool runs out and forbid voting until it has been refilled. That would avoid the ongoing re-tallying cost, but would require voters to renew their votes if the authority owner is unreliable with maintaining its fee pool. It could also be seen as a countermeasure against voter apathy. :-)

Yet another option would be to have a per-voter fee pool that is paid by the voter on each balance change. When the voter's fee pool runs out, his votes are removed. IMO that would be the most simple, most fair, and most effective approach. What do you think?

[abitmore]

Yet another option would be to have a per-voter fee pool that is paid by the voter on each balance change. When the voter's fee pool runs out, his votes are removed. IMO that would be the most simple, most fair, and most effective approach. What do you think?

That brings the same DoS problem targeting individual voters, which imo is even worse than a global fee pool.

[pmconrad]

That brings the same DoS problem targeting individual voters, which imo is even worse than a global fee pool.

Good point.

So, scrap the on-the-fly tallying? Instead count during maintenance (possibly only every n maintenance intervals), apply a tallying fee per in proportion to the number of holders (voters? votes?) paid by a per-authority fee pool?

[sschiessl-bcp]

What is the performance comparison (estimated) of

a) having on-the-fly tallying, with a fee for every retally_interval to be paid by the authority creator? Letting the fee roll out requires re-voting (I find that acceptable)

b) doing maintenance interval retallying?

Neither a) or b) would have DOS angels, will they?

[abitmore]

So, scrap the on-the-fly tallying? Instead count during maintenance (possibly only every n maintenance intervals), apply a tallying fee per in proportion to the number of holders (voters? votes?) paid by a per-authority fee pool?

Sounds reasonable to me.

[pmconrad]

What is the performance comparison (estimated) of
a) having on-the-fly tallying, with a fee for every retally_interval to be paid by the authority creator?
b) doing maintenance interval retallying?

The performance cost for on-the-fly tallying depends mostly on the number of balance changes, whereas the cost for maintenance-interval tallying depends on the number of balances.

The important difference is that it is difficult to counter the number of balance changes with a fee, because every operation can induce a balance change. This leads to DoS problems. A fee per retally_interval does not solve this.
The cost for maintenance retallying OTOH is somewhat predictable.