BitShares Forum

Main => Stakeholder Proposals => Topic started by: bytemaster on May 03, 2015, 01:35:31 pm

Title: Paid Workers Proposal for Review
Post by: bytemaster on May 03, 2015, 01:35:31 pm
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? 

Title: Re: Paid Workers Proposal for Review
Post by: Chuckone on May 03, 2015, 01:47:39 pm

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?
Title: Re: Paid Workers Proposal for Review
Post by: zerosum on May 03, 2015, 01:48:34 pm
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.
Title: Re: Paid Workers Proposal for Review
Post by: xeroc on May 03, 2015, 02:25:47 pm
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!!
Title: Re: Paid Workers Proposal for Review
Post by: betax on May 03, 2015, 02:33:04 pm
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%
Title: Re: Paid Workers Proposal for Review
Post by: bitmarket on May 03, 2015, 02:39:06 pm

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.
Title: Re: Paid Workers Proposal for Review
Post by: BTSdac on May 03, 2015, 02:43:33 pm
like great ,do we have to vote this by share, only one oppose this can vote negative vote.
Title: Re: Paid Workers Proposal for Review
Post by: Empirical1.2 on May 03, 2015, 02:48:30 pm
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. 



Title: Re: Paid Workers Proposal for Review
Post by: pc on May 03, 2015, 02:49:42 pm
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.

Title: Re: Paid Workers Proposal for Review
Post by: arhag on May 03, 2015, 02:53:14 pm
I've described the paid worker solution that I would like to see in this post (https://bitsharestalk.org/index.php/topic,15627.0.html). 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(?)). 
Title: Re: Paid Workers Proposal for Review
Post by: pc on May 03, 2015, 02:55:10 pm
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. :-) )
Title: Re: Paid Workers Proposal for Review
Post by: BunkerChainLabs-DataSecurityNode on May 03, 2015, 03:22:42 pm

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.
Title: Re: Paid Workers Proposal for Review
Post by: joele on May 03, 2015, 03:32:10 pm
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%
Title: Re: Paid Workers Proposal for Review
Post by: fuzzy on May 03, 2015, 03:49:18 pm
I've described the paid worker solution that I would like to see in this post (https://bitsharestalk.org/index.php/topic,15627.0.html). 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%
Title: Re: Paid Workers Proposal for Review
Post by: zerosum on May 03, 2015, 05:35:51 pm
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. :)

It should be clear but if it is not - the pay is always in BTS anyway. The assets come useful in many cases in answering the question - how many BTS should we pay this 'worker' today?:
- Hire toast @ $100K/y - every day he receives the amount of BTS to achieve that salary. No matter the BTS price.

The point is - why not give this flexibility to workers (and the system as a whole) when it does not cost much to do this calculation?
Title: Re: Paid Workers Proposal for Review
Post by: donkeypong on May 03, 2015, 05:41:43 pm
This is good. I hope it's enough money for the developers. Frankly, voting for all these delegates and understanding their roles in the development team has been tiresome. I'd rather someone else manage this and still leave enough money that we can use to bring in new business.
Title: Re: Paid Workers Proposal for Review
Post by: Geneko on May 03, 2015, 05:50:37 pm
You do not have to reinvent the wheel. Whatever Bishare need is CEO. There are basically two separate issues. One is collecting funds and the other is proper allocation. There are several methods of collecting funds including dilution but only one person should be responsible for spending. That person should be voted in and out.
We need simple solution. One man responsible for the whole project. We only need to vote for him. Everything else is over complicating and overestimating of ability and motivation of single account to participate in evaluating and decision making. Even average Joe accepts his imaginable role, he would be reasoning as described in Parkinson’s Law of Triviality.

http://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality
Title: Re: Paid Workers Proposal for Review
Post by: cube on May 04, 2015, 02:32:19 am
The OP seems like an overly and unnecessary complicated way of addressing delegate pay dilution. It would not address dilution. In fact, it would do more harm than good to bts.

1) "We have 7 core developers that need at least $25,000 per month (combined)"

Not surprisingly, the core devs needs its funding.  The question is what happened to the ags and pts funding for both Bitshares and Vote.  Have they been used up?  If there are fund left, use them instead of diluting the bitshares supply.

Empirical mentioned ""another 365 million BTS to the core development company (12%+ equity) would add to those concerns I think. "
This concern needs to be addressed.

2) "we would receive 250,000 BTS per day"

250k bts out of a total available 432k bts, you are talking about core devs taking 60% of the available 'dilution-to-fund'.  If the core devs are talking such a major part of 'dilution-to-fund', why not take out this "250k bts per day for the next 5 years" from the bts supply and then you manage this fund separately to pay your core developers?

3) "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."

To ask the Core Devs to wait for 5 years before they can use their pay is to ask them to bear too much risk unfairly and unnecessarily.  A core dev who has to keep worrying about his pay (in bts going up or down in price) each day is not good.  He should be concentrating on his work and not the bts-price-of-the-day.

And even if the project struggles and manages to be a success at the end of 5 years, dilution is NEVER insignificant.  At least the impact due to the perception of dilution is ALWAYS significant.

If the shares are worthless at the end of 5 years, the core devs get nothing?

It need not be a case of a either-success-or-failure to the Core Devs or the BTS Investors after a long 5-year.  Both the Core Devs and Investors can manage, minimise and share the risk together.

4) As PC pointed out, this new way will disadvantage small non-core workers greatly.

5) "432k bts/day to spend"
A limit and a cap above is unhelpful.  What if the developments needed more fund?  What if we needed more developers? What if the bts price dropped even further? 

6) "Perhaps most importantly, this would still keep the number of block producers decentralized and keep the sell pressure caused by dilution at bay."

Keeping block producers decentralised is good.  But this will not keep away sell pressure because dilution is there.  What you need is building confidence in both the investors and users that this project will turn out to be successful.

Move whatever fund you need to pay for development out of the supply of bts. Better still, find other funding source and bring bts back to zero or near-zero inflation.



Title: Re: Paid Workers Proposal for Review
Post by: Musewhale on May 04, 2015, 02:38:45 am
 +5% +5% +5%
great, good idea, i like it, just do it.
Title: Re: Paid Workers Proposal for Review
Post by: role on May 04, 2015, 02:41:42 am
 +5% +5%
Title: Re: Paid Workers Proposal for Review
Post by: bitmarket on May 04, 2015, 02:43:55 am
re: centralization.

I had centralization as a concern as well because 12% after 5 years is significant.   However a couple of realizations put my mind at ease.

1. Those bts go to one company that distributes it to many people. So it is not as centralized as first thought.
2. The dilution should be in USD's or gold (one way or another, even if it is the project promising to burn leftover).  getting $25k per month in bts in 3 years will be way less than what we imagine today.

I no longer think centralization is a problem.
Title: Re: Paid Workers Proposal for Review
Post by: crzme on May 04, 2015, 03:33:44 am
SBM
Title: Re: Paid Workers Proposal for Review
Post by: jcrubino on May 04, 2015, 04:12:14 am
I think 3 years is a more equitable term to decide if the business project is viable for the devs and the community.

This is the make or break term for normal businesses and I believe the cryptocoin space might be more accelerated in terms of market validation of product. 
Title: Re: Paid Workers Proposal for Review
Post by: role on May 04, 2015, 04:14:40 am
史诗般的冲刺!你们再也买不到2毛的bts了 :D
Title: Re: Paid Workers Proposal for Review
Post by: freedom on May 04, 2015, 04:18:02 am
法克
Title: Re: Paid Workers Proposal for Review
Post by: liondani on May 04, 2015, 04:50:54 am
Vested for 5 years? Give them more bits salary! Vested for 3 years give them less bts... dynamic salary :P

Sent from my ALCATEL ONE TOUCH 997D

Title: Re: Paid Workers Proposal for Review
Post by: emski on May 04, 2015, 05:16:31 am
Looks like a good idea...
I've always fancied separation of block signers and Paid Workers.
Vesting period on the received funds is a nice touch.
Title: Re: Paid Workers Proposal for Review
Post by: bitmeat on May 04, 2015, 05:59:34 am
This is what I've been preaching for since day one of BitShares. I am absolutely excited about the new direction and all of you should be too!!!

Thank you, BM for making the right calls in these difficult testing times. Some may not feel the same, but I believe this is a major step in the right direction.

I hope this gets voted in.
Title: Re: Paid Workers Proposal for Review
Post by: joele on May 04, 2015, 06:44:46 am
I've described the paid worker solution that I would like to see in this post (https://bitsharestalk.org/index.php/topic,15627.0.html). 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%
Title: Re: Paid Workers Proposal for Review
Post by: luckybit on May 04, 2015, 07:29:31 am
My suggestions based on my previous post here: https://bitsharestalk.org/index.php/topic,1692.msg18720.html#msg18720

How about a bounty exchange platform with an Ask/Bid?

This is essentially a bounty auction and exchange platform. It is completely algorithmic in approach and completely automated. It determines the true market price of any kind of labor by reaching the equilibrium point between the supply and demand through the bid/ask.

It would be centralized at first but could be made decentralized, it's also a way to determine who would be selected for the bounty in a completely automated fashion.

It may even allow workers to trade jobs on the exchange provided they do so before the expiration date. This way if a worker bit off more than he could chew he could exchange his bounty with someone else and they'd get paid in his place if they complete it.

Instructions
As the employer first you'd put up your bidding price which is the highest you're willing to pay, then a bunch of potential bid fillers put up their asking price and according to the algorithm it would meet in the middle according to supply and demand at an equilibrium point. This would give the market the true price of the labor.
Input: Employers enter a job description and bidding price to be displayed as the maximum bounty reward.
Input: Employees/Job hunters enter their asking prices, mapped to their Keyhotee IDs.
DAC: An algorithm selects the employee willing to work for the lowest asking price (lowest bounty reward)
DAC: A bot sends an encrypted message to the public key of the Keyhotee ID address and sends a bounty token to their wallet.
DAC: The transaction and exchange exist entirely in a blockchain so that if necessary anyone with that bounty token can exchange their bounty token for anyone else's.
Output1: The job is completed by the expiration date on the bounty token, and the bounty token is redeemed at the true price of labor in the market.
Output2: The job is not completed by the expiration date and the bounty token is never redeemed, therefore it is invalid and expired.
Social Contract: 50% Protoshares, 45% Angelshares, 5% Promotion, Discount and Giveaway shares

What could go wrong? Someone could lose their bounty token and then the bounty would expire wasting valuable time. On the other hand it would save time if someone can trade their received bounty with another person or split their bounty with another person all in automated fashion by using the divisibility of the bounty token. So if I did 90% of the labor and I could not do that final 10% then I could break off 10% of the bounty token and give it to anyone willing to work for it.

Let me know if this idea could work?


^^^^

The gist of the idea is to create a job auction exchange. Jobs are auctioned on the blockchain. A UIA could represent a job and when the job is done all who have the asset can redeem for BitUSD.

Of course it would have to be simplified due to the limitations of the blockchain but ultimately the market should determine things. Let anyone bid for positions. Let the community for up or down the positions from which could be bid for and let the community set the amount it is willing to pay in some algorithmic fashion so that the jobs are auctioned to the lowest bidder.

http://www.jobauctions.com/

Title: Re: Paid Workers Proposal for Review
Post by: fuzzy on May 04, 2015, 08:17:54 am
My suggestions based on my previous post here: https://bitsharestalk.org/index.php/topic,1692.msg18720.html#msg18720

How about a bounty exchange platform with an Ask/Bid?

This is essentially a bounty auction and exchange platform. It is completely algorithmic in approach and completely automated. It determines the true market price of any kind of labor by reaching the equilibrium point between the supply and demand through the bid/ask.

It would be centralized at first but could be made decentralized, it's also a way to determine who would be selected for the bounty in a completely automated fashion.

It may even allow workers to trade jobs on the exchange provided they do so before the expiration date. This way if a worker bit off more than he could chew he could exchange his bounty with someone else and they'd get paid in his place if they complete it.

Instructions
As the employer first you'd put up your bidding price which is the highest you're willing to pay, then a bunch of potential bid fillers put up their asking price and according to the algorithm it would meet in the middle according to supply and demand at an equilibrium point. This would give the market the true price of the labor.
Input: Employers enter a job description and bidding price to be displayed as the maximum bounty reward.
Input: Employees/Job hunters enter their asking prices, mapped to their Keyhotee IDs.
DAC: An algorithm selects the employee willing to work for the lowest asking price (lowest bounty reward)
DAC: A bot sends an encrypted message to the public key of the Keyhotee ID address and sends a bounty token to their wallet.
DAC: The transaction and exchange exist entirely in a blockchain so that if necessary anyone with that bounty token can exchange their bounty token for anyone else's.
Output1: The job is completed by the expiration date on the bounty token, and the bounty token is redeemed at the true price of labor in the market.
Output2: The job is not completed by the expiration date and the bounty token is never redeemed, therefore it is invalid and expired.
Social Contract: 50% Protoshares, 45% Angelshares, 5% Promotion, Discount and Giveaway shares

What could go wrong? Someone could lose their bounty token and then the bounty would expire wasting valuable time. On the other hand it would save time if someone can trade their received bounty with another person or split their bounty with another person all in automated fashion by using the divisibility of the bounty token. So if I did 90% of the labor and I could not do that final 10% then I could break off 10% of the bounty token and give it to anyone willing to work for it.

Let me know if this idea could work?


^^^^

The gist of the idea is to create a job auction exchange. Jobs are auctioned on the blockchain. A UIA could represent a job and when the job is done all who have the asset can redeem for BitUSD.

Of course it would have to be simplified due to the limitations of the blockchain but ultimately the market should determine things. Let anyone bid for positions. Let the community for up or down the positions from which could be bid for and let the community set the amount it is willing to pay in some algorithmic fashion so that the jobs are auctioned to the lowest bidder.

http://www.jobauctions.com/

I love this idea.
Title: Re: Paid Workers Proposal for Review
Post by: pc on May 04, 2015, 08:28:15 am
How about a bounty exchange platform with an Ask/Bid?

This is essentially a bounty auction and exchange platform. It is completely algorithmic in approach and completely automated. It determines the true market price of any kind of labor by reaching the equilibrium point between the supply and demand through the bid/ask.

It would be centralized at first but could be made decentralized, it's also a way to determine who would be selected for the bounty in a completely automated fashion.

It may even allow workers to trade jobs on the exchange provided they do so before the expiration date. This way if a worker bit off more than he could chew he could exchange his bounty with someone else and they'd get paid in his place if they complete it.

Instructions
As the employer first you'd put up your bidding price which is the highest you're willing to pay, then a bunch of potential bid fillers put up their asking price and according to the algorithm it would meet in the middle according to supply and demand at an equilibrium point. This would give the market the true price of the labor.
Input: Employers enter a job description and bidding price to be displayed as the maximum bounty reward.
Input: Employees/Job hunters enter their asking prices, mapped to their Keyhotee IDs.
DAC: An algorithm selects the employee willing to work for the lowest asking price (lowest bounty reward)
DAC: A bot sends an encrypted message to the public key of the Keyhotee ID address and sends a bounty token to their wallet.
DAC: The transaction and exchange exist entirely in a blockchain so that if necessary anyone with that bounty token can exchange their bounty token for anyone else's.
Output1: The job is completed by the expiration date on the bounty token, and the bounty token is redeemed at the true price of labor in the market.
Output2: The job is not completed by the expiration date and the bounty token is never redeemed, therefore it is invalid and expired.
Social Contract: 50% Protoshares, 45% Angelshares, 5% Promotion, Discount and Giveaway shares

What could go wrong? Someone could lose their bounty token and then the bounty would expire wasting valuable time. On the other hand it would save time if someone can trade their received bounty with another person or split their bounty with another person all in automated fashion by using the divisibility of the bounty token. So if I did 90% of the labor and I could not do that final 10% then I could break off 10% of the bounty token and give it to anyone willing to work for it.

Let me know if this idea could work?


^^^^

The gist of the idea is to create a job auction exchange. Jobs are auctioned on the blockchain. A UIA could represent a job and when the job is done all who have the asset can redeem for BitUSD.

Of course it would have to be simplified due to the limitations of the blockchain but ultimately the market should determine things. Let anyone bid for positions. Let the community for up or down the positions from which could be bid for and let the community set the amount it is willing to pay in some algorithmic fashion so that the jobs are auctioned to the lowest bidder.

http://www.jobauctions.com/

IMO an automated DAC is unsuitable for matching workers and jobs, because for an employer the price is only one of many criteria for selecting an employee. An employer may want to hand over a job to a more skilled/experienced worker even if he has to pay a higher price.

You proposal is missing a crucial component: who gets to decide when/if a job has been completed? You're going to need arbitrators in case of a dispute.

Also, managing such a platform creates a massive overhead for the employers and may be unsuitable for small tasks.
Title: Re: Paid Workers Proposal for Review
Post by: luckybit on May 04, 2015, 08:34:44 am
How about a bounty exchange platform with an Ask/Bid?

This is essentially a bounty auction and exchange platform. It is completely algorithmic in approach and completely automated. It determines the true market price of any kind of labor by reaching the equilibrium point between the supply and demand through the bid/ask.

It would be centralized at first but could be made decentralized, it's also a way to determine who would be selected for the bounty in a completely automated fashion.

It may even allow workers to trade jobs on the exchange provided they do so before the expiration date. This way if a worker bit off more than he could chew he could exchange his bounty with someone else and they'd get paid in his place if they complete it.

Instructions
As the employer first you'd put up your bidding price which is the highest you're willing to pay, then a bunch of potential bid fillers put up their asking price and according to the algorithm it would meet in the middle according to supply and demand at an equilibrium point. This would give the market the true price of the labor.
Input: Employers enter a job description and bidding price to be displayed as the maximum bounty reward.
Input: Employees/Job hunters enter their asking prices, mapped to their Keyhotee IDs.
DAC: An algorithm selects the employee willing to work for the lowest asking price (lowest bounty reward)
DAC: A bot sends an encrypted message to the public key of the Keyhotee ID address and sends a bounty token to their wallet.
DAC: The transaction and exchange exist entirely in a blockchain so that if necessary anyone with that bounty token can exchange their bounty token for anyone else's.
Output1: The job is completed by the expiration date on the bounty token, and the bounty token is redeemed at the true price of labor in the market.
Output2: The job is not completed by the expiration date and the bounty token is never redeemed, therefore it is invalid and expired.
Social Contract: 50% Protoshares, 45% Angelshares, 5% Promotion, Discount and Giveaway shares

What could go wrong? Someone could lose their bounty token and then the bounty would expire wasting valuable time. On the other hand it would save time if someone can trade their received bounty with another person or split their bounty with another person all in automated fashion by using the divisibility of the bounty token. So if I did 90% of the labor and I could not do that final 10% then I could break off 10% of the bounty token and give it to anyone willing to work for it.

Let me know if this idea could work?


^^^^

The gist of the idea is to create a job auction exchange. Jobs are auctioned on the blockchain. A UIA could represent a job and when the job is done all who have the asset can redeem for BitUSD.

Of course it would have to be simplified due to the limitations of the blockchain but ultimately the market should determine things. Let anyone bid for positions. Let the community for up or down the positions from which could be bid for and let the community set the amount it is willing to pay in some algorithmic fashion so that the jobs are auctioned to the lowest bidder.

http://www.jobauctions.com/

IMO an automated DAC is unsuitable for matching workers and jobs, because for an employer the price is only one of many criteria for selecting an employee. An employer may want to hand over a job to a more skilled/experienced worker even if he has to pay a higher price.

You proposal is missing a crucial component: who gets to decide when/if a job has been completed? You're going to need arbitrators in case of a dispute.

Also, managing such a platform creates a massive overhead for the employers and may be unsuitable for small tasks.
http://www.jobauctions.com/
Title: Re: Paid Workers Proposal for Review
Post by: fuzzy on May 04, 2015, 08:58:04 am
How about a bounty exchange platform with an Ask/Bid?

This is essentially a bounty auction and exchange platform. It is completely algorithmic in approach and completely automated. It determines the true market price of any kind of labor by reaching the equilibrium point between the supply and demand through the bid/ask.

It would be centralized at first but could be made decentralized, it's also a way to determine who would be selected for the bounty in a completely automated fashion.

It may even allow workers to trade jobs on the exchange provided they do so before the expiration date. This way if a worker bit off more than he could chew he could exchange his bounty with someone else and they'd get paid in his place if they complete it.

Instructions
As the employer first you'd put up your bidding price which is the highest you're willing to pay, then a bunch of potential bid fillers put up their asking price and according to the algorithm it would meet in the middle according to supply and demand at an equilibrium point. This would give the market the true price of the labor.
Input: Employers enter a job description and bidding price to be displayed as the maximum bounty reward.
Input: Employees/Job hunters enter their asking prices, mapped to their Keyhotee IDs.
DAC: An algorithm selects the employee willing to work for the lowest asking price (lowest bounty reward)
DAC: A bot sends an encrypted message to the public key of the Keyhotee ID address and sends a bounty token to their wallet.
DAC: The transaction and exchange exist entirely in a blockchain so that if necessary anyone with that bounty token can exchange their bounty token for anyone else's.
Output1: The job is completed by the expiration date on the bounty token, and the bounty token is redeemed at the true price of labor in the market.
Output2: The job is not completed by the expiration date and the bounty token is never redeemed, therefore it is invalid and expired.
Social Contract: 50% Protoshares, 45% Angelshares, 5% Promotion, Discount and Giveaway shares

What could go wrong? Someone could lose their bounty token and then the bounty would expire wasting valuable time. On the other hand it would save time if someone can trade their received bounty with another person or split their bounty with another person all in automated fashion by using the divisibility of the bounty token. So if I did 90% of the labor and I could not do that final 10% then I could break off 10% of the bounty token and give it to anyone willing to work for it.

Let me know if this idea could work?


^^^^

The gist of the idea is to create a job auction exchange. Jobs are auctioned on the blockchain. A UIA could represent a job and when the job is done all who have the asset can redeem for BitUSD.

Of course it would have to be simplified due to the limitations of the blockchain but ultimately the market should determine things. Let anyone bid for positions. Let the community for up or down the positions from which could be bid for and let the community set the amount it is willing to pay in some algorithmic fashion so that the jobs are auctioned to the lowest bidder.

http://www.jobauctions.com/

IMO an automated DAC is unsuitable for matching workers and jobs, because for an employer the price is only one of many criteria for selecting an employee. An employer may want to hand over a job to a more skilled/experienced worker even if he has to pay a higher price.

You proposal is missing a crucial component: who gets to decide when/if a job has been completed? You're going to need arbitrators in case of a dispute.

Also, managing such a platform creates a massive overhead for the employers and may be unsuitable for small tasks.
http://www.jobauctions.com/

Wouldn't a reputation system help with all the problems you are talking about PC?
Title: Re: Paid Workers Proposal for Review
Post by: cass on May 04, 2015, 09:53:52 am
How about a bounty exchange platform with an Ask/Bid?

This is essentially a bounty auction and exchange platform. It is completely algorithmic in approach and completely automated. It determines the true market price of any kind of labor by reaching the equilibrium point between the supply and demand through the bid/ask.

It would be centralized at first but could be made decentralized, it's also a way to determine who would be selected for the bounty in a completely automated fashion.

It may even allow workers to trade jobs on the exchange provided they do so before the expiration date. This way if a worker bit off more than he could chew he could exchange his bounty with someone else and they'd get paid in his place if they complete it.

Instructions
As the employer first you'd put up your bidding price which is the highest you're willing to pay, then a bunch of potential bid fillers put up their asking price and according to the algorithm it would meet in the middle according to supply and demand at an equilibrium point. This would give the market the true price of the labor.
Input: Employers enter a job description and bidding price to be displayed as the maximum bounty reward.
Input: Employees/Job hunters enter their asking prices, mapped to their Keyhotee IDs.
DAC: An algorithm selects the employee willing to work for the lowest asking price (lowest bounty reward)
DAC: A bot sends an encrypted message to the public key of the Keyhotee ID address and sends a bounty token to their wallet.
DAC: The transaction and exchange exist entirely in a blockchain so that if necessary anyone with that bounty token can exchange their bounty token for anyone else's.
Output1: The job is completed by the expiration date on the bounty token, and the bounty token is redeemed at the true price of labor in the market.
Output2: The job is not completed by the expiration date and the bounty token is never redeemed, therefore it is invalid and expired.
Social Contract: 50% Protoshares, 45% Angelshares, 5% Promotion, Discount and Giveaway shares

What could go wrong? Someone could lose their bounty token and then the bounty would expire wasting valuable time. On the other hand it would save time if someone can trade their received bounty with another person or split their bounty with another person all in automated fashion by using the divisibility of the bounty token. So if I did 90% of the labor and I could not do that final 10% then I could break off 10% of the bounty token and give it to anyone willing to work for it.

Let me know if this idea could work?


^^^^

The gist of the idea is to create a job auction exchange. Jobs are auctioned on the blockchain. A UIA could represent a job and when the job is done all who have the asset can redeem for BitUSD.

Of course it would have to be simplified due to the limitations of the blockchain but ultimately the market should determine things. Let anyone bid for positions. Let the community for up or down the positions from which could be bid for and let the community set the amount it is willing to pay in some algorithmic fashion so that the jobs are auctioned to the lowest bidder.

http://www.jobauctions.com/

IMO an automated DAC is unsuitable for matching workers and jobs, because for an employer the price is only one of many criteria for selecting an employee. An employer may want to hand over a job to a more skilled/experienced worker even if he has to pay a higher price.

You proposal is missing a crucial component: who gets to decide when/if a job has been completed? You're going to need arbitrators in case of a dispute.

Also, managing such a platform creates a massive overhead for the employers and may be unsuitable for small tasks.
http://www.jobauctions.com/

Wouldn't a reputation system help with all the problems you are talking about PC?

i intend ot agree PC!

Who will decide, for example, on graphic related tasks, if an design is finished in view of requirements, graphic style, sustainability?
On technical side requirements are much more clearer to communicate ... but for esthetic etc. purposes ... who will decide if a job task is solved?
(used the designer example ... you know why^^)
Title: Re: Paid Workers Proposal for Review
Post by: fuzzy on May 04, 2015, 09:55:07 am
How about a bounty exchange platform with an Ask/Bid?

This is essentially a bounty auction and exchange platform. It is completely algorithmic in approach and completely automated. It determines the true market price of any kind of labor by reaching the equilibrium point between the supply and demand through the bid/ask.

It would be centralized at first but could be made decentralized, it's also a way to determine who would be selected for the bounty in a completely automated fashion.

It may even allow workers to trade jobs on the exchange provided they do so before the expiration date. This way if a worker bit off more than he could chew he could exchange his bounty with someone else and they'd get paid in his place if they complete it.

Instructions
As the employer first you'd put up your bidding price which is the highest you're willing to pay, then a bunch of potential bid fillers put up their asking price and according to the algorithm it would meet in the middle according to supply and demand at an equilibrium point. This would give the market the true price of the labor.
Input: Employers enter a job description and bidding price to be displayed as the maximum bounty reward.
Input: Employees/Job hunters enter their asking prices, mapped to their Keyhotee IDs.
DAC: An algorithm selects the employee willing to work for the lowest asking price (lowest bounty reward)
DAC: A bot sends an encrypted message to the public key of the Keyhotee ID address and sends a bounty token to their wallet.
DAC: The transaction and exchange exist entirely in a blockchain so that if necessary anyone with that bounty token can exchange their bounty token for anyone else's.
Output1: The job is completed by the expiration date on the bounty token, and the bounty token is redeemed at the true price of labor in the market.
Output2: The job is not completed by the expiration date and the bounty token is never redeemed, therefore it is invalid and expired.
Social Contract: 50% Protoshares, 45% Angelshares, 5% Promotion, Discount and Giveaway shares

What could go wrong? Someone could lose their bounty token and then the bounty would expire wasting valuable time. On the other hand it would save time if someone can trade their received bounty with another person or split their bounty with another person all in automated fashion by using the divisibility of the bounty token. So if I did 90% of the labor and I could not do that final 10% then I could break off 10% of the bounty token and give it to anyone willing to work for it.

Let me know if this idea could work?


^^^^

The gist of the idea is to create a job auction exchange. Jobs are auctioned on the blockchain. A UIA could represent a job and when the job is done all who have the asset can redeem for BitUSD.

Of course it would have to be simplified due to the limitations of the blockchain but ultimately the market should determine things. Let anyone bid for positions. Let the community for up or down the positions from which could be bid for and let the community set the amount it is willing to pay in some algorithmic fashion so that the jobs are auctioned to the lowest bidder.

http://www.jobauctions.com/

IMO an automated DAC is unsuitable for matching workers and jobs, because for an employer the price is only one of many criteria for selecting an employee. An employer may want to hand over a job to a more skilled/experienced worker even if he has to pay a higher price.

You proposal is missing a crucial component: who gets to decide when/if a job has been completed? You're going to need arbitrators in case of a dispute.

Also, managing such a platform creates a massive overhead for the employers and may be unsuitable for small tasks.
http://www.jobauctions.com/

Wouldn't a reputation system help with all the problems you are talking about PC?

i intend ot agree PC!

Who will decide, for example, on graphic related tasks, if an design is finished in view of requirements, graphic style, sustainability?
On technical side requirements are much more clearer to communicate ... but for esthetic etc. purposes ... who will decide if a job task is solved?
(used the designer example ... you know why^^)

Couldn't delegates decide on this? 
Title: Re: Paid Workers Proposal for Review
Post by: oldman on May 04, 2015, 02:18:51 pm
I like the idea; Cube brings up some valid concerns. But overall,  +5%
Title: Re: Paid Workers Proposal for Review
Post by: pc on May 04, 2015, 04:28:37 pm
Who will decide, for example, on graphic related tasks, if an design is finished in view of requirements, graphic style, sustainability?
On technical side requirements are much more clearer to communicate ... but for esthetic etc. purposes ... who will decide if a job task is solved?
(used the designer example ... you know why^^)

Couldn't delegates decide on this?

I think nobody wants to have certain delegates (like me) make decisions concerning graphic style. ;-)
Title: Re: Paid Workers Proposal for Review
Post by: ripplexiaoshan on May 04, 2015, 05:08:50 pm
Why not selling the diluted BTS shares to VC to get fund to pay for core developers?  The whole voting system is not very functional, because most of the vested shares go to exchange, who do not vote for anybody. Thus I doubt the voting mechanism will work for the case in your proposal. Bitshares will end up dead if there is no new fund.
Title: Re: Paid Workers Proposal for Review
Post by: Harvey on May 04, 2015, 05:52:09 pm
Personally, I would like to see the Core DEVs get additional 30 paid delegates rather than changing the allocation rule again. 
Title: Re: Paid Workers Proposal for Review
Post by: pc on May 04, 2015, 06:36:04 pm
Personally, I would like to see the Core DEVs get additional 30 paid delegates rather than changing the allocation rule again.
+1 (and to be clear here: those 30 or whatever should go to the *core* team in blacksburg)
Title: Re: Paid Workers Proposal for Review
Post by: xeroc on May 04, 2015, 06:57:26 pm
Personally, I would like to see the Core DEVs get additional 30 paid delegates rather than changing the allocation rule again.
+1 (and to be clear here: those 30 or whatever should go to the *core* team in blacksburg)
I would have no problem with that ..
but i see advantages is separating block signers from feed publishes and businesses ... can we have both? .. maybe after 1.0 ..
Title: Re: Paid Workers Proposal for Review
Post by: cube on May 04, 2015, 07:16:13 pm
Personally, I would like to see the Core DEVs get additional 30 paid delegates rather than changing the allocation rule again.
+1 (and to be clear here: those 30 or whatever should go to the *core* team in blacksburg)
I would have no problem with that ..
but i see advantages is separating block signers from feed publishes and businesses ... can we have both? .. maybe after 1.0 ..

Yes. I think this is the most logical path.  Even though the Chinese has rejected getting a second delegate for Cass when the bts price dropped some time back, I believe they are more open to a dev having more delegates voted in now.  Dilution should be handled separately eg via a VC fund injection.  Recall BM mentioned a VC is interested in bitshares.
Title: Re: Paid Workers Proposal for Review
Post by: Ander on May 04, 2015, 09:05:02 pm
I would like to ask: What is the big problem with the current system which requires this change?
Why does this change need to be prioritized now, when we are desperate for things like a stable client?

I think we should avoid creating a huge overhand of vesting BTS which people know will be unlocked at some point in the future.  This could make people think "Well, if I invest in BTS now, I'm going to get dumped on in the future as soon as those shares become unlocked".
Title: Re: Paid Workers Proposal for Review
Post by: luckybit on May 04, 2015, 09:35:09 pm
How about a bounty exchange platform with an Ask/Bid?

This is essentially a bounty auction and exchange platform. It is completely algorithmic in approach and completely automated. It determines the true market price of any kind of labor by reaching the equilibrium point between the supply and demand through the bid/ask.

It would be centralized at first but could be made decentralized, it's also a way to determine who would be selected for the bounty in a completely automated fashion.

It may even allow workers to trade jobs on the exchange provided they do so before the expiration date. This way if a worker bit off more than he could chew he could exchange his bounty with someone else and they'd get paid in his place if they complete it.

Instructions
As the employer first you'd put up your bidding price which is the highest you're willing to pay, then a bunch of potential bid fillers put up their asking price and according to the algorithm it would meet in the middle according to supply and demand at an equilibrium point. This would give the market the true price of the labor.
Input: Employers enter a job description and bidding price to be displayed as the maximum bounty reward.
Input: Employees/Job hunters enter their asking prices, mapped to their Keyhotee IDs.
DAC: An algorithm selects the employee willing to work for the lowest asking price (lowest bounty reward)
DAC: A bot sends an encrypted message to the public key of the Keyhotee ID address and sends a bounty token to their wallet.
DAC: The transaction and exchange exist entirely in a blockchain so that if necessary anyone with that bounty token can exchange their bounty token for anyone else's.
Output1: The job is completed by the expiration date on the bounty token, and the bounty token is redeemed at the true price of labor in the market.
Output2: The job is not completed by the expiration date and the bounty token is never redeemed, therefore it is invalid and expired.
Social Contract: 50% Protoshares, 45% Angelshares, 5% Promotion, Discount and Giveaway shares

What could go wrong? Someone could lose their bounty token and then the bounty would expire wasting valuable time. On the other hand it would save time if someone can trade their received bounty with another person or split their bounty with another person all in automated fashion by using the divisibility of the bounty token. So if I did 90% of the labor and I could not do that final 10% then I could break off 10% of the bounty token and give it to anyone willing to work for it.

Let me know if this idea could work?


^^^^

The gist of the idea is to create a job auction exchange. Jobs are auctioned on the blockchain. A UIA could represent a job and when the job is done all who have the asset can redeem for BitUSD.

Of course it would have to be simplified due to the limitations of the blockchain but ultimately the market should determine things. Let anyone bid for positions. Let the community for up or down the positions from which could be bid for and let the community set the amount it is willing to pay in some algorithmic fashion so that the jobs are auctioned to the lowest bidder.

http://www.jobauctions.com/

IMO an automated DAC is unsuitable for matching workers and jobs, because for an employer the price is only one of many criteria for selecting an employee. An employer may want to hand over a job to a more skilled/experienced worker even if he has to pay a higher price.

You proposal is missing a crucial component: who gets to decide when/if a job has been completed? You're going to need arbitrators in case of a dispute.

Also, managing such a platform creates a massive overhead for the employers and may be unsuitable for small tasks.
http://www.jobauctions.com/

Wouldn't a reputation system help with all the problems you are talking about PC?

i intend ot agree PC!

Who will decide, for example, on graphic related tasks, if an design is finished in view of requirements, graphic style, sustainability?
On technical side requirements are much more clearer to communicate ... but for esthetic etc. purposes ... who will decide if a job task is solved?
(used the designer example ... you know why^^)

Collaborative filtering could decide. Vote up or down until a threshold is reached and pay is doled out.
Title: Re: Paid Workers Proposal for Review
Post by: Stan on May 04, 2015, 09:47:22 pm
I would like to ask: What is the big problem with the current system which requires this change?
Why does this change need to be prioritized now, when we are desperate for things like a stable client?

I think we should avoid creating a huge overhand of vesting BTS which people know will be unlocked at some point in the future.  This could make people think "Well, if I invest in BTS now, I'm going to get dumped on in the future as soon as those shares become unlocked".
We have an integrated solution to 17 different issues.  Relax.

There is no problem except perception.  This particular new tool addresses the mere worry that a couple percent of dilution is somehow responsible for the current depression.

You are not getting married.  If this idea gets proposed and approved and remains unrevoked, you can  enjoy the work of the devs for four years and then Sell if you think the company that brought you all this is going to dump it all in year five.   :)
Title: Re: Paid Workers Proposal for Review
Post by: Ander on May 04, 2015, 09:55:51 pm
There is no problem except perception.  This particular new tool addresses the mere worry that a couple percent of dilution is somehow responsible for the current depression.

I dont think that a couple percent of dilution is responsible for the current depression.  I think more people worry about the fact that things change constantly, and that the stable client is still not released.

I worry about changing things yet again, without a very clear benefit.  What makes the new plan massively superior to the current paid delegates, that means we should direct development efforts towards this change right now, when there are also other critical features and fixes that need to be worked on?


Quote
You are not getting married.  If this idea gets proposed and approved and remains unrevoked, you can  enjoy the work of the devs for four years and then Sell if you think the company that brought you all this is going to dump it all in year five.   :)

I don't think the devs are all go to dump in year 5, and I dont want to sell (unless the price is waaaaay higher).  But I want to avoid a scenario where traders have the idea "we all better race to dump prior to these vesting shares being unlocked".  But I guess that is a problem for another time.
Title: Re: Paid Workers Proposal for Review
Post by: fuzzy on May 04, 2015, 09:57:44 pm
Who will decide, for example, on graphic related tasks, if an design is finished in view of requirements, graphic style, sustainability?
On technical side requirements are much more clearer to communicate ... but for esthetic etc. purposes ... who will decide if a job task is solved?
(used the designer example ... you know why^^)

Couldn't delegates decide on this?

I think nobody wants to have certain delegates (like me) make decisions concerning graphic style. ;-)

That is why a delegate like yourself would likely heavily consider the opinions of the community at large, and then also consider the thoughts of a delegate like cass. Right?
Title: Re: Paid Workers Proposal for Review
Post by: Permie on May 04, 2015, 09:58:44 pm
My suggestions based on my previous post here: https://bitsharestalk.org/index.php/topic,1692.msg18720.html#msg18720

How about a bounty exchange platform with an Ask/Bid?

This is essentially a bounty auction and exchange platform. It is completely algorithmic in approach and completely automated. It determines the true market price of any kind of labor by reaching the equilibrium point between the supply and demand through the bid/ask.

It would be centralized at first but could be made decentralized, it's also a way to determine who would be selected for the bounty in a completely automated fashion.

It may even allow workers to trade jobs on the exchange provided they do so before the expiration date. This way if a worker bit off more than he could chew he could exchange his bounty with someone else and they'd get paid in his place if they complete it.

Instructions
As the employer first you'd put up your bidding price which is the highest you're willing to pay, then a bunch of potential bid fillers put up their asking price and according to the algorithm it would meet in the middle according to supply and demand at an equilibrium point. This would give the market the true price of the labor.
Input: Employers enter a job description and bidding price to be displayed as the maximum bounty reward.
Input: Employees/Job hunters enter their asking prices, mapped to their Keyhotee IDs.
DAC: An algorithm selects the employee willing to work for the lowest asking price (lowest bounty reward)
DAC: A bot sends an encrypted message to the public key of the Keyhotee ID address and sends a bounty token to their wallet.
DAC: The transaction and exchange exist entirely in a blockchain so that if necessary anyone with that bounty token can exchange their bounty token for anyone else's.
Output1: The job is completed by the expiration date on the bounty token, and the bounty token is redeemed at the true price of labor in the market.
Output2: The job is not completed by the expiration date and the bounty token is never redeemed, therefore it is invalid and expired.
Social Contract: 50% Protoshares, 45% Angelshares, 5% Promotion, Discount and Giveaway shares

What could go wrong? Someone could lose their bounty token and then the bounty would expire wasting valuable time. On the other hand it would save time if someone can trade their received bounty with another person or split their bounty with another person all in automated fashion by using the divisibility of the bounty token. So if I did 90% of the labor and I could not do that final 10% then I could break off 10% of the bounty token and give it to anyone willing to work for it.

Let me know if this idea could work?


^^^^

The gist of the idea is to create a job auction exchange. Jobs are auctioned on the blockchain. A UIA could represent a job and when the job is done all who have the asset can redeem for BitUSD.

Of course it would have to be simplified due to the limitations of the blockchain but ultimately the market should determine things. Let anyone bid for positions. Let the community for up or down the positions from which could be bid for and let the community set the amount it is willing to pay in some algorithmic fashion so that the jobs are auctioned to the lowest bidder.

http://www.jobauctions.com/

After reading this fantastic idea I came up with my own proposal for how this could work.

TL;DR:
Separation of community/company maintenance (Delegates) and core development.
Delegates compete to act as maintainers of the blockchain and as the human element to DAC decision making.
Core development could be funded by contracts between the shareholders and developers.
Devs propose development and a pay schedule. Shareholders pay into proposal-specific funds as they see fit and development starts once a given pledge-threshold is met.
These proposals are contracts to complete a given task within a stated timeframe for a price acceptable to the shareholders.


Here is a hypothetical scenario I hope will illustrate how this could work.

I unlock my BitShares wallet and see that I have 500 cds (core-dev-shares) and navigate to the 'Development Proposals' tab. 1 cds = 1 bts but can only be spent per the terms of a core development contract.
I see that Invictus Innovations has a proposal for bitAssets 2.0. The team claim it will take 2 months and are asking for 200k bts and $2k bitUSD upfront with a 5M bts completion-'bounty'. Of this 5M bts, 2.5M will be held in escrow for 1 year and 2.5M will be converted to bitUSD on a weekly basis from the start of development until depleted. The team promises to provide proof of progress to
the community and expects Delegates to scrutinise the details.
Underneath this proposal I see that two delegates I trust (delegate.kencode and fuzzy.beyondbitcoin) have evaluated the proposal and interviewed Invictus Innovations and conclude that they think it is a proposal worthy of investment. Fuzzy has provided an .mp3 file to his 'town hall' interview and kencode has convinced me that the economic reasoning holds up.
I am now a reassured and confident shareholder so pledge 60% of my 500 cds to this proposal.
I see Moonstone is nearly funded so I send another 20% there.
But I also notice that ByteMaster has another great proposal but doesn't have the time to implement it right now. It's a minor feature not worth the time yet. He has requested an exorbitant fee to prioritise this work over his spare time but I'm sure he expects someone else to pitch for a much lower cost.
I see underneath that 'script.kiddie' has already offered to whip up the code for just $500 bitUSD with a 5k bts royalty fee to be paid to bytemaster. I pledge some more of my 500 cds and see it is instantly converted to bitUSD at market price.

A month later I come back to my wallet to check my cds balance. Script.kiddie has the new feature running smoothly but I see that another project he proposed didn't get funded within the time-window and the 50 cds that I pledged has been refunded to me to allocate to other projects.


I think that trying to merge the two distinct 'departments' of core development and efficient company maintenance stifles innovation and diversity in both departments.
Delegates should get paid for being delegates and core development teams should pitch and get paid solely for contracted tasks completed.

In order to ensure max decentralization of our DAC the shareholders need to actively participate in all aspects of the DAC.
As we are all humans with short attention spans these decisions need to be spoon-fed to us. The easier it is to participate, the more shareholders we get to take part.
If anything is complicated or hard to evaluate, participation will drop off sharply.

Groups of humans are known for witch hunts so we should make sure that when these happen they do not spill over into unrelated areas of the DAC.
For example; if a mob gets stirred up to oust a delegate providing a slow price feed then we need to be certain that there won't be any collateral damage. So delegates cannot also be responsible for funding core development.

Taulant and Moonstone have stated that they aim to demonstrate their worth by taking on risk and offering the shareholders the opportunity to invest by buying their product (their code) and having them open-source it. Could core devs take a similar approach?

Data and necessary info needs to be compiled by the DAC for presentation to the shareholders so they can make informed decisions.

Delegates need to be easily evaluated with a quick look at a list of statistics. Delegate pay should pay for the efficient running of delegate tasks only.
Core development needs to be pitched to the shareholders in a modular fashion and opened up to the free market – I propose by way of a crowd sale system.
Dev teams need to show their goals and code needs to be written in a way that allows numerous parties to add to the codebase over time. A clear list of tasks to be completed allows separate dev teams to pitch separate projects. The shareholders can then fund development as quickly or as gradually as they wish. Projects won't overlap so less time is wasted, and potential dev teams know that they will get paid for the work they do.

Shareholders who are delegates could also pitch for core development tasks if they are so inclined but shareholders need to be able to quickly see who is doing the job for which they are specifically being paid for.

For delegates this should mean that shareholders can view a list of hard stats that accurately tell them who is performing well and who isn't.
These stats include:
1) Uptime
2) Block propagation
3) Average time per price feed (possibly broken down per asset – this could be displayed next to a measure of volatility of the specified asset for a fair assessment.)
4) Other clear cut and useful stats.
5) A percentage of how many successfully funded core-dev proposals the delegate reviewed and advised on.
Delegates should also be responsible for being oracles on contracts between the shareholders/DAC and core development teams. They are the human element of the DAC so should evaluate the viability of core development proposals and also check-in on project progress.  Delegates would have no authority to stop shareholders funding unrealistic proposals but should use their reputation to serve the shareholders in an advisory capacity.


Instead of funding core dev with dilution, those block rewards could be sent proportionally to each account by their holdings. The funds could be held in some kind of multisig account that allows them to only be spent by contributing to core dev project proposal crowd sales.

Proposals for core development could be published in a separate section of the core wallet in a way that acts to 'crowd sale' the proposed project.
It costs a nominal fee to publish these ideas to avoid bloat and make it easier for shareholders to assess less options. These proposals are contracts to complete a given task within a stated timeframe for a price acceptable to the shareholders.

Core Dev Proposals contain:
1) A summary of the problems aiming to be solved, what the finished product will look like/do and why/how it will work
2) a timeline
3) A fee structure. Perhaps an upfront fee and a recurring payment schedule or an on-completion bounty.
4) Proposals can also be published with the expectation that someone other than the author will bid to actually compete the task.  Devs who wish the implement someone else's idea can include a royalty payment in their proposal. 'Fund us and we'll pay 10kbts to the author as a royalty.'
This 'royalty' is voluntary but encourages 'ideas people' to promote their ideas to establish themselves in the community to increase the likelihood they'll get a royalty and as a consequence more people hear about the best proposals.
The author of a proposal may also be a large stakeholder with lots of funds to pledge to a developer team to implement their idea, so devs may want to attract this 'VC money' and so offer a symbolic/generous royalty.

The party can then pitch themselves to the shareholders on why they should get this contract. For example:

'We propose to implement BM's proposal for bitAssets 2.0. Upfront we require: 10k bts, £2k bitUSD, 5M bts to be held in escrow until completion except each month 0.5 bitGold is paid out from the fund.'

These proposals accomplish:
1) Separation of DAC maintenance and DAC development
2) Open-sourcing of ideas for core development. If a proposal contains a good idea but asks for too much funding, other parties are able to promise the same project for an alternative payment schedule.
3) A direct relationship between the shareholders and core development incorporated into the DAC itself.
Title: Re: Paid Workers Proposal for Review
Post by: Ander on May 04, 2015, 10:19:17 pm
My counterproposal:

* Instead of spending time on this, spend time on getting bitAssets 2.0 finalized and coded, and getting stable client released fairly soon. 

* As a result of 1.0 release and improved bitassets which ahve better convertability and don't punish shorts, BTS price hopefully rebounds.  Developer pay goes back towards what we would like it to be.  If BTS price doesnt rebound, developers create more paid delegates, and the community can vote them in to keep devs fed.

* Later on, now that the critical and immediate needs of Bitshares are completed, if we feel that separating workers from block producers is important, put time into working on this.  But even then, it is competing against other features that would be nice, such as the bond market, prediction market, voting on proposals, smart contracts, etc.


If the plan in the original post in this thread is better than my plan, or is critical right now for some reason, please explain why.  I am very open to hearing this, and am not going to claim that I am definitely right or anything like that.  After all, the core team is MUCH better informed about what is going on in bitshares than I am, and they know everything going on behind the scenes, and I don't. 

What makes it so that we NEED to prioritize work on this change right now?  Is this the biggest thing for us to work on right now?  Is it worth pivoting in this way, given the perception that we already pivot too much, and that we are also already pivoting on bitAssets (which is necessary). 


I would like to see a Bitshares that doesnt just pivot, pivot, pivot, over and over.  But sticks with working things and gives them time to work.  We learned that bitassets had a problem and we needed to fix that, which is important, and justifies the pivot there.  What requires the pivot here, at this point in the development?  If the devs need more compensaiton, which is justified imo given that the price declined so much, isnt the easy answer of 'devs create more delegates and we vote them in' a much better solution?  One which requires no development time because it doesnt change bitshares in any way?


I would really like to see a stable 1.0 release which fixes problems people are having with the client as soon as possible.  Other things should not be being prioritized over this unless they are essential.

Thanks!
Title: Re: Paid Workers Proposal for Review
Post by: bytemaster on May 04, 2015, 10:22:45 pm
My counterproposal:

* Instead of spending time on this, spend time on getting bitAssets 2.0 finalized and coded, and getting stable client released fairly soon. 

* As a result of 1.0 release and improved bitassets which ahve better convertability and don't punish shorts, BTS price hopefully rebounds.  Developer pay goes back towards what we would like it to be.  If BTS price doesnt rebound, developers create more paid delegates, and the community can vote them in to keep devs fed.

* Later on, now that the critical and immediate needs of Bitshares are completed, if we feel that separating workers from block producers is important, put time into working on this.  But even then, it is competing against other features that would be nice, such as the bond market, prediction market, voting on proposals, smart contracts, etc.


If the plan in the original post in this thread is better than my plan, or is critical right now for some reason, please explain why.  I am very open to hearing this, and am not going to claim that I am definitely right or anything like that.  After all, the core team is MUCH better informed about what is going on in bitshares than I am, and they know everything going on behind the scenes, and I don't. 

What makes it so that we NEED to prioritize work on this change right now?  Is this the biggest thing for us to work on right now?  Is it worth pivoting in this way, given the perception that we already pivot too much, and that we are also already pivoting on bitAssets (which is necessary). 


I would like to see a Bitshares that doesnt just pivot, pivot, pivot, over and over.  But sticks with working things and gives them time to work.  We learned that bitassets had a problem and we needed to fix that, which is important, and justifies the pivot there.  What requires the pivot here, at this point in the development?  If the devs need more compensaiton, which is justified imo given that the price declined so much, isnt the easy answer of 'devs create more delegates and we vote them in' a much better solution?  One which requires no development time because it doesnt change bitshares in any way?


I would really like to see a stable 1.0 release which fixes problems people are having with the client as soon as possible.  Other things should not be being prioritized over this unless they are essential.

Thanks!

Relax.  We are working on a stable "1.0" that you will be thrilled about.  The full set of features / documentation / etc will be well defined and released in about a month. 
Title: Re: Paid Workers Proposal for Review
Post by: Ander on May 04, 2015, 10:28:26 pm
Relax.  We are working on a stable "1.0" that you will be thrilled about.  The full set of features / documentation / etc will be well defined and released in about a month.

This is excellent, and if the plan is "we will release stable '1.0' first, and this is something we will work on afterwards", then that sounds better.  I just want to make sure we have good priorities, and release critical fixes and stability before we go changing things too much. :)
Title: Re: Paid Workers Proposal for Review
Post by: Permie on May 04, 2015, 10:32:41 pm
Quote
Ander: I would really like to see a stable 1.0 release which fixes problems people are having with the client as soon as possible.  Other things should not be being prioritized over this unless they are essential.

I agree. I think our core product bitUSD needs to work flawlessly on a stable client with adequate bts ---> bank account services before any other major changes are made.

Then once we have a working product that we can leave to spread and attract customers I think it is important to out-source core development to multiple parties.
A few months spent designing and implementing a new core-development Delegate-like system to effectively outsource core development tasks could spark exponential development.

If we set up the environment correctly 'pivoting' will no longer be a problem and shareholders can have assurances that work paid for will be completed. Under the current system shareholders do not have enough information to evaluate the progress of core-development - there are simply too many delegates to investigate on a regular basis and the details of their projects are somewhat inaccessible.

Quote
Relax.  We are working on a stable "1.0" that you will be thrilled about.  The full set of features / documentation / etc will be well defined and released in about a month. 
Quote

Great to hear. Clear and concise information is what shareholders need
Title: Re: Paid Workers Proposal for Review
Post by: crzme on May 05, 2015, 01:18:45 am
Your ignorance once again hurt the market.
Title: Re: Paid Workers Proposal for Review
Post by: fuzzy on May 05, 2015, 01:20:57 am
My suggestions based on my previous post here: https://bitsharestalk.org/index.php/topic,1692.msg18720.html#msg18720

How about a bounty exchange platform with an Ask/Bid?

This is essentially a bounty auction and exchange platform. It is completely algorithmic in approach and completely automated. It determines the true market price of any kind of labor by reaching the equilibrium point between the supply and demand through the bid/ask.

It would be centralized at first but could be made decentralized, it's also a way to determine who would be selected for the bounty in a completely automated fashion.

It may even allow workers to trade jobs on the exchange provided they do so before the expiration date. This way if a worker bit off more than he could chew he could exchange his bounty with someone else and they'd get paid in his place if they complete it.

Instructions
As the employer first you'd put up your bidding price which is the highest you're willing to pay, then a bunch of potential bid fillers put up their asking price and according to the algorithm it would meet in the middle according to supply and demand at an equilibrium point. This would give the market the true price of the labor.
Input: Employers enter a job description and bidding price to be displayed as the maximum bounty reward.
Input: Employees/Job hunters enter their asking prices, mapped to their Keyhotee IDs.
DAC: An algorithm selects the employee willing to work for the lowest asking price (lowest bounty reward)
DAC: A bot sends an encrypted message to the public key of the Keyhotee ID address and sends a bounty token to their wallet.
DAC: The transaction and exchange exist entirely in a blockchain so that if necessary anyone with that bounty token can exchange their bounty token for anyone else's.
Output1: The job is completed by the expiration date on the bounty token, and the bounty token is redeemed at the true price of labor in the market.
Output2: The job is not completed by the expiration date and the bounty token is never redeemed, therefore it is invalid and expired.
Social Contract: 50% Protoshares, 45% Angelshares, 5% Promotion, Discount and Giveaway shares

What could go wrong? Someone could lose their bounty token and then the bounty would expire wasting valuable time. On the other hand it would save time if someone can trade their received bounty with another person or split their bounty with another person all in automated fashion by using the divisibility of the bounty token. So if I did 90% of the labor and I could not do that final 10% then I could break off 10% of the bounty token and give it to anyone willing to work for it.

Let me know if this idea could work?


^^^^

The gist of the idea is to create a job auction exchange. Jobs are auctioned on the blockchain. A UIA could represent a job and when the job is done all who have the asset can redeem for BitUSD.

Of course it would have to be simplified due to the limitations of the blockchain but ultimately the market should determine things. Let anyone bid for positions. Let the community for up or down the positions from which could be bid for and let the community set the amount it is willing to pay in some algorithmic fashion so that the jobs are auctioned to the lowest bidder.

http://www.jobauctions.com/

After reading this fantastic idea I came up with my own proposal for how this could work.

TL;DR:
Separation of community/company maintenance (Delegates) and core development.
Delegates compete to act as maintainers of the blockchain and as the human element to DAC decision making.
Core development could be funded by contracts between the shareholders and developers.
Devs propose development and a pay schedule. Shareholders pay into proposal-specific funds as they see fit and development starts once a given pledge-threshold is met.
These proposals are contracts to complete a given task within a stated timeframe for a price acceptable to the shareholders.


Here is a hypothetical scenario I hope will illustrate how this could work.

I unlock my BitShares wallet and see that I have 500 cds (core-dev-shares) and navigate to the 'Development Proposals' tab. 1 cds = 1 bts but can only be spent per the terms of a core development contract.
I see that Invictus Innovations has a proposal for bitAssets 2.0. The team claim it will take 2 months and are asking for 200k bts and $2k bitUSD upfront with a 5M bts completion-'bounty'. Of this 5M bts, 2.5M will be held in escrow for 1 year and 2.5M will be converted to bitUSD on a weekly basis from the start of development until depleted. The team promises to provide proof of progress to
the community and expects Delegates to scrutinise the details.
Underneath this proposal I see that two delegates I trust (delegate.kencode and fuzzy.beyondbitcoin) have evaluated the proposal and interviewed Invictus Innovations and conclude that they think it is a proposal worthy of investment. Fuzzy has provided an .mp3 file to his 'town hall' interview and kencode has convinced me that the economic reasoning holds up.
I am now a reassured and confident shareholder so pledge 60% of my 500 cds to this proposal.
I see Moonstone is nearly funded so I send another 20% there.
But I also notice that ByteMaster has another great proposal but doesn't have the time to implement it right now. It's a minor feature not worth the time yet. He has requested an exorbitant fee to prioritise this work over his spare time but I'm sure he expects someone else to pitch for a much lower cost.
I see underneath that 'script.kiddie' has already offered to whip up the code for just $500 bitUSD with a 5k bts royalty fee to be paid to bytemaster. I pledge some more of my 500 cds and see it is instantly converted to bitUSD at market price.

A month later I come back to my wallet to check my cds balance. Script.kiddie has the new feature running smoothly but I see that another project he proposed didn't get funded within the time-window and the 50 cds that I pledged has been refunded to me to allocate to other projects.


I think that trying to merge the two distinct 'departments' of core development and efficient company maintenance stifles innovation and diversity in both departments.
Delegates should get paid for being delegates and core development teams should pitch and get paid solely for contracted tasks completed.

In order to ensure max decentralization of our DAC the shareholders need to actively participate in all aspects of the DAC.
As we are all humans with short attention spans these decisions need to be spoon-fed to us. The easier it is to participate, the more shareholders we get to take part.
If anything is complicated or hard to evaluate, participation will drop off sharply.

Groups of humans are known for witch hunts so we should make sure that when these happen they do not spill over into unrelated areas of the DAC.
For example; if a mob gets stirred up to oust a delegate providing a slow price feed then we need to be certain that there won't be any collateral damage. So delegates cannot also be responsible for funding core development.

Taulant and Moonstone have stated that they aim to demonstrate their worth by taking on risk and offering the shareholders the opportunity to invest by buying their product (their code) and having them open-source it. Could core devs take a similar approach?

Data and necessary info needs to be compiled by the DAC for presentation to the shareholders so they can make informed decisions.

Delegates need to be easily evaluated with a quick look at a list of statistics. Delegate pay should pay for the efficient running of delegate tasks only.
Core development needs to be pitched to the shareholders in a modular fashion and opened up to the free market – I propose by way of a crowd sale system.
Dev teams need to show their goals and code needs to be written in a way that allows numerous parties to add to the codebase over time. A clear list of tasks to be completed allows separate dev teams to pitch separate projects. The shareholders can then fund development as quickly or as gradually as they wish. Projects won't overlap so less time is wasted, and potential dev teams know that they will get paid for the work they do.

Shareholders who are delegates could also pitch for core development tasks if they are so inclined but shareholders need to be able to quickly see who is doing the job for which they are specifically being paid for.

For delegates this should mean that shareholders can view a list of hard stats that accurately tell them who is performing well and who isn't.
These stats include:
1) Uptime
2) Block propagation
3) Average time per price feed (possibly broken down per asset – this could be displayed next to a measure of volatility of the specified asset for a fair assessment.)
4) Other clear cut and useful stats.
5) A percentage of how many successfully funded core-dev proposals the delegate reviewed and advised on.
Delegates should also be responsible for being oracles on contracts between the shareholders/DAC and core development teams. They are the human element of the DAC so should evaluate the viability of core development proposals and also check-in on project progress.  Delegates would have no authority to stop shareholders funding unrealistic proposals but should use their reputation to serve the shareholders in an advisory capacity.


Instead of funding core dev with dilution, those block rewards could be sent proportionally to each account by their holdings. The funds could be held in some kind of multisig account that allows them to only be spent by contributing to core dev project proposal crowd sales.

Proposals for core development could be published in a separate section of the core wallet in a way that acts to 'crowd sale' the proposed project.
It costs a nominal fee to publish these ideas to avoid bloat and make it easier for shareholders to assess less options. These proposals are contracts to complete a given task within a stated timeframe for a price acceptable to the shareholders.

Core Dev Proposals contain:
1) A summary of the problems aiming to be solved, what the finished product will look like/do and why/how it will work
2) a timeline
3) A fee structure. Perhaps an upfront fee and a recurring payment schedule or an on-completion bounty.
4) Proposals can also be published with the expectation that someone other than the author will bid to actually compete the task.  Devs who wish the implement someone else's idea can include a royalty payment in their proposal. 'Fund us and we'll pay 10kbts to the author as a royalty.'
This 'royalty' is voluntary but encourages 'ideas people' to promote their ideas to establish themselves in the community to increase the likelihood they'll get a royalty and as a consequence more people hear about the best proposals.
The author of a proposal may also be a large stakeholder with lots of funds to pledge to a developer team to implement their idea, so devs may want to attract this 'VC money' and so offer a symbolic/generous royalty.

The party can then pitch themselves to the shareholders on why they should get this contract. For example:

'We propose to implement BM's proposal for bitAssets 2.0. Upfront we require: 10k bts, £2k bitUSD, 5M bts to be held in escrow until completion except each month 0.5 bitGold is paid out from the fund.'

These proposals accomplish:
1) Separation of DAC maintenance and DAC development
2) Open-sourcing of ideas for core development. If a proposal contains a good idea but asks for too much funding, other parties are able to promise the same project for an alternative payment schedule.
3) A direct relationship between the shareholders and core development incorporated into the DAC itself.

Um let's ignore my name was put in there for a moment.  I love this proposal. I also think that RGCRYPTO is working on a bitshares chamber of commerce that would fit perfectly into this.

My counterproposal:

* Instead of spending time on this, spend time on getting bitAssets 2.0 finalized and coded, and getting stable client released fairly soon. 

* As a result of 1.0 release and improved bitassets which ahve better convertability and don't punish shorts, BTS price hopefully rebounds.  Developer pay goes back towards what we would like it to be.  If BTS price doesnt rebound, developers create more paid delegates, and the community can vote them in to keep devs fed.

* Later on, now that the critical and immediate needs of Bitshares are completed, if we feel that separating workers from block producers is important, put time into working on this.  But even then, it is competing against other features that would be nice, such as the bond market, prediction market, voting on proposals, smart contracts, etc.


If the plan in the original post in this thread is better than my plan, or is critical right now for some reason, please explain why.  I am very open to hearing this, and am not going to claim that I am definitely right or anything like that.  After all, the core team is MUCH better informed about what is going on in bitshares than I am, and they know everything going on behind the scenes, and I don't. 

What makes it so that we NEED to prioritize work on this change right now?  Is this the biggest thing for us to work on right now?  Is it worth pivoting in this way, given the perception that we already pivot too much, and that we are also already pivoting on bitAssets (which is necessary). 


I would like to see a Bitshares that doesnt just pivot, pivot, pivot, over and over.  But sticks with working things and gives them time to work.  We learned that bitassets had a problem and we needed to fix that, which is important, and justifies the pivot there.  What requires the pivot here, at this point in the development?  If the devs need more compensaiton, which is justified imo given that the price declined so much, isnt the easy answer of 'devs create more delegates and we vote them in' a much better solution?  One which requires no development time because it doesnt change bitshares in any way?


I would really like to see a stable 1.0 release which fixes problems people are having with the client as soon as possible.  Other things should not be being prioritized over this unless they are essential.

Thanks!

Relax.  We are working on a stable "1.0" that you will be thrilled about.  The full set of features / documentation / etc will be well defined and released in about a month. 

Good. I'm glad to see us moving forward here. Because this has been by far the most concerning aspect of bitshares in my mind for the past year.  Imho if we had a very easy to use UI and stable wallet we would not need an affiliate program because our most passionate community members would have sold bitshares very effectively to those around the without the need for payment. This would have meant we could have focused instead on fixing the issues with ensuring interest was included in accounts...which would have been epic for 3rd world users--the people who are foaming at the mouth for liquid interest bearing accounts.
Title: Re: Paid Workers Proposal for Review
Post by: muse-umum on May 05, 2015, 04:24:09 am
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?

Stop thinking about anything else before you deliver a wallet which any HUMANBEING is able to operate. Will you?
钱包都没法正常使用的前提下就别去谈其他的鸡巴玩意。
Title: Re: Paid Workers Proposal for Review
Post by: fuzzy on May 05, 2015, 05:09:48 am
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?

Stop thinking about anything else before you deliver a wallet which any HUMANBEING is able to operate. Will you?
钱包都没法正常使用的前提下就别去谈其他的鸡巴玩意。


This truthfully is the big take away.  I hate to say it but it comes up over and over again.  There is a recurring theme here.  Luckily BM says that this is one of the big things on the horizon.  Even if he is wrong, moonstone is going to be....well.  Sexy:
(http://i.imgur.com/7spl15Q.png)
Title: Re: Paid Workers Proposal for Review
Post by: BTSdac on May 05, 2015, 09:56:07 am
Objectively speaking
I like this idea ,  but we must lost some user/investor  if this proposal would been carried out finally .
we also have 7 core developers now?  I doubt  it, because recently there are less and less code update
Title: Re: Paid Workers Proposal for Review
Post by: Stan on May 05, 2015, 03:50:43 pm
Plenty of code being developed off line to maximize the huge lead BitShares is building on its competition.

All of the concerns people keep expressing are being addressed in a far, far more comprehensive way than an outside observer could possibly imagine.

Would you really want us to abandon our carefully designed comprehensive solution to run off after every angry demand someone posts in bold print? 

This is a chess game and sometimes a player needs to make a few "pointless" moves in advance that the average kibitzer doesn't fully appreciate at the time.

 :)

Title: Re: Paid Workers Proposal for Review
Post by: nomoreheroes7 on May 05, 2015, 04:05:24 pm
Plenty of code being developed off line to maximize the huge lead BitShares is building on its competition.

All of the concerns people keep expressing are being addressed in a far, far more comprehensive way than an outside observer could possibly imagine.

Would you really want us to abandon our carefully designed comprehensive solution to run off after every angry demand someone posts in bold print? 

This is a chess game and sometimes a player needs to make a few "pointless" moves in advance that the average kibitzer doesn't fully appreciate at the time.

 :)

Sure have been a lot of hints lately at something huge in the pipeline...hope the wait (and cheap BTS) are worth it.
Title: Re: Paid Workers Proposal for Review
Post by: Empirical1.2 on May 05, 2015, 04:12:31 pm
I would like to ask: What is the big problem with the current system which requires this change?
Why does this change need to be prioritized now, when we are desperate for things like a stable client?

I think we should avoid creating a huge overhand of vesting BTS which people know will be unlocked at some point in the future.  This could make people think "Well, if I invest in BTS now, I'm going to get dumped on in the future as soon as those shares become unlocked".

The paid worker proposal seems to be specifically tied to the 'project' BM is proposing. So it is most likely a workaround for VC funding.

Personally I don't think I'll be a fan unless the VC is also a gateway or that's in the mix too.

Title: Re: Paid Workers Proposal for Review
Post by: Riverhead on May 05, 2015, 06:21:02 pm
"Devs need to pay the rent and buy food today" and "We'll vest their pay for five years" does not reconcile. Who fronts the cash for their salary in the mean time? If they have been given their salary up front to pay bills who gets the vested BTS?

So if I understand correctly it boils down to some combination of:

1) An affiliate revenue program will be enough to support seven devs now and the five year vest BTS are like stock options and not salary.

2) Someone fronts all the money for salaries and is paid back via affiliate revenue with the big bonus of BTS after five years once their project has helped make it all a big success.

3) The shareholders are voting on the stock options given to the project owners after five years and not how much the project will earn day to day.

Am I close?
Title: Re: Paid Workers Proposal for Review
Post by: xeroc on May 05, 2015, 06:30:43 pm
Am I close?
:o
All of the concerns people keep expressing are being addressed in a far, far more comprehensive way than an outside observer could possibly imagine.

 :P :P
Title: Re: Paid Workers Proposal for Review
Post by: Pheonike on May 05, 2015, 06:51:29 pm
I can understand using BTS as a stock option, but 5 years is too long.  2 years is long enough to know if this will be a success. If we are not ready in 2 years then someone else will have already mopped the floor with us by then anyway. With everything being open-sourced  it is easy for a competitor to build on your stuff faster than you can pivot sometimes. We have been lucky so far, but that luck is going to run out sooner than later.
Title: Re: Paid Workers Proposal for Review
Post by: bytemaster on May 05, 2015, 06:52:58 pm
I would like to ask: What is the big problem with the current system which requires this change?
Why does this change need to be prioritized now, when we are desperate for things like a stable client?

I think we should avoid creating a huge overhand of vesting BTS which people know will be unlocked at some point in the future.  This could make people think "Well, if I invest in BTS now, I'm going to get dumped on in the future as soon as those shares become unlocked".

The paid worker proposal seems to be specifically tied to the 'project' BM is proposing. So it is most likely a workaround for VC funding.

Personally I don't think I'll be a fan unless the VC is also a gateway or that's in the mix too.

;)
Title: Re: Paid Workers Proposal for Review
Post by: zerosum on May 05, 2015, 06:54:40 pm
"Devs need to pay the rent and buy food today" and "We'll vest their pay for five years" does not reconcile. Who fronts the cash for their salary in the mean time? If they have been given their salary up front to pay bills who gets the vested BTS?

So if I understand correctly it boils down to some combination of:

1) An affiliate revenue program will be enough to support seven devs now and the five year vest BTS are like stock options and not salary.

2) Someone fronts all the money for salaries and is paid back via affiliate revenue with the big bonus of BTS after five years once their project has helped make it all a big success.

3) The shareholders are voting on the stock options given to the project owners after five years and not how much the project will earn day to day.

Am I close?

Alternatively:

-Stan got BM's memo.
-Gave it a little bit of PR polishing...not much just replaced the 5 day vesting with 5 year vesting.

Voilà!
Title: Re: Paid Workers Proposal for Review
Post by: Stan on May 05, 2015, 07:12:21 pm
“There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.

There is another theory which states that this has already happened.”


― Douglas Adams, The Restaurant at the End of the Universe
Title: Re: Paid Workers Proposal for Review
Post by: zerosum on May 05, 2015, 07:29:20 pm
“There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.

There is another theory which states that this has already happened.”


― Douglas Adams, The Restaurant at the End of the Universe

Actually more appropriate is the monster ,(forgot its name) described/created by the same author. Anyway the monster believes that if you cannot see it the monster itself cannot see you.
So the best defense against it, is to close you own eyes

[Edit]
The Ravenous Bugblatter Beast of Traal is a wild animal from the planet of Traal, known for its never-ending hunger and if you can't see it, it assumes it can't see you.

if the Guide is to be believed. For, according to the Guide, draping a towel over your head will confuse the beast long enough for one to make a quick getaway. This is because (as mentioned above) the philosophy of The Ravenous Bugblatter Beast is that, if you can't see it, it can't see you.
Title: Re: Paid Workers Proposal for Review
Post by: Tuck Fheman on May 05, 2015, 07:46:40 pm
;)

Thanks for answering (I think/hope) my question from the other thread.
Title: Re: Paid Workers Proposal for Review
Post by: Stan on May 05, 2015, 07:56:21 pm
“There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.

There is another theory which states that this has already happened.”


― Douglas Adams, The Restaurant at the End of the Universe

Actually more appropriate is the monster ,(forgot its name) described/created by the same author. Anyway the monster believes that if you cannot see it the monster itself cannot see you.
So the best defense against it, is to close you own eyes

[Edit]
The Ravenous Bugblatter Beast of Traal is a wild animal from the planet of Traal, known for its never-ending hunger and if you can't see it, it assumes it can't see you.

if the Guide is to be believed. For, according to the Guide, draping a towel over your head will confuse the beast long enough for one to make a quick getaway. This is because (as mentioned above) the philosophy of The Ravenous Bugblatter Beast is that, if you can't see it, it can't see you.

(https://encrypted-tbn3.gstatic.com/images?q=tbn:ANd9GcTG5eZYJu47B_ce97aFqOwRpvGxmwr2DANQzhg9RnXuFuk17mZ-Sw)
Title: Re: Paid Workers Proposal for Review
Post by: rajarush on May 05, 2015, 07:58:21 pm

How about a bounty exchange platform with an Ask/Bid?

This is essentially a bounty auction and exchange platform. It is completely algorithmic in approach and completely automated. It determines the true market price of any kind of labor by reaching the equilibrium point between the supply and demand through the bid/ask.

It would be centralized at first but could be made decentralized, it's also a way to determine who would be selected for the bounty in a completely automated fashion.

It may even allow workers to trade jobs on the exchange provided they do so before the expiration date. This way if a worker bit off more than he could chew he could exchange his bounty with someone else and they'd get paid in his place if they complete it.

Instructions
As the employer first you'd put up your bidding price which is the highest you're willing to pay, then a bunch of potential bid fillers put up their asking price and according to the algorithm it would meet in the middle according to supply and demand at an equilibrium point. This would give the market the true price of the labor.
Input: Employers enter a job description and bidding price to be displayed as the maximum bounty reward.
Input: Employees/Job hunters enter their asking prices, mapped to their Keyhotee IDs.
DAC: An algorithm selects the employee willing to work for the lowest asking price (lowest bounty reward)
DAC: A bot sends an encrypted message to the public key of the Keyhotee ID address and sends a bounty token to their wallet.
DAC: The transaction and exchange exist entirely in a blockchain so that if necessary anyone with that bounty token can exchange their bounty token for anyone else's.
Output1: The job is completed by the expiration date on the bounty token, and the bounty token is redeemed at the true price of labor in the market.
Output2: The job is not completed by the expiration date and the bounty token is never redeemed, therefore it is invalid and expired.
Social Contract: 50% Protoshares, 45% Angelshares, 5% Promotion, Discount and Giveaway shares

What could go wrong? Someone could lose their bounty token and then the bounty would expire wasting valuable time. On the other hand it would save time if someone can trade their received bounty with another person or split their bounty with another person all in automated fashion by using the divisibility of the bounty token. So if I did 90% of the labor and I could not do that final 10% then I could break off 10% of the bounty token and give it to anyone willing to work for it.

Let me know if this idea could work?


^^^^

The gist of the idea is to create a job auction exchange. Jobs are auctioned on the blockchain. A UIA could represent a job and when the job is done all who have the asset can redeem for BitUSD.

Of course it would have to be simplified due to the limitations of the blockchain but ultimately the market should determine things. Let anyone bid for positions. Let the community for up or down the positions from which could be bid for and let the community set the amount it is willing to pay in some algorithmic fashion so that the jobs are auctioned to the lowest bidder.

http://www.jobauctions.com/

IMO an automated DAC is unsuitable for matching workers and jobs, because for an employer the price is only one of many criteria for selecting an employee. An employer may want to hand over a job to a more skilled/experienced worker even if he has to pay a higher price.

You proposal is missing a crucial component: who gets to decide when/if a job has been completed? You're going to need arbitrators in case of a dispute.

Also, managing such a platform creates a massive overhead for the employers and may be unsuitable for small tasks.
http://www.jobauctions.com/

Wouldn't a reputation system help with all the problems you are talking about PC?

i intend ot agree PC!

Who will decide, for example, on graphic related tasks, if an design is finished in view of requirements, graphic style, sustainability?
On technical side requirements are much more clearer to communicate ... but for esthetic etc. purposes ... who will decide if a job task is solved?
(used the designer example ... you know why^^)

Just want to quote, it looks long


Sent from my iPhone using Tapatalk
Title: Re: Paid Workers Proposal for Review
Post by: hodor on May 05, 2015, 08:02:17 pm
I would like to ask: What is the big problem with the current system which requires this change?
Why does this change need to be prioritized now, when we are desperate for things like a stable client?

I think we should avoid creating a huge overhand of vesting BTS which people know will be unlocked at some point in the future.  This could make people think "Well, if I invest in BTS now, I'm going to get dumped on in the future as soon as those shares become unlocked".

The paid worker proposal seems to be specifically tied to the 'project' BM is proposing. So it is most likely a workaround for VC funding.

Personally I don't think I'll be a fan unless the VC is also a gateway or that's in the mix too.

;)

http://www.youtube.com/watch?v=wC871hNBig4&t=1m6s
Title: Re: Paid Workers Proposal for Review
Post by: rajarush on May 05, 2015, 08:02:26 pm

My suggestions based on my previous post here: https://bitsharestalk.org/index.php/topic,1692.msg18720.html#msg18720

How about a bounty exchange platform with an Ask/Bid?

This is essentially a bounty auction and exchange platform. It is completely algorithmic in approach and completely automated. It determines the true market price of any kind of labor by reaching the equilibrium point between the supply and demand through the bid/ask.

It would be centralized at first but could be made decentralized, it's also a way to determine who would be selected for the bounty in a completely automated fashion.

It may even allow workers to trade jobs on the exchange provided they do so before the expiration date. This way if a worker bit off more than he could chew he could exchange his bounty with someone else and they'd get paid in his place if they complete it.

Instructions
As the employer first you'd put up your bidding price which is the highest you're willing to pay, then a bunch of potential bid fillers put up their asking price and according to the algorithm it would meet in the middle according to supply and demand at an equilibrium point. This would give the market the true price of the labor.
Input: Employers enter a job description and bidding price to be displayed as the maximum bounty reward.
Input: Employees/Job hunters enter their asking prices, mapped to their Keyhotee IDs.
DAC: An algorithm selects the employee willing to work for the lowest asking price (lowest bounty reward)
DAC: A bot sends an encrypted message to the public key of the Keyhotee ID address and sends a bounty token to their wallet.
DAC: The transaction and exchange exist entirely in a blockchain so that if necessary anyone with that bounty token can exchange their bounty token for anyone else's.
Output1: The job is completed by the expiration date on the bounty token, and the bounty token is redeemed at the true price of labor in the market.
Output2: The job is not completed by the expiration date and the bounty token is never redeemed, therefore it is invalid and expired.
Social Contract: 50% Protoshares, 45% Angelshares, 5% Promotion, Discount and Giveaway shares

What could go wrong? Someone could lose their bounty token and then the bounty would expire wasting valuable time. On the other hand it would save time if someone can trade their received bounty with another person or split their bounty with another person all in automated fashion by using the divisibility of the bounty token. So if I did 90% of the labor and I could not do that final 10% then I could break off 10% of the bounty token and give it to anyone willing to work for it.

Let me know if this idea could work?


^^^^

The gist of the idea is to create a job auction exchange. Jobs are auctioned on the blockchain. A UIA could represent a job and when the job is done all who have the asset can redeem for BitUSD.

Of course it would have to be simplified due to the limitations of the blockchain but ultimately the market should determine things. Let anyone bid for positions. Let the community for up or down the positions from which could be bid for and let the community set the amount it is willing to pay in some algorithmic fashion so that the jobs are auctioned to the lowest bidder.

http://www.jobauctions.com/

After reading this fantastic idea I came up with my own proposal for how this could work.

TL;DR:
Separation of community/company maintenance (Delegates) and core development.
Delegates compete to act as maintainers of the blockchain and as the human element to DAC decision making.
Core development could be funded by contracts between the shareholders and developers.
Devs propose development and a pay schedule. Shareholders pay into proposal-specific funds as they see fit and development starts once a given pledge-threshold is met.
These proposals are contracts to complete a given task within a stated timeframe for a price acceptable to the shareholders.


Here is a hypothetical scenario I hope will illustrate how this could work.

I unlock my BitShares wallet and see that I have 500 cds (core-dev-shares) and navigate to the 'Development Proposals' tab. 1 cds = 1 bts but can only be spent per the terms of a core development contract.
I see that Invictus Innovations has a proposal for bitAssets 2.0. The team claim it will take 2 months and are asking for 200k bts and $2k bitUSD upfront with a 5M bts completion-'bounty'. Of this 5M bts, 2.5M will be held in escrow for 1 year and 2.5M will be converted to bitUSD on a weekly basis from the start of development until depleted. The team promises to provide proof of progress to
the community and expects Delegates to scrutinise the details.
Underneath this proposal I see that two delegates I trust (delegate.kencode and fuzzy.beyondbitcoin) have evaluated the proposal and interviewed Invictus Innovations and conclude that they think it is a proposal worthy of investment. Fuzzy has provided an .mp3 file to his 'town hall' interview and kencode has convinced me that the economic reasoning holds up.
I am now a reassured and confident shareholder so pledge 60% of my 500 cds to this proposal.
I see Moonstone is nearly funded so I send another 20% there.
But I also notice that ByteMaster has another great proposal but doesn't have the time to implement it right now. It's a minor feature not worth the time yet. He has requested an exorbitant fee to prioritise this work over his spare time but I'm sure he expects someone else to pitch for a much lower cost.
I see underneath that 'script.kiddie' has already offered to whip up the code for just $500 bitUSD with a 5k bts royalty fee to be paid to bytemaster. I pledge some more of my 500 cds and see it is instantly converted to bitUSD at market price.

A month later I come back to my wallet to check my cds balance. Script.kiddie has the new feature running smoothly but I see that another project he proposed didn't get funded within the time-window and the 50 cds that I pledged has been refunded to me to allocate to other projects.


I think that trying to merge the two distinct 'departments' of core development and efficient company maintenance stifles innovation and diversity in both departments.
Delegates should get paid for being delegates and core development teams should pitch and get paid solely for contracted tasks completed.

In order to ensure max decentralization of our DAC the shareholders need to actively participate in all aspects of the DAC.
As we are all humans with short attention spans these decisions need to be spoon-fed to us. The easier it is to participate, the more shareholders we get to take part.
If anything is complicated or hard to evaluate, participation will drop off sharply.

Groups of humans are known for witch hunts so we should make sure that when these happen they do not spill over into unrelated areas of the DAC.
For example; if a mob gets stirred up to oust a delegate providing a slow price feed then we need to be certain that there won't be any collateral damage. So delegates cannot also be responsible for funding core development.

Taulant and Moonstone have stated that they aim to demonstrate their worth by taking on risk and offering the shareholders the opportunity to invest by buying their product (their code) and having them open-source it. Could core devs take a similar approach?

Data and necessary info needs to be compiled by the DAC for presentation to the shareholders so they can make informed decisions.

Delegates need to be easily evaluated with a quick look at a list of statistics. Delegate pay should pay for the efficient running of delegate tasks only.
Core development needs to be pitched to the shareholders in a modular fashion and opened up to the free market – I propose by way of a crowd sale system.
Dev teams need to show their goals and code needs to be written in a way that allows numerous parties to add to the codebase over time. A clear list of tasks to be completed allows separate dev teams to pitch separate projects. The shareholders can then fund development as quickly or as gradually as they wish. Projects won't overlap so less time is wasted, and potential dev teams know that they will get paid for the work they do.

Shareholders who are delegates could also pitch for core development tasks if they are so inclined but shareholders need to be able to quickly see who is doing the job for which they are specifically being paid for.

For delegates this should mean that shareholders can view a list of hard stats that accurately tell them who is performing well and who isn't.
These stats include:
1) Uptime
2) Block propagation
3) Average time per price feed (possibly broken down per asset – this could be displayed next to a measure of volatility of the specified asset for a fair assessment.)
4) Other clear cut and useful stats.
5) A percentage of how many successfully funded core-dev proposals the delegate reviewed and advised on.
Delegates should also be responsible for being oracles on contracts between the shareholders/DAC and core development teams. They are the human element of the DAC so should evaluate the viability of core development proposals and also check-in on project progress.  Delegates would have no authority to stop shareholders funding unrealistic proposals but should use their reputation to serve the shareholders in an advisory capacity.


Instead of funding core dev with dilution, those block rewards could be sent proportionally to each account by their holdings. The funds could be held in some kind of multisig account that allows them to only be spent by contributing to core dev project proposal crowd sales.

Proposals for core development could be published in a separate section of the core wallet in a way that acts to 'crowd sale' the proposed project.
It costs a nominal fee to publish these ideas to avoid bloat and make it easier for shareholders to assess less options. These proposals are contracts to complete a given task within a stated timeframe for a price acceptable to the shareholders.

Core Dev Proposals contain:
1) A summary of the problems aiming to be solved, what the finished product will look like/do and why/how it will work
2) a timeline
3) A fee structure. Perhaps an upfront fee and a recurring payment schedule or an on-completion bounty.
4) Proposals can also be published with the expectation that someone other than the author will bid to actually compete the task.  Devs who wish the implement someone else's idea can include a royalty payment in their proposal. 'Fund us and we'll pay 10kbts to the author as a royalty.'
This 'royalty' is voluntary but encourages 'ideas people' to promote their ideas to establish themselves in the community to increase the likelihood they'll get a royalty and as a consequence more people hear about the best proposals.
The author of a proposal may also be a large stakeholder with lots of funds to pledge to a developer team to implement their idea, so devs may want to attract this 'VC money' and so offer a symbolic/generous royalty.

The party can then pitch themselves to the shareholders on why they should get this contract. For example:

'We propose to implement BM's proposal for bitAssets 2.0. Upfront we require: 10k bts, £2k bitUSD, 5M bts to be held in escrow until completion except each month 0.5 bitGold is paid out from the fund.'

These proposals accomplish:
1) Separation of DAC maintenance and DAC development
2) Open-sourcing of ideas for core development. If a proposal contains a good idea but asks for too much funding, other parties are able to promise the same project for an alternative payment schedule.
3) A direct relationship between the shareholders and core development incorporated into the DAC itself.



Sent from my iPhone using Tapatalk
Title: Re: Paid Workers Proposal for Review
Post by: Tuck Fheman on May 05, 2015, 08:06:11 pm
Why didn't these guys do this on our blockchain? '

http://www.thebitcoinchannel.com/archives/43730

Because it was not alive and offering incentives to these guys like we need it to.

Obligatory 'pics or it didn't happen'.

Title: Re: Paid Workers Proposal for Review
Post by: Tuck Fheman on May 05, 2015, 08:08:12 pm
http://www.youtube.com/watch?v=wC871hNBig4&t=1m6s

(http://download.ultradownloads.com.br/wallpaper/276172_Papel-de-Parede-Meme-I-See-What-You-Did-There_1366x768.jpg)
Title: Re: Paid Workers Proposal for Review
Post by: helloworld on May 06, 2015, 01:33:34 am
My counterproposal:

* Instead of spending time on this, spend time on getting bitAssets 2.0 finalized and coded, and getting stable client released fairly soon. 

* As a result of 1.0 release and improved bitassets which ahve better convertability and don't punish shorts, BTS price hopefully rebounds.  Developer pay goes back towards what we would like it to be.  If BTS price doesnt rebound, developers create more paid delegates, and the community can vote them in to keep devs fed.

* Later on, now that the critical and immediate needs of Bitshares are completed, if we feel that separating workers from block producers is important, put time into working on this.  But even then, it is competing against other features that would be nice, such as the bond market, prediction market, voting on proposals, smart contracts, etc.


If the plan in the original post in this thread is better than my plan, or is critical right now for some reason, please explain why.  I am very open to hearing this, and am not going to claim that I am definitely right or anything like that.  After all, the core team is MUCH better informed about what is going on in bitshares than I am, and they know everything going on behind the scenes, and I don't. 

What makes it so that we NEED to prioritize work on this change right now?  Is this the biggest thing for us to work on right now?  Is it worth pivoting in this way, given the perception that we already pivot too much, and that we are also already pivoting on bitAssets (which is necessary). 


I would like to see a Bitshares that doesnt just pivot, pivot, pivot, over and over.  But sticks with working things and gives them time to work.  We learned that bitassets had a problem and we needed to fix that, which is important, and justifies the pivot there.  What requires the pivot here, at this point in the development?  If the devs need more compensaiton, which is justified imo given that the price declined so much, isnt the easy answer of 'devs create more delegates and we vote them in' a much better solution?  One which requires no development time because it doesnt change bitshares in any way?


I would really like to see a stable 1.0 release which fixes problems people are having with the client as soon as possible.  Other things should not be being prioritized over this unless they are essential.

Thanks!

 +5%  +5%  +5%
Title: Re: Paid Workers Proposal for Review
Post by: helloworld on May 06, 2015, 01:59:31 am
I understand current BTS's price can't maintain 7 core developers,my opinion is that when the price is low, Devs can create more delegate to make sure maitain their live(Vote up by shareholders), when the price up, excess delegate will be vote down by shareholders, The most important key is give the right to shareholders,

It is more simple to understand. more easy to accept.and not change the rule.

Abort VC?  I think it's delegate their own thing, shareholders need't to care. and also need't care lock 5 years or 2 years, may be don't need lock, Just the Devs and VC make deal, It is OK.
Title: Re: Paid Workers Proposal for Review
Post by: role on May 06, 2015, 05:18:50 am
你是老板,你说了算   +5%
Title: Re: Paid Workers Proposal for Review
Post by: merivercap on May 06, 2015, 10:13:02 am
The proposal seems fine for the most part although the nature of Bitshares will seem more cliquish if all the core developers are part of one corporation with VC funding.  It will be like Coinbase developers being the main developers of Bitcoin.  I don't think there is anything wrong with that, but the perception might deter others from wanting to build on top of Bitshares and fear that a monolithic entity would have too much influence over the protocol.   It would probably look better if all the core devs were from several independent corporations.  BTW is the new company going to maintain the main Bitshares wallet?  It would seem so since it wouldn't make sense for core devs to build separate ones.

I figure based on your budget a $1 million seed round can last a few years for the new company.  The funding would probably be more favorable to the new company as a $1 million convertible note at a $5/10 million conversion cap depending on how well you can negotiate a deal with the VC or partner company.   

Anyways according to the hints, it seems like there is positive news coming. 
Title: Re: Paid Workers Proposal for Review
Post by: sumantso on May 06, 2015, 01:04:11 pm
I would like to ask: What is the big problem with the current system which requires this change?
Why does this change need to be prioritized now, when we are desperate for things like a stable client?

Under this new approach their combined pay would be 3x higher
Title: Re: Paid Workers Proposal for Review
Post by: zerosum on May 07, 2015, 11:30:56 pm
I would like to ask: What is the big problem with the current system which requires this change?
Why does this change need to be prioritized now, when we are desperate for things like a stable client?

I think we should avoid creating a huge overhand of vesting BTS which people know will be unlocked at some point in the future.  This could make people think "Well, if I invest in BTS now, I'm going to get dumped on in the future as soon as those shares become unlocked".

The paid worker proposal seems to be specifically tied to the 'project' BM is proposing. So it is most likely a workaround for VC funding.

Personally I don't think I'll be a fan unless the VC is also a gateway or that's in the mix too.

;)

The  rumour is it is actually itBit !!! https://www.itbit.com/
Title: Re: Paid Workers Proposal for Review
Post by: Ander on May 07, 2015, 11:39:08 pm
The  rumour is it is actually itBit !!! https://www.itbit.com/

Nice try. :P 

But, itbit is pretty bullish for Bitcoin and the whole sector imo.
Title: Re: Paid Workers Proposal for Review
Post by: zerosum on May 08, 2015, 12:02:30 am
The  rumour is it is actually itBit !!! https://www.itbit.com/

Nice try. :P 

But, itbit is pretty bullish for Bitcoin and the whole sector imo.

I do not know...judge for yourself.

Ever since the time when we all thought the on/off ramps are in the pipeline last year, BM is saying that "the problem with all partners is they are startup(s) too, so they have to go through regulation step and licensing. The current once do not want extra trouble...and I do not blame them." 
UIA allowing regulatory compliance of future partners is arguable the most heavily developed feature for the last what?... any way a lot of months...
Stan start talking about an exiting times this summer, but he cannot actually talk about them. BM is exited about affiliate program + privatized bitAssets (and I guess the said UIAs).
BM talked about a week or so ago with somebody integrating BTS on their (exchange/gateway do not remember exactly).
BM gives the firs clue (in a   ;) form) it is a gateway (at least partly).
bitBIT gets its license.
I become aware of this this rumour - itBit is the partner BM is hinting about and Stan can't talk about....
Title: Re: Paid Workers Proposal for Review
Post by: Ander on May 08, 2015, 12:07:04 am
The  rumour is it is actually itBit !!! https://www.itbit.com/

Nice try. :P 

But, itbit is pretty bullish for Bitcoin and the whole sector imo.

I do not know...judge for yourself.

Ever since the time when we all thought the on/off ramps are in the pipeline last year, BM is saying that "the problem with all partners is they are startup(s) too, so they have to go through regulation step and licensing. The current once do not want extra trouble...and I do not blame them." 
UIA allowing regulatory compliance of future partners is arguable the most heavily developed feature for the last what?... any way a lot of months...
Stan start talking about an exiting times this summer, but he cannot actually talk about them. BM is exited about affiliate program + privatized bitAssets (and I guess the said UIAs).
BM talked about a week or so ago with somebody integrating BTS on their (exchange/gateway do not remember exactly).
BM gives the firs clue (in a   ;) form) it is a gateway (at least partly).
bitBIT gets its license.
I become aware of this this rumour - itBit is the partner BM is hinting about and Stan can't talk about....

Hell of a rumor if true, but I wouldnt believe it unless an announcement was made.  We got screwed too much last year believing the hints and rumors. :)

Plenty of reasons to buy BTS at these prices even if nothing huge like this is coming.  We are undervalued even if the only thing that happens this summer is a stable client released.
Title: Re: Paid Workers Proposal for Review
Post by: zerosum on May 08, 2015, 12:19:04 am
BTW Ander - great response in the other thread regarding bitAsset.  +5%

Which leads me to - robrigo was looking for someone to talk about bitAssets trading on the  Bitcoin and Gravy show  and I believe you are a great fit for the job. Let me find the link.
Title: Re: Paid Workers Proposal for Review
Post by: ebit on May 08, 2015, 02:33:37 am
welcome VC
welcome External Funding
Title: Re: Paid Workers Proposal for Review
Post by: jaran on May 08, 2015, 03:49:29 am
itBit seems way too legit for bitshares.  There are former senators and shit bankers on their board.  They will probably announce a Ripple partnership due to the recent fine. 

Hope you are right though.
Title: Re: Paid Workers Proposal for Review
Post by: xeroc on May 08, 2015, 07:18:18 am
They will probably announce a Ripple partnership due to the recent fine. 
???
Title: Re: Paid Workers Proposal for Review
Post by: xeroc on May 08, 2015, 07:22:52 am
The  rumour is it is actually itBit !!! https://www.itbit.com/

Nice try. :P 

But, itbit is pretty bullish for Bitcoin and the whole sector imo.

I do not know...judge for yourself.

Ever since the time when we all thought the on/off ramps are in the pipeline last year, BM is saying that "the problem with all partners is they are startup(s) too, so they have to go through regulation step and licensing. The current once do not want extra trouble...and I do not blame them." 
UIA allowing regulatory compliance of future partners is arguable the most heavily developed feature for the last what?... any way a lot of months...
Stan start talking about an exiting times this summer, but he cannot actually talk about them. BM is exited about affiliate program + privatized bitAssets (and I guess the said UIAs).
BM talked about a week or so ago with somebody integrating BTS on their (exchange/gateway do not remember exactly).
BM gives the firs clue (in a   ;) form) it is a gateway (at least partly).
bitBIT gets its license.
I become aware of this this rumour - itBit is the partner BM is hinting about and Stan can't talk about....
http://www.reddit.com/r/Bitcoin/comments/358wcb/itbits_exchange_allows_frontrunning/
Title: Re: Paid Workers Proposal for Review
Post by: cass on May 08, 2015, 07:34:33 am
The  rumour is it is actually itBit !!! https://www.itbit.com/

Nice try. :P 

But, itbit is pretty bullish for Bitcoin and the whole sector imo.

I do not know...judge for yourself.

Ever since the time when we all thought the on/off ramps are in the pipeline last year, BM is saying that "the problem with all partners is they are startup(s) too, so they have to go through regulation step and licensing. The current once do not want extra trouble...and I do not blame them." 
UIA allowing regulatory compliance of future partners is arguable the most heavily developed feature for the last what?... any way a lot of months...
Stan start talking about an exiting times this summer, but he cannot actually talk about them. BM is exited about affiliate program + privatized bitAssets (and I guess the said UIAs).
BM talked about a week or so ago with somebody integrating BTS on their (exchange/gateway do not remember exactly).
BM gives the firs clue (in a   ;) form) it is a gateway (at least partly).
bitBIT gets its license.
I become aware of this this rumour - itBit is the partner BM is hinting about and Stan can't talk about....
http://www.reddit.com/r/Bitcoin/comments/358wcb/itbits_exchange_allows_frontrunning/

:)
Title: Re: Paid Workers Proposal for Review
Post by: ronald on May 08, 2015, 10:51:22 am
Good idea   There also have to be budget for marketing initiatives

Step 1:   Assume there are at most 432,000 BTS per day available to be paid to workers.  (50 BTS every 10 seconds)

Ammendement: a BitUSD budget a day available to be paid to workers instead of BTS; frozen for 2 years

Those new BitUSD are created by issuing new BTS shares at marktconform price
Title: Re: Paid Workers Proposal for Review
Post by: bitmarley on May 08, 2015, 03:34:24 pm
FromOP:
"Step 2:   Assume there is a list of projects that specify how much they need paid each day.

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
"


Thanks BM for sharing the idea. I think voting by project is great. Consider the idea of making each project open to many bidders. We can all vote on which projects are the best ideas and approximately how much we are all willing to chip-in. Then many developers can come along and bid on each project by detailing their proposals. This way we will also have backup providers in case something goes wrong with first developer/group. 
Title: Re: Paid Workers Proposal for Review
Post by: Permie on May 08, 2015, 07:42:01 pm
Thanks BM for sharing the idea. I think voting by project is great. Consider the idea of making each project open to many bidders. We can all vote on which projects are the best ideas and approximately how much we are all willing to chip-in. Then many developers can come along and bid on each project by detailing their proposals. This way we will also have backup providers in case something goes wrong with first developer/group.
+5%
Title: Re: Paid Workers Proposal for Review
Post by: yiminh on May 09, 2015, 01:58:34 am
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?

16 month and not a stable wallet, the core dev team needs to be fired,the market is doing just that, let the free market work its magic.
Title: Re: Paid Workers Proposal for Review
Post by: rgcrypto on May 09, 2015, 03:19:08 am


Quote from: yiminh

Quote
16 month and not a stable wallet, the core dev team needs to be fired,the market is doing just that, let the free market work its magic.

Rome wasn't built in 16 months.

Can't wait to be able to vote on those projects because at the end of the day...money talks. (Now is the time to buy if you want to have voting power in the future)

Title: Re: Paid Workers Proposal for Review
Post by: yiminh on May 09, 2015, 06:13:34 am


Quote from: yiminh

Quote
16 month and not a stable wallet, the core dev team needs to be fired,the market is doing just that, let the free market work its magic.

Rome wasn't built in 16 months.

Can't wait to be able to vote on those projects because at the end of the day...money talks. (Now is the time to buy if you want to have voting power in the future)

BTS dilution every 2 month, II'll take Fedral Reserve anyday!
Title: Re: Paid Workers Proposal for Review
Post by: yiminh on May 09, 2015, 06:20:22 am


Quote from: yiminh

Quote
16 month and not a stable wallet, the core dev team needs to be fired,the market is doing just that, let the free market work its magic.

Rome wasn't built in 16 months.

Can't wait to be able to vote on those projects because at the end of the day...money talks. (Now is the time to buy if you want to have voting power in the future)

BTS dilution every 2 month, II'll take Fedral Reserve anyday! with any luck someone should takeover the project and put BM and his gang out of their misery, then BTS might have a fighting chance, trust is like vigirlity, once you lose it, you'll never get it back.
Title: Re: Paid Workers Proposal for Review
Post by: santaclause102 on May 09, 2015, 01:03:16 pm
Is it correct that the 101 delegates would keep on existing besides the paid workers and the 101 delegates would just produce blocks whereas the workers would "work" and have nothing to do with block production? Also is it true that workers would be getting paid by dilution whereas delegates are paid by tx fees?

I ask this because in the latest mumble session BM said something (replying to Riverhead's question more towards the end of the hangout) about having workers and delegates side by side until delegates are voted out. That confused me a bit...
 
Title: Re: Paid Workers Proposal for Review
Post by: BTSdac on May 09, 2015, 01:19:44 pm
this idea maybe is good , but we cannot change any rule, so it is useless, stop to discussing it , I had loss much, I don`t want to lose all
Title: Re: Paid Workers Proposal for Review
Post by: sittingduck on May 09, 2015, 04:07:20 pm
I don't think he was proposing to change the dilution  rate, just the power stakeholders have.


Sent from my iPhone using Tapatalk
Title: Re: Paid Workers Proposal for Review
Post by: BTSdac on May 10, 2015, 01:20:46 pm
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.
 
Title: Re: Paid Workers Proposal for Review
Post by: sittingduck on May 10, 2015, 02:07:42 pm

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
Title: Re: Paid Workers Proposal for Review
Post by: role on May 10, 2015, 02:20:23 pm
this idea maybe is good , but we cannot change any rule, so it is useless, stop to discussing it , I had loss much, I don`t want to lose all



 +5%
Title: Re: Paid Workers Proposal for Review
Post by: Stan on May 10, 2015, 03:10:36 pm
this idea maybe is good , but we cannot change any rule, so it is useless, stop to discussing it , I had loss much, I don`t want to lose all



 +5%

We need to distinguish between property rights (which should always be secure) and system functionality which must continuously advance, or die.

The minute we decide that we cannot change to stay the best, a competitor will emerge that does not suffer under those constraints. 

Would you really want the results of our latest R&D to go to a competitor because BitShares cannot change to incorporate it?

Otherwise, BitShares would suffer the ultimate fate of Bitcoin.  Stuck roaring in the tar pits, failing to adapt, unable to compete.

Ultimately it is for the shareholders to decide.  But the choice is never simply whether to adopt a new technology or not.  It is always whether we want to allow some competitor pick it up and use it against us!

Title: Re: Paid Workers Proposal for Review
Post by: nomoreheroes7 on May 10, 2015, 03:18:15 pm
this idea maybe is good , but we cannot change any rule, so it is useless, stop to discussing it , I had loss much, I don`t want to lose all



 +5%

We need to distinguish between property rights (which should always be secure) and system functionality which must continuously advance, or die.

The minute we decide that we cannot change to stay the best, a competitor will emerge that does not suffer under those constraints. 

Would you really want the results of our latest R&D to go to a competitor because BitShares cannot change to incorporate it?

Otherwise, BitShares would suffer the ultimate fate of Bitcoin.  Stuck roaring in the tar pits, failing to adapt, unable to compete.

Ultimately it is for the shareholders to decide.  But the choice is never simply whether to adopt a new technology or not.  It is always whether we want to allow some competitor pick it up and use it against us!

This. Adapt and evolve, or stagnate and die. It's that simple.

Gotta do what you gotta do.
Title: Re: Paid Workers Proposal for Review
Post by: Chuckone on May 10, 2015, 04:07:25 pm
this idea maybe is good , but we cannot change any rule, so it is useless, stop to discussing it , I had loss much, I don`t want to lose all



 +5%

We need to distinguish between property rights (which should always be secure) and system functionality which must continuously advance, or die.

The minute we decide that we cannot change to stay the best, a competitor will emerge that does not suffer under those constraints. 

Would you really want the results of our latest R&D to go to a competitor because BitShares cannot change to incorporate it?

Otherwise, BitShares would suffer the ultimate fate of Bitcoin.  Stuck roaring in the tar pits, failing to adapt, unable to compete.

Ultimately it is for the shareholders to decide.  But the choice is never simply whether to adopt a new technology or not.  It is always whether we want to allow some competitor pick it up and use it against us!

Evolution is an iterative process. Getting it right on the first attempt is nearly impossible. To have the best product out there and outpace the competition, Bitshares needs to be agile and focused on always improving the product as well as the market rules. Liquidity and 3rd party development will come naturally if Bitshares is the best offer out there, creating a whole ecosystem around the plaform. That's when network effect will start to have a significant impact. At that point, "Powered by Bitshares" will be a sign people will look at with confidence and trust.

But that scenario won't and can't happen if Bitshares' stakeholders automatically vote against what might be good ideas, in fear that change might have a negative impact on their investment. I, too, took a hit with the merger. But as I said, getting it right on the first attempt is nearly impossible, and only those who evolve ultimately survive.
Title: Re: Paid Workers Proposal for Review
Post by: Thom on May 10, 2015, 05:07:03 pm
this idea maybe is good , but we cannot change any rule, so it is useless, stop to discussing it , I had loss much, I don`t want to lose all

 +5%

We need to distinguish between property rights (which should always be secure) and system functionality which must continuously advance, or die.

The minute we decide that we cannot change to stay the best, a competitor will emerge that does not suffer under those constraints. 

Would you really want the results of our latest R&D to go to a competitor because BitShares cannot change to incorporate it?

Otherwise, BitShares would suffer the ultimate fate of Bitcoin.  Stuck roaring in the tar pits, failing to adapt, unable to compete.

Ultimately it is for the shareholders to decide.  But the choice is never simply whether to adopt a new technology or not.  It is always whether we want to allow some competitor pick it up and use it against us!

Evolution is an iterative process. Getting it right on the first attempt is nearly impossible. To have the best product out there and outpace the competition, Bitshares needs to be agile and focused on always improving the product as well as the market rules. Liquidity and 3rd party development will come naturally if Bitshares is the best offer out there, creating a whole ecosystem around the plaform. That's when network effect will start to have a significant impact. At that point, "Powered by Bitshares" will be a sign people will look at with confidence and trust.

But that scenario won't and can't happen if Bitshares' stakeholders automatically vote against what might be good ideas, in fear that change might have a negative impact on their investment. I, too, took a hit with the merger. But as I said, getting it right on the first attempt is nearly impossible, and only those who evolve ultimately survive.
+5% Stan!

So long as we don't stray so far from our principles that we cease to further the cause of financial freedom for all in favor of "the greatest profit / broadest adoption".

I agree, "you gotta do what you gotta do to survive", but if you can't survive while sticking to your goals & principles, what's the point? IMO you're just paper in the wind, going here & there not by your own will but rather by the will others impose on you that you acquiesce to. Yet it's not easy to know how to strike the proper balance.

I tend to think that if everything this ecosystem is to become is left solely up to shareholders (with BM / Stan / Devs only there to implement what shareholders dictate), it will become just another heavily regulated, mainstream tool that would accomplish very little towards the goal of financial freedom for everyone.

However, I do believe proposal voting is a very important tool and should be implemented. When is debatable, and how / who will control of the proposals is also an important consideration.

I myself would like to see a proposal / voting system that provides formal, qualitative and quantitative information about proposals. Many people have put forth their ideas on how to do this. I believe shareholder input should be considered with more weight than it has been in the past, but not so much that it completely dictates and defines what the BitShares ecosystem is. I say this to convey that my confidence is much greater in BM than in the shareholders, of which I have little idea who the major players are or what principles guide them. I am more willing to trust BM because I am more informed of the principles that guide his decisions, which in general I agree with, so I would like him & his team to still have a strong, dominant role in the trajectory of this ecosystem.

I see a well thought out proposal system as being necessary in BitShares' evolution. It would be a very useful tool in the hands of an open minded management team to help guide them and make informed decisions, as well as fostering a spirit of community, and empowerment to individuals to influence what BitShares is.

The principles upon which the BitShares ecosystem was started, are the same principles that started bitcoin, are the same as those that fueled this ecosystem's growth, and will continue to motivate it's continued growth and evolution into the future, if necessary by fork and redeployment as a new ecosystem if need be. You can't extinguish the inner craving for freedom.
Title: Re: Paid Workers Proposal for Review
Post by: Permie on May 10, 2015, 07:56:19 pm
this idea maybe is good , but we cannot change any rule, so it is useless, stop to discussing it , I had loss much, I don`t want to lose all

 +5%

We need to distinguish between property rights (which should always be secure) and system functionality which must continuously advance, or die.

The minute we decide that we cannot change to stay the best, a competitor will emerge that does not suffer under those constraints. 

Would you really want the results of our latest R&D to go to a competitor because BitShares cannot change to incorporate it?

Otherwise, BitShares would suffer the ultimate fate of Bitcoin.  Stuck roaring in the tar pits, failing to adapt, unable to compete.

Ultimately it is for the shareholders to decide.  But the choice is never simply whether to adopt a new technology or not.  It is always whether we want to allow some competitor pick it up and use it against us!

Evolution is an iterative process. Getting it right on the first attempt is nearly impossible. To have the best product out there and outpace the competition, Bitshares needs to be agile and focused on always improving the product as well as the market rules. Liquidity and 3rd party development will come naturally if Bitshares is the best offer out there, creating a whole ecosystem around the plaform. That's when network effect will start to have a significant impact. At that point, "Powered by Bitshares" will be a sign people will look at with confidence and trust.

But that scenario won't and can't happen if Bitshares' stakeholders automatically vote against what might be good ideas, in fear that change might have a negative impact on their investment. I, too, took a hit with the merger. But as I said, getting it right on the first attempt is nearly impossible, and only those who evolve ultimately survive.
+5% Stan!

So long as we don't stray so far from our principles that we cease to further the cause of financial freedom for all in favor of "the greatest profit / broadest adoption".

I agree, "you gotta do what you gotta do to survive", but if you can't survive while sticking to your goals & principles, what's the point? IMO you're just paper in the wind, going here & there not by your own will but rather by the will others impose on you that you acquiesce to. Yet it's not easy to know how to strike the proper balance.

I tend to think that if everything this ecosystem is to become is left solely up to shareholders (with BM / Stan / Devs only there to implement what shareholders dictate), it will become just another heavily regulated, mainstream tool that would accomplish very little towards the goal of financial freedom for everyone.

However, I do believe proposal voting is a very important tool and should be implemented. When is debatable, and how / who will control of the proposals is also an important consideration.

I myself would like to see a proposal / voting system that provides formal, qualitative and quantitative information about proposals. Many people have put forth their ideas on how to do this. I believe shareholder input should be considered with more weight than it has been in the past, but not so much that it completely dictates and defines what the BitShares ecosystem is. I say this to convey that my confidence is much greater in BM than in the shareholders, of which I have little idea who the major players are or what principles guide them. I am more willing to trust BM because I am more informed of the principles that guide his decisions, which in general I agree with, so I would like him & his team to still have a strong, dominant role in the trajectory of this ecosystem.

I see a well thought out proposal system as being necessary in BitShares' evolution. It would be a very useful tool in the hands of an open minded management team to help guide them and make informed decisions, as well as fostering a spirit of community, and empowerment to individuals to influence what BitShares is.

The principles upon which the BitShares ecosystem was started, are the same principles that started bitcoin, are the same as those that fueled this ecosystem's growth, and will continue to motivate it's continued growth and evolution into the future, if necessary by fork and redeployment as a new ecosystem if need be. You can't extinguish the inner craving for freedom.
+5%

Does anybody know who the major stakeholders are likely to be?
I'm wondering if they invested in Dan's vision for Bitshares or merely as a profit-seeking investment.
Are the shareholders likely to prioritise keeping BitShares free, open and anonymous?
Title: Re: Paid Workers Proposal for Review
Post by: Method-X on May 10, 2015, 10:26:01 pm
Are the shareholders likely to prioritise keeping BitShares free, open and anonymous?

That is a fantastic question and cuts to the very heart of our corrupt society.

Rhetorical question:

What do shareholders in traditional companies vote for? (short term profit or long term profit)
Title: Re: Paid Workers Proposal for Review
Post by: role on May 11, 2015, 03:08:19 am
谈钱之前,咱能先把内盘大姨妈治好吗?
Title: Re: Paid Workers Proposal for Review
Post by: fuzzy on May 11, 2015, 04:25:55 am
Are the shareholders likely to prioritise keeping BitShares free, open and anonymous?

That is a fantastic question and cuts to the very heart of our corrupt society.

Rhetorical question:

What do shareholders in traditional companies vote for? (short term profit or long term profit)

I'd imagine it depends, but is skewed generally toward short-term. 
Title: Re: Paid Workers Proposal for Review
Post by: BTSdac on May 11, 2015, 04:53:21 am
you gays do not know marketing  ,stupid discussing
Title: Re: Paid Workers Proposal for Review
Post by: lzr1900 on May 11, 2015, 06:34:55 am
谈钱之前,咱能先把内盘大姨妈治好吗?
内盘大姨妈已经止住了
Title: Re: Paid Workers Proposal for Review
Post by: BunkerChainLabs-DataSecurityNode on May 11, 2015, 07:33:16 am
Some interesting responses here.

I think we are approaching a tipping point for BitShares.
Title: Re: Paid Workers Proposal for Review
Post by: Ben Mason on May 11, 2015, 07:46:20 am
I'd love some help getting my head around this please!

Delegates are currently being paid to do all sorts of things including their primary role of block production. Delegates are paid with a % of tx fees up to 100%. The delegate voting system is being used not only to fund block production, but also other critically important activities like development.

Bm's proposal is to enable the seperation of block production (delegates) and other important activities (workers.) 

Where does the daily pool of worker/project funding come from?
Why is VC funding more likely with a split between delegates and workers?

Assuming the above is accurate, I support the proposal because whatever has encouraged this innovation, I have always liked the idea of delegates having a specific block production role which is easy for bts holders to assess and vote on. This is the most critical function that resists subversion. I also like the idea of voting in workers with additional, measurable objectives with defined requirements, remuneration and timescales. As others have pointed out, reputation within the system will become very valuable and help to maintain high standards. The developers need additional funding at this stage, however, the innovation will be very useful for the future so rather than voting in more core dev delegates, we might as well deal with it now.

I support all efforts to innovate, though I agree with all others who insist on adhering to clearly defined priorities or at the very least a fairly  open re-evaluation of them. Proposal discussions and testing ideas is essential to the health of the Bitshares community and ensuring our competitive edge.
Title: Re: Paid Workers Proposal for Review
Post by: pc on May 11, 2015, 09:01:33 am
Delegates are currently being paid to do all sorts of things including their primary role of block production. Delegates are paid with a % of tx fees up to 100%. The delegate voting system is being used not only to fund block production, but also other critically important activities like development.

Bm's proposal is to enable the seperation of block production (delegates) and other important activities (workers.) 

Where does the daily pool of worker/project funding come from?

Delegates are being paid with a percentage of tx fees plus dilution of max 50 BTS/block. BM's proposal separates the funding of delegates and other workers by paying delegates from tx fees, and other workers from dilution at a rate of max 50 BTS/block.
Title: Re: Paid Workers Proposal for Review
Post by: Ben Mason on May 11, 2015, 09:13:31 am
Delegates are currently being paid to do all sorts of things including their primary role of block production. Delegates are paid with a % of tx fees up to 100%. The delegate voting system is being used not only to fund block production, but also other critically important activities like development.

Bm's proposal is to enable the seperation of block production (delegates) and other important activities (workers.) 

Where does the daily pool of worker/project funding come from?

Delegates are being paid with a percentage of tx fees plus dilution of max 50 BTS/block. BM's proposal separates the funding of delegates and other workers by paying delegates from tx fees, and other workers from dilution at a rate of max 50 BTS/block.
Thanks pc!
Title: Re: Paid Workers Proposal for Review
Post by: helloworld on May 11, 2015, 09:35:24 am
The delegate voting system is OK.

BTS price falling down and down, Thare must be something wrong was happened, but it could't made by the delegate voting system.

The system run well

So , think about the real reason why the price continue falling down!

Let's the free market decide something' price.
Let‘s the shareholders decide BTS where will go.
Title: Re: Paid Workers Proposal for Review
Post by: role on May 11, 2015, 09:56:21 am
谈钱之前,咱能先把内盘大姨妈治好吗?
内盘大姨妈已经止住了

bitusd区去看看再说
Title: Re: Paid Workers Proposal for Review
Post by: Stan on May 11, 2015, 11:37:51 am
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.
Title: Re: Paid Workers Proposal for Review
Post by: BunkerChainLabs-DataSecurityNode on May 11, 2015, 11:56:47 am
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.
Title: Re: Paid Workers Proposal for Review
Post by: helloworld on May 11, 2015, 02:41:04 pm

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?
Title: Re: Paid Workers Proposal for Review
Post by: helloworld on May 11, 2015, 03:00:19 pm
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.
Title: Re: Paid Workers Proposal for Review
Post by: xeroc on May 11, 2015, 03:42:43 pm
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
Title: Re: Paid Workers Proposal for Review
Post by: Thom on May 11, 2015, 06:56:45 pm
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?
Title: Re: Paid Workers Proposal for Review
Post by: bytemaster on May 11, 2015, 07:58:00 pm
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.
Title: Re: Paid Workers Proposal for Review
Post by: Ander on May 11, 2015, 08:15:54 pm
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?
Title: Re: Paid Workers Proposal for Review
Post by: bytemaster on May 11, 2015, 08:24:28 pm
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.
Title: Re: Paid Workers Proposal for Review
Post by: mint chocolate chip on May 11, 2015, 09:04:11 pm
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.
Title: Re: Paid Workers Proposal for Review
Post by: Xeldal on May 11, 2015, 09:13:38 pm

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.
Title: Re: Paid Workers Proposal for Review
Post by: bytemaster on May 11, 2015, 09:16:07 pm

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.   
Title: Re: Paid Workers Proposal for Review
Post by: Thom on May 11, 2015, 10:20:01 pm
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.
Title: Re: Paid Workers Proposal for Review
Post by: bytemaster on May 11, 2015, 10:33:58 pm
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:

Quote
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. 


Title: Re: Paid Workers Proposal for Review
Post by: yiminh on May 11, 2015, 10:49:07 pm
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:

Quote
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!
Title: Re: Paid Workers Proposal for Review
Post by: Pheonike on May 11, 2015, 10:49:49 pm
I think witness showed be called producer. Just me 2bts. :) . Witness sounds to removed from the process.
Title: Re: Paid Workers Proposal for Review
Post by: sittingduck on May 11, 2015, 11:01:48 pm
Yiminh. His paid delegate position says otherwise.   These ideas clearly are focused on decentralizing control and minimizing regulatory risk.   Bitcoin has developers set fees and blocksizes. It is a major challenge to change these this.  With these tools BM is giving us the power to make changes without hard forks or developer intervention.  No one else has anything close. 


Sent from my iPhone using Tapatalk
Title: Re: Paid Workers Proposal for Review
Post by: clayop on May 11, 2015, 11:05:54 pm
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!

Price does tell something but does not tell everything. The main reason of falling price may be stock market bubbles. When the bubble pops, prepared cryptos will revive.
Title: Re: Paid Workers Proposal for Review
Post by: julian1 on May 11, 2015, 11:07:02 pm
So we are going to rewrite bitassets ( now up to version 3), and we are going to rewrite dpos (now version 2) and we still haven't got a version 1 of the client.

All this discussion about the micro-management of incentives and roles is no different to the government ruling by decree and setting up distortions and inefficiencies in the free-market.

A seamless Web Client with a contract execution VM, backed by a low-cost distributed consensus algorithm + community is what is needed to attract the people who will build out an ecosystem.
Title: Re: Paid Workers Proposal for Review
Post by: zerosum on May 11, 2015, 11:08:37 pm

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


Quote
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.





I thinks this makes it clear now (for Thom and others) and easy to remember!

There will be 3 roles:

1) Jehovah's - short from "Jehovah's Witnesses" - produces blocks!

2) Writers - short from "Code Writers" - the main function that a 100% paid delegate in version 1.0 used to do.

3) Signers - also easy to remember from -"co-signer on a dynamic multi-sig signers" as well  as "the main blockchain parameter (the constitution of the blockchain) signers"


 :)
Title: Re: Paid Workers Proposal for Review
Post by: Ander on May 11, 2015, 11:10:18 pm
I agree that producer (short for block producer) seems like a better name to me than witness. 

Or maybe even call it a "miner"?



Regarding the genesis account.  Lets say that people wanted to change the block size (a current topic being debated in bitcoin where it is hard to resolve because miners have to agree on a hard fork).  How would that work?

Would the genesis account propose a block size change, and then shareholders vote on it over two weeks?   Would delegates be voting for it?
Title: Re: Paid Workers Proposal for Review
Post by: yiminh on May 11, 2015, 11:10:48 pm
Yiminh. His paid delegate position says otherwise.   These ideas clearly are focused on decentralizing control and minimizing regulatory risk.   Bitcoin has developers set fees and blocksizes. It is a major challenge to change these this.  With these tools BM is giving us the power to make changes without hard forks or developer intervention.  No one else has anything close. 


Sent from my iPhone using Tapatalk

People don't have time to mess with voting of single delegates with so many alt-coins out there, they just sell BTS, that's called voting with your feet, current price means all delegats are voted out!
Title: Re: Paid Workers Proposal for Review
Post by: clayop on May 11, 2015, 11:14:42 pm
So we are going to rewrite bitassets ( now up to version 3), and we are going to rewrite dpos (now version 2) and we still haven't got a version 1 of the client.

All this discussion about the micro-management of incentives and roles is no different to the government ruling by decree and setting up distortions and inefficiencies in the free-market.

A seamless Web Client with a contract execution VM, backed by a low-cost distributed consensus algorithm + community is what is needed to attract the people who will build out an ecosystem.

Based on my experience of persuading people to invest Bitshares, almost all of them are not ready to get involved in Blockchain technology. What we need is a firm model in which employees, shareholders, and the blockchain are interplay with healthy profit-cost structure.

Remember, Bitshares is a DAC. People want to be shareholders of this DAC only if it makes profits.
Title: Re: Paid Workers Proposal for Review
Post by: clayop on May 11, 2015, 11:19:50 pm
In DPOS 2.0, what condition makes burned fees (or profits) greater than token newly created (cost)?

I think reverse-dilution is very important point for potential investors.
Title: Re: Paid Workers Proposal for Review
Post by: merivercap on May 11, 2015, 11:42:35 pm
I think witness showed be called producer. Just me 2bts. :) . Witness sounds to removed from the process.

Isn't 'validator' the usual term used?

Title: Re: Paid Workers Proposal for Review
Post by: starspirit on May 11, 2015, 11:51:53 pm
Suppose stakeholders are simultaneously funding two projects that have a point of irreconcilable conflict in their design (i.e. only one or the other change can exist once made). For example, let's suppose it was two completely different designs for a bitAsset or UIA structure, and the community was divided on which was best. What is the process by which the community would ultimately enforce adoption of one over the other? Is it a case that this could lead to 2 differently coded clients, and how is that resolved by the community/market?
Title: Re: Paid Workers Proposal for Review
Post by: Thom on May 12, 2015, 03:17:56 am
Lucky for you I have been working on just such a paper... here is a preview of the motivation for this:

Quote
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. 

That certainly defined the roles and their functions, but many other questions remain unanswered. I look forward to your paper and the answers to the questions it will hopefully provide.

Are all delegates required to sign off on the multi-sig account to change anything?

My first impression is DPoS 2.0 sounds better and more formal / mature than DPoS 1.0 and I like it. I am somewhat skeptical about whether the delegate pool (will there be a limit on the number of delegates?) can reach unanimous decisions to satisfy the multi-sig, but the concept seems quite sound.

PS - a minor nit: I don't care for the "witness" label either. Producer, verifier, certify-er, or even "blockhead" seem better, but hey - it's a subjective call, and I can live with it if necessary.
Title: Re: Paid Workers Proposal for Review
Post by: jsidhu on May 12, 2015, 04:12:39 am
In DPOS 2.0, what condition makes burned fees (or profits) greater than token newly created (cost)?

I think reverse-dilution is very important point for potential investors.
I agree... investors consider that bullish for hodling.
Title: Re: Paid Workers Proposal for Review
Post by: triox on May 12, 2015, 04:29:33 am
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. 

Is this a good moment to reintroduce the idea of partial "witness" randomization?
https://bitsharestalk.org/index.php/topic,15015
Title: Re: Paid Workers Proposal for Review
Post by: BunkerChainLabs-DataSecurityNode on May 12, 2015, 04:54:34 am
This is looking good.

I think while the optics of the term 'witness' don't seem appealing, I can tell that this choice was made largely out of creating some legal protection to the roll and perhaps some flexibility so as to not get hooked into a particular regulatory pigeonhole simply because we call it something. For example, there are certain ramifications if in this 2.0 version instead of calling delegates delegates we called them 'accountants'. In terms of tax code and such, the term 'producer' could have certain ramifications further complicated by what it is we are actually producing.

I think the term denotes a balance to the whole system so that there is still oversight even to each delegate providing a counterparty verification system of sorts. Delegates working with 'producers' almost reminds me of terms like Congress and big business. Witness is more along the lines of what someone who is trusted to verify does.. a notary public for example is needed to witness the verification of documents.. in this case.. the verification of transactions.

Overall as far as 2.0 goes.. this is all far less scarier than it initially felt like it was going to be. While it certainly added a degree of complication.. all higher organisms are complex. We are only seeing a small preview so there is more to this.. if you like it.. TIME TO BUY! :D

I am excited to see how all of this comes together.

(http://i61.tinypic.com/30t78f6.jpg)
Title: Re: Paid Workers Proposal for Review
Post by: starspirit on May 12, 2015, 05:34:59 am
I like the idea of not forcing workers and delegates to be signers (witnesses). But I feel the witness/worker/delegate role split is possibly too prescriptive. Ultimately we need to allow for many different forms in which people may add value to the system and community, and allow stakeholders to empower them. I suspect that in very little time we may be finding many cases of such people who do not fit any of these 3 prescribed roles.

Title: Re: Paid Workers Proposal for Review
Post by: xeroc on May 12, 2015, 08:03:29 am
This is looking good.

I think while the optics of the term 'witness' don't seem appealing, I can tell that this choice was made largely out of creating some legal protection to the roll and perhaps some flexibility so as to not get hooked into a particular regulatory pigeonhole simply because we call it something. For example, there are certain ramifications if in this 2.0 version instead of calling delegates delegates we called them 'accountants'. In terms of tax code and such, the term 'producer' could have certain ramifications further complicated by what it is we are actually producing.

I think the term denotes a balance to the whole system so that there is still oversight even to each delegate providing a counterparty verification system of sorts. Delegates working with 'producers' almost reminds me of terms like Congress and big business. Witness is more along the lines of what someone who is trusted to verify does.. a notary public for example is needed to witness the verification of documents.. in this case.. the verification of transactions.

Overall as far as 2.0 goes.. this is all far less scarier than it initially felt like it was going to be. While it certainly added a degree of complication.. all higher organisms are complex. We are only seeing a small preview so there is more to this.. if you like it.. TIME TO BUY! :D

I am excited to see how all of this comes together.
I second that!
Title: Re: Paid Workers Proposal for Review
Post by: bytemaster on May 12, 2015, 12:54:50 pm
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. 

Is this a good moment to reintroduce the idea of partial "witness" randomization?
https://bitsharestalk.org/index.php/topic,15015

All that does is increase costs.  Under the proposed system there are no limits so if the stakeholders can muster enough votes you can have as many witnesses as desired, but the total COST of operating the system will be higher too and therefore profits will be lower.
Title: Re: Paid Workers Proposal for Review
Post by: triox on May 13, 2015, 04:09:47 pm
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. 

Is this a good moment to reintroduce the idea of partial "witness" randomization?
https://bitsharestalk.org/index.php/topic,15015

All that does is increase costs.  Under the proposed system there are no limits so if the stakeholders can muster enough votes you can have as many witnesses as desired, but the total COST of operating the system will be higher too and therefore profits will be lower.

I don't believe this affects costs, since it's the same number of nodes that have to reach agreement in any given round.

Taking the numbers from the original thread: the 101 active delegates only loose 5% of revenue in exchange for the next 900 nodes getting to sign a block every 48 hours on average.

This gets even more important under the proposed system, since a lower number of signers will be easier to deanonymize, DDoS or hack. A percentage of signers being from a large pool may be a desirable safety feature.
Title: Re: Paid Workers Proposal for Review
Post by: pc on May 13, 2015, 04:38:23 pm

I don't believe this affects costs, since it's the same number of nodes that have to reach agreement in any given round.

Taking the numbers from the original thread: the 101 active delegates only loose 5% of revenue in exchange for the next 900 nodes getting to sign a block every 48 hours on average.

It increases the cost because it means that the top 1000 delegates have to maintain active nodes and must always be prepared to sign a block. The delegate payments must somehow cover that cost, otherwise 899 of those 1000 have no reason to keep their nodes online - which would result in an overall worse reliability of the network and higher average transaction times.
Title: Re: Paid Workers Proposal for Review
Post by: roadscape on May 18, 2015, 06:26:32 pm
Lucky for you I have been working on just such a paper... here is a preview of the motivation for this:

Quote
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. 


I like the separation of powers and particularly the idea of the genesis account, with its delayed/rejectable txs.. very cool.
Do you envision the genesis account containing funds and making transfers?
Can anyone transfer funds to this account without approval?
Title: Re: Paid Workers Proposal for Review
Post by: bytemaster on May 19, 2015, 02:07:42 pm
Lucky for you I have been working on just such a paper... here is a preview of the motivation for this:

Quote
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. 


I like the separation of powers and particularly the idea of the genesis account, with its delayed/rejectable txs.. very cool.
Do you envision the genesis account containing funds and making transfers?
Can anyone transfer funds to this account without approval?

Yes and Yes.   
Title: Re: Paid Workers Proposal for Review
Post by: Riverhead on May 19, 2015, 04:22:56 pm

Starting to get my head around the new structure. I really really like it. A question, out of many to come I'm sure, is why does the genesis account need money? Is the fee to change a blockchain parameter greater than a transaction fee?

If this is answered elsewhere a simple RTFM will do :).
Title: Re: Paid Workers Proposal for Review
Post by: Pheonike on May 19, 2015, 04:36:32 pm

Will there be an exclusion that does not allow worker/witness/delegates to be from the same account/address?  If someone is going to fill more than one of those roles simultaneously there should be clear separation on the chain as well.
Title: Re: Paid Workers Proposal for Review
Post by: Riverhead on May 19, 2015, 04:49:00 pm

Will there be an exclusion that does not allow worker/witness/delegates to be from the same account/address?  If someone is going to fill more than one of those roles simultaneously there should be clear separation on the chain as well.

I can understand worker and witness being the same person. They'd be like the backbone delegates we have now. However I can understand why being a delegate and either of the two other roles at the same time would be a conflict of interest.
Title: Re: Paid Workers Proposal for Review
Post by: Pheonike on May 19, 2015, 05:02:01 pm

Im saying the account/address used for worker/witness/delegate should not be able to voted into more than one of those roles simultaneously. If someone wants to be a worker and witness then those should be two different accounts and campaigned for separately. They real life person is a separate issue.
Title: Re: Paid Workers Proposal for Review
Post by: BunkerChainLabs-DataSecurityNode on May 19, 2015, 05:11:08 pm

Will there be an exclusion that does not allow worker/witness/delegates to be from the same account/address?  If someone is going to fill more than one of those roles simultaneously there should be clear separation on the chain as well.

I can understand worker and witness being the same person. They'd be like the backbone delegates we have now. However I can understand why being a delegate and either of the two other roles at the same time would be a conflict of interest.

It's going to be interesting to see how the community chooses to handle that. Perhaps it's better to allow all proposals to be brought forward and allow all of it be openly considered. Otherwise I it could lead to a culture of sock-puppets and arms-length affiliated operators within the ecosystem. At the end of the day, even if they are in all spaces, they are still just one of many who can provide check and balance as well.

Perhaps in situations like that then a multi-sig is standard.. or maybe the multi-sig being the standard for all then conflict becomes moot.

I think Pheonike regarding separate accounts is good at least to make the accounting easier for everyone to follow. I don't know though in regards to splitting their voting power.. because then their stake will be halfed or thirded if I am understanding what you are suggesting correctly.
Title: Re: Paid Workers Proposal for Review
Post by: Pheonike on May 19, 2015, 05:47:22 pm

I'm saying if you want to be a witness then set up a account and campaign for votes. If you want to be a worker then send in proposals and campaign for votes.  I'm saying a vote for for you be a witness should not be included in the the vote for you to worker if you are using the same account. The cleanest way to avoid that is make it two separate accounts.
Title: Re: Paid Workers Proposal for Review
Post by: bytemaster on May 19, 2015, 05:48:29 pm

I'm saying if you want to be a witness then set up a account and campaign for votes. If you want to be a worker then send in proposals and campaign for votes.  I'm saying a vote for for you be a witness should not be included in the the vote for you to worker if you are using the same account. The cleanest way to avoid that is make it two separate accounts.

They would be voted separately.
Title: Re: Paid Workers Proposal for Review
Post by: BTSdac on May 20, 2015, 06:44:29 pm

I'm saying if you want to be a witness then set up a account and campaign for votes. If you want to be a worker then send in proposals and campaign for votes.  I'm saying a vote for for you be a witness should not be included in the the vote for you to worker if you are using the same account. The cleanest way to avoid that is make it two separate accounts.

They would be voted separately.
Hi BM I have to question ,
1.there is no encourage for people to vote more ,
2. there is no vote term vote is permanent,  it make delegate would very positive while vote campaign, but after that motive is weak by time . I don`t know if you is be aware of this