Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: Voting proposal  (Read 516 times)

0 Members and 1 Guest are viewing this topic.

Offline BTSdac

Voting proposal
« on: November 29, 2014, 06:02:07 PM »

BTS pay developer and marketing salary by delegate pay in blockchain, it is a very great way.  but now the pay rate just can turn down cannot turn up.
so many delegate must set 100% pay rate delegate in first, but BTSer cannot know his work for BTS( exclude BM ,toast ,stan and svk, they done great work for BTS )
if we develop a new vote model let delegate not only turn down the pay rate, but turn up the pay rate also.
1.each delegate can set a pay rate same as current vote regular .
2. the different is  Btser should set a delegate pay rate when he vote a delegate.  and default is 3%.
3. if the pay rate vote by BTS stakeholder is high than pay rate set by delegate , this stakeholder voting is effective. as opposite, if the pay rate vote by BTS stakeholder is low than pay rate set by delegate ,this this stakeholder voting is invalid temporarily till lower pay rate set by delegate  , so delegate can set low pay let he have enough poll to top 101.

take a example
if Roy want to run a 100% pay rate delegate , some people think Roy is  worth for 100% pay rate ,but other people think ROY run a  50% pay rate delegate is OK . so there is  5% poll vote Roy as  100% pay rate , and  5% poll vote Roy as 50% pay rate. , so there is only 5% poll is effective. other 5% poll is ineffective because the pay rate vote by BTS stakeholder is lower than Roy set .

and now in BTS if delegate want to been in top 101 ,he must have  6% poll .
so Roy can turn down his delegate pay rate to 50%,  so his all pole is effective . he can been in top 101
three months pass. Roy do very good job for BTS . many people vote he as 100% pay rate delegate . there have 10 % poll vote Roy as 100% delegate in all , then Roy turn up his delegate pay rate to  100%.
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091

Offline bytemaster

Re: Voting proposal
« Reply #1 on: November 29, 2014, 06:18:43 PM »
Not practical at a translation size level.  Would double trx size and computation.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline liondani

Re: Voting proposal
« Reply #2 on: November 29, 2014, 06:23:37 PM »


Not practical at a translation size level.  Would double trx size and computation.




what about that proposal...
it would be great that we have the option integrated in the wallet to vote independently for the pay rate for elected delegates...  imagine when you vote for a  delegate to have a second field  where you can enter your preferred pay rate... The actual payrate could be the average or median payrate from all voters... In that way the delegates don't need to campaign for new delegates with different names every now and then (it will be confusing)... 

Sent from my ALCATEL ONE TOUCH 997D

 +5% That's an interesting idea.



Sent from my ALCATEL ONE TOUCH 997D



Sent from my ALCATEL ONE TOUCH 997D

  https://bitshares.OPENLEDGER.info/?r=GREECE  | You are in Control | BUY | SELL | SHORT | SWAP | LOAN | TRADE |  

Offline Stan

  • Hero Member
  • *****
  • Posts: 2862
  • You need to think BIGGER, Pinky...
    • View Profile
    • Cryptonomex
  • BTS: Stan
Re: Voting proposal
« Reply #3 on: November 29, 2014, 06:29:56 PM »
BTS pay developer and marketing salary by delegate pay in blockchain, it is a very great way.  but now the pay rate just can turn down cannot turn up.
so many delegate must set 100% pay rate delegate in first, but BTSer cannot know his work for BTS( exclude BM ,toast ,stan and svk, they done great work for BTS )
if we develop a new vote model let delegate not only turn down the pay rate, but turn up the pay rate also.
1.each delegate can set a pay rate same as current vote regular .
2. the different is  Btser should set a delegate pay rate when he vote a delegate.  and default is 3%.
3. if the pay rate vote by BTS stakeholder is high than pay rate set by delegate , this stakeholder voting is effective. as opposite, if the pay rate vote by BTS stakeholder is low than pay rate set by delegate ,this this stakeholder voting is invalid temporarily till lower pay rate set by delegate  , so delegate can set low pay let he have enough poll to top 101.

take a example
if Roy want to run a 100% pay rate delegate , some people think Roy is  worth for 100% pay rate ,but other people think ROY run a  50% pay rate delegate is OK . so there is  5% poll vote Roy as  100% pay rate , and  5% poll vote Roy as 50% pay rate. , so there is only 5% poll is effective. other 5% poll is ineffective because the pay rate vote by BTS stakeholder is lower than Roy set .

and now in BTS if delegate want to been in top 101 ,he must have  6% poll .
so Roy can turn down his delegate pay rate to 50%,  so his all pole is effective . he can been in top 101
three months pass. Roy do very good job for BTS . many people vote he as 100% pay rate delegate . there have 10 % poll vote Roy as 100% delegate in all , then Roy turn up his delegate pay rate to  100%.

To win votes, some candidates might agree to burn some of their 100% salary until they are proven, or escrow it with a trusted IT delegate until some objective metric is achieved.   

Its hard to make a one-size fits all algorithm to handle this.  That's why we have left it to market forces.

I note that in the past 24 hours we have gained more value per share than we lose in 5 years of max dilution, so adding complexity to slice and dice a delegate's pay rate may not be worth the effort.  We can already slice and dice them by how long they stay voted in.  That's pretty good vernier control already.

The amount of impact that giving a delegate a month or two to prove herself is negligible.  It will probably be so hard to win a slot that we are in danger of swinging the other way and making it too hard to attract the top talent we need.

Its a balance.  But making the first months painful for new talent seems counterproductive in the Big Picture.
« Last Edit: November 29, 2014, 06:45:56 PM by Stan »
Anything said on these forums does not constitute an intent to create a legal obligation or contract of any kind.   These are merely my opinions which I reserve the right to change at any time.

Offline chryspano

  • Hero Member
  • *****
  • Posts: 610
    • View Profile
Re: Voting proposal
« Reply #4 on: November 29, 2014, 07:04:23 PM »

what about that proposal...


it would be great that we have the option integrated in the wallet to vote independently for the pay rate for elected delegates...  imagine when you vote for a  delegate to have a second field  where you can enter your preferred pay rate... The actual payrate could be the average or median payrate from all voters... In that way the delegates don't need to campaign for new delegates with different names every now and then (it will be confusing)... 

Sent from my ALCATEL ONE TOUCH 997D



Sent from my ALCATEL ONE TOUCH 997D

I think we should not add unnecessary complexity, we either believe in a delegate and the work he is doing or we don't. If we believe in a delegate's work then we need to fuel him as much as we can. Just my opinion.


Offline matt608

  • Hero Member
  • *****
  • Posts: 878
    • View Profile
Re: Voting proposal
« Reply #5 on: November 29, 2014, 08:25:39 PM »
A voter can always change their mind.  If you want "Roy" ;D at 50% not 100% you could re-evaluate your voting decision after a shorter time period time period than you would for delegates you fully support.

Offline BTSdac

Re: Voting proposal
« Reply #6 on: November 30, 2014, 06:07:20 AM »
Not practical at a translation size level.  Would double trx size and computation.

Voting take much translation size as you said , So is there any possibility that reduce voting frequency. if there is a suggestion change threshold to need to vote in Gui

I mean if I had 100K BTS ,and I have voted  delegate A for 100K BTS,  and I receive another 1BTS now.  I have 100,001BTS now . and I now add delegate B as my supported delegate ,client would sign two voting imformation in translation, when I update my voting

1. add 1 BTS voting to delegate A;
2. vote delegate B 100,001BTS, 
is it right ?

you can notice "vote delegate B 100,001BTS" is the most important information that I want to express, but the information that "add 1bts voting to delegate A" can been ignored .if client just sign information that "vote delegate B 100,001 BTS,"  and  ignore information "add 1 BTS voting to delegate A" as default in GUI
it can reduce  size of translation , you know if I voted 100 delegates, it will reduce much size.

so if the poll change for one delegate I vote less than 1% (or other ) of whole poll I voted to him. Gui client can ignore this change and don`t sign this information in translation as recommend. of course, update all voting change API  should been keep in command line.
« Last Edit: November 30, 2014, 06:15:35 AM by BTSdac »
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091

Offline BTSdac

Re: Voting proposal
« Reply #7 on: December 01, 2014, 09:22:05 AM »
Not practical at a translation size level.  Would double trx size and computation.

Voting take much translation size as you said , So is there any possibility that reduce voting frequency. if there is a suggestion change threshold to need to vote in Gui

I mean if I had 100K BTS ,and I have voted  delegate A for 100K BTS,  and I receive another 1BTS now.  I have 100,001BTS now . and I now add delegate B as my supported delegate ,client would sign two voting imformation in translation, when I update my voting

1. add 1 BTS voting to delegate A;
2. vote delegate B 100,001BTS, 
is it right ?

you can notice "vote delegate B 100,001BTS" is the most important information that I want to express, but the information that "add 1bts voting to delegate A" can been ignored .if client just sign information that "vote delegate B 100,001 BTS,"  and  ignore information "add 1 BTS voting to delegate A" as default in GUI
it can reduce  size of translation , you know if I voted 100 delegates, it will reduce much size.

so if the poll change for one delegate I vote less than 1% (or other ) of whole poll I voted to him. Gui client can ignore this change and don`t sign this information in translation as recommend. of course, update all voting change API  should been keep in command line.
user can set a Min percentage of poll change he would  for a delegate , client update poll if change is over this percentage . otherwise don`t update poll
like we set time of lock wallet.
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091

Offline BTSdac

Re: Voting proposal
« Reply #8 on: January 07, 2015, 10:32:18 AM »
Not practical at a translation size level.  Would double trx size and computation.
could you consider this suggestion again ,  now many people register 100% pay rate first .  but there is a embarrassed situation.
some developer or marketing is new for forum. BTS holder cannot support his as 100% delegate.  but delegate only can down ,cannot up , so developer have to register 100% delegate
in other way , if consider BTS as a company , 100% delegate as staff of it ,  salary of each staff should been different acc.to what he done . but now each staff get same pay .
and could you say more details why this would double trx side .  only a extra pay rate value is included in trx with voting , 1 byte is enough ? is it right?
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091

 

Google+