MasterCoin: New Protocol Layer Starting From “The Exodus Address”

[killerstorm]

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:

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

[1713487147]

1713487147

[1713487147]

1713487147

[1713487147]

1713487147

[lnternet]

I was wondering if/how/when it would be possible to implement a currency on a private website. Something like "Gold", which can be transferred between users of the site as well as outside, is safe, and leaves no worries for the developers. Can MSC do this yet?

[rbdrbd]

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:

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.

[djohnston]

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

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

[Tachikoma]

+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

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:

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.

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.

[rbdrbd]

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.

I (respectfully) totally disagree. Why is this necessary? Do we need 10 different bitcoind implementations to compare the interpretation of the bitcoin spec? If the Mastercoin spec is open to multiple material differences based on its "interpretation", then that tells me that it needs to be revised to remove ambiguity. Currently, it has a lot of that and I've started asking questions to help close that gap around some of these new features. I know you and many others have done a ton in this area, and I'm sure others will help out as well. However, some small level of ambiguity will still persist, so to your point, I agree that we maybe need 2 full parser/stack implementations, but not 10. It's simply not something that the average mastercoin developer should have to deal with.

In the world of bitcoin, 90%+ of developers just hang off of bitcoind. That doesn't stop anyone from developing their own bitcoin parsing tools (e.g. sx, and others). It's just dumb to require everyone to develop their own block parsers just to be able to do anything with bitcoin. killerstorm may say the parsing mastercoin transactions is so simple a monkey could do it, but I don't know the first thing about parsing multi-sig transactions, for instance, and I'm sure the vast majority of devs on this board don't either (nor do they care). If I was going to add value to mastercoin, I'd rather work on the application I had in mind itself, rather than dinking around with bit fiddling to get my "interpretation" of the spec to show 907.3302929 MSC for transaction 3f04398298292fbcdd0f vs my buddy's showing a balance of 907.594029. Come on....waste of time.

Having each developer basically creating their own parser off the spec when we could have one mastercoind that 90% of devs use is not optimal, in my opinion. I'd think that we want 90% of devs on this creating end-user solutions that add real value around mastercoin's awesome feature set, NOT more parser implementations that result in the confusion and issues we've been seeing lately between masterchest, mymastercoins, and master-coin explorer. Imagine that x100.

I say, if you're the 10% of devs that want or need to create your own parser and spec engine, go for it. Otherwise, use mastercoind, hook into the realtime event feed, spend 10 minutes writing the code to parse apart the JSON for the events you want, and focus on your features.

That is the only way Mastercoin is going to win this race.

[djohnston]

I've just posted a separate thread detailing my proposal to "Standardize the Distribution Rate of Dev MSC via the MSC Protocol"

I hope anyone that wants to discuss this topic will come over to this thread and offer me their feedback.

https://bitcointalk.org/index.php?topic=342431.0

Partial Sneak Peak of my post:

I propose we formalize the distribution of "Dev MSC", to mirror the amount of Dev MSC generated each month. Further more that these Dev MSC be distributed in proportion to the amount of BTC won by participants in Mastercoin bounties that month. With the intension being, that this distribution process will be fully controlled by the Mastercoin community via the existing Bounty system and up coming Proof of Stake voting.

Lets talk some simple math here.

Simple Dev MSC Distribution Equation:  A / B = C * D = E
(A) Amount of awards an individual earns in BTC during a 30 day period, divided by,
(B) the total amount of BTC awarded during that 30 day period, equals
(C) his or her individual award percentage, times
(D) the total Dev MSC generated during that 30 day period, equals
(E) the amount of Dev MSC awarded to the individual in addition to his BTC awards during the 30 day period.

Example #1 (using round numbers):
A (100 BTC) / B (1,000 BTC) = C (10%) * D (1,000 MSC) = E (100 MSC)

There are 56,316 Dev MSC that will ever be generated.
28,158 Dev MSC will be generated this year or 2,346 MSC each month.
So if a developer won 10% of the bounties this month he or she would earn 234.6 Dev MSC (worth 35.19 BTC / $24,633 USD at current MSC / BTC / USD prices).

[bitwhizz]

Well then if takichoma wants an awesome offer, give takichoma an awesome offer ! we really need people like him working on this full time

[zbx]

This project *absolutely* needs multiple full time developers. Mastercoin foundation needs to make that happen ASAP. At my business, I can hire 3 developers to work full time for me (as well as around 13 other assorted full time engineers) and we pull in less each year than the mastercoin foundation has sitting around. Not sure why this can't be done with Mastercoin as well. Run it like a business. Priority number 1.

I strongly agree. Let them work alongside the current developers, if need be.

I think that it would probably be a good idea to pick one implementation to be the reference implementation *eventually* (to avoid forks).

[dacoinminster]

I think that everyone agrees we need to hire some of our developers full time. Tachikoma and I talked about this awhile back, and we realized that (like me) he was really expensive to hire full-time. However, the Mastercoin Foundation has a LOT more money now than it did then. I see no reason why we can't get at least two of our four devs into full-time positions. Ideally, I'd like to get all four. The payout from the upcoming bounty ought to make any transitions much less difficult for them.

[Ola]

I think that everyone agrees we need to hire some of our developers full time. Tachikoma and I talked about this awhile back, and we realized that (like me) he was really expensive to hire full-time. However, the Mastercoin Foundation has a LOT more money now than it did then. I see no reason why we can't get at least two of our four devs into full-time positions. Ideally, I'd like to get all four. The payout from the upcoming bounty ought to make any transitions much less difficult for them.

+1000

I vote for 4 dedicated developers with a project manager or scrum master-like entity to get this organized into a focused effort and interface between the devs and yourself, while you focus your efforts on overall strategy  and this is very important. Maybe you too should consider taking up a similar offer to work on this full time too?...This type of minimal business organization will definitely increase the efficiency of the full time staff several multitudes over. Also I think the main developers should get the awesome offers they are asking for...that is how you get awesome talent to leave and join new companies and we definitely want the best...what happens if tachikoma and others gets a promotion at his job with more responsibilities?

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.

I agree with you rbdrdb, even though I am formally trained with c++ I generally  avoid any headaches from tinkering with lower level engineering. We DEFINITELY NEED a "Master Daemon", your recommendation is needed and I don't think that it should be treated as an after thought , rather to have a small number of developers working along side main devs on the "Master Daemon" which opens up the platform to everyone just like bitcoin  https://en.bitcoin.it/wiki/API_reference_(JSON-RPC).

[littleblue]

I think that everyone agrees we need to hire some of our developers full time. Tachikoma and I talked about this awhile back, and we realized that (like me) he was really expensive to hire full-time. However, the Mastercoin Foundation has a LOT more money now than it did then. I see no reason why we can't get at least two of our four devs into full-time positions. Ideally, I'd like to get all four. The payout from the upcoming bounty ought to make any transitions much less difficult for them.

+9999

[ripper234]

Here are (the slides) from yesterday's meetup of the Israeli Mastercoin Foundation.

Don't forget to hit Play, there are animations.

We'll upload the full video in the following days.

[ripper234]

I just posted this to the Opportunities thread:

1.
I've opened a new Spreadsheet that will always contain the latest bounty amounts.

2.
I have written this blog post describing the bounty process. We need more participation in order to keep accelerating - your input is welcome.

3.
Also, I increased the bounty of the Budget Website from $500 to $1000

4.
and added this new bounty:

Spend from Multisig

https://trello.com/c/ftjuT9gH/57-1500-spend-from-multisig

Bounty: $1500

Using Bitcoin multisig addresses, you can send MSC or any MSC derived currency to a multisig address today.

However, today, there isn't a way to spend money sent to such addresses.

Acceptance Criteria

Alice, Bob and Charlie share a multisig address. Alice should be able to "initiate multisig send" from her wallet. This pops up a notification on Bob's and Charlie's wallets. One of them "confirms send", and the funds are now sent. The notification can be hidden if nobody confirms it within a certain amount of time.

What is required for this bounty is adding a UI to at least two Mastercoin clients, and demonstrating the above flow on the real production network. The bounty would be split between the developers of both clients.

FYI - I believe no spec changes are required to make this work.

[zathras]

In a perfect world, I would happily devote more time to Mastercoin, I've lived and breathed it pretty much whenever I'm not working my day job & am of course 100% behind it - there is however an issue I haven't seen discussed which for me at least is significant.

There are real-world financial burdens (mortgage, bills etc) that have to be paid.  My full time earnings are in fiat - and that's a critical factor.  Cryptocurrencies are still a very new and volatile way of transferring monetary value (for example I had a fairly substantial bitcoin transaction earlier this week that was worth significantly less to the recipient in the time it took to confirm it in 6 blocks).  Consider if you will, being paid in bitcoin & mastercoin only for the next {x months/years}.  The ups and downs of these values will determine the amount of fiat you would have that month to pay the bills.  It could be fantastic and you become very wealthy.  It could also end in tears if a crash in value restricts your ability to pay said bills.  My number one priority over anything else will always be providing for my family (and stably).  

The foundation I'm sure would look at adjusting payments along with market values but just as volatility affects conversion to fiat, so does it affect the resources of the foundation.  A crash in bitcoin value is also a crash in foundation resources.  For the sake of debate, what happens if bitcoin for example crashes to $50?  How would the foundation cover it's payments to its hires?  I think that's an unlikely scenario, but unlikely enough to put 100% of your income on is the question.  My apologies if this comes across as negativity that's not my intention at all - I'm simply considering (out loud) the potential risks.

Mastercoin is a project I thoroughly support and believe is going to be something that really starts to attract 'big money' (corporate) to cryptocurrencies.  I currently spend as much time developing as I can, but I have a full time job which takes up the lion's share of my time.  I still do endeavor to be responsive to any issues with any of my Masterchest software.

As they say 'never close a door' & I'm not ruling anything out, but as nice (I'm guilty too) as it is to get swept up in the incredible growth in just our first few short months when it comes to things like employment and where your income comes from (and how reliable that income is) a longer term perspective is needed.

Thanks

Note, I'd be happy to read any info anyone can provide on a precedent for full-time work paid in cryptocurrencies.

EDIT: for clarity

[prophetx]

CALLING ALL WRITERS: MASTERCOIN DOCUMENTATION CONTEST – $5000 BOUNTY

https://bitcointalk.org/index.php?topic=336454.msg3610871#msg3610871

http://blog.mastercoin.org/2013/11/22/calling-all-writers-mastercoin-documentation-contest-bounty/

[FTWbitcoinFTW]

When i use MastercoinAdvisor
The consol shut down right after enter the receving address
i have to make a quick screenshoot for save the information needed
I'm alone with this problem ?
Thanks
Also how to copy/past in the console ?

[maxmint]

When i use MastercoinAdvisor
The consol shut down right after enter the receving address
i have to make a quick screenshoot for save the information needed
I'm alone with this problem ?
Thanks
Also how to copy/past in the console ?

You have to start MastercoinAdvisor from a terminal window ("Command prompt") then it won't quit.

[zbx]

In a perfect world, I would happily devote more time to Mastercoin, I've lived and breathed it pretty much whenever I'm not working my day job & am of course 100% behind it - there is however an issue I haven't seen discussed which for me at least is significant.

There are real-world financial burdens (mortgage, bills etc) that have to be paid.  My full time earnings are in fiat - and that's a critical factor.  Cryptocurrencies are still a very new and volatile way of transferring monetary value (for example I had a fairly substantial bitcoin transaction earlier this week that was worth significantly less to the recipient in the time it took to confirm it in 6 blocks).  Consider if you will, being paid in bitcoin & mastercoin only for the next {x months/years}.  The ups and downs of these values will determine the amount of fiat you would have that month to pay the bills.  It could be fantastic and you become very wealthy.  It could also end in tears if a crash in value restricts your ability to pay said bills.  My number one priority over anything else will always be providing for my family (and stably).  

The foundation I'm sure would look at adjusting payments along with market values but just as volatility affects conversion to fiat, so does it affect the resources of the foundation.  A crash in bitcoin value is also a crash in foundation resources.  For the sake of debate, what happens if bitcoin for example crashes to $50?  How would the foundation cover it's payments to its hires?  I think that's an unlikely scenario, but unlikely enough to put 100% of your income on is the question.  My apologies if this comes across as negativity that's not my intention at all - I'm simply considering (out loud) the potential risks.

Mastercoin is a project I thoroughly support and believe is going to be something that really starts to attract 'big money' (corporate) to cryptocurrencies.  I currently spend as much time developing as I can, but I have a full time job which takes up the lion's share of my time.  I still do endeavor to be responsive to any issues with any of my Masterchest software.

As they say 'never close a door' & I'm not ruling anything out, but as nice (I'm guilty too) as it is to get swept up in the incredible growth in just our first few short months when it comes to things like employment and where your income comes from (and how reliable that income is) a longer term perspective is needed.

Thanks

Note, I'd be happy to read any info anyone can provide on a precedent for full-time work paid in cryptocurrencies.

EDIT: for clarity

Would the Mastercoin Foundation be willing to pay developers in fiat?

[addzz]

When i use MastercoinAdvisor
The consol shut down right after enter the receving address
i have to make a quick screenshoot for save the information needed
I'm alone with this problem ?
Thanks
Also how to copy/past in the console ?

You have to start MastercoinAdvisor from a terminal window ("Command prompt") then it won't quit.

here is a screenshot:
http://imgur.com/J2J5yiN