Quote

+1000

Thanks for all the +1's people. The thing is I'm not stuck in a dead-end job at the moment. I have a pretty awesome job already, although perhaps not as awesome as Mastercoin, so getting me to work fulltime on Mastercoin would require a pretty awesome offer. It's a good thing there is more talent attached to this project

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

I +1 Killerstorm's explanation. We absolutely need different Mastercoin implementations from the get-go to compare our interpretation of the spec. I already wrote an addition to the spec that should make comparing implementations very easy. For those interested you can read the initial draft of the verification API here.

Quote from: djohnston on November 21, 2013, 07:04:51 PM

Great presentation Ron. Well articulated my friend. I'll post the recording once it is uploaded.

https://plus.google.com/u/0/events/cosfuleudovf9bbitllefb93874

I enjoyed it as well. I was a bit sad though that none of the slides mentioned anything developed by me or the other developers. We all worked very hard to make Mastercoin more then an idea, to create something tangible. People who watched the presentation might have the idea that there is nothing yet.