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

Sorry for making your lives so difficult

If it's comforting to you, I have too many ideas for myself as well ... I can't sleep in the last week because of all the adrenaline.
I know I'll have to wind down a bit (health is top priority), but I'm still pushing myself just a bit more because I can't let this go.

Don't worry all, I'm in perfect health ... there's just so much going on these days with Bitcoin, Mastercoin and everything, it's mind boggling.

Terrific proposal Tachikoma!
I haven't delved into the technicals, but I love how we distribute and standardize even our QA processes.
This should be in the spec. Submit a pull request?

If creating custom urls is a problem for you we can just do the discovery method. I'm guessing creating a mastercoin.txt file in your root is possible? If so we can have a json file there that has two keys.


This would tell the API where and how to query the data. The transaction lookup would become /mastercoin-verify/transactions?id=addresssuppliedhere.

Would this work for everybody?
Agreed, it's awesome Ros is taking the lead. The only problem is that he has way too many ideas and the developers can't keep up with the growing feature-list

I just wanted to drop a note here congratulating Ron Gross (ripper234) on volunteering to commit his full time efforts as the Executive Director for the Mastercoin Foundation (unanimously confirmed by the Board).

As many of you know and J.R. has stated here before, the Mastercoin Foundation has been searching for someone to take the Executive Director role for the last 70 days since the Exodus Address period finished.

This emerged organically as Ron began spending more and more of his time on the Mastercoin Project, after having participated in the Exodus Address and being very active in the community. I've witnessed first hand Ron passionately spread the word to many early adopters, host the very first Mastercoin meetup, actively recruit additional developers, advocate for improvements to the protocol including the Proof of Stake system / Contracts For A Difference, and get the Mastercoin protocol officially up on Github.

Thanks Ron for committing your time, energy and talents to this extremely important project for all of us in the Bitcoin / Mastercoin community.

David A. Johnston - Executive Director of BitAngels.co and Board Member of the Mastercoin Foundation

P.S. All the developers on this thread are awesome! I check in about once a day and I'm constantly blown away by the progress and how fast things are moving forward. Its not said often enough, so let me just state for the record, "You guys are rock stars".



  

Yep; peek and decode because the sequence numbers are wrong.  The open question is whether 'peek and decode' is acceptable.  Tachikoma & I after some discussion agreed that we'd allow for peek & decode if the sequence numbers weren't done right, but JR has to make the final call as to whether that makes it into the spec.

From the suggested amendment:

FYI fwiw as it stands now Masterchest does not currently implement 'peek & decode' in code.  It's a principal we've suggested and I'm waiting to see if it's accepted before cutting code.

Another example is ecb77ee990de29745de949462e1f6e44584c310a0da12c9fbdf86dbe6ffabcfc, we discussed this one a few pages back.  The sequence numbers are in the wrong order so Masterchest throws it out.  'Peek and decode' could have validated this transaction.

Completely agree this would be a good idea.  My views on APIs from the beginning have been that we should have compatible APIs available for end users so thin clients don't have to rely on a single 'source of truth' (ie they can aggregate data from multiple sources for verification). 

As to the specific approach I'd need to have a think about this (as currently for my implementations you would use GET ......./whatever.aspx?parameter=value rather than GET ...../parameter/value).

The speed at which speed is accelerating speed is just accelerating with a speedy acceleration.

Crazy world.

Ok thanks.    transaction falls in the "peek and decode".

mastercoin-tools / masterchain.info will support offline wallet in a user-friendly way.
I expect it to take another 1-2 weeks until it is ready.

I am no expert on Armory but I believe it can sign raw transactions. If this is indeed the case you can use mastercoin-explorer.com to create the offers then sign the raw transactions with your own client and relay them through Eligius or Blockhain.info. I also have plans to implement seedless addresses into my wallet software but that's a long term plan. This can be used right now.

Hi guys, quick question on the distributed exchange: as Mastercoin is becoming much more valuable now, is there a way to create buy and sell offers from a totally "offline" machine?

I was planning on moving to an offline armory-based setup (with cheapo laptop with no internet connection) for BTC, and wanted to use this same kind of setup with MSC as well...i.e. comprise the trade on the offline machine (that has wallet.dat), then sneakernet/email some trade code/key/trade token to the connected machine to actually input into the MSC network (that does not have wallet.dat). It seems that currently one can not do simple sends with an offline setup like this (from my own experimentation), but I wanted to check on the distributed exchange features.

If this is not possible, then any ideas when someone may get around to it? If MSC raises another 10-30x, you'll have several MSC millionaires in the bunch. If I was one of those guys, I'd be very concerned with doing any trades out of a wallet connected to the internet.

(oh and Tachikoma...btw, the top50 page is broken again ...it displays, but is not showing the full list like it was before...but if you're having parse errors/invalids, then that would make sense why http://mastercoin-explorer.com/addresses)

I haven't pushed to git for a while. I will finish my rspec testsuite and push the code, they are almost human-readable and should be easy enough to understand

i'd like to document these cases at some point.  which codebase should i look at? is it on github?

thanks

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. 

5ba2c63199d06815a4b385038b9515e21f0f1693818b5d289842f8931107a766 

Receipt Sequence is  95 and Data sequence is 100.   


Is this still valid?

The following address have balance differences in MyMastercoins (balance is the same with MasterChest) and Mastercoin-Explorer

1Q1sFqsi8S5DxV5hz6sWLamGBp9To93iG7
1KZmDQGzGJWYmPP9X3b7TA9dY91KBXgaG4
1D2UUm9noQ5eW7mQ8oMiqxvbFqB8wuvvWS
1GaNupdUBzfVF2B3JUAY1rZwHoXJgjyzXj
1AGFxUanxnWnrTiwLsY4NyvNZTv3RWFnfT
1HRE7U9XNPD8kJBCwm5Q1VAepz25GBXnVk
1FZ9VevcVXQseSAQPe3zuCzsWQavQpZo4g
182osbPxCo88oaSX4ReJwUr9uAcchmJVaL
1255GUS55xvs6rkiuEzgfT35jq4Kkk9gQL
1GStibNbpqjg9Uzk1HhfkH75iU4qgND3w5
17P14P4J5Mqg9CfdKLqeLGgW4izfPUEtTc
1K2qmHwxyZumsfWPWekrEwo62UzvxY6V9m
1Gy9bvCewiwjVEr6DoAvMgvvCcvoaA7rqo
1BZQqDm9sQLMU85YZPhus1fCudxaNbCvFK
1HMGFJLpVabBkPr7qqcMUXtwrTxfdYUgKL
1LSvh4a96Gp3M9buwefrweiM9pGFzVb6Q9
1DhaCk1w29NgzWcxuRDdzMwEpP4Htt5UVF
1FQSAnnotZBmeQxoSdv3ZykewjhpC5AJmd
1HnnR3S9KiNv1KobVQKEz5xuhrTm8ArTYh
1GK6Q2xo5zYnaZgcYVQrtyLvUjYoCZW6Hq


Tachikoma,

I agree on the API.

Mastercoin web-services verification API proposal.

The Mastercoin validation rules are getting harder the more transaction types are being added. We need a way to easily determine when one of the implementations differs from the others. In order to faciliate this I would recommend every webbased Mastercoin service implements an API that repsonds to a few API calls in a specific format. This data can be used by a third-party application/webapplication to compare implementations and give notifications when there is no consensus.

I would like to start out simple with just two API calls which return valid JSON files.

GET /mastercoin-verify/addresses


This could be used to do a quick and dirty comparison between address balances. If the amount differs between implementations the following API call be used to find the offending transaction.

GET /mastercoin-verify/transactions/

Code:

{address: 1KZmDQGzGJWYmPP9X3b7TA9dY91KBXgaG4, transactions: [{tx_hash: 5f01def181b761f1d03bcd20590c5729a47b11c68955b364add9253d7aec5eb9, valid: true}, {tx_hash: 130c5175d4f3e9add03bd1d115a87b26e613293fbe3815b970f8fc830f018ebc, valid: false}....etc]}

Using these methods we can find the offending transaction and report it. Either by sending an email to signed up developers, simply displaying the transaction on a site or some other way. End users can even use it themselves to verify their own transactions and make sure they are valid everywhere.

We could make the urls customisable and create a robots.txt like file that tells us where to find the API calls per service but I couldn't think of a reason why we can't hardcode the paths.

I would like to make this an addendum to the spec, although I'm not 100% sure it belongs there. Opinions?

Yeah I totally agree. This is more a bug then anything else. I've spend the last few days rewriting / adding to the validation code since there are now so many use cases to consider.

+1 I also think there should be a 3rd transaction for the actual payment. Btc sent in the  Accept offer should not be considered as payment.

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.