Regarding BSIP022

[ThomasFreedman]

Well done, nice work!

The only thing I had concern about was committee power, as their ability to set decay parameters could position them to become a centralized body more easily unless the range of decay they can adjust (max age, rate of decay) has hard coded limits committee must work within that mitigate that concern.

Also, I've long held that exchanges should NOT have voting rights, but how can that be accomplished? Blacklisting is not the answer, b/c as you say that power could be extended to individual accounts and thus effectively amount to control / censorship of individuals.

How to identify an exchange's account is one method of addressing the problem. Another might be a cap on stake for voting (max_stake_weight - an account with 1M bts = an account with > 1M BTS) it would equalize power of biggest stakeholders, but also discourages holding > max_stake_weight. What would impact on that be? Not saying 1M is the correct limit, just an example. However, the idea may lead to a more decentralized ecosystem.

[jcalfee]

About Exchange Power: If the chain can utilize vesting then this is a good way to detour exchange power. This is used in Steem where users have voting power based on how much is vesting (3 months). Exchanges will probably want that liquid. Honestly though, the underlying issue is that people use centralized exchanges for what ever reason. This issue could very well work it self out over time.

I say no to blacklisting too.. Vector for abuse like you said, and this may need some measure of preventing sock puppet accounts.

[rngl4b]

What do you think could happen if accounts were able to vote only with their collateral and vesting stakes? Could this kind of prediction-market layer encourage voting, with a measurable incentive/compromise ratio?

Everyone would be voting only with what they are wiling to invest into the network (and with the income they recently generated if vesting balances get weighted too).

Centralized exchanges would loose trust if they put their users funds as collateral to trade and vote (if not done with agreement and participation from their users). Their possible vesting balances are just a little fraction of what exchanges can have in their wallets.

Big stakes would have to weight their votes in the market with their own money, and thus vote wisely. Real proxies would be more incentivized to build (or to emerge from) communities, with users more prone to move between communities/proxies that benefits from betting/voting to fund the same value propositions.

Could something like this take us closer to a limited but actually functional profit sharing economy?

Sonds strange, is it possible that enforcing futarchy and even meritocracy rules into voting, we could get a fairer power distribution than the actual? easier consensus building towards funding the mutually, or the clearly most beneficial network development, seems to be the only potentially big scaling threat we can face at some point not so far. I think it deserves a good talk.

Don't mean to distract from priorities and already discussed, easier solutions. Just raw thoughts trying to simplify and put together some already proposed ideas to keep research up.

[grctest]

@ThomasFreedman wrote: The only thing I had concern about was committee power, as their ability to set decay parameters could position them to become a centralized body more easily unless the range of decay they can adjust (max age, rate of decay) has hard coded limits committee must work within that mitigate that concern.

I agree that it could be possible for a committee with such tools to collaborate to change the parameters for increased power, Absolute power corrupts absolutely. It would be hilarious PR though if we had a committee attempt to form a dictatorship, the appropriate response would be for the network to remove their votes then revert the parameters.

Perhaps it could be more appropriately hardcoded to require a hardfork to change, making it far more difficult to change without network consensus.

@ThomasFreedman wrote: Also, I've long held that exchanges should NOT have voting rights, but how can that be accomplished? Blacklisting is not the answer, b/c as you say that power could be extended to individual accounts and thus effectively amount to control / censorship of individuals.

I think @jcalfee's idea regarding bitshares holders placing their BTS into a vesting balance similar to SteemPower in Steem.

@ThomasFreedman wrote: How to identify an exchange's account is one method of addressing the problem. Another might be a cap on stake for voting (max_stake_weight - an account with 1M bts = an account with > 1M BTS) it would equalize power of biggest stakeholders, but also discourages holding > max_stake_weight. What would impact on that be? Not saying 1M is the correct limit, just an example. However, the idea may lead to a more decentralized ecosystem.

You're right, if an account was blocked/blacklisted from voting, they could simply create a new account to vote with immediately. On the other hand, I don't think we'd see exchanges doing this though, because they usually only use the same account name with user-personalized-memos for simplicity.

---

@jcalfee wrote: About Exchange Power: If the chain can utilize vesting then this is a good way to detour exchange power. This is used in Steem where users have voting power based on how much is vesting (3 months). Exchanges will probably want that liquid.

I like the idea of locking BTS away in a vesting balance, which would prevent exchanges voting with their hot wallets however they may place their cold storage funds into vesting if the payout schedule is sufficient to supply their hot wallets.

A downside to BTS Power (BTS locked in vesting balance) is that by severely reducing the supply of liquid BTS we may starve the smartcoin trading pairs of liquidity. On the other hand, a goal for substantial smartcoin generation is a reduced liquidity of BTS which may cause an uptrend in the market trading rates on centralized exchanges. All speculation really..

@jcalfee wrote: Honestly though, the underlying issue is that people use centralized exchanges for what ever reason. This issue could very well work it self out over time.

I agree that it's concerning that such substantial BTS holdings are kept on centralized exchanges, the current path of ignoring the causes/consequences of voter apathy won't solve voter apathy.

In terms of causes, the bitshares-ui worker proposal will likely improve the visibility/presence of voting within the client. The consequences of voter apathy could be deal with via expiring votes.

[grctest]

@jcalfee I created BSIP-0024 to cover your idea for locking BTS away for BTS power/influence. https://github.com/bitshares/bsips/pull/29

[beyondbitcoin]

please join t.me/btsworkers to keep up to date on the bsips and worker proposals posted here and help keep others updated.

we have weekly hangouts that pay people who are working on bitshares to join up and provide updates and to push for bsips to be funded. :)

https://steemit.com/bitshares/@officialfuzzy/bitshares-hangout-37-2017-09-08-opensource-agenda-beyondbit-payouts-powered-by-sp

[pmconrad]

The original thread on bitsharestalk regarding this subject is now more than two years old. Can someone extract some numbers, like

• what percentage of witness/committee votes hasn't been updated in the last 6, 12, 24 months?
• what percentage of witness/committee votes is coming from accounts that haven't shown any activity within the last 6, 12, 24 months?
• what percentage of votes is voting through a proxy?
• what percentage of proxy votes is coming from accounts that haven't shown any activity within the last 6, 12, 24 months?

[grctest]

@pmconrad Sounds like a reasonable request, however how would we retrieve this data efficiently? You can't see user vote data on cryptofresh/open-explorer, nor retrieve it using python-bitshares directly.

I suppose we'd need to process every transaction, filtering out non-vote transactions, before we can begin answering the above questions?

Perhaps we only need to evaluate each account's last vote? Brings the data down to a max of 500k(ish) tx to evaluate.

@oxarbitrage Do you believe there's an easier way of doing this?

---

Edit: quick pseudocode for dumping this data

for (x in range(115000000)):
  try:  
    tx = get_object 1.11.x
  except:
    continue
  if (tx.new_options is not None):
    log transaction details
  else:
    continue

We could slow down the above dumping script by keeping a large dict of account_id:timestamp, and work backwards from the latest transaction number to only retrieve the latest vote, however it might take longer and require a lot of RAM.. I'll look into this script and get back to you..

[oxarbitrage]

@grctest you can go against an elasticsearch wrapper, should be easier, pls check samples at:

https://github.com/oxarbitrage/bitshares-es-wrapper

more specifically, on xeroc account: http://209.188.21.157:5000/get_account_history?account_id=1.2.282&from=0&size=10&sort_by=-block_data.block_time&from_date=2017-09-01&to_date=now

you are going to need a script that parse the op field and look for the new_options as you proposed. will be a bit more efficient than doing it directly against the node.

[grctest]

@oxarbitrage Ah, just saw your post there, I threw together a script to dump the data which turns out would take 22 days with a single instance.. though if I ran 22 instances it'd take only a day..

https://github.com/BTS-CM/BTS-Vote-extractor

---

But you're right, your es wrapper search could work, but then it's a matter of 500k accounts to perform this es-wrapper check against if we want a full insight..

"It is even possible to make queries to all the accounts in a period of time, getting the network activity in that range: View Online Sample"

This looks very useful, if we're assuming a vote validity of 1 year maximum, then we would be able to skip several hundred thousand account queries, then it's a matter of establishing these account's core asset (BTS) balances (or vote weight if summarized somewhere?) and working out the impact of BSIP 22's proposed changes against proxies/workers/witnesses/committee members.

[grctest]

@oxarbitrage Is there any kind of summary of applied witness votes we can retrieve from the Bitshares client? The UI is able to show the total votes, so surely it knows of the TXIDs of each vote, which would massively reduce the quantity of TX to inspect.

Or is the above idea of dumping all new_options TX the best bet?

[btsfav]

I think votes should decay after 365 days of NO account action

[grctest]

Think we could use the 'Added a new api call get_account_history_by_operations to the rpc api and the cli_wallet.' function which was recently introduced to bitshares-core to dump each account's new_options operations?

@btsfav What would the rate of decay after the 365 day delay be?

[abitmore]

@grctest For some reason (performance related), that new API is very limited. I think it's better to collect data via Elastic Search plugin.

[rngl4b]

All this makes me think about a network_monitor (or an 'explorer') plugin, to define loading ops such as top n proxies vote history (back to a specified time), the same for price feeds and its medians, tx/s... basically all the information we can gather to improve decision making about development paths, proxies, witnesses, committee members, blockchain parameters, workers, etc.

[abitmore]

@rngl4b we do need such tools, but it hasn't to be a plugin. Actually everyone can make an external tool to help on this, like what has been done in CryptoFresh. Since the back end dev resource is limited, I more like the external tool approach. More action, less talk / think / wish.

[rngl4b]

And the Elastic Search plug in. You core devs are making history. I guess my whole point is that resources are only limited by our ability to gather consensus.

[clockworkgr]

voting.bitshares.works (pending foundation agreement or an equivalent domain if not) is one more item on a huge backlog of stuff I'm working on...

I've mentioned it on telegram before.

Really need to see how I'll prioritize the backlog :/

[abitmore]

Stale.