Technology Update: Merge, Test and Boogie

To be the leader in Bitcoin-based financial platforms, you need adoption, and to get adoption, you need utility, features and ease of use. While we have a number of innovative projects being launched using the Master Protocol as it has been developed over the past year, we still need enhanced features, additional flexibility and robust security to the users.

A proposal for distributing application-level metadata in a global format has been proposed,
which if implemented would reduce the amount of metadata storage required for Smart Properties on the Bitcoin blockchain (and slimmer is better for the whole ecosystem). Please read this and provide comments.

Asset issuers have been asking for more control over the assets they create. Not only the ability to create assets on demand, but also the means to manage those assets, and transfer ownership of those assets. The learning curve on decentralized financial assets is pretty steep, we’re finding that people are now starting to “get it” – and the foundations that have been built are exactly what issuers need to build upon and make the next killer app.

The MetaDEx is getting closer to release, taking oodles of input from experts and making it beautifully simple to execute.

The Over-under

Prepping a new software release brings the contributors together to determine the best fit for new changes, discussion surrounding caveats and edge cases, and what the changes will impact going forward.

Next week we will release the next tagged release of Master Core for integrators, version 0.0.7.

This will be the last tagged release before we build and distribute the next beta of Master Core that will include the front-end user interface for the downloadable wallet (and, of course, multiple platform support). This tagged release is to provide integrators with the most up-to-date protocol enhancements and to make sure they will be ready for the users using the forthcoming beta.

The deep

In preparation for next week’s new tagged release of Master Core, this week the team has been busy merging in the remaining code and running unit tests and black box testing against the critical functions.

So far, we’ve tested and approved p2sh multi-sig and manual issuances after thorough testing on Bitcoin testnet. Re-org protection was merged yesterday and today (and throughout the weekend), we’ll be making sure that the daemon remains stable and accurate (as it has been up to now). The re-org protection allows Master Core to recover better from a blockchain re-org, whereas the prior builds provided a warning to the user, but did not automatically reparse.

A side-refactoring of the file structure of the code was also made yesterday to allow for smoother merges of new features in the future.

The skinny

Omniwallet got some major updates this week, and over the weekend will be getting even more, related to Master Core integration, the new database backend, and front-end UI updates. Part of getting the new builds of Master Core out have been to assist in getting the old underpinnings of Omniwallet removed and replaced with the reference client. The same is happening for, which by next week will also be running against Master Core. All of this in preparation for new asset types, faster and more responsive services and more detailed data to be presented to the end-user.

Next week integrators get a lot. Shortly thereafter, the UI will be ready, and everyone will be able to see it.

See areas of improvement? Have any questions? The more masterminds the better! Join the project. Ask me anything!

Craig Sellars

CTO, MSC Foundation

craig (at)

Technology Update: Merge, Test and Boogie

Utility is the Mother of Liquidity

Good Afternoon Masterminds,

Recently a member of the MSC Reddit community (yandi23) asked me to address this question: “When can you make a post on the liquidity of Mastercoin?”

Thanks for the question yandi23. I’ve been working up plans on how the community can build up the liquidity of MSC and so your question is well timed and I work to address it in detail below in this post.

Utility is what gives a token organic demand, which in turn drives increased value and liquidity in a market. The first feature creating direct utility for the MSC token is the Meta Decentralized Exchange (Meta DEx). As more tokens are listed on the Master Protocol and MSC is required for the common trading pair on the Meta DEx, organic demand for MSC will build and the market cap and liquidity will be a reflection of the level of this organic demand. Here is the link to the OmniWallet feedback Google Doc if you want to add your suggestions or report bugs to enhance the utility of the DEx and soon the Meta DEx.

Happy testing : )

Context and History:
Lets start by examining the past. In the beginning, at the founding of the Bitcoin network, the bitcoin tokens had virtually no utility and thus no demand for the use of its token and as it logically follows, no liquidity in the market.

As more users acquired bitcoins and began trading them among themselves, eventually offering to purchase goods and services with their bitcoins, the utility of the bitcoin token began to materialize as a payment network. It took several years before the utility of bitcoin grew enough for a meaningful market price for the tokens to emerge and even then the small market cap and liquidity of the Bitcoin network really limited the use of the bitcoin token to fairly small purchases of real world or digital goods.

As user growth continued an organic process of building the market cap and liquidity of bitcoin emerged and resulted in many exchanges actively listing it for trade, many professional traders coming into the market, a large ecosystem of merchants accepting it, and users holding bitcoin over the long term as a store of value.

The Path for MSC:
In many ways the Master Protocol has been on a similar journey the past year. Since the crowdsale last August the MSC community has been working to build the reference client (MasterCore) and users have begun issuing tokens on the platform as of April 22nd 2014 (MaidSafe, API Network, soon Merchant Coin, Real Coin and many others).

Since the launch of the Decentralized Exchange (DEx) feature, users have been able to trade MSC and BTC with zero third party exchange risk and extremely low fees based on bitcoin dust level transactions.

The next step is to extend the Meta DEx feature to support all user issued tokens on the MSC protocol to trade against MSC as a common trading pair. Finally the world will be free of any future “Gox” type event because this feature will permanently remove third parties from the trading equation and bring a full P2P architecture into reality.

The launch of the Meta Dex is the first time that anyone has an organic reason to purchase MSC (to use as the common trading pair) and thus the first direct utility the token has provided in the system. Before that time users held MSC because they believed that the MSC system would develop utility as some point in the future.

It was expected at first that every feature of the protocol (for example the creation of tokens) would require some amount of MSC, however it was decided in May 2014 that in order to avoid creating unneeded friction in the system, only those features requiring MSC for solid technical reasons would require their use. The Meta DEx is the first of the features that meets this standard.

The Math About The Importance of Liquidity:
So the reason that liquidity is key for the Meta DEx is that while the fees are limited to the dust level transactions required to run the system, if the “spread” between buys and sells are greater on the Meta DEx than a centralized exchange, then that adds a cost to the user of the Meta DEx. As liquidity increases the “spread” becomes more narrow and it becomes more efficient for the user. In our case the key to liquidity is the depth of offers on the order book.

Lets use some math to give an example. User Bob wants to purchase 1 BTC worth of XAP on the Meta DEx. First he has to grab some MSC on the DEx to buy the XAP with (since MSC is the common trading pair). If there are 10 BTC worth of MSC on the order book and the sell offers are evenly spread up the price curve, then by purchasing 1 BTC worth of MSC, Bob will have moved the price of MSC by 10%. This is a substantial move and has in essence cost Bob an extra 10% on the price of his trade.

If the order book has 100 BTC worth of MSC sell offers, then Bob’s purchase would only move the market price 1%.
If the order book has 1,000 BTC worth of MSC sell offers, then Bob’s purchase would only move the market price 0.1%

So with an order book 1,000 BTC deep, a user can easily make trades in the 1 to 10 BTC range and move the market less than 1%. Thus at this order book depth the Meta DEx becomes competitive with a centralized exchange on direct and indirect costs of conducting a trade.

At the time of writing (2014/09/11) the depth of the BTC / MSC order book on the DEx is 163 BTC between the 200 to 46 mBTC price ranges. This is an important number to watch and will need to increase toward the 1,000 BTC range for traders doing exchanges larger than 1 BTC to be attracted to using the DEx and Meta DEx.

Action Items To Improve Liquidity / Order Book Depth: 
1. Educate traders and market makers on how to use the Omni Wallet Decentralized Exchange.

2. Build the API and RPC calls for MasterCore / OmniWallet according to the best practices of established exchanges for pro users to access.

3. Make the Omni Wallet API pull-able for third parties, such as to list all volume and price on the decentralized exchange.

4. Community testing of the OmniWallet interface and reporting suggestions to the OmniWallet team to improve the trading experience is key. Here is the link to the Google Doc for feedback:

I believe we can address these fundamental drivers of order book depth and liquidity in the coming weeks and months. This is a major priority for me as the Chairman of the Foundation and generally for the DEx and Meta DEx features of the OmniWallet and MasterCore to be successful in the market.

I’ve been spending a lot of hours testing the OmniWallet and DEx features the past few weeks.

I hope you will join me in this testing and most importantly report your feedback to the devs via the Google Doc.

Best Regards,

David A. Johnston
Chairman of the Board MSC Foundation

David (at)

Utility is the Mother of Liquidity

Omniwallet Milestone v0.17

Full steam ahead on the OmniEngine! In our last Milestone Summary I mentioned that were hard at work on a new database for Omni driven by data from Mastercore. That work continues to push forward with almost every ounce of effort we have. OmniEngine is now capable of parsing and handling all BTC transactions and details. Additionally it can handle all current MasterProtocol transaction types, Properties and Property History. While this is a good chunk of functionally usable code we now need to look at streamlining and improving the efficiency. Development of new forward facing features/improvements for Omni has slowed down while we have refocused our efforts on the database. But all is not forgotten, we are working on a new unified ‘look and feel’ (see below) and we do have a few fixes and improvements to Safely mark the close of Milestone v0.17

Omni New design


Milestone Summary (See the full list of details on Github):

  • Wallet Backup/Import feedback/summary improvements
  • Visual feedback for new address creation in wallet
  • Trade page feedback/improvements
  • UI/UX updates
  • Rapid deployment of updated code
  • Crowd-sourced Security Testing
On the Horizon:
  • New Database driven interface
  • Continuing integration of Master Core features
  • Additional SP token values in USD

Take a look and let us know what you think, we’re always happy for user feedback.

Next up, watch Our Mrs. Reynolds in Milestone v0.18

Omniwallet Milestone v0.17

Communication, Transparency and the tools that help.

Shannon here wearing my communication’s hat today. One of the big goals recently has been the streamlining of communication both within the foundation but as well as communicating with the community. Since that time I have been working to pull many of our channels of communication into one location and working with David and Adam to make the channels we do have be easier to search and consume. I’m releasing some of those tools now and want to take a few minutes to explain what we are currently doing and my goals moving forward.

In a post by David he mentioned a program developed I think for GitHub called HUBOT which was an automated interactive agent that a team can communicate with to do various tasks, like answering queries or relaying messages. The project is widely used and respected. I back-burnered the addition of this software into our internal stack early on. About a month and a half ago I was reading an article about the executive who created flickr as an internal project for a video game project that eventually went belly up (Read more here). The article went on to talk about a new piece of software “Slack” that his current team developed to handle internal communication and I was intrigued. I promptly installed and started trying to understand the pull power of what it could do.

Sslacklack on the surface looks much like a web based IRC implementation, complete with rooms prefixed with a # (#general, #random) that are easily created by any user using the system. But looking a little deeper at the concept of integration, the true of power of slack slowly starts to creep in. At it’s heart the Slack environment encourages adding integrations to your system. An integration is essentially an API connected to the slack infrastructure.

They offer roughly 60 connections to various API’s, some of which open up other APi lists. They also offer simple web hooks and event based scripting. This opens the door for nearly unlimited combination of actions that can be scripted. You can have external forces or events trigger things to happen in one or all of your slack “rooms” you can have events that happen in a slack room trigger something to happen externally. The options are really quite amazing. But as with most things that have such a powerful capability, it’s up to the user to decide how best to harness this.

Quickly an example of a task that I was able to automate in a matter of minutes without writing any code is as follows: The reminding of team members, publicly about their blog posting schedule.

First I created a calendar specifically to keep events that correlate with each member’s blog posting day.
I created an event that fires a few minute before each event.
when this event fires it triggers an HTTP POST call that takes the details of the calendar event and passes the values into the “slackbot” api
Slackbot APi takes the values and sends a message to the #general channel: slack.reminderThis automation will run until I turn it off and took literally minutes to create. This was sort of a whimsical automation because I could and I needed a way to gently remind people of what’s being published today and by who.

Part of our goal of transparency was making our Skype group chats more easily accessible, stage 1 of this is complete and we now have 4 skype channels that are logged and the messages pumped into a slack channel representation of the skype group. Stage 2 will be to relay these same messages to to allow people without skype to be able to see what’s going happening. I’ll issue another update when the skype=>forum integration is complete. Here is the github repository that contains the application I wrote to help log the Skype group chats. It requires only your slack api endpoint and api key along with the groups you are interested in logging and the matching slack channel.


Another feature we are working on is a singular publishing point from within slack. We created plugins for both Facebook and Twitter that interface with slack through a project very similar to HUBOT called MMBOT, a C# port of HUBOT, I’m at heart a .Net and Java developer so I jumped at a C# bot that I can use to tie together the missing pieces.

Here are the plugins I wrote to facilitate the publishing of tweets and facebook posts. This particular integration uses the Zapier API which brings with it over 80 additional API connections that can be consumed using slack, hubot, mmbot, etc.



Communication, Transparency and the tools that help.

Genercoin – the Green ENERgy Asset backed coin born on the Master Protocol by Judith – BizDev at the Mastercoin Foundation

Dear Masterminds,

We are extremely fortunate to provide a platform for innovative projects  We’ve been working with variety of innovators, and experts who want to create amazing projects.

 Today, I would like to introduce you to GENERcoin.

GENERcoin is the Green ENERgy Asset Backed Coin that is backed by Arterran Renewables innovative solid bio fuel made from sustainable non food sources, such as manure, and municipal solid waste that is a direct replacement to coal. Coal contributes 40% of green house gas emissions in the US alone(source US EPA). Each GEC is a receipt and claim for the bio fuel that backs each coin.

GENERcoin is modeled from this concept and is backed by the deliverable renewable green energy assets provided by Arterran Renewables NextGen Solid Bio fuel. Each GENERcoin, built upon the Master Protocol, is a claim, a receipt, for the energy backing each coin which may be redeemed, traded or exchanged according to the holders wish.

The value of GENERcoin is represented by the deliverable energy it is backed by, which can be more stable than debt assets which may be devalued due to inflation.

If you want to know more about the GenerCoin project, please visit:


Great things are happening to the Master Protocol

Point of contact for companies and organizations who want to issue a token (Judith Jakubovics) Judith (-at-) and on Skype: Judith.Jakubovics

Genercoin – the Green ENERgy Asset backed coin born on the Master Protocol by Judith – BizDev at the Mastercoin Foundation

Technology Update: Sleep when you’re dead.

It’s been another frenetic and massively productive week in the Mastermind world, with new features flying in to the codebase faster than we’ve seen before.

This week we’ve pulled in more RPC updates, interface updates, manual (unlocked) issuance of assets (grant, revoke), p2sh multi-sig, and additional re-org protection – and that’s just in Master Core. No less than four third-party integrators (exchanges and wallets) have begun tying Master Core into their backend systems this week, and next week is going to be a frenzy of testing, building, testing, packaging and testing.

Two of the groups who are white-labeling Omniwallet have also provided some exceptional feedback and contributions in terms of scalability, security and interface, and the community that is growing around the Master Protocol is finally beginning to see the capabilities that are about to be unleashed.

On the testing front, we’ve updated our spock engine to allow for more automated tests on commit and builds, working through “cumulative hashes” that allow all clients to know that the balances they are using are the same as all other clients.

For Omniwallet, we’re soliciting feedback from users in our “What’s in Our Wallet” survey (which, if you haven’t yet, submit your thoughts – it will guide the future direction of Omni), populated the OmniEngine backend database, added logic processing from DEx payments, and begin integrating the new front-end API.

QA and testing were hot on the plate this week, as we welcome a new team member who will be focused on test plans and quality assurance.

Exciting new ideas are being pumped into the spec on an almost daily basis: smart property administration, futures contracts, ways to decrease transaction fees, and minimizing the blockchain storage requirements of Master Protocol transactions.

The Master Core UI is getting closer to release, as well; below can be seen the Balances tab:

All in all, the team has been working around the clock, continuing to knock the socks off anyone in the general vicinity. As an old colleague once told me, when referring to working non-stop: “you can sleep when you’re dead.”  Our next release will be coming soon, and with it the results of months of non-stop effort will be shared with the world.  

As always, we solicit and invite contributors to come and comment, critique or contribute. The more masterminds the better. Ask me anything, and keep your eyes peeled for what’s coming.

Craig Sellars

CTO, Mastercoin Foundation

craig (at)

Technology Update: Sleep when you’re dead.

Omni: A Tale of Two

Omniwallet today has two major pieces that are the focus of the team in order to leverage the new database infrastructure that will power the next revision of the web wallet.

The first piece has been under heavy development for the past 3 weeks: the back end module which populates the database with usable data, gloriously called OmniEngine. It is the engine behind Omni, driving the data into the correct place in the database and dragging the data onto the page for the user to see.

At present it can parse, store, retrieve and handle all Bitcoin transactions as well as most Mastercoin transactions. Thanks to frequent updates to Master Core, we can now add support and logic for Distributed EXchange payments as well as the transactions used in the upcoming MetaDEx feature.

The second piece, on which we have officially broken ground today, is the front end api which allows Omniwallet to properly interact and retrieve data from the database. Just because we have the data is no good if you can’t use it – and this api will allow Omniwallet (and in the future, other tools) to properly extract relevant transaction data and make it intelligible and presentable to the end-user.

We’re hoping to have most of these puzzle pieces in place and ready within the next few weeks, so keep an eye out for updates.

Omni: A Tale of Two