Bitcoin Forum

BACKGROUND for Poll:

Original Post https://bitcointalk.org/index.php?topic=342431.0

Edit: To clarify this proposal is predicated upon the Proof of Stake system and Distributed bounty systems being implemented in order to direct the distribution of these Dev MSC in a decentralized manor.

From original post.

"I propose we formalize the distribution of "Dev MSC", to mirror the amount of Dev MSC generated each month. Further more that these Dev MSC be distributed in proportion to the amount of BTC won by participants in Mastercoin bounties that month. With the intension being, that this distribution process will be fully controlled by the Mastercoin community via the existing Bounty system and up coming Proof of Stake voting.  

It seems a simple and elegant distribution curve, and is awarded in proportion to the the BTC anyone earns or wins as part of working on the Mastercoin implementations, competitions and bounties. That way everyone can be confident in how this gets distributed and earning some of the Exodus funds comes with an automatic bonus of earning a proportional amount of Dev MSC.

Lets talk some simple math here.

Simple Dev MSC Distribution Equation:  A / B = C * D = E
(A) Amount of awards an individual earns in BTC during a 30 day period, divided by,
(B) the total amount of BTC awarded during that 30 day period, equals
(C) his or her individual award percentage, times
(D) the total Dev MSC generated during that 30 day period, equals
(E) the amount of Dev MSC awarded to the individual in addition to his BTC awards during the 30 day period.

Example #1 (using round numbers):
A (100 BTC) / B (1,000 BTC) = C (10%) * D (1,000 MSC) = E (100 MSC)

There are 56,316 Dev MSC that will ever be generated.
28,158 Dev MSC will be generated this year or 2,346 MSC each month.
So if a developer won 10% of the bounties this month he or she would earn 234.6 Dev MSC (worth 35.19 BTC / $24,633 USD at current MSC / BTC / USD prices)."

BACK GROUND FOR THOSE THAT HAVEN'T READ THE MASTERCOIN SPEC 1.2

There are two main types of Mastercoins. MSC and Dev MSC (there are also Test MSC, but I won't get into those here). All original Mastercoins (MSC) were generated between August 1st and August 31st by all those that sent funds to the "Exodus Address", these total 563,162. In addition the Mastercoin protocol generated 10% additional Dev MSC (originally termed Reward MSC) which total 56,316 Dev MSC. Combined you get all the Mastercoins that will ever exist 619,478.

Here is the reference from the Mastercoin Spec:  https://github.com/mastercoin-MSC/spec
"For every 10 Mastercoins sold, an additional “dev Mastercoin” was also created,"

The generation of these Dev MSC is controlled by an algorithm described in the spec.
"Which are being awarded to the Exodus Address slowly over the years following the fundraiser. These delayed Mastercoins will ensure that we (the Mastercoin Foundation) have funding to complete the features desired by users. The reward is be structured so that we receive 50% of the reward by one year after the initial sale, 75% by a year later, 87.5% by a year later, and so on". Here is a Google Doc that has been public since the beginning of the project simply calculates how many Dev MSC are available for Distribution each year. https://docs.google.com/spreadsheet/ccc?key=0AmR_eSvAkuXSdDI3Y1JnVjFvUDBXOWZiZl8zZ2Rkamc&usp=sharing

You can see the current total of the accumulating Dev MSC here: https://docs.google.com/a/bitangels.co/spreadsheet/ccc?key=0AtCyUJvk_IyNdGpVcnpBN2tOczFmbVRnck5TWjZuRFE#gid=1

8,080 MSC generated so far with 6,580 not yet Distributed via a bounty.

There isn't a description in the protocol on how the Dev MSC are to be distributed or at what rate.

Thanks for participating in the poll.

I have an issue with the wording of this poll.

"proportionately to each developer's contributions"

What about other people except developers like project managers, documentors, etc. ?
How does the community measure each developers contributions?

I think if you turned the first option into "Distribute 100% of the Dev MSC into a community controlled pool, who will then decide based on Proof of Stake how and whether to spend this pool", I would be 100% down with this option.

The community can then decide ad hoc whether the immediately spend all MSC, or slow down when needed (or perhaps even borrow more funds (https://trello.com/c/C3zc82Ob/43-lending-spec) in order to accelerate if it wants to).

IMO this is the only viable option. Why decentralize 50% of the Dev MSC when we can just as easily decentralize control of 100% of them? We decide then ad hoc how to spend them.

https://bitcointalk.org/index.php?topic=75029.0

I don't think you can put micro-level decisions up to a vote and expect a good outcome. People don't have enough time to investigate every little thing. If most people abstain due to time constraints and ignorance, special interests will end up dominating the voting. That's bad for everyone.

It would be better to elect a general manager and allocate a budget to him. If he fucks up, then his budget can get cut or he can be replaced. These are macro-level issues which it makes sense to decide by vote.

I suggested this in the linked post in April 2012. It is still a good idea.

Commentary: We have pools for mining, elected heads of state, and CEOs for a reason. Decentralizing every decision = a committee makes every decision. Ugh. Hierarchies are good too. They just need to be kept accountable.

Ripper and I talked and we are now aligned.

It was just a confusion on the wording of the Poll.

We both agree that 100% of the Dev MSC should be handing out via the Bounty System / Proof of Stake, and until that time 100% of the Dev MSC should be handed out via the current bounty system.

The sooner we get the distributed bounty system / proof of stake system in place the better, but in the mean time lets get those Dev MSC to work for the Developers doing such a great job building the Mastercoin features.

Will read this fully at home and cast my vote later.

My reservation is that with bounties, we never know how long it will take to finish. How do you decide for what length of time someone deserves x percentage of the newly released MSC??

 I voted no for that reason, but I reserve in some use cases that it could be more useful to pay out a percentage of the newly released MSCs in l time, but still, it's incredibly difficult deciding what that percentage is even worth, especially before the fact. I voted no because we can exercise more financial latitude over what is spent and for how much. From a distributed voting perspective, an actual amount for l time vs x% of the new coins between l time is easier to evaluate, IMHO.

I won't get in to this issue atm - just make sure that either way the dev team will end up working with a Project manager OR scrum/agile..

Crossposted from the main thread (since it's more relevant here):


You have to be careful here with that kind of blind "firehose" strategy. As the developer behind "masterdaemon", which will soon be released, I will probably soon be the "5th" or "6th" developer. Why, in that case, should any of the other developers help me at all, if all I'm essentially doing is pulling money away from them? This kind of distribution scheme has a negative incentive to grow the dev community.

I mean, hell, I'd love to get this product out, sit around, and collect a "paycheck" in MSC dev funds, but I don't think that's very effective (speaking against my self-interest here). I would pay the active developers a smaller amount of MSC on an ongoing basis (on top of what you pay them in any kind of full-time salary, etc), and save at least half of that new amount every month for devs that release something NEW into the
community. This will incentivise people to develop new products and services for Mastercoin, and it will encourage new devs to join up (or existing devs to develop additional products/services), instead of making some un-inviting "money club" where all you're doing when you join up is taking away money from someone else. Coins awarded would be a subjective measure of how valuable the community finds this new product (we could even have a voting thread of mechanism for it).

I learned a lot of lessons starting and growing companies. I see a lot of these same mistakes being made (or being proposed) in this project. Especially when it comes to compensating and motivating developers/employees. Do we have anyone on the board that has "boots on the ground" operational experience growing profitable software/tech startups with more than 10 employees?

I can only speak for myself. I've been an entrepreneur for 12 years. I've built 5 successful companies in software / technology grown two of them past 30 employees each. www.linkedin.com/in/davidajohnston/

I'm a big believer in vesting people in the outcome of a projects success. I've run teams as large as 25 with a monthly burn rate of $25,000 thanks to being generous with shares in the company. That way everyone is aligned and building the longterm value of the company, not just sitting around collecting a big "salary".

The other point I would make is this. The reason we have ASIC mining chips today is that miners knew there would be 50 Bitcoins mined each block day and day out for the first four years. They had confidence in the distribution rate and didn't have to account for human behavior that changed day to day.

We can accomplish similar great feats if we also have a standard distribution rate. We would have more developers who value the Dev MSC and they would pull in more developers still until the market reached a balance with dozens of developers being compensated on a full time basis, not through a centralized salary system, but through a decentralized bounty system.

Lets have enough faith in our developers that they will come up with amazing things if place the right incentive structure in place.

I pose this conundrum to you David: Considering that even if we thought Candidate A deserved x% of the amount of new MSCs released in l time period, the award process involved (waiting for a contest to end, judging, etc) will not lead to a linear or any sort of regular distribution rate.

Have any of your companies ever had a constant new stream of shares to give out, or did you know how exactly many you have and how many you would be willing to give out?

Vokain,

Thanks for the good questions. Here are my thoughts on the different concerns you bring up.

Question 1. Considering that even if we thought Candidate A deserved x% of the amount of new MSCs released in l time period, the award process involved (waiting for a contest to end, judging, etc) will not lead to a linear or any sort of regular distribution rate.

Answer: This is one of the first questions that came up, given our current big contest for the Distributed Exchange is a multi month effort. What I've proposed to the board and the community is that in future none of our contests run longer than 30 days from the time of original announcement to pay out. This will mean breaking up large contests / features into smaller milestones, which I actually believe will be more effective from a participation / judgement perspective. The Board is already headed in this direction as it would be much harder to attract developers full time, if bounties are being paid out at a rate radically longer, than the typical 30 day period most people have their bills set to.

Question 2. Have any of your companies ever had a constant new stream of shares to give out, or did you know how exactly many you have and how many you would be willing to give out?

Answer: Actually all of my companies have had a constant new stream of shares to vest with employees / founders / advisors. The system we had in place was 4 year vesting schedules that vested new shares with employees each month they stayed with the company. The investors were perfectly happy with this as the employees added more value to the company than the cost of their new shares, so the price of each share increased year by year even though the pool of shares was slowly increasing in size. We have a very similar opportunity here with the Distribution Rate of the Dev MSC. The current version of the protocol says that the rate of Dev MSC "generation" shall be 50% the first year, 25% the second year, 12.5% the third year, 6.25% the fourth year and so on. Thus 93.75% of the total 56,316 Dev MSC that will ever be generated will be vested to developers / contributors the first four years of the project. Which I think is logical as the first four years are by far the most important and early / risky stages of the project. We had a similar "risk premium" for all employees who joined the company early in my technology companies. Those that join the project when it has 5 employees are taking a greater risk than those joining when the project has 50 or 500 employees. And thus should be rewarded for taking that risk.