Topic: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) - page 43. (Read 129207 times)

Ok json is validated.

Thank you, I am getting an offline system in a few days and will try that out. I'll document whatever works and send it to Ron to make part of the FAQ.

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 now got your idea. Your delay 1 block will work to fix this issue.


Try (missing  s)
http://mymastercoins.com/jtransactions.aspx?Address=1QF9Hag3nyjAcXRd6mFrL5KyM3r71hVu2T

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.

We can give priority to purchase offer over selling offer is they have the same block time.
That way user b will get the price at .1

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.  

Opinions!?

It seems you might have misunderstood what a distributed exchange means. In this case it's not a place you go to exchange. It's a feature of Mastercoin build into the protocol. In order to sell/buy coins you need to send a crafted Mastercoin message with information on what you want to buy/sell. These wallets you talk about offer to do this for you and thus implement the distributed exchange functionality. 

ok where exactly is it explained as to how you will construct this Distributed Exchange?

it seems the winners of this Distributed Exchange contest are making anything but a Distributed Exchange. (appears to be wallets and other tools analogous to past Color Coin efforts).

if you have a Distributed Exchange, I would be very interested to see what you have done.

Please provide some information.  Thanks.

MyMastercoins.com

Here are the JSON files based on Tachikoma's API
http://mymastercoins.com/jaddress.aspx
http://mymastercoins.com/jtransactions.aspx?Address=$AddressHere


The default CurrencyID=1.   You can place &CurrencyID=2 for Test MSC.

PS.  I'm still working on the URL rewrite.

Sounds great. Maybe it may make sense for your test suite cases to be standardized at some level eventually (and possibly maintained independently), so that other library implementations can use those same test cases. That would make debugging differences between implementations (and their bugs) more apples-to-apples, and give a good "baseline" point for new library/backend implementations.

I'm already writing an rspec test-suite for my Rails implementation. It won't have 100% coverage but it will give you a good explanation of what to test for and how to implement it.

My implementation is based on Bitcoin-ruby, Zathras uses Bitcoin and Grazcoin Obelisk, loads of different backends

An idea: this API should be a great start for web-based MSC packages, but as at least I see the base MSC parsing libraries (such as mastercoin-tools maybe) being the base of the implementation, wouldn't it be good to add a unit test suite to them? Or are these various web tools currently using their own MSC parser implementations at this time?

I'm wondering what everyone's thought is to these multiple implementations of the MSC spec... eventually a good idea may be to code a reference implementation up in C/C++, which can then be brought up into higher level language libraries (in Ruby/Python/Java/C#, etc) using tools like swig/FFI/Cython, etc to prevent having to duplicate the "guts" of the protocol for each separate language. Maybe this was the idea behind mastercoin-tools and pymastercoin, etc eventually...??

Even the above would not be necessary if there was a standard "test suite" list of test scenarios published, which each MSC parser library implementation would build a scripted unit test suite against. Then, as various "gotchas" were caught that fell through the cracks of the test suite, it could be enhanced to cover those, as well as giving additional test scenarios for new features as they are built in and implemented across the various libraries. The pass rate on this standard list of test scenarios would denote the overall quality of the library, and keep functionality consistent across languages, sites, etc. "Certified status" could even be awarded by the Mastercoin foundation to implementations that consistently have a pass rate > X%.

I think this is in the spirit of what Tachikoma is trying to do, but not every MSC tool is web-based, with a web-based API.

Just a thought...

I've just send a pull request on Github for the verification API. I've added one more thing and that's supplying the currency_id you want to see the data on. Easiest way to read the text is not via the PR but via this direct link. As always please discuss the specification in the pull request itself to keep the discussion centralised.

Yes, I believe so. I haven't started building it myself so I can't be 100% sure but it looks valid enough!

Can you also use a mod-rewrite like solution to get a proper url?

Hi Tachikoma,

Will this json work?
http://mymastercoins.com/MSCJSON.aspx

Thanks a lot David!

My reply

http://pastebin.com/V1D8f2Hi

Awesome. I will submit a pull request later today.

I think I just noticed your profile photo for the first time.
WE ALL LOVE ZATHRAS!!!

Fantastic   Congrats & Thanks Ron.


Actually taking a second glance at this I can just use a URL rewrite mod so shouldn't be a problem