ripper234 will this be a no brainer if at least 10 people echo this? I hope to everything we believe in Tachikoma does not think otherwise.
We do have such plans ourselves. David is forming a more detailed plan, and J.R is reaching out to all the developers to determine their availability and focus.
I fully agree that we should be able to fund development in a more orderly fashion.
I personally think this should be higher on our priorities than standardizing the way Dev MSCs are spent.
The former is a specific task - hire a few developers.
The latter is a higher order problem, and I would take some convincing before I'm satisfied with a solution there.
David & J.R - to your attention.
^ This is good to hear, I am Glad that that you all are already talking about this.
So what is the lowest unit of an MSC going to be called? We should give that lowest unit a name and price all Mastercoins in those units on all exchanges which follow the standard. The lowest unit for Bitcoin is a satoshi but the Bitcoin exchanges are making a huge mistake by pricing everything like 1.0 -> 0.0000001 when they should just say it's 100,000,000 satoshi. So if a whole Mastercoin is 100,000,000 units then we need to be selling in the hundreds of millions of units of Mastercoin for psychological purposes.
That is my suggestion and I hope people understand the importance this change could have.
+1 willet sounds good to me.
ripper234 has asked me to create a thread to investigate the creation of a “mastercoind” program to help lower the bar to entry for the mastercoin development community. This is an idea I put forward on bitcointalk earlier
1.
The ProblemThe basic idea is that Mastercoin transaction processing even today is quite involved and is going to get much harder as new features continue to be added to the spec. Currently, we have multiple efforts at creating a parsing framework for the stack, which both must be able to parse the various types of Mastercoin transactions (Class A, B and in the future, C transactions), as well as be able to apply the rules of the spec -– which itself is still quite nebulous in places -- to these transactions.
In the words of killerstorm, "Different implementations might implement it in different ways, and getting it right is very, very tricky."
2 For proof of this today, we can look at the frequent regressions and incompatibilities we are witnessing between the various implementations (e.g. mastercoin-explorer, mymastercoins, masterchest). For example, there have been several times when I put an MSC-containing address into these three tools, and got two or three different balances reported back. This is absolutely no fault to the developers themselves, who have been doing an excellent and admirable job of building something in quite a short timeframe (working part-time, too). However, it does reflect both the current ambiguous nature of the spec in areas, as well as the base complexity of the Mastercoin concept itself.
This situation will only become orders of magnitude more complex as additional features are layered on, and I believe we need to be proactive now and come up with a way to head this off at the pass, or else we will pay for it painfully later, in dealing with regressions and confusion instead of blazing forward with innovating new feature implementations.
The SolutionTo this end, I believe Mastercoin needs a “reference-client” implementation, which, similar to bitcoind, would take care of implementing the “guts” of the spec and take it out to a higher level interface which would focus on things that have actually happened, after all of the Bitcoin and Mastercoin parsing and rule validation have been taken into effect. The daemon would start up, stay resident, and as new bitcoin blocks were processed by bitcoind, would parse and interpret any Mastercoind-transactions and make them available to its clients via an asynchronous (callback-driven) streamed event API, or a request-based synchronous API.
Then, instead of having to write their own parser and spec interpretation logic from scratch, Mastercoin developers could simply hook into mastercoind by spending 10 minutes writing the code to connect to mastercoind, subscribe to events, and decode the JSON-based responses for what they were interested in. Psuedo-code for an example event feed may be similar to:
• "address A sent address B 50 MSC"
• "address C put out an offer for 50 MSC @ .50/ea. offer ID is 1234".
• "address D bid on offer 1234 for 20 of the 50 MSC"
• "address E created a smart property named 'foobar' with currency ID 4567"
The first example, taken out to the JSON text that mastercoind may actually return, would be:
{“operation”: “sendmsc”, “from”: “1CE8bBr1dYZRMnpmyYsFEoexa1YoPz2mfB”, “to”: “1EcpemQkcq9Dit7yF9hxEKZzGVkAScwDrP”, “transactionID”: “3f0bcd2930[…]”, “amount”: 50, “block”: 23849202, “when”: “20101117T09:42:00“}Like bitcoind, the daemon could be made available for Windows, Linux and Mac OS X.
The BenefitsThe advantage of this approach is that instead of forcing each new potential Mastercoin developer to essentially write their own parsing and spec-interpretation logic, they could skip that and get started with the actual application they had in mind immediately. Suddenly the bar to Mastercoin development is drastically lowered, and participation by the majority of developers out there is now possible (where before, one would need to have domain-specific knowledge of Bitcoin and Mastercoin inner workings to participate – as most developers are not comfortable with bit twiddling and/or writing implementations to a spec).
This would bring Mastercoin development inline with Bitcoin development, where 90%+ of developers just hang-off of bitcoind and interact with it via its API interface.
For the remaining 10% or less of devs that want or need to create their own parsing interface, they are totally free to do so, similar to how Bitcoin has the ‘sx’ toolset as an alternative to bitcoind.Conclusion and LogisticsThe result is an environment where the bar to new Mastercoin development is greatly lowered, and new developers can focus on writing applications that innovate and add value to the effort on day one, not after having to spend 3 months jumping through the hoops of hacking together their own block parsing and spec interpretation logic.
Mastercoind could be created and maintained by a 2 to 4 member development team employed by the foundation, and made available to the community. The community could then be leveraged (via bounties) to create solutions, most of which would be on top of mastercoind (however, alternative mastercoind implementations could still be created as well, as stated earlier). The result is a drastically larger and healthier ecosystem, with a drastically lowered bar to entry, and minimal reproduction of work.
Thanks for your consideration of this proposal. Please feel free to comment on any of these points, and I would be happy to answer any questions.
And, if the community favors this, I would be willing to produce the skeleton for a 'mastercoind' in Python, which I can do in a 1 week period.1: The original postings where I proposed this:
2: See
https://bitcointalk.org/index.php?topic=265488.msg3665847#msg3665847I think everybody that wants to build on top of the mastercoin protocol should go here and vote:
In my opinion this is 1 or 2 levels down in priority to hiring full time developers.
