Open abitmore opened 6 years ago
support. DAC need this.
Support! Very useful and very powerful feature.
Would that be feasible computationally? It needs to go through all the holders of different assets and accumulate the respective stake.
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.
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.
maybe we need set a threshold for the DAC to open this function.
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?
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.
I like the idea - could encourage UIA usage more 👍
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?
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.
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.
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.
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.
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?
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.
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
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
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.
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.
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.
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.
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 authorityasset_id_type voting_asset
- the asset on which to base the votingunsigned_int num_members
- the number of authority members to vote on if fixed, or 0 otherwiseunsigned_int min_members
- the minimum number of authority members to elect, or 0 if fixedunsigned_int max_members
- the maximum number of authority members that can be elected, or 0 if fixedflat_set<account_id_type> candidates
- a list of candidates eligible for voting, or emptyoptional<asset_id_type> candidate_holders
- and asset that candidates must hold to be eligible for votingbool proxy_allowed
- indicates if proxy voting is allowedoptional<time_point_sec> vote_until
- an optional ending date after which voting slates are frozenValidation:
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.num_members
is 0 then min_members
and max_members
must both be positive.num_members
is positive then both min_members
and max_members
must equal 0.candidates
is not empty then
max(num_members,min_members)
.candidate_holders
must not be present.candidate_holders
is present the candidates
must be empty.vote_until
, if present, must be in the futureEvaluation:
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
.
Fields:
account_id_type owner
- the account to pay the fee, must have created the authorityelected_authority_id_type authority
- the authority to deleteValidation:
The operation must not be used before the time of the hardfork.
authority
must exist.owner == authority.creator
Evaluation:
authority
is returned to owner
.elected_authority_object
is deleted.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.
Fields:
account_id_type voter
- the voting account, also pays feeelected_authority_id_type authority
- the authority on which to voteunsigned_int number
- the number of members the authority should have, or 0 if it is fixedflat_set<account_id_type> votes_to_add
- a list of accounts to add to the current voting slateflat_set<account_id_type> votes_to_remove
- a list of accounts to remove from the current voting slateoptional<account_id_type> proxy
- an optional voting proxyValidation:
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.authority.vote_until
is present, then it must be in the future.authority.num_members > 0
then number
must equal 0.authority.num_members == 0
then authority.min_members <= number <= authority.max_members
.votes_to_add
:
authority
authority.candidates
is not empty then it must be contained thereinauthority.candidate_holders
is present then it must own tokens of the given typevotes_to_remove
:
authority
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.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:
proxy
is not present but voter
had set a proxy on this authority
before
voter
's token balance from the old proxy's proxy token count and adjust vote tally accordingly.votes_to_add
as described below.proxy
is present and voter
had not set a proxy before
voter
's balance to proxy
's proxy token count and adjust vote tally accordingly.proxy
is present and voter
had set a (different) proxy before
proxy
is not set
votes_to_add
, votes_to_remove
and number
are applied to the user's voting slate.voting_balance
be the sum of the voter
's token balance of the asset plus his proxy token balance.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
.authority
.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.
adjust_balance
The chain logic for adjusting account balances is modified as follows:
authority
object.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
.
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.
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.
This document is placed in the public domain.
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.
It is part of the motivation. I see no reason why this shouldn't be in there.
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.
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_authority
s?
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?
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.
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.
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.
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?
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
I also propose that the flag voting_allowed
also disables the delete operation, to allow that an assets configuration/management can be made permanent.
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.
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"?
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:
candidates
, sorted and weighted by the votes received in voting_asset
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
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?
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.
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.
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.)
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.
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.
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.
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?
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.
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.)
What is the reason that BTS
is excluded to be the voting_asset
?
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.
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.
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.
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"?
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)
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
Merged an ready to advance imo https://github.com/bitshares/bsips/blob/master/bsip-0084.md
Who else can confirm?
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
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