Great start...a few things:

* "Secured with 2,047 Terahash/s" doesn't mean much to most people. You could say something about this being more than any other coin besides bitcoin and Namecoin, or put it in perspective in some way (1/4 of the bitcoin hashpower, or whatever it is)
* http://ixcoin.co does not resolve (please add an A record for that, in addition to the one you have for www.ixcoin.co)

Just hedging a bit, and also diversifying.

Please remove my buy order, and put in a sell order for up to 150 at .139

Most all prices are down because of China clamping down on bitcoin a bit.

http://www.coindesk.com/price-crashes-china-outlaws-bitcoin-financial-institutions/

As I understand it at least (and I may not be 100% correct), zbx was a candidate for Tech Lead. He had talked to Ron and Ron was down with him working through the dev hires.

I think now there's some organization taking form, which is why you are seeing more people. But I think there needs to be a clear organizational structure laid out to everyone, otherwise it just ends up looking like (and working like) a Chinese firedrill. The board's hiring strategy is still not clear to me, but to their credit, I sent them over an organizational diagram and we have been working through what the final structure will look like. Hopefully we can get something finalized shortly that will lend some clarity to everyone.

The problem is, essentially, to grow, roles need to be delegated. If I bring on someone to do thing X, then I still take care of thing X and don't tell them anything about the decisions I'm making, that can be a problem. I'd like to think that Ron had this conversation with you before he had the conversation with zbx (things have been moving quickly lately I guess).

Ok, that makes sense. I think that's why we're all confused. Ron didn't make any of that known to anyone else (zbx, or myself, unless I'm off here). So to me it just looked like a unilateral, ad-hoc decision.

Hopefully, that's just because zbx hadn't been brought on yet as the Tech Lead candidate. Otherwise, I think the board needs to give some more thought to it's communication workflow.

(I have to re-iterate that I'm not trying to be difficult here. But I got involved initially because I saw a distinct lack of organization which was going to hinder Mastercoin from staying competitive. I'm not talking about bureaucracy or anything, just having the right people making the right kind of decisions, and having best practices in place --- e.g. viewing a resume/doing an interview to get a better idea of who is coming on to a team ... there's nothing odd about that).

You proposed a technological solution. There didn't seem to be much objection to that (or what there was was cleared up). The next step is determining who will work on it full time (as this is the core product for the full-time team). I asked a question to that extent. How is that not on topic?

Actually, nevermind. If you and zbx are talking that's fine. I'll get the info through him.

Ok, I wasn't aware of that. Ron had also tasked zbx to help out/take care of the dev hiring as a Tech Lead candidate. I think there is a little bit of confusion from that all, then. (unless zbx was aware of this, then it's just me being out of the loop )

Not trying to be difficult, I'd just like to get a better idea of his experience and background.

z0mbie, thanks for stepping up. Do you have a resume or CV you could send to the board and zbx, who has been helping out with hiring for these full time devs? Just to give a bit of a better idea of your background?

(apologies if you've already done this...just wasn't sure)

I'm down for what's best for the community, given that we can bring something to market quickly and intelligently without sacrificing quality (which I was never advocating doing, BTW ). This is why I put forward the idea of me completing masterdaemon before I actually went off and did it...I do have a decent amount of time already sunk into it, but didn't want to finish it up without getting everyone's feedback for exactly this reason -- namely that something else would pop up.

I put forward masterdaemon and the general concept initially because we needed *something*. As this team becomes more established and the idea gains traction, it makes sense that we would have a more formalized product materialize. Perhaps some of the documentation can end up being picked over, or something (or I can get a few MSC for my troubles, hah!).

Let's definitely have a thought out design and "do it right", but especially if we have 1 or more people working on it full-time and we make maximal use of established libraries where it makes sense, I would think we should be able to put our heads together and come up with something relatively quickly.

I'm excited about the prospects of us all working together to assemble a talented and experienced full-time team to work on this and other core products.

Ok, that's good that the focus is using other people's solid code whereever possible.

Given this, would you be willing to risk a guess as to how long it may take to get v1.0 of this out, given that you have your friend and maybe yourself working full-time on it? Being a developer by trade myself, I know how off these kinds of high level estimates can sometimes be, so if you are not sure, that's fine too.

(I just look at Nxt coming up along side, as well as the success Protoshares is having on the exchanges. Things are ripe for this.)

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

This sounds like a solid proposition. At first I was against using some rather obscure language like Go, but I did some research on it and came away impressed.

It's not clear from your proposal, but I would strongly recommend against us writing our own bitcoin block chain parsing logic. Instead, I would recommend we use SWiG to integrate up against libbitcoin (which already can write out to a leveldb backend):

• Go and linking to C++ libraries: http://www.swig.org/Doc2.0/Go.html
• Libbitcoin: https://bitcointalk.org/index.php?topic=30646.0

Writing our own block chain implementation would be a big hassle to both do and maintain, when there's already an excellent library for this. The only hang up here is I don't believe it's been compiled under Windows yet...but that would be a good use of a bounty possibly (i.e. get the dev to spend some time to get a build under windows going...would enhance libbitcoin AND Mastercoin).

Failing that, I would just initially integrate up against bitcoind, to minimize time-to-market as much as possible. Once this thing is out and running up against bitcoind, time can be taken to develop the necessary functionality to remove that dependency. (This guy has some Go code that interacts with bitcoind on Github, which may be a good start for bootstrapping: https://github.com/GeertJohan/go.bitcoin)

I'm encouraged we're finally getting to this point in the conversation. We needed a mastercoind out yesterday.

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.

+10. If I ask someone if they want a job and they tell me no, and we can't work any deal out, I move on to someone else. As I've said before, the mechanics of Mastercoin are not magical. For 70k/yr you can find oodles of qualified people who will work on this thing full time. This is being made a lot harder than it should be.

I am talking to David again today and this is one of my topics.

That's what I think is starting to happen with this coin. It's being updated to the newest bitcoin code. Now all we need is a website, forums, etc.

e.g. http://www.yacoin.org/ for example

Maybe we could organize a bounty for this. I'd be willing to contribute some.

From what you've communicated earlier on this thread, it sounds like an updated client will soon be released as well, based off of the 0.8 code?? (correct me if I'm wrong)

Also, do we know who maintains the current website??? It seems all you need to have a coin that gains a ton in value these days is a kick ass website and an attractive client (I mean, look at Megacoin, jeez).

Ixcoin being one of the first coins, and having 1/4 - 1/2 the hash power of bitcoin is huge, and most people don't recognize that.

May be worth gathering a bounty to do a new site.

Guys, just an FYI: I have a meeting with several board members today to present a proposed corporate structure for the Mastercoin foundation.

Other things I am interested in:

• Discussing defining a specific date for elections of the non-provisional board
• Discussing the creation of formal bylaws for the foundation (if none already exist), which lay out things like board term length, board voting rights, corporate structure, etc.
• Discussing the core development team: How it will look, who will be hired, etc.

Next step after this is a call with the current and proposed developers to see if we can reach consensus on a technical direction and approach. That will dictate the exact direction we take with the reference client (i.e. if it makes sense for me to finish up the first version of masterdaemon and get it over to start with that, then I can do that).

-Robby

It seems you got the wrong idea of what I wrote. I do not think in the least that JR should give me MSC. What I meant by that was that JR should consider contributing some of his bonus to others in the project in a controlled/merit-based fashion (i.e. performance plans, bounties met, etc) to preserve the value of his own MSC, especially if his own continued involvement will stay minimal.

This is my opinion, I was only putting it out there. I do not expect the board to have any say in any of this (it's JR's property). It was more something for JR to think about. Given that, I probably could have stated it a bit differently, but that's all I meant.

And, I started working on mastercoin-related code with no salary, or no promised bounty either. I did it because I saw the need.

I point out things that could use improvement with the project, and offer reasonable suggestions and solutions, all without insulting people and calling them names. What's the goal buddy? To have a project that's successful, or to smile and pretend certain challenges don't exist, and end up with a pile of valueless bits when someone else takes the work and forks it? This team is new, no one is perfect, and we are all just figuring it out as we go along. But we should all be open to educated suggestions and advice from others in how to improve.

I just got off the phone with David Johnson. We had a great conversation and I think we're largely in agreement on things, especially around the need for a reference implementation. I think the next steps here, at least on the development front, are to get a call together with the developers and a few others and hash out the following:

* The current state of the spec and technology
* What does a reference client need to look like
* What's the best way to get there (e.g. dedicated team of X devs...how should it look, how should it run, etc)

I do have the beginning implementation of what could turn into the basis of a reference client (with the core-protocol implementation being built in to it), or the group could decide to take a totally different approach.

The plan would be to build a consensus opinion within this group, and then present it to the community for its opinion and blessing.

My feeling at this time is that a small dev team can be formed (which I will probably not be a part of, but may contribute code for at least at first), which will build a multi-platform, easy to use reference client utilizing best-practices. Beyond that, the bounties, etc approach can be taken with the community to build features and applications around this reference client. This is very similar to how the bitcoin community works.

I'd like to thank David for taking my call, and being so open to discussing the state of things and the best way to move forward.