Author Topic: Paid Workers Proposal for Review  (Read 43835 times)

0 Members and 1 Guest are viewing this topic.

Offline fuzzy

I've described the paid worker solution that I would like to see in this post. I think we should just let the management of project/worker payment be delegated to the elected delegates. The shareholders should make their desires/opinions official known to the delegates via a non-binding proposal system on the blockchain. The delegates are trusted to carry through with the shareholder wishes (in a responsible way), and if they fail to do so they will be voted out. I think giving this responsibility to the delegates rather than the shareholders (essentially adding that level of indirection) should hopefully make the workers feel like they are less likely to get the rug pulled from underneath them due to some chaotic irrational/emotional response from the masses. The delegates essentially act as a check on the shareholders. However, they ultimately answer to the shareholders because they can be easily voted out and replaced by new delegates that will consider shareholder opinion more.

There are also safeguards preventing delegates from just spending as much on a worker as they want (beyond just the hard dilution limit) such as the dilution budget collectively available to them (that they don't necessarily need to all spend) by virtue of being elected with some budget request (which could only be adjusted up by getting a new version of their delegate elected by shareholders) and the fact that a super majority of the delegates need to agree to any change to the worker pay list. One other thing I would add to my linked proposal is that the recipient account in the worker pay list could either be a vesting type or a non-vesting type. The vesting type would have an additional parameter in the tuple defining the vesting period that the recipient needs to wait until they can access the accumulated funds held under their name.

Edit: By the way, if it wasn't clear, the approach described above allows the super majority of the delegates to implement any policy for funding projects (including the one in your post BM). The idea is that the policy isn't encoded as code in the blockchain, and therefore is more dynamic. The non-binding proposal system can allow shareholders to vote for and against any project with a start and end date, for example, and the delegates are responsible for carrying out that policy. It is sort of like the difference between the Turing complete scripts on Ethereum vs smart contracts implemented using a super majority multisig of executors and actually executing the deterministic code off-chain (like Open Transactions' Voting Pools, or Codius smart contracts, or maybe future BitShares smart contracts(?)).

 +5%
WhaleShares==DKP; BitShares is our Community! 
ShareBits and WhaleShares = Love :D

Offline joele

  • Sr. Member
  • ****
  • Posts: 467
    • View Profile
Great.
One more thing - make the budget definable in bitAsset (not only) BTS. Should be easy once a day to calculate how much bts is the required say 2000 bitusd/day.
This.

Plus +5% for finally having workers and signers!!

 +5% +5%

+5%

Offline BunkerChainLabs-DataSecurityNode


We have 7 core developers that need at least $25,000 per month (combined) just to pay for Food, Shelter, and Clothing and earning 1/4 what they could make on the free market.  These 7 core developers form a company that produces a wallet and profits from referral income.   This company would have a funded project with a roadmap for BTS and would receive 250,000 BTS per day that their project is in the top list of  projects for 4 years.


I'm not sure I totally understands where the money to pay the 7 core developers will come from without being able to sell anything from their pay for 5 years? The referral program might be able to help funding it, but will it be enough? Will there be VC investment to cover for what's missing?

I think that is the point.  This real world company can accumulate bts, and effectively sell shares in it to an angel/vc.  I am just not sure a VC will be excited about investing in a company that could get voted out at a moments notice.

Here is what I love about this idea:
1. I would much rather hire Bytemaster Co or similar to hire and manage a core dev team than try to vote on a core dev team one at a time.
2. Vesting is great for eliminating dilution sell pressure.
3. I think one team with leadership will be far more efficient long term that many competing delegates

My reservations about the plan:
1. Will VC's find sufficient value to put up good money for a maybe vote.  Although the VC's could commit to a payment schedule and only pay in each month that the project is voted in.   On the good side... It is not my problem.   It is bytemaster Co and his competitors job to solve this problem.  But it is my problem in that I dont want him and others to be set up to fail.
2. Although it eliminates sell pressure, it could be argued that it absorbs buying pressure too.  But I dont think this is particularly valid as that kind of buying pressure (angel/VC) would not be a normal stake holder buyer so it just introduces a new kind of buyer in a cool way.

I am not a VC.. but I would imagine this would be a VERY innovative way for them to have a metric read on the progress and viability of a project. I think what you suggested would likely be the case.. get voted out for whatever reason and the the VC money hits pause.. it's up to the company then to turn things around.

Either way it helps to get the company to share in the risk and attract only true entrepreneurs and viable projects with an end for success. Unlike so many that see only getting funding from a VC to be the success.. which has become the culture in most parts for the past 10 years.

A 5 year term however in 'internet years' is an awfully LONG time. That I think might be the friction point for most VCs to have as guarantee that takes so long and to weather potentially so many changes of the Internet to eventually access should the project had prove a failure. I think a 2-3 year term might be more viable.

Most projects are brought to market at least even in beta within a half year window from what I have seen. If it was somehow received lack luster.. badly executed.. whatever.. and the tap turns off.. the VC is left holding the bag for another 4+ years to get back some of his losses.. certainly not a bad thing for BTS!... however a product that makes things more difficult will be received with limited success and could be a lame duck offer in the end. ie. we got this mechanism, but nobody wants to use it because nobody can sell it. To be a VC could live with something on the books failing for a few more years, but dragging it through their portfolio for half a decade in Internet years seems like a hard sell.

From a practical perspective I am wondering if this is something that gets built into the wallet? Does this mean we have a new tab beside delegates called 'Company', or 'Workers', or 'Projects'?

It's interesting the example given is a mirror of Moonstone. I admit I find myself thinking in terms of the said example of funding programmers only. I am having trouble applying this to other types of projects. but perhaps as it takes form it will become more clear.

As for using assets as well.. while I understand the convenience factor to this, I can also see why Dan would suggest BTS only... locking funds in BTS will do more good for the ecosystem as a whole vs. one asset or another perhaps. Each project can convert to whatever asset/fiat of their choosing depending on their preference on their own end. If it's a BTS project though, it should be in BTS. Don't work at GM and drive a Ford so to speak. :)

That's all that comes to mind in terms of what is being proposed.

As for other suggestions like arhags.. his seems more elegant to me from a community perspective.
+-+-+-+-+-+-+-+-+-+-+
www.Peerplays.com | Decentralized Gaming Built with Graphene - Now with BookiePro and Sweeps!
+-+-+-+-+-+-+-+-+-+-+

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Step 3:   Pay out projects in order of total approval once per day until all 432,000 BTS has been consumed.

This all-or-nothing approach is an even bigger problem. Suppose I propose development of some specific feature that will take me 6 months to complete. I get voted in and start working. After 3 months, someone bigger is voted in above me, leaving me with no payment and an unfinished product. That's a lose-lose situation.

(If you expect voters to act rationally and not vote me out after 3 months I suggest a reality check. :-) )
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
I've described the paid worker solution that I would like to see in this post. I think we should just let the management of project/worker payment be delegated to the elected delegates. The shareholders should make their desires/opinions official known to the delegates via a non-binding proposal system on the blockchain. The delegates are trusted to carry through with the shareholder wishes (in a responsible way), and if they fail to do so they will be voted out. I think giving this responsibility to the delegates rather than the shareholders (essentially adding that level of indirection) should hopefully make the workers feel like they are less likely to get the rug pulled from underneath them due to some chaotic irrational/emotional response from the masses. The delegates essentially act as a check on the shareholders. However, they ultimately answer to the shareholders because they can be easily voted out and replaced by new delegates that will consider shareholder opinion more.

There are also safeguards preventing delegates from just spending as much on a worker as they want (beyond just the hard dilution limit) such as the dilution budget collectively available to them (that they don't necessarily need to all spend) by virtue of being elected with some budget request (which could only be adjusted up by getting a new version of their delegate elected by shareholders) and the fact that a super majority of the delegates need to agree to any change to the worker pay list. One other thing I would add to my linked proposal is that the recipient account in the worker pay list could either be a vesting type or a non-vesting type. The vesting type would have an additional parameter in the tuple defining the vesting period that the recipient needs to wait until they can access the accumulated funds held under their name.

Edit: By the way, if it wasn't clear, the approach described above allows the super majority of the delegates to implement any policy for funding projects (including the one in your post BM). The idea is that the policy isn't encoded as code in the blockchain, and therefore is more dynamic. The non-binding proposal system can allow shareholders to vote for and against any project with a start and end date, for example, and the delegates are responsible for carrying out that policy. It is sort of like the difference between the Turing complete scripts on Ethereum vs smart contracts implemented using a super majority multisig of executors and actually executing the deterministic code off-chain (like Open Transactions' Voting Pools, or Codius smart contracts, or maybe future BitShares smart contracts(?)). 
« Last Edit: May 03, 2015, 03:06:16 pm by arhag »

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
IMO the general payment scheme sucks, because it inevitably leads to centralisation of any kind of development. As bm's specific proposal shows, it is much easier to present a large proposal for funding some kind of company than expecting individual contributors to come up with their own proposals and work on having them voted in. The current scheme is much more flexible wrt the many smaller contributors that we currently have.

The specific proposal for more adequate funding for today's core devs makes absolute sense.

Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline Empirical1.2

  • Hero Member
  • *****
  • Posts: 1366
    • View Profile
Great.
One more thing - make the budget definable in bitAsset (not only) BTS. Should be easy once a day to calculate how much bts is the required say 2000 bitusd/day.
This.


 +5% +5%

 +5%  for definable in BitAsset.

Also BTS is already pretty centralised and target-able,  another 365 million BTS to the core development company (12%+ equity) would add to those concerns I think. 



If you want to take the island burn the boats

Offline BTSdac

  • Hero Member
  • *****
  • Posts: 1219
    • View Profile
  • BitShares: K1
like great ,do we have to vote this by share, only one oppose this can vote negative vote.
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091

Offline bitmarket

  • Sr. Member
  • ****
  • Posts: 369
    • View Profile
    • BitShares TV

We have 7 core developers that need at least $25,000 per month (combined) just to pay for Food, Shelter, and Clothing and earning 1/4 what they could make on the free market.  These 7 core developers form a company that produces a wallet and profits from referral income.   This company would have a funded project with a roadmap for BTS and would receive 250,000 BTS per day that their project is in the top list of  projects for 4 years.


I'm not sure I totally understands where the money to pay the 7 core developers will come from without being able to sell anything from their pay for 5 years? The referral program might be able to help funding it, but will it be enough? Will there be VC investment to cover for what's missing?

I think that is the point.  This real world company can accumulate bts, and effectively sell shares in it to an angel/vc.  I am just not sure a VC will be excited about investing in a company that could get voted out at a moments notice.

Here is what I love about this idea:
1. I would much rather hire Bytemaster Co or similar to hire and manage a core dev team than try to vote on a core dev team one at a time.
2. Vesting is great for eliminating dilution sell pressure.
3. I think one team with leadership will be far more efficient long term that many competing delegates

My reservations about the plan:
1. Will VC's find sufficient value to put up good money for a maybe vote.  Although the VC's could commit to a payment schedule and only pay in each month that the project is voted in.   On the good side... It is not my problem.   It is bytemaster Co and his competitors job to solve this problem.  But it is my problem in that I dont want him and others to be set up to fail.
2. Although it eliminates sell pressure, it could be argued that it absorbs buying pressure too.  But I dont think this is particularly valid as that kind of buying pressure (angel/VC) would not be a normal stake holder buyer so it just introduces a new kind of buyer in a cool way.
Host of BitShares.TV and Author of BitShares 101

Offline betax

  • Hero Member
  • *****
  • Posts: 808
    • View Profile
Great.
One more thing - make the budget definable in bitAsset (not only) BTS. Should be easy once a day to calculate how much bts is the required say 2000 bitusd/day.
This.

Plus +5% for finally having workers and signers!!

 +5% +5%
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Great.
One more thing - make the budget definable in bitAsset (not only) BTS. Should be easy once a day to calculate how much bts is the required say 2000 bitusd/day.
This.

Plus +5% for finally having workers and signers!!

zerosum

  • Guest
Great.
One more thing - make the budget definable in bitAsset (not only) BTS. Should be easy once a day to calculate how much bts is the required say 2000 bitusd/day.

Offline Chuckone

  • Sr. Member
  • ****
  • Posts: 314
    • View Profile

We have 7 core developers that need at least $25,000 per month (combined) just to pay for Food, Shelter, and Clothing and earning 1/4 what they could make on the free market.  These 7 core developers form a company that produces a wallet and profits from referral income.   This company would have a funded project with a roadmap for BTS and would receive 250,000 BTS per day that their project is in the top list of  projects for 4 years.


I'm not sure I totally understands where the money to pay the 7 core developers will come from without being able to sell anything from their pay for 5 years? The referral program might be able to help funding it, but will it be enough? Will there be VC investment to cover for what's missing?

Offline bytemaster

There have been many discussions over the past 6 months about having paid workers separate from Delegates as well as changing the maximum income per worker without increasing the dilution limit.   I would like to explore how this might look and see what ideas you all can come up with.

Step 1:   Assume there are at most 432,000 BTS per day available to be paid to workers.  (50 BTS every 10 seconds)
Step 2:   Assume there is a list of projects that specify how much they need paid each day.
Step 3:   Pay out projects in order of total approval once per day until all 432,000 BTS has been consumed.
Step 4:   Have several projects that payout to no one (burning) and thus prevent dilution.

Next define each project in terms of the following parameters:

1) Start Date
2) Fundings to Receive Per Day
3) End Date for Funding
4) Vesting Period for Funds Received

Next give each account the ability to vote *FOR* or *AGAINST* each funding proposal.
Sort all projects by NET votes including the burn projects.
Each projects funding would flow to an account with multi-sig authority (for serious projects that demand accountability).

Under this model I would propose the following project:
We have 7 core developers that need at least $25,000 per month (combined) just to pay for Food, Shelter, and Clothing and earning 1/4 what they could make on the free market.  These 7 core developers form a company that produces a wallet and profits from referral income.   This company would have a funded project with a roadmap for BTS and would receive 250,000 BTS per day that their project is in the top list of  projects for 4 years.   The funds would not vest for 5 years which means the core company would not sell their 250,000 BTS/day for 5 years.    5 years is long enough that the project is either a success and the dilution is insignificant or a complete failure and the shares are worthless anyway.   Either way existing BTS holders benefit from work today that is ultimately paid for in 5 years.  Each year the devs can re-negotiate their project funding and shareholders can vote in new terms as the vote down the old terms. 

At any time this developer company could be fired by giving more votes to a burn proposal or an alternative set of developers.  When they are fired they stop receiving new income but must still wait for 5 years before they can touch any of the BTS they have already earned.   

This would have the core devs consuming about half of the available dilution (3% per year) and allowing the community room to fund other projects with the remaining half of the funds.   

Currently the Core DEVs have about 15 paid delegate slots and their pay vests immediately.   Under this new approach their combined pay would be 3x higher but it wouldn't vest for 5 years.   Perhaps most importantly, this would still keep the number of block producers decentralized and keep the sell pressure caused by dilution at bay.  Additionally it makes it easier for shareholders to vote for one "company" than for individual developers which may come and go without accountability.   

By having VOTES AGAINST a project it becomes easier for stakeholders to vote down projects they explicitly don't want funded in the event of a change in circumstances.

Thoughts? 

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.