Paid Workers Proposal for Review

[yiminh]

Well, Stan introduced a new role that wasn't part of this discussion but it boils down to:

1) Who runs nodes and includes transactions (block producers) which should be elected and have no other roles and how much do they get paid for this one role (just enough to cover costs)

2) Who (if anyone) gets paid, how much, for how long, and how much vesting, and with what priority given a defined maximum budget of 5 BTS / sec for all spending

3) Who gets to set block chain parameters (fees, block sizes, block producer pay, maintenance collateral requirements, vesting terms, referral program parameters, etc)

Answer is these roles are all separate and individually voted on.

Thanks for that Dan, it helps. Would you please label the roles and associate them with the functions they perform? I've seen the term worker used, but that is vague and could apply to all roles. I used manager, assuming a team lead position which you have now dispelled by saying all of the roles are voted into place. Presumably all of these roles are called delegates?

Does a vesting period apply to all of the roles? It doesn't seem to make sense for the block signers if they are only being reimbursed for server costs, nor does that seem reasonable to me. I know you've said the nodes "pretty much run themselves once setup", but that doesn't reduce the time to maintain a delegate node to zero. Besides, in my experience over the last 3 months it's consumed a significant amount of time, far from the claim it runs itself with minimal investments of time.

Stan used "workers, signers & knob turners", just to confuse things even more.

You also said you didn't think these new roles would have much of an impact on existing delegates. The discussion hasn't even addressed cases like Riverhead who acts as the technical arm of several delegates. Will he be paid and voted into place independently for each (worker?) he supports? What about structure / rules to insure a good measure of reliability and decentralization?  What about qualifications to roles?

I think any serious proposal should spell out in detail the before and after effects it will have on our existing way of doing things, nominations, delegate fees (the same for all roles?), voting, pay, whether delegate teams will be allowed etc etc. It's not a trivial undertaking to accomplish and get done before the 1.0 release along with everything else. I feel this is a major discussion that cuts to the heart of DPoS, and it needs to be refined and solidified prior to 1.0. The good news is that as far as anyone knows, the date for when 1.0 goes into the wild is not yet public. With topics like this still under heavy discussion, that's a good thing indeed, as it allows time to hammer out these fundamental changes we're discussing.

I am curious why you think it's necessary for all of these roles to be voted into place separately and would like to hear your perspective on that. I also think the point Ander raised about the complexity of our ecosystem and effect on voter apathy should not be discounted.

I do agree the delegate structure needs improvement and that should be done prior to releasing 1.0. So this discussion is on target IMO.

Lucky for you I have been working on just such a paper... here is a preview of the motivation for this:

Under DPOS 1.0 the stakeholders would select 101 delegates by approval voting.  These delegates would take turns producing blocks every 10 seconds. Each delegate would get to set their own pay rate as a percent of the maximum.  Decisions about which fees to charge and hard-forks to adopt rested in the hands of delegates which acted individually.

This system worked reasonably well but over time some serious issues became apparent. Some of these issues include:

Requiring stakeholders to select 101 delegates may be too much leading to most stakeholders voting for less than 101 or not carefully vetting the delegates they chose.
Forcing all “employees” to run servers to get paid significantly complicated the hiring of people without those skills.
There was no way to come to a consensus on what the fee structure should be.
With a total budget of $50,000 per month of new issuance, each individual delegate had a maximum budget of $500 per month which is not enough to get someone’s full time attention.   It was politically unpopular to give one individual multiple delegate positions for fear of centralization.
Delegates have too much control in a single position that opens them up to unnecessary legal liability.

DPOS 2.0 Overview

Under DPOS 2.0 the roles of delegates have been divided into 3 categories:

Witness - produces blocks and is paid a percentage of transaction fees.
Worker - is paid a fixed number of tokens per day to perform a task
Delegate - co-signer on a dynamic multi-sig account with permissions to change blockchain parameters.

Each of these roles is filled by approval voting.  The number of Witnesses and Delegates is directly voted upon by the stakeholders.    Each stakeholder must vote for at least as many Witnesses and Delegates as they believe the system should have.   The number of witnesses/delegates is defined such that at least 50% of voting shareholders believe there is sufficient decentralization.  The number of workers is determined by how many workers the available daily budget will cover when paid out to workers from most approved to least approved.



Delegates

The delegates have multi-sig control over a special account dubbed the “genesis account”.  This multi-sig account can do anything any other account can do with a 2 week delay.  If enough delegates are voted out within two weeks of jointly approving a transaction then the transaction will fail to go through.   

The “genesis account” has the unique privilege of changing critical parameters such as: Block Interval, Block Size, Witness Pay Rate, Burn Rate, and even the review period for their own transactions.   

Delegates are not paid positions and are therefore honorary and held by individuals who have a vested interest negotiating changes to the network parameters. 

Legally the delegates have no direct power other than to propose changes for the stakeholders to reject.   This means delegate positions are safe from regulation and power truly rests in the hands of the stakeholders.   

Unlike DPOS 1.0 where each delegate operates independently, under DPOS 2.0 delegates are forced to reach consensus directly before any change can be proposed. 

Dob't know if you are stupid or just pretend don't know, the current market cap says you are fired, so get out of BTS space please!

[bytemaster]

Well, Stan introduced a new role that wasn't part of this discussion but it boils down to:

1) Who runs nodes and includes transactions (block producers) which should be elected and have no other roles and how much do they get paid for this one role (just enough to cover costs)

2) Who (if anyone) gets paid, how much, for how long, and how much vesting, and with what priority given a defined maximum budget of 5 BTS / sec for all spending

3) Who gets to set block chain parameters (fees, block sizes, block producer pay, maintenance collateral requirements, vesting terms, referral program parameters, etc)

Answer is these roles are all separate and individually voted on.

Thanks for that Dan, it helps. Would you please label the roles and associate them with the functions they perform? I've seen the term worker used, but that is vague and could apply to all roles. I used manager, assuming a team lead position which you have now dispelled by saying all of the roles are voted into place. Presumably all of these roles are called delegates?

Does a vesting period apply to all of the roles? It doesn't seem to make sense for the block signers if they are only being reimbursed for server costs, nor does that seem reasonable to me. I know you've said the nodes "pretty much run themselves once setup", but that doesn't reduce the time to maintain a delegate node to zero. Besides, in my experience over the last 3 months it's consumed a significant amount of time, far from the claim it runs itself with minimal investments of time.

Stan used "workers, signers & knob turners", just to confuse things even more.

You also said you didn't think these new roles would have much of an impact on existing delegates. The discussion hasn't even addressed cases like Riverhead who acts as the technical arm of several delegates. Will he be paid and voted into place independently for each (worker?) he supports? What about structure / rules to insure a good measure of reliability and decentralization?  What about qualifications to roles?

I think any serious proposal should spell out in detail the before and after effects it will have on our existing way of doing things, nominations, delegate fees (the same for all roles?), voting, pay, whether delegate teams will be allowed etc etc. It's not a trivial undertaking to accomplish and get done before the 1.0 release along with everything else. I feel this is a major discussion that cuts to the heart of DPoS, and it needs to be refined and solidified prior to 1.0. The good news is that as far as anyone knows, the date for when 1.0 goes into the wild is not yet public. With topics like this still under heavy discussion, that's a good thing indeed, as it allows time to hammer out these fundamental changes we're discussing.

I am curious why you think it's necessary for all of these roles to be voted into place separately and would like to hear your perspective on that. I also think the point Ander raised about the complexity of our ecosystem and effect on voter apathy should not be discounted.

I do agree the delegate structure needs improvement and that should be done prior to releasing 1.0. So this discussion is on target IMO.

Lucky for you I have been working on just such a paper... here is a preview of the motivation for this:

Under DPOS 1.0 the stakeholders would select 101 delegates by approval voting.  These delegates would take turns producing blocks every 10 seconds. Each delegate would get to set their own pay rate as a percent of the maximum.  Decisions about which fees to charge and hard-forks to adopt rested in the hands of delegates which acted individually.

This system worked reasonably well but over time some serious issues became apparent. Some of these issues include:

Requiring stakeholders to select 101 delegates may be too much leading to most stakeholders voting for less than 101 or not carefully vetting the delegates they chose.
Forcing all “employees” to run servers to get paid significantly complicated the hiring of people without those skills.
There was no way to come to a consensus on what the fee structure should be.
With a total budget of $50,000 per month of new issuance, each individual delegate had a maximum budget of $500 per month which is not enough to get someone’s full time attention.   It was politically unpopular to give one individual multiple delegate positions for fear of centralization.
Delegates have too much control in a single position that opens them up to unnecessary legal liability.

DPOS 2.0 Overview

Under DPOS 2.0 the roles of delegates have been divided into 3 categories:

Witness - produces blocks and is paid a percentage of transaction fees.
Worker - is paid a fixed number of tokens per day to perform a task
Delegate - co-signer on a dynamic multi-sig account with permissions to change blockchain parameters.

Each of these roles is filled by approval voting.  The number of Witnesses and Delegates is directly voted upon by the stakeholders.    Each stakeholder must vote for at least as many Witnesses and Delegates as they believe the system should have.   The number of witnesses/delegates is defined such that at least 50% of voting shareholders believe there is sufficient decentralization.  The number of workers is determined by how many workers the available daily budget will cover when paid out to workers from most approved to least approved.



Delegates

The delegates have multi-sig control over a special account dubbed the “genesis account”.  This multi-sig account can do anything any other account can do with a 2 week delay.  If enough delegates are voted out within two weeks of jointly approving a transaction then the transaction will fail to go through.   

The “genesis account” has the unique privilege of changing critical parameters such as: Block Interval, Block Size, Witness Pay Rate, Burn Rate, and even the review period for their own transactions.   

Delegates are not paid positions and are therefore honorary and held by individuals who have a vested interest negotiating changes to the network parameters. 

Legally the delegates have no direct power other than to propose changes for the stakeholders to reject.   This means delegate positions are safe from regulation and power truly rests in the hands of the stakeholders.   

Unlike DPOS 1.0 where each delegate operates independently, under DPOS 2.0 delegates are forced to reach consensus directly before any change can be proposed. 

[Thom]

Well, Stan introduced a new role that wasn't part of this discussion but it boils down to:

1) Who runs nodes and includes transactions (block producers) which should be elected and have no other roles and how much do they get paid for this one role (just enough to cover costs)

2) Who (if anyone) gets paid, how much, for how long, and how much vesting, and with what priority given a defined maximum budget of 5 BTS / sec for all spending

3) Who gets to set block chain parameters (fees, block sizes, block producer pay, maintenance collateral requirements, vesting terms, referral program parameters, etc)

Answer is these roles are all separate and individually voted on.

Thanks for that Dan, it helps. Would you please label the roles and associate them with the functions they perform? I've seen the term worker used, but that is vague and could apply to all roles. I used manager, assuming a team lead position which you have now dispelled by saying all of the roles are voted into place. Presumably all of these roles are called delegates?

Does a vesting period apply to all of the roles? It doesn't seem to make sense for the block signers if they are only being reimbursed for server costs, nor does that seem reasonable to me. I know you've said the nodes "pretty much run themselves once setup", but that doesn't reduce the time to maintain a delegate node to zero. Besides, in my experience over the last 3 months it's consumed a significant amount of time, far from the claim it runs itself with minimal investments of time.

Stan used "workers, signers & knob turners", just to confuse things even more.

You also said you didn't think these new roles would have much of an impact on existing delegates. The discussion hasn't even addressed cases like Riverhead who acts as the technical arm of several delegates. Will he be paid and voted into place independently for each (worker?) he supports? What about structure / rules to insure a good measure of reliability and decentralization?  What about qualifications to roles?

I think any serious proposal should spell out in detail the before and after effects it will have on our existing way of doing things, nominations, delegate fees (the same for all roles?), voting, pay, whether delegate teams will be allowed etc etc. It's not a trivial undertaking to accomplish and get done before the 1.0 release along with everything else. I feel this is a major discussion that cuts to the heart of DPoS, and it needs to be refined and solidified prior to 1.0. The good news is that as far as anyone knows, the date for when 1.0 goes into the wild is not yet public. With topics like this still under heavy discussion, that's a good thing indeed, as it allows time to hammer out these fundamental changes we're discussing.

I am curious why you think it's necessary for all of these roles to be voted into place separately and would like to hear your perspective on that. I also think the point Ander raised about the complexity of our ecosystem and effect on voter apathy should not be discounted.

I do agree the delegate structure needs improvement and that should be done prior to releasing 1.0. So this discussion is on target IMO.

[bytemaster]

The whole "stable client" thing keeps getting thrown out there, but last I checked it has only ever crashed on me one time.   I haven't heard many complaints from the 0.9 series.   

I trust that you would not ignore the cries of instability simply because you have not experienced it.

I've personally experienced hundreds of crashes, maybe 20 or more just in the last week with 0.9 .... the windows GUI version anyways, the CLI version I've rarely had any issue with.

Our crash reports show the crashes are almost always in Qt's webkit code for Win32.   It doesn't seem to crash like that on the Mac.    Unfortunately, we are unable to easily fix webkit crashes without major overhaul to the wallet architecture which is what we are in the process of doing.   

[Xeldal]

The whole "stable client" thing keeps getting thrown out there, but last I checked it has only ever crashed on me one time.   I haven't heard many complaints from the 0.9 series.   

I trust that you would not ignore the cries of instability simply because you have not experienced it.

I've personally experienced hundreds of crashes, maybe 20 or more just in the last week with 0.9 .... the windows GUI version anyways, the CLI version I've rarely had any issue with.

[mint chocolate chip]

The proposed concept of splitting delegate positions into three roles (signers, workers, and knob-turners) would not necessarily change a single thing.  The instant after such a change, the same people would be doing the same jobs under new titles.  Then, over time, the stakeholders might slowly vote to sort people out into specializing in the jobs they do best.

The new "worker" category would just give stakeholders better control over who is working for them.  It would add the ability to specify a pay rate, a term limit and a vesting period and give them the ability to quickly remove non-performers from office.

But if you like things the way they are, the new tools would still allow you to vote to keep it that way.

Could we pause here & get a definition of these (3?) roles Stan mentioned? Are each of these roles voted into being separately or as a team? How is the pay rate of each role established?

Well, Stan introduced a new role that wasn't part of this discussion but it boils down to:

1) Who runs nodes and includes transactions (block producers) which should be elected and have no other roles and how much do they get paid for this one role (just enough to cover costs)
2) Who (if anyone) gets paid, how much, for how long, and how much vesting, and with what priority given a defined maximum budget of 5 BTS / sec for all spending
3) Who gets to set block chain parameters (fees, block sizes, block producer pay, maintenance collateral requirements, vesting terms, referral program parameters, etc)

Answer is these roles are all separate and individually voted on.

All this added complexity seems unnecessary to me, and increases the problem that BTS is already too complicated for most crypto enthusiasts to understand. 

We already have a difficult enough time getting people to vote for delegates.  If they need to vote for even more things that they dont know about: delegates and workers and blockchain parameters and so on, it will just discourage people even more from voting.

Why is this being considered and important problem that we need to work on solving now, when the bigger problem is that the client isnt stable and needs more work on key features?  What is wrong with the current setup where the paid delegates are hiring technical people to run their nodes, and giving them 5% of the pay or whatever. 

Sure, maybe we want to modify this some in the future but why is it important now?

Because we don't want major changes after 1.0.    Because we want to discuss these things for the sake of discussion and long-term planning.   Short term thinking is what got us where we are right now and a longer term perspective is what is necessary to get us where we want to go.

The whole "stable client" thing keeps getting thrown out there, but last I checked it has only ever crashed on me one time.   I haven't heard many complaints from the 0.9 series.   

Just because we discuss this doesn't mean we are not working on those other things.    There is a whole lot to building a stable client and some of it is foundational.   We are actively working on it with a holistic approach.

The .9 series has given me more issues than any before it.

[bytemaster]

The proposed concept of splitting delegate positions into three roles (signers, workers, and knob-turners) would not necessarily change a single thing.  The instant after such a change, the same people would be doing the same jobs under new titles.  Then, over time, the stakeholders might slowly vote to sort people out into specializing in the jobs they do best.

The new "worker" category would just give stakeholders better control over who is working for them.  It would add the ability to specify a pay rate, a term limit and a vesting period and give them the ability to quickly remove non-performers from office.

But if you like things the way they are, the new tools would still allow you to vote to keep it that way.

Could we pause here & get a definition of these (3?) roles Stan mentioned? Are each of these roles voted into being separately or as a team? How is the pay rate of each role established?

Well, Stan introduced a new role that wasn't part of this discussion but it boils down to:

1) Who runs nodes and includes transactions (block producers) which should be elected and have no other roles and how much do they get paid for this one role (just enough to cover costs)
2) Who (if anyone) gets paid, how much, for how long, and how much vesting, and with what priority given a defined maximum budget of 5 BTS / sec for all spending
3) Who gets to set block chain parameters (fees, block sizes, block producer pay, maintenance collateral requirements, vesting terms, referral program parameters, etc)

Answer is these roles are all separate and individually voted on.

All this added complexity seems unnecessary to me, and increases the problem that BTS is already too complicated for most crypto enthusiasts to understand. 

We already have a difficult enough time getting people to vote for delegates.  If they need to vote for even more things that they dont know about: delegates and workers and blockchain parameters and so on, it will just discourage people even more from voting.

Why is this being considered and important problem that we need to work on solving now, when the bigger problem is that the client isnt stable and needs more work on key features?  What is wrong with the current setup where the paid delegates are hiring technical people to run their nodes, and giving them 5% of the pay or whatever. 

Sure, maybe we want to modify this some in the future but why is it important now?

Because we don't want major changes after 1.0.    Because we want to discuss these things for the sake of discussion and long-term planning.   Short term thinking is what got us where we are right now and a longer term perspective is what is necessary to get us where we want to go.

The whole "stable client" thing keeps getting thrown out there, but last I checked it has only ever crashed on me one time.   I haven't heard many complaints from the 0.9 series.   

Just because we discuss this doesn't mean we are not working on those other things.    There is a whole lot to building a stable client and some of it is foundational.   We are actively working on it with a holistic approach.

[Ander]

The proposed concept of splitting delegate positions into three roles (signers, workers, and knob-turners) would not necessarily change a single thing.  The instant after such a change, the same people would be doing the same jobs under new titles.  Then, over time, the stakeholders might slowly vote to sort people out into specializing in the jobs they do best.

The new "worker" category would just give stakeholders better control over who is working for them.  It would add the ability to specify a pay rate, a term limit and a vesting period and give them the ability to quickly remove non-performers from office.

But if you like things the way they are, the new tools would still allow you to vote to keep it that way.

Could we pause here & get a definition of these (3?) roles Stan mentioned? Are each of these roles voted into being separately or as a team? How is the pay rate of each role established?

Well, Stan introduced a new role that wasn't part of this discussion but it boils down to:

1) Who runs nodes and includes transactions (block producers) which should be elected and have no other roles and how much do they get paid for this one role (just enough to cover costs)
2) Who (if anyone) gets paid, how much, for how long, and how much vesting, and with what priority given a defined maximum budget of 5 BTS / sec for all spending
3) Who gets to set block chain parameters (fees, block sizes, block producer pay, maintenance collateral requirements, vesting terms, referral program parameters, etc)

Answer is these roles are all separate and individually voted on.

All this added complexity seems unnecessary to me, and increases the problem that BTS is already too complicated for most crypto enthusiasts to understand. 

We already have a difficult enough time getting people to vote for delegates.  If they need to vote for even more things that they dont know about: delegates and workers and blockchain parameters and so on, it will just discourage people even more from voting.

Why is this being considered and important problem that we need to work on solving now, when the bigger problem is that the client isnt stable and needs more work on key features?  What is wrong with the current setup where the paid delegates are hiring technical people to run their nodes, and giving them 5% of the pay or whatever. 

Sure, maybe we want to modify this some in the future but why is it important now?

[bytemaster]

The proposed concept of splitting delegate positions into three roles (signers, workers, and knob-turners) would not necessarily change a single thing.  The instant after such a change, the same people would be doing the same jobs under new titles.  Then, over time, the stakeholders might slowly vote to sort people out into specializing in the jobs they do best.

The new "worker" category would just give stakeholders better control over who is working for them.  It would add the ability to specify a pay rate, a term limit and a vesting period and give them the ability to quickly remove non-performers from office.

But if you like things the way they are, the new tools would still allow you to vote to keep it that way.

Could we pause here & get a definition of these (3?) roles Stan mentioned? Are each of these roles voted into being separately or as a team? How is the pay rate of each role established?

Well, Stan introduced a new role that wasn't part of this discussion but it boils down to:

1) Who runs nodes and includes transactions (block producers) which should be elected and have no other roles and how much do they get paid for this one role (just enough to cover costs)
2) Who (if anyone) gets paid, how much, for how long, and how much vesting, and with what priority given a defined maximum budget of 5 BTS / sec for all spending
3) Who gets to set block chain parameters (fees, block sizes, block producer pay, maintenance collateral requirements, vesting terms, referral program parameters, etc)

Answer is these roles are all separate and individually voted on.

[Thom]

The proposed concept of splitting delegate positions into three roles (signers, workers, and knob-turners) would not necessarily change a single thing.  The instant after such a change, the same people would be doing the same jobs under new titles.  Then, over time, the stakeholders might slowly vote to sort people out into specializing in the jobs they do best.

The new "worker" category would just give stakeholders better control over who is working for them.  It would add the ability to specify a pay rate, a term limit and a vesting period and give them the ability to quickly remove non-performers from office.

But if you like things the way they are, the new tools would still allow you to vote to keep it that way.

Could we pause here & get a definition of these (3?) roles Stan mentioned? Are each of these roles voted into being separately or as a team? How is the pay rate of each role established?

[xeroc]

BTS getting more complex, The more complex system made more complex issue, So the more complex system must be more complex to resolve the more complex issue. and so on, BTS will be dead.

So it must be stop to made more complex rule.

The most probable way to resolve BTS's issue is made the rule as simple as possible.
Not only the delegate voting system ,and it is same to mechanism to creating a stable digital currency.

Make the most simple rule to resolve complex issue.
This is the way to succeed.

TCP/IP is simple
HTTP/SMTP/XMPP/IMAP are complex

we don't want to trade just one token ..
we want an exchange
AND a pegged asset ..

also, simple is not easy to define ... but both, bitasset1.0 and bitasset2.0 are rather simple compared to traditional markets

[helloworld]

BTS getting more complex, The more complex system made more complex issue, So the more complex system must be more complex to resolve the more complex issue. and so on, BTS will be dead.

So it must be stop to made more complex rule.

The most probable way to resolve BTS's issue is made the rule as simple as possible.
Not only the delegate voting system ,and it is same to mechanism to creating a stable digital currency.

Make the most simple rule to resolve complex issue.
This is the way to succeed.

[helloworld]

I don't think he was proposing to change the dilution  rate, just the power stakeholders have.


Sent from my iPhone using Tapatalk

no one can change rule,  this discussing is useless, if the income cannot pay the core developer income ,we have AGS, to pay them , and if change the rule it would make bts price drop so much , delegate income would decrease much.

So you think the ags funds will last that long?   They are mostly gone and at these prices they can only cover for short time. 

The only rule left is stakeholders decide.  From what I see here delegates would be split and their income unchanged.   Going forward shareholders can vote different mixes of funding and block producers.


Sent from my iPhone using Tapatalk

Ags fouds will spend over, and the income cannot pay the core developer,  I think it's normal status. The issue not come from BTS voting system.

Just like miner in bitcoin，if the biction' price cannot pay the miner, so the miner decide to increase amount per blockchain?

it is a joke.

stakeholders and VC have any relation？

[BunkerChainLabs-DataSecurityNode]

The proposed concept of splitting delegate positions into three roles (signers, workers, and knob-turners) would not necessarily change a single thing.  The instant after such a change, the same people would be doing the same jobs under new titles.  Then, over time, the stakeholders might slowly vote to sort people out into specializing in the jobs they do best.

The new "worker" category would just give stakeholders better control over who is working for them.  It would add the ability to specify a pay rate, a term limit and a vesting period and give them the ability to quickly remove non-performers from office.

But if you like things the way they are, the new tools would still allow you to vote to keep it that way.

Vote to not change?! Geez.. yer making crypto way to much like the real world.

Thank you for the clarification on this though.. Without even this much detail I always understood it as an added measure of redistribution control.

[Stan]

The proposed concept of splitting delegate positions into three roles (signers, workers, and knob-turners) would not necessarily change a single thing.  The instant after such a change, the same people would be doing the same jobs under new titles.  Then, over time, the stakeholders might slowly vote to sort people out into specializing in the jobs they do best.

The new "worker" category would just give stakeholders better control over who is working for them.  It would add the ability to specify a pay rate, a term limit and a vesting period and give them the ability to quickly remove non-performers from office.

But if you like things the way they are, the new tools would still allow you to vote to keep it that way.