Quote from: killerstorm on November 21, 2013, 06:12:47 PM

Quote from: rbdrbd on November 21, 2013, 05:45:20 PM

Once we have a solid mastercoin API library that can work across multiple languages (optimally do basic parsing in C, then use swig, etc to take out to Python, Perl, Ruby, etc) then the skill bar level is DRASTICALLY lowered. At that point, you can get generic webdevs and generaic devs that have a good mid-level understanding of bitcoin/mastercoin to do the work.

Parsing transactions is an easy part. Maintaining the state is the hard part.

You need some means of representing the state, i.e. balance, pending orders and so on for each address.

Then you read a stream of messages and apply them one by one according to certain rules. E.g. for simple send you need this:

1. check if sending address balance is sufficient
2. decrease balance of sending address by X
3. increase balance of receiving address by X

To implement more complex rules you need more state variables for each address.

Now, the question is, are you going to implement it in C? How?

Implementing only parsing in C and rules in high-level language won't have an effect you're aiming for: parsing itself is straightforward, but rules aren't.

Example:

Quote

An address marked as savings can only do simple transfers (transaction type=0). All other transaction types require addresses without a reversibility time window.

This definitely makes sense: we do not want to define how savings feature interacts with all types of transactions

But what happens if I declare an address as savings after I have submitted an offer? Does it cancel a pending order? Or is this 'mark as savings' command ignored?

Different implementations might implement it in different ways, and getting it right is very, very tricky. On the other hand, deserialization is something a monkey can implement when it has the right tools

Great points. I'm no bitcoin expert obviously, but I know with bitcoin there are blockchain parsers (such as https://github.com/znort987/blockparser) that can run through and compile stats on the block chain (e.g. simple aggregate metrics, a list of addresses with balances and their balances, etc). Obviously, the rules behind mastercoin are a very good deal more complex than bitcoin, but perhaps some kind of parser could be written (not necessarily in C) that could run either as a one-shot (parse through the chain and output) or resident (with streaming output).

Output would be in a simplified JSON-formatted structure, that comprise "absolute actions" that have been validated through the spec-derived rule set encoded into the parser itself.

e.g "address A sent address B 50 MSC". In this case, the parser has done all of the difficult parsing and validation (such as, the sending address having the balance, the transaction being a valid Class A/B/C one, whatever else)...it outputs this in JSON format, a higher level web tool can either read it from a file (streamed or as a static/batch run) or maybe attach to the process's event interface via TCP/IP and get it that way.

other examples:
"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"

This way, all higher level utilities could hook into this Mastercoin daemon, which would take care of implementing the guts of the spec and take it out to a higher level streamed, JSON encoded "absolute" API, which would focus on things that have actually happened, after all of the parsing and rule validation have been taken into effect. The daemon could be available for windows, linux and mac OS X. A JSON RPC-driven query interface would also be available to allow querying of specific smart properties, transaction IDs, etc.

Hell, write the thing in ruby and use Tachikoma's work as a base for it. Or make it in python (everyone loves python, and that way I'll want to hack on it! :p)

....We shall call it.... "mastercoind" (*pinkie over mouth*)

Maybe I am smoking crack here and this won't gain us much. Just thought I'd put it out there to get the ball rolling for potential solutions. If doing the above makes sense, it would bring us in line with the way bitcoin does things (e.g. bitcoind hooking into exchange sites, armory client, p2pool, pushpool daemon, bitcoin-qt, etc), and speed new development efforts up 20x, as what we're doing now seems a bit similar to forcing everyone who wants to build their own computer to create the CPU from scratch, instead of just buying the parts and slapping them together.