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.
Great.This.
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.
Great.This.
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.
Plus +5% for finally having workers and signers!!
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?
Great.This.
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.
+5% +5%
Step 3: Pay out projects in order of total approval once per day until all 432,000 BTS has been consumed.
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.
Great.This.
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.
Plus +5% for finally having workers and signers!!
+5% +5%
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(?)).
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. :)
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(?)).
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?
My suggestions based on my previous post here: https://bitsharestalk.org/index.php/topic,1692.msg18720.html#msg18720How 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/
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/
http://www.jobauctions.com/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/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/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.
Wouldn't a reputation system help with all the problems you are talking about PC?
http://www.jobauctions.com/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.
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^^)
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?
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 ..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 ..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)
but i see advantages is separating block signers from feed publishes and businesses ... can we have both? .. maybe after 1.0 ..
http://www.jobauctions.com/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.
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^^)
I would like to ask: What is the big problem with the current system which requires this change?We have an integrated solution to 17 different issues. Relax.
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".
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. :)
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. ;-)
My suggestions based on my previous post here: https://bitsharestalk.org/index.php/topic,1692.msg18720.html#msg18720How 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/
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.
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.
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
My suggestions based on my previous post here: https://bitsharestalk.org/index.php/topic,1692.msg18720.html#msg18720How 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.
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.
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?
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?
钱包都没法正常使用的前提下就别去谈其他的鸡巴玩意。
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.
:)
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".
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.
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.
"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?
“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
;)
“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.
http://www.jobauctions.com/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.
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^^)
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.
;)
My suggestions based on my previous post here: https://bitsharestalk.org/index.php/topic,1692.msg18720.html#msg18720How 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.
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.
http://www.youtube.com/watch?v=wC871hNBig4&t=1m6s
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!
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
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/
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.
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....
They will probably announce a Ripple partnership due to the recent fine.???
http://www.reddit.com/r/Bitcoin/comments/358wcb/itbits_exchange_allows_frontrunning/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/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....
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%
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?
Quote16 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)
Quote from: yiminhQuote16 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!
Quote from: yiminhQuote16 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.
I don't think he was proposing to change the dilution rate, just the power stakeholders have.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.
Sent from my iPhone using Tapatalk
I don't think he was proposing to change the dilution rate, just the power stakeholders have.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.
Sent from my iPhone using Tapatalk
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
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%
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 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!
+5% Stan!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%+5% Stan!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.
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.
Are the shareholders likely to prioritise keeping BitShares free, open and anonymous?
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)
谈钱之前,咱能先把内盘大姨妈治好吗?内盘大姨妈已经止住了
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?
Thanks pc!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.
谈钱之前,咱能先把内盘大姨妈治好吗?内盘大姨妈已经止住了
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.
I don't think he was proposing to change the dilution rate, just the power stakeholders have.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.
Sent from my iPhone using Tapatalk
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
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.
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.
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?
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.
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?
The .9 series has given me more issues than any before it.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 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.
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.
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.
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.
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.
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:QuoteUnder 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!
Stan used "workers, signers & knob turners", just to confuse things even more.QuoteUnder 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.
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
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.
I think witness showed be called producer. Just me 2bts. :) . Witness sounds to removed from the process.
Lucky for you I have been working on just such a paper... here is a preview of the motivation for this:QuoteUnder 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.
In DPOS 2.0, what condition makes burned fees (or profits) greater than token newly created (cost)?I agree... investors consider that bullish for hodling.
I think reverse-dilution is very important point for potential investors.
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.
This is looking good.I second that!
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.
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
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.
Lucky for you I have been working on just such a paper... here is a preview of the motivation for this:QuoteUnder 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.
Lucky for you I have been working on just such a paper... here is a preview of the motivation for this:QuoteUnder 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?
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.
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.
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.
Hi BM I have to question ,
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.