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

[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 https://github.com/bitshares/bitshares-core/issues/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.