Topic: MasterCoin: New Protocol Layer Starting From “The Exodus Address” - page 43. (Read 448462 times)

This is good news, great to have Tachikoma in the team .

Great. I think it's time for me to buy more mastercoins. :-)

I'm about to make a couple payments from 1Exodus, including sending more BTC to secure storage:

200 BTC to 18S23kiGWkgVtsUuXMkvLohGxhVasujyMa
200 BTC to 1G6YQefEZEweatGsmVJFDRVSySYTzgXWg6
200 BTC to 1L2uRf8ShoDTZ67cU4Wq8VLJbFddvr5jWS
200 BTC to 1NccyJvcPhu3qhZ7LwFBbQygFsNGDjLdT4
200 BTC to 19jvwkkn9r27w479zAdLS51JXzPjVaR56A

Also, a payment to prophetx for his work on our blog:
0.24691358 to 1GFC6Kc1UiH8m48EPCFpK7j8Cs9hbyyF55

Ledger of all project expenditures is here: https://docs.google.com/spreadsheet/ccc?key=0AtCyUJvk_IyNdGpVcnpBN2tOczFmbVRnck5TWjZuRFE#gid=0

Thanks!

David: Regarding Who do we want as Board Members, I do agree with you in general on those points. However, I would say that the person must have some level of focus on Mastercoin. For instance, if Brock is so busy he has no time to ever engage the Mastercoin community or promote Mastercoin in his interactions with others, what difference does it make? In that case, Mastercoin board membership would just be another honary distinction to him, where it might have gone further with someone else.

I think the board composition should be a good mix of folks that are both connection and experience-heavy. I do see the value in what a board like this could do for Mastercoin, even though most of them would probably not have day-to-day involvement.

Regarding Vote Capping, I'm looking forward to your proposal. I think eventually this may not be an issue, but I see it as a potentially major issue in the foreseeable future (as JR, and the top 3 holders for that matter, are sitting on a LOT of Mastercoin). JR has also made it clear that he does not intend to sell for awhile. I think what would be best for the community would be working through a fair and reasonable proposal like you are putting together, where we can get JR onboard (and communicating that much), as well as the members of the community that have smaller balances but may be "hungrier" as LuckyBit stated. These folks can have a ton to contribute, if they think their voice matters and makes a difference.

Regarding your voting schedule, that seems alright to me, especially if things continue to move forward like this under the provisional board (meaning that we don't have a lot of lost time and motion until these elections).

Lastly, in respect to Tachikoma's mastercoind proposal, I am largely in agreement with that, pending a concern or two. I've posted my comment in his thread.

Thanks to everyone that's commented. I'm starting to really believe that we're getting Mastercoin on track to a bright future.

-Robby

Robbie, David, Tachikoma...this is all great news..I thank you for your efforts. I am glad to this thing heading in the right direction finally setting the foundation for efficiency and success...

I just posted our proposal for a reference implementation, comments/critique welcome.

It would be impossible to enforce 'one person, one vote'. There's nothing to stop someone from distributing his 10,000 MSC across many addresses and voting as many times as he wants.

I see where you are coming from, but I think that if there were somebody whom the community trusted who was in charge of hiring developers, then the security mistake could be avoided, and the hiring process, from the community's standpoint, would be much simpler. What do you think?

Tachikoma that's great news! I have seen your skills and Mastercoin could hit sky high with you!!

I disagree. I think one man one vote is better but my opinion doesn't matter because I don't have 10,000 MSC.

The reason it matters to me is because I think people who are already rich may end up with different priorities from people who aren't. If you're a millionaire already you might not make the same decisions. If someone has only a few MSC they would want those few MSC to be worth a lot, but if someone has a lot of MSC they might not care as much how MSC are worth because they have enough money already.

People with less MSC are more hungry. I've seen with BTC that some of the most active and true believers also don't have a lot of BTC so they believe BTC will go to the moon and they will be the strongest hands who wont sell. Someone who has 1000 BTC or more will probably be thinking about selling it right now.

You have to make sure any developer you choose can be trusted by the community and someone who cares about the Mastercoin project. Just choosing random developers for critical functionality is a security mistake.

Hope the family sees the positives. 

Great news! I hope you guys are able to sort something out 

Hey guys,

I just had a interesting call with Ron so I thought I would chime in.

Ron made me a very interesting offer for the lead developer position, one that might actually be good enough for me to drop my day job. One of the things we discussed was the need for a reference implementation. I will be creating a topic in the coming days to specify my thoughts on this reference implementation and how it might differ from Robby's idea's.

I also sent in the following pull request, comments welcome. It should help clear up some earlier confusing and make the spec more clear. Please comment on the pull request and not in thread.

Good question.

The Proof of Stake is still in testing so its not formally open yet.

Though if someone wants to create a thread for Board candidates they are welcome to and I'll add new names to the Voting Google Doc.

I think we should set the deadline for nominees before everyone leaves for the holidays.

Say Friday December 20th 2013

Then begin voting when people are back from the Christmas / New Year Holidays.

Say Monday January 6th 2014

If we think 15 "work days" is long enough for the vote we could close the voting on January 24th 2014.

I'm just thinking aloud given the different calendar constraints upcoming and actually giving enough time to test and get the voting system working in a transparent and open way. Its all public addresses so it should be pretty easy.

Input welcome. Other opinions are welcome.

Please excuse my ignorance - I think I need clarification.  Is voting now open for just the first of seven positions?  If not, is there a date/deadline for all nominees to be identified with an designated voting period to follow?

Robby,

Thanks for posting the summary of the discussion. I appreciate you heavily engaging the community.

I'll add a couple of additional notes to the topics you covered.

Tech Lead:

Thanks for the introduction Robby. I look forward to connecting with the guy you recommended. I've already emailed him.

Foundation Bylaws

Correct the current Mastercoin Foundation Bylaws are a simple fork of the Bitcoin Foundation's from Github. Switching the words "Bitcoin" for "Mastercoin" and removing the names of the Bitcoin Foundation Board members. I've added the link to the Repo on the MastercoinFoundation.org website, so the docs are easy to find.

If you want to help me upgrade the By Laws with a little Markdown magic, that would be much appreciated. Here is the link.

https://github.com/DavidJohnstonCEO/Mastercoin-Foundation-Legal-Repo

One of the things we need to do is add a note about all those participating in the Exodus Address getting automatic life time memberships to the Mastercoin Foundation. And define how others join, the cost, and different levels and such.

Thanks!

Board Elections

Agreed we need to get the voting mechanism in place and then we can go ahead and figure the rest out.

I've created a Google Doc to track the voting. I've created a public address which we can use for the first vote.

https://docs.google.com/spreadsheet/ccc?key=0AosWigpBxkwZdHZlY3ZtTVRvM0E4bkdkWmRBempOUGc&usp=sharing

I've added the candidates I'm aware of to the Google Doc.

The mechanism is simple. Those that send BTC to the address, the number of MSC connected to their public address (using the Mastercoin lookup) will be credited to each of the 7 members they vote for.

Who do we want as Board Members

As for who we want as Board Members I hope everyone will consider my input on this given I've served on a number of Boards over the years.

The most important criteria for a Board member ought to be: Connections + Relationships they can bring to bare in order to benefit the Foundation's work and more broadly the whole Mastercoin Community. In a close second is the level of experience the candidate has in developing new technology projects in order to provide input and accountability.

Let me give you one simple example. I sat on the Board of a Biotech / Energy Startup. The most important member we attracted was the retired President of a major oil company. Because of her connections we made important in roads with a Fortune 100 strategic partner that ended up funding our renewable energy efforts. Without her I'm sure our startup would not have been taken seriously or would we have had the experience to know how to manage such a big customer / relationship.

That's what you want out of a board member. You want someone with relationships, connections, and experience to provide accountability and input to management who tackles things day to day.

Brock Pierce is the perfect example of this. The guy is basically the grandfather of virtual currency having been building and investing in startups in the space since the late 1990's / early 2000's. He is a super Angel in the Bitcoin space and travels around the world to jurisdictions such as Singapore, Hong Kong and others helping build companies in the Bitcoin space. While you are never going to get Brock to work full time on Mastercoin, his relationships, connections and input are invaluable to the Mastercoin effort having been there since the Exodus Address and actively been involved in Board discussions.

We want a clear separation between Board Members and the operational team. I agree with your comment about wanting to avoid conflicts of interest with those providing accountability and those receiving the funds for their efforts.

Vote Capping

As for capping voting power of individuals, I would agree that by its very definition in order to qualify as "Autonomous" as used in the Decentralized Applications White Paper (https://github.com/DavidJohnstonCEO/DecentralizedApplications), no entity can have majority control of the tokens of the Mastercoin Decentralized Application.

I think it could be put forward that you don't even want an individual that could block a 66% super majority vote. However once we move below that threshold I believe the numbers become more subjective. Is 25%, 15%, or 10% too much?

As everyone knows J.R. currently holds 28% of the MSC. Thus assuming the Proof of Stake operates on a 50% simple majority vote, J.R. would need another 23% of the MSC to vote with him to change the protocol or conversely he would need 23% of the MSC to vote with him to block a protocol change.

The complexities of trying to force a voting cap might be difficult in practice given the unlimited number of ways people could circumvent such a cap.

Honestly, I don't think this is really going to be an issue as we go forward, over time all those that participated in the Exodus Address (including J.R.) will diversify their holdings, just as most of the early holders of Bitcoin have diversified over the years. As these early participants sell MSC in order to make investments or take profits the ownership of MSC will come into the hands of more and more participants and the absolute percentage size of ownership pools will naturally decline. Its already happening. There were around 500 original participants and now we see thousands of Mastercoin transactions, mostly to new users thus diluting the holdings of the original participants.

I take this issue very seriously and I know many here have strongly held views on this subject. I'll be making a proposal by the end of next week, that I believe will help address this point of contention. I'm working on a proposal that both respects J.R.'s rights to MSC he purchased during the Exodus Address period and will benefit the community in a very tangible way. I'd give more details here, but I'm getting all the different aspects aligned first so that the proposal isn't half baked.

Masterdaemon

Agreed. I'm glad to see this moving forward.

Thanks for the summary, Robby!
There are so many open topics, did you discuss/agree with David about what are the highest priorities short-term?

Just an update: Had a good talk with David. Here were the items of discussion:

Tech Lead

I proposed an individual who had reached out to me as a potential for the teach lead role (after I had had the chance to talk to him about the technology needs around the organization, his ideas, his technical capabilities, etc). David and the board will be reviewing this, and moving forward from there. How I personally see this Tech Lead/CTO-type role is as following:

• Instrumental in recruiting and building the full-time development team
• Works with developers and hired consultants to maintain, enhance and modify the spec
• Product owner for “core tools” such as any future “reference client” or “reference library” that may exist
• Seen as a major technical advisor on the team (in addition to the developers already involved, for instance)

I initially had thought of applying for this role, but this individual and I share a lot of these same goals and I know for a fact that he will have much more time to contribute to the role than I would, and thus most likely be more effective. We already have some ideas for qualified devs we can reach out to that may be interested, and I have a dev I may pull in if it makes sense.


Foundation Bylaws

I brought up the topic of having solid bylaws in place for the foundation that outline topics such as:

• Duration of term on board
• Board size
• Community voting procedures (e.g. stake-based)
• Board voting requirements (things that require a supermajority for example, over a simple majority)
• Any board member requirement/restrictions

David had earlier forked the Bitcoin Foundation bylaws as a start. We both agree that these need to be modified and enhanced to fit mastercoin, after the above type criteria are fully fleshed out. I can lend some time to that process.


Board Elections

This is a big one. David and I worked through his stake voting proposal and came down with a simple system we think will work, basically:

• Candidates for board membership nominate themselves, or are nominated by others and agree to the nomination
• A thread / page containing each member’s qualifications and summary of why they should be a member is published to the community
• One or more addresses are established
• Members send a very small amount of BTC (from a MSC-containing address) to up to X addresses (e.g. 2-4 addresses) for the member(s) they would want to vote for.
• The source address for incoming BTC is verified against one or more Mastercoin block explorers to get the MSC balance.
• The votes are manually tallied by an independent 3rd party and published as an Excel spreadsheet or Google spreadsheet
• Candidates with the most voting stake (not most # of votes) win (I brought up weighting in total # of votes as well, but David felt it was best to keep as simple as possible for starters at least)
• Community members are free to reproduce and validate the results for themselves

As this requires no special tools or technology, this is something we can do ASAP. David and I both agreed that a general board election should be the first order of business for this system.

Some things to still hammer out, first, regarding this and the general board structure (which I am just putting out there, I don’t necessarily agree with any of these):

• With voting, should we decide to cap the maximum stake contribution to something like 10%? (e.g. JR’s 32% or so would be capped to 10%, or whatever the number is). The goal would to hopefully allow for a more fair vote by limiting the total amount of influence large holders can exercise, while still of course allowing these large holders to exercise their opinion.
• Should we require folks that are current board members to abstain from a vote? If so, how would we verify this without making board member’s addresses pubic?
• We need to decide on the size of the board. I think 5 would work…maybe even 3. It should be an odd number, and I’m thinking 7 is a bit too big. Just my thoughts….
• Also need to finalize board member term length. I’m thinking 1 year, with this first term maybe being 6 months, as a lot can change early on.
• If someone is a board member, should they be allowed to hold an executive role as well? Meaning, if I’m Tech Lead or CFO/Finance Lead, should I be allowed to be a board member as well? I can see a potential situation where if I’m in both kinds of roles, I can use my budget approval rights as a board member to “vote in” my pet projects.
• As a counter-point to the above, we could do the opposite and require that each board member also serve a role in the organization, with a minimum time commitment. This wasn't something David was for when I brought it up, but there are potential benefits, such as that we have the most interested and committed folks on the board. ... I am not sure about this one though, it may be good to have two different groups for board and day-to-day team, to ensure balance of opinion/sentiment

Just some thoughts. I would appreciate conversation around this. Let’s get these issues cleared up and settled so that we can proceed with the board elections ASAP.


Masterdaemon

I put forward an email on the developers list with the goal of trying to reach rough consensus for me moving forward and finishing and releasing masterdaemon as the initial “reference client candidate” (pending developer review and demonstrated community adoption).

Reference client only means that it’s what the core, full-time dev team (once we have one) will maintain. As I expressed in the masterdaemon/mastercoind thread, the goal is to get something out that allows community developers to more easily build mastercoin-driven applications, as well as eventually allowing Mastercoin to be listed on current centralized exchanges like Cryptsy and Vircurex, if that makes sense.

If I can get a general approval from the current developers, I’ll put forth a reasonable proposal to the board to finish it up. Upon that being approved, I’ll complete the product (including binaries and an installer for Windows) and publish and support it. Once we have the full-time dev team, I will then knowledge transfer off to them.



I’m sure I forgot something here. I just wanted to give an update. Thanks again to David for spending his valuable time talking to me and making an effort to connect.

You and me both