Topic: mastercoind proposal to speed development: Please read, vote, and comment - page 3. (Read 6059 times)

+1  Makes all the sense in the world..I am waiting on this

Could one of the existing projects be repackaged to be this?

https://bitcointalksearch.org/topic/m.3695215

Okay, I'll bite. Makes perfect sense

This is what I initially thought as well (i.e. a reference library, either in a single language like python, or in C, which could be taken out to a variety of languages). However, as killerstorm has noted in his reply at https://bitcointalksearch.org/topic/m.3665847 , most of the challenge lies in reconstructing the stream of Mastercoin messages from block to block, not in the parsing of the blocks themselves. In this case, I feel a separate resident daemon lends itself better to this (i.e. parsing transactions and maintaining state), and is superior to a reference library for the following reasons:

• one could use any language to interact with it, not just python (or whatever else)
• if other languages were desired, we wouldn't have to write separate implementations in each language (or be forced to use a lower level language and bind it up to the language of choice, if we wanted to share code, for instance)
• It has a very straightforward analogy to bitcoind, and can be quickly picked up by devs that have dealt with bitcoind
• like bitcoind, it can store its state independently of the application that's using it
• is potentially less error prone and "foolproof" in real-world usage, as it's more self-contained
• It can be distributed pre-compiled, with no binding/linking required

qwk: I just reset the poll to account for improving the options, given that I didn't want to try to unfairly re-interpret your vote. Please vote again if you wish.

If all you want is some kind of reference implementation to follow or use in real-world-applications, I don't see a need for a mastercoinD, rather, a reference library in the language of choice (I guess that would be Python for most developers right now).

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¹.

The Problem

The 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."² 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 Solution

To this end, I believe Mastercoin needs a “reference-client” front-end API provider 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:


Like bitcoind, the daemon could be made available for Windows, Linux and Mac OS X.

The Benefits
The 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 Logistics

The 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.

¹: The original postings where I proposed this:

• https://bitcointalksearch.org/topic/m.3666117
• https://bitcointalksearch.org/topic/m.3667049

²: See https://bitcointalksearch.org/topic/m.3665847