Author Topic: Delegate standards  (Read 3137 times)

0 Members and 1 Guest are viewing this topic.

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
Is there a field atm where delegates can provide information about their campaign etc or anything to proof their forum or real world id? At least it's not visible in the gui...
svk added some tweaks to bitsharesblocks and the GUI interface to address the proposal in
http://wiki.bitshares.org/index.php/Delegate/PublicData
do you know where this info will  be stored (on chain?) and where will it be available (gui?)?

The data is stored on the blockchain in each account's "public_data" field. This field accepts a json object so you can put lots of things in there. What I've done is add a couple of those fields to the client as well as to bitsharesblocks. The field names will be translated to whatever language the user is using, but the actual content will be in whatever language the user used when he entered it in his client.

It will be available in the accounts tab in the gui, and is already available on bitsharesblocks.

https://github.com/BitShares/web_wallet/pull/464

http://bitsharesblocks.com/delegates/delegate?name=dev.bitsharesblocks
that adds a lot of value. Thanks svk!

Offline svk

Is there a field atm where delegates can provide information about their campaign etc or anything to proof their forum or real world id? At least it's not visible in the gui...
svk added some tweaks to bitsharesblocks and the GUI interface to address the proposal in
http://wiki.bitshares.org/index.php/Delegate/PublicData
do you know where this info will  be stored (on chain?) and where will it be available (gui?)?

The data is stored on the blockchain in each account's "public_data" field. This field accepts a json object so you can put lots of things in there. What I've done is add a couple of those fields to the client as well as to bitsharesblocks. The field names will be translated to whatever language the user is using, but the actual content will be in whatever language the user used when he entered it in his client.

It will be available in the accounts tab in the gui, and is already available on bitsharesblocks.

https://github.com/BitShares/web_wallet/pull/464

http://bitsharesblocks.com/delegates/delegate?name=dev.bitsharesblocks
Worker: dev.bitsharesblocks

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
Is there a field atm where delegates can provide information about their campaign etc or anything to proof their forum or real world id? At least it's not visible in the gui...
svk added some tweaks to bitsharesblocks and the GUI interface to address the proposal in
http://wiki.bitshares.org/index.php/Delegate/PublicData
do you know where this info will  be stored (on chain?) and where will it be available (gui?)?

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Is there a field atm where delegates can provide information about their campaign etc or anything to proof their forum or real world id? At least it's not visible in the gui...
svk added some tweaks to bitsharesblocks and the GUI interface to address the proposal in
http://wiki.bitshares.org/index.php/Delegate/PublicData

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
+5%

at least the delegates should offer a way to communicate with them .. publicly ..

preferably written in the public data field of the delegate itself .. ONCHAIN!
Is there a field atm where delegates can provide information about their campaign etc or anything to proof their forum or real world id? At least it's not visible in the gui...
« Last Edit: November 26, 2014, 08:30:33 am by delulo »

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
+5%

at least the delegates should offer a way to communicate with them .. publicly ..

preferably written in the public data field of the delegate itself .. ONCHAIN!

Offline BTSdac

  • Hero Member
  • *****
  • Posts: 1219
    • View Profile
  • BitShares: K1
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
Bumping this a bit...

I think the proposal in the OP is easy to do and will bring much more quality to voting decisions!

One example: There is a delegate called "daslab". How do I know that is toast or just some random guy that named his delegate daslab?
If there was a standard expectation to put the link of your delegate promotion into the "Delegate Info" section that would be immediately obvious.

Offline Shentist

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 1601
    • View Profile
    • metaexchange
  • BitShares: shentist

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
Observation: Looking at the list of delegate in the client I find many of which I do not know who they are. It would be good to know who they are and if they want to stay completely anonymous that would be great to know to. As it is atm I have to google all the unknown delegate names and see if for example cny.bts500 made a thread on the forum where that delegate team says who is behind it. 

Proposal:
It would greatly improve the reliability and accountability of DPOS if there would be some widely acknowledged standard among shareholders about what "formal" criteria every delegate should fulfill.

Here are the criteria I would propose but please discuss.

1) Every delegate should be transparent about (in his delegate name or in "delegate info" in the client) the identity status and state into which category they fall:
a) completely anonymous
b) a forum member
c) public identity

2) Every delegate should commit to not do vote buying (buying votes with money = offering those that vote for that delegate to share the profit from his delegate pay)

...what else....??

Result:
- It would be less easy for a bad actor to trick shareholders into voting for multiple delegates he all controls especially given that most shareholders will try to minimize the effort put into voting / delegate research.
- It would make it easier to decide who to vote for which in return should result in higher voting participation which in return increases security.
- It encourages the discussion about who to vote for and why.

All those criteria can not be enforced by code nor do we want legal contracts to enforce anything... What is left to (soft)enforce is is a common understanding / habits / a voting and campaigning culture which could look like this: Because there is a widely accepted set of formal criteria for campaigning as a delegate delegates would follow those requirements: Being transparent about their identity status in the client and stating that they do not do any vote buying in their delegate campaign thread here on the forum. 

Those are not content related criteria like reliability or reputation but general voting and campaigning habits that would improve DPOS a lot if it is widely accepted/required.
« Last Edit: November 20, 2014, 04:11:14 pm by delulo »