Actually we will be using libraries wherever possible, as long as they don't bring in hard depdencies, like Bitcoind. I've already talked with Amir about using Libbotcoin for Mastercoin purposes. An other option we came up with is using parts of BTCD which is a pure Go implementation of the Bitcoin reference implementation. It is still alpha but it's already passing block acceptance tests so it looks like we can cut development time by using parts of their libs. The only problem is we haven't had time to really dive into their code and see how useful it would be for us.

We have considered using Bitcoind as an interim solution however we rather cut that out since it would be wasting a lot of resources. We only need a small part of the Blockchain it makes no sense to waste all those resources saving data on transactions we will never use.

Ah yeah. The new file it's looking for is wallets/default_wallet. I believe there should however be a migration system in place that should automatically do this for you. If it hasn't try moving your wallet to that folder/ filename but please back it up first

Are you always invalidating it? Or only if there are two purchase offers on both of the addresses? I think it would add flexibility if we would allow multi-input payments we just need to track which inputs have an offer open.

In other news:

I just posted our proposal for a reference implementation, comments/critique welcome.

I just posted our proposal for a reference implementation, comments/critique welcome.

Hey guys,

I wanted to give my proposal for an official Mastercoin daemon reference implementation. I think enough valid arguments have already been raised why this is needed but just to confirm.

• It would enable rapid development of products based on Mastercoin without having to know all the ins and outs of the protocol.
• It would serve as a guideline for other implementations on how interpret the rules.
• It would make it easier to get Mastercoin trading on exchanges.

Now when creating a reference implementation the following features are of major importance.

• Cross-platform
• The least amount of dependencies
• Optimised for speed and security
• Readable code and documentation
• Testable (TDD/BDD)
• High level API on top

I've discussed this a lot over the last few weeks with a dear friend of mine, who hopefully be involved with the project soon too, and we came up with the following suggestions.

We would develop a reference implementation in Go using Leveldb as data storage. The application would exist of multiple levels and be developer in the following steps

• Reader module; the reader module would be responsible for reading and listening for messages from different sources (this doesn't have to be Bitcoin perse but would be so initially).
• Parser; retrieves and parses data specifically for Mastercoin and save it to a key value storage (leveldb).
• API Library; the higher level API library which serves as a wrapper around the reader, parser and database interface (so it should be possible to develop upon the specification, rather than the JSON RPC)
• JSON-RPC; A JSON interface wrapper around the library API

The lowest level would be the reader module. This module would read messages from different sources. Initially this would be the Bitcoin block chain. The reader module would be responsible for listing in on a network, gathering messages and then saving these messages to be parsed by the second module. The second module would be the parser itself. It would go through all unparsed messages and retrieve the Mastercoin data. It would then go through all the logic dictated in the spec and save the data in a presentable form in the leveldb database. The last module would be a JSON-RPC interface that gives easy access to all the data saved in the database. There will be no hard dependency on any Bitcoin specific application like Bitcoind. We want it to be as much as stand-alone project as possible carefully weighing development against the dependency cost.

We are considering Go for the following reasons.

• Cross-platform portability and cross-platform compilable
• Easy multithreading
• Secure out of the box. I.e. buffer overflows can't lead to arbitrary code execution
• Build in garbage collection
• Easy dependency management
• Easy syntax, compared to languages like c

Of course there are also downsides to Go.

• Although production-ready it's a relatively young language
• Slower to develop than Python / Ruby

This would be no small project and would probably not make any quick gains. However we believe this might be what is needed for the the future stability of Mastercoin. The idea is that I would keep my curren Ruby libraries up to date with the new features while simultaneously working on the Go implementation. However my friend would have the main role and would be doing the most work on it.

Please voice your opinions and concerns so we can come to a final solution for this problem.

What kind of payment is this suppose to be? A payment for the distributed exchange?

I guess we need to think of a way to properly handle this case. I'm guessing that we could backtrace and see if one of these addresses did a Purchase Offer. If both of them did a purchase offer we invalidate the transaction. Could that work?

Devs, please take a look at this pull request and comment on the spec.

Hey guys,

I just had a interesting call with Ron so I thought I would chime in.

Ron made me a very interesting offer for the lead developer position, one that might actually be good enough for me to drop my day job. One of the things we discussed was the need for a reference implementation. I will be creating a topic in the coming days to specify my thoughts on this reference implementation and how it might differ from Robby's idea's.

I also sent in the following pull request, comments welcome. It should help clear up some earlier confusing and make the spec more clear. Please comment on the pull request and not in thread.

Ah, you were trying to get it directly from javascript? That won't work because of cross-origin restrictions.

Is it possible it's just validating your transactions? Open Electrum open an acitivity monitor like top and see if Electrum is doing something.

What's the md5 of your 1.9.5 portable.

The question was actually for Maxmint 

And then it quits back to the console?

That's the point

What does electrum -v give you ?

Can you open the link in your browser?

Everything is already disabled.

How would you propose restricting it? Currently none of the clients allow it. That should be restriction enough. I opened it up once to get some test results into the blockchain, this gave us a lot of valuable information and I'm still happy I did it.


We should have done this from the start. Register a handful of MSC addresses that are 'allowed' to do these transactions before the protocol officially supports it. It's the only way to safely develop new features.

Full transparency; I already suggested this to J.R. I asked him if somebody, perhaps even me, could get the rights to make the decision on trivial things that are unclear in the spec and if I (or somebody else) would be allowed to create a portable reference implementation that could be comparable to bitcoind.  


I believe this was always the plan.

I will give you one thing. We are quickly getting to the point that we need more leadership. I've tried to fill in where I could but it's just not doable anymore. The worst thing about Mastercoin is that it already has value. If it was up to me I probably would have done that differently but it's too late for that now. It is out there, people gave it value and we have to work with what we got. If Mastercoin wouldn't have any monetory value nobody would have given a rat's ass about how it was all handled.

Seriously this is so childish. Mastercoin is one big experience and we are still trying to figure everything out as we go. I really don't get why you, Killerstorm, are on such a witch-hunt to bring so much negative attention to the project. What do you think to gain by this?

I'm out. I just want to build cool technologies, I don't feel like being sucked in to your negative spiral of attention. I have enough going on in my life not to be soaked in by internet-drama.

If somebody wants to evil then yes, he could write his own Mastercoin messages for distributed exchange, send them over the network see how they are interpret by the different sites and then see if he can somehow use that in such a way that he can invalidate a later send Simple Send. However at this moment the knowledge only exists with the developers and there is no guaranteed way to safely do this as the evil doer since there is no way of knowing who currently has the right way of implementing a feature.

In the future this might become a problem, but as of right now I see nothing wrong with it. I agree that in the future it's better to discuss a block at which a certain future will be enabled to prevent evil-doers from abusing it.

Your second argument is valid.