abitmore commented 6 years ago

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 commented 6 years ago

support. DAC need this.

bangzi1001 commented 6 years ago

Support! Very useful and very powerful feature.

xeroc commented 6 years ago

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

abitmore commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

TheTaconator commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

I like the idea - could encourage UIA usage more 👍

sschiessl-bcp commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Two factors

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
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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

shulthz commented 5 years ago

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 commented 5 years ago

Here are my thoughts:

num_members, min_members, max_members: Why three arguments? A fixed num_members could be reflected by min_members == max_members, couldn't it?
I assume creator must be voting_asset owner?
Can there be several elected_authoritys?
candidate_holders could be a amount object (asset_id and amount), which makes only holders of at least amount eligible
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?
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.
Suggest to rename candidate_holders to candidates_are_holders_of. I know, long, but self-explanatory
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.
What is it that elected_authority_object can do to the voting_asset?
Why exclude PMs and MPAs?

pmconrad commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

I also propose that the flag voting_allowed also disables the delete operation, to allow that an assets configuration/management can be made permanent.

pmconrad commented 5 years ago

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

It already is.

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?

Anything is possible, although that's outside the scope of this BSIP. E. g. using it for price feeding is proposed in BSIP-83.

I think you mix personal understanding in this.

Of course I do. When I write a BSIP, I write down my personal understanding. Then we discuss this, and change when necessary. There is no technical reason to leave out MPAs or PMs, so if you guys think they should be available too I'll add them.

pmconrad commented 5 years ago

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.

I don't think that's a good idea. There are other ways to achieve the same, so there's no need to add this.

he flag voting_allowed also disables the delete operation, to allow that an assets configuration/management can be made permanent

I don't understand. Which "delete operation"?

sschiessl-bcp commented 5 years ago

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

It already is.

I think I misunderstood. I ll try again: Currently, this BSIP allows two types of authorities:

the accounts of the authority are the ones as mentioned in candidates, sorted and weighted by the votes received in voting_asset
the accounts of the authority are the ones that hold candidate_are_holders_of, sorted and weighted by the votes received in voting_asset In both cases, the number of accounts in the authority must be within the limits provided.

What I was hoping to have available as well is

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

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?

Anything is possible, although that's outside the scope of this BSIP. E. g. using it for price feeding is proposed in BSIP-83.

Yes, I did not mean to say this BSIP should define how it will be set at the end. Is the intention that this elected_authority object can be set as a price feed provider directly? And if so, can it also be set as a whitelist/blacklist authority?

sschiessl-bcp commented 5 years ago

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.

I don't think that's a good idea. There are other ways to achieve the same, so there's no need to add this.

Could you elaborate how this would be possible please?

he flag voting_allowed also disables the delete operation, to allow that an assets configuration/management can be made permanent

I don't understand. Which "delete operation"?

The delete_elected_authority operation.

shulthz commented 5 years ago

Of course I do. When I write a BSIP, I write down my personal understanding.

When i read a BSIP, I will read the design and the generalized purpose of this design, everyone has different comment or understanding to the design and this BSIP, we can't write everyone's comment in the BSIP.

pmconrad commented 5 years ago

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?

Is the intention that this elected_authority object can be set as a price feed provider directly? And if so, can it also be set as a whitelist/blacklist authority?

The elected_authority defined here is nothing but a weighted list of accounts. This BSIP also defines that the weighted list of accounts can be used as an authority in an account.

Other use-cases for the list are possible, including price-feeding or black/whitelisting, but of of scope.

Could you elaborate how this would be possible please?

Create a manager account where the active authority is elected from asset XYZ, and the owner authority is committee. Transfer ownership of XYZ to the manager account. Both the committee and the elected authority can change asset settings.

Admittedly, this gives the elected authority more powers than just changing flags. However, I still think it would be bad design if election by asset owners and control over asset flags were conflated like this.

the flag voting_allowed also disables the delete operation, to allow that an assets configuration/management can be made permanent

Preventing asset configuration from being modified is not achieved by preventing the elected authority from being deleted. Again, this suggestion conflates voting through an asset with managing of the asset. I think these two things should remain separate.

we can't write everyone's comment in the BSIP

I'm glad we agree on this. (Of course it also means that we can't consider everyone's request to remove a comment from the original author.)

shulthz commented 5 years ago

I'm glad we agree on this. (Of course it also means that we can't consider everyone's request to remove a comment from the original author.)

BSIP is wrote for community, not for original author, what's the original author think or comment is meaningless for community, but every comment will affect the vote.

sschiessl-bcp commented 4 years ago

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.

Is the intention that this elected_authority object can be set as a price feed provider directly? And if so, can it also be set as a whitelist/blacklist authority?

The elected_authority defined here is nothing but a weighted list of accounts. This BSIP also defines that the weighted list of accounts can be used as an authority in an account.

Other use-cases for the list are possible, including price-feeding or black/whitelisting, but of of scope.

I think it would be a great addition to create use-cases for this new authority.

Could you elaborate how this would be possible please?

Create a manager account where the active authority is elected from asset XYZ, and the owner authority is committee. Transfer ownership of XYZ to the manager account. Both the committee and the elected authority can change asset settings.

Admittedly, this gives the elected authority more powers than just changing flags. However, I still think it would be bad design if election by asset owners and control over asset flags were conflated like this.

If committee is allowed to also create custom active authorities, then all use-cases could be handled. What's your standpoint on that?

the flag voting_allowed also disables the delete operation, to allow that an assets configuration/management can be made permanent

Preventing asset configuration from being modified is not achieved by preventing the elected authority from being deleted. Again, this suggestion conflates voting through an asset with managing of the asset. I think these two things should remain separate.

Not directly prevented, but it allows the use-case of handing over an asset to an elected_authority, without the ability to influence said authority later on. For example, if the former asset owner can simply delete the authority, then it has leverage.

pmconrad commented 4 years ago

every comment will affect the vote.

True. IMO voters should receive as much information about a new feature as possible, so they can make an educated decision. E. g. they should be told what could be done with a new feature.

If they disapprove a good feature because it could have one application they don't like... well, no comment. It's like forbidding hammers because you can kill people with a hammer. Or like not telling people that hammers can kill, so people don't get upset about hammers.

If committee is allowed to also create custom active authorities, then all use-cases could be handled. What's your standpoint on that?

That's off-topic here. Generally I think BSIP-40 should see some testing in practice before we consider wider application.

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.

shulthz commented 4 years ago

True. IMO voters should receive as much information about a new feature as possible, so they can make an educated decision. E. g. they should be told what could be done with a new feature.

I don't think you give a easy understanding example or information to them, you just give them a non-existent and hard understanding thing and want them to understand well, i don't think they will understand what you talked about.

If they disapprove a good feature because it could have one application they don't like... well, no comment. It's like forbidding hammers because you can kill people with a hammer. Or like not telling people that hammers can kill, so people don't get upset about hammers.

How to use the hammers is the choice of people, you just need to tell them the generalized purpose of the hammers. When i sell a hammers to people, did i need to write down the one of use is kill people?

sschiessl-bcp commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

pmconrad commented 4 years ago

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

sschiessl-bcp commented 4 years ago

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.).
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).
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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

Who else can confirm?

thul3 commented 4 years ago

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 ? https://github.com/bitshares/bsips/issues/186

bitshares / bsips

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

Abstract

Motivation

Rationale

Specifications

1. New asset flag "voting_allowed"

2. New operation "create_elected_authority"

3. New operation "delete_elected_authority"

4. New operation "update_asset_vote"

5. `adjust_balance`

6. `account_update_operation`

Discussion

Risks

Summary for Shareholders

Copyright

bitshares / bsips

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

Abstract

Motivation

Rationale

Specifications

1. New asset flag "voting_allowed"

2. New operation "create_elected_authority"

3. New operation "delete_elected_authority"

4. New operation "update_asset_vote"

5. adjust_balance

6. account_update_operation

Discussion

Risks

Summary for Shareholders

Copyright

5. `adjust_balance`

6. `account_update_operation`