None of the websites recognize those coins yet. Don't worry, they will. I'm planning on sending some of those MSC to each of the website owners. I hate to distract them from what they are doing now though.

Also, we're bullish on MSC here at the Mastercoin Foundation. So we'd much rather buy them than spend the ones we have

Thanks, that worked! Your feed is not valid JSON yet however. Strings and keys need to be surrounded in quotes, I think it should be valid after that.

You can always check your feed using: http://jsonlint.com/

I wouldn't want to make an exception for just one message, it needs to be protocol wide if we want to even consider this.

FYI: I made a small change to the Verification Spec; I changed the url from mastercoin-verify to mastercoin_verify. I also tried checking out your urls but http://mymastercoins.com/jtransaction.aspx?Address=1QF9Hag3nyjAcXRd6mFrL5KyM3r71hVu2T doesn't seem to work.

My verification API is online.

http://mastercoin-explorer.com/mastercoin_verify/addresses
http://mastercoin-explorer.com/mastercoin_verify/transactions/17UDyggWFP6T3tUPTUEHMU8gxRtLZHG322

As soon as I have some tools available I will create a small comparison service.

Something has been bothering me when coding up my Mastercoin implementation these last few weeks. There is one thing in the spec that makes coding up Mastercoin implementations a lot harder and, because of this, less reliable then it has to be.

The position of a certain transaction in a given block. You constantly have to do two separate checks, 'is there a transaction in this block that has a position lower then the current one that can influence this message?' if not 'query all previous blocks for the information' that you need. It also contributes to the 'random chance' effect I already spoke about. Depending on the position of your transaction in a given block it might be either invalid or valid.

I hate chance, and I would like to eliminate it as a factor for Mastercoin.

My proposal would make everything a lot cleaner and easier to work with but would introduce a 1 block lag.

Current situation
User A creates a 'Selling Offer' of 1 MSC for 0.1 BTC in block 25
User B creates a 'Purchase Offer' of this 1 MSC while User A modifies it's original order to now sell 1 MSC for 0.9 MSC. Both transactions end up in block 26 but the modified 'Selling offer' ends up above the 'Purchase Offer'.

If user B still wants to buy user a's offer he now needs to pay 0.9 while if luck was different he could have paid 0.1 BTC.

Artificial 1 Block lag
User A creates a 'Selling Offer' of 1 MSC for 0.1 BTC in block 25
User B creates a 'Purchase Offer' of this 1 MSC while User A modifies it's original order to now sell 1 MSC for 0.9 MSC. Both transactions end up in block 26.

However to get all information this time we skip checking the current block and only look at what happend before this block. The offer gets matched up to the original one regardless of which position the changed 'Selling Offer' ended up with.

I understand if this is a controversial topic but I want to bring it up anyway because I really believe this will make everything better. 

Since there are only three 0.00006 outputs, one of which is the Exodus we know the recipient address is the one that does not contain the mastercoin data. I believe we decided this would be valid. 

Thanks for the ref, must have missed that somehow.  I'm not sure Tachikoma is saying that's the way it should be, more that's the way his implementation currently works.  Hopefully he'll clarify.

In my own view considering these transactions valid would be deviating from the current 3 step process (sell offer, accept offer, make payment).  I think it adds code complexity and may confuse the usage message if we start saying the 'accept offer' can contain bitcoin funds in the reference output to the seller that count towards the payment.

Tachikoma, I'm doing some cross testing - can you please let me know which transaction ID you're using to validate payment for this purchase/accept offer transaction 33644e6f24b29e1ef170d78ff04eab6f7e19368908edc6d477f9902697a71d67?

Thanks!

Tachikoma and bitoy: I am LOVING these charts!

Seriously. I am so jealous of you guys. This has got to be the most fun programming project I have ever seen. I'm grateful for the part I get to play in it, even if I'm not (currently) slinging code.

Thanks mate, have to say I am quite proud of how the new exchange panels look, might post a teaser screenie later after work

bitoy - great job on mymastercoins.com!

I've added links to the OP of the main project thread, and to our subreddit. I'll see about getting it listed on Mastercoin.org too. Looks like masterchain.info needs a link from there too.

Thanks!

If anybody notices that their project isn't linked from one of our channels, please let me know. I don't want to slight anyone!

According to my interoperation Buyer B's Purchase Offer would be invalid since he wanted 10 coins but at that moment only 7 were available.

I don't think so. The payment was one block later then the "Purchase Offer"

Thanks for checking my data. I'm not sure I understand you correctly though. Could you try explaining it with examples what went wrong?