300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread)

[ripper234]

Zathras / Grazcoin need your thoughts on the following.

User A has 300 Mastercoins and creates/broadcasts selling offer to sell these 300 coins. What happens with user A's balance?

Two options as I see it:

1. The 300 get deducted from his balance making it 0 and simple send transactions sent while his offer is still valid open will get invalidated until he cancels the offer.
2. The 300 stay and are not reserved, only accepted offers get deducted from the balance. If User A sends 100 coins while the offer was still open and User B wants to purchase 300 coins his Purchase Offer will be invalid and he should not send the funds.

I prefer option 1 since it makes things easier to work with and it's expected behaviour on exchanges. This would also mean that you can't make an valid offer that is larger then the amount of MSC that you hold.

Posting an offer that is larger than the amount of MSC you hold is actually an important feature in my book.
Gox had this a while back.

You might want to let _the system_ know you want to sell, even if you don't have the balance yet.
Then, immediately when you receive funds (e.g. you're waiting for a 3rd party to pay you), these funds turn into a live offer.

The UI and offer matching engine should filter "live offers" from offers that lack funding.

I support option #2, not #1.

[1715397994]

1715397994

[1715397994]

1715397994

[1715397994]

1715397994

[1715397994]

1715397994

[ripper234]

Sorry I just saw you good idea to discuss this over at the issue, and not here.
I won't be commenting on this issue here anymore, only on github.

[zbx]

I would however encourage you to target Class B transactions in your software for simple sends rather than Class A due to the blockchain bloat issue.

Yeah, it's on my to-do list .

[Bitoy]

Simple Send Chart
http://mymastercoins.com/About.aspx

Test MSC Chart
http://mymastercoins.com/CurrencyCharts.aspx?CurrencyID=2

(but It needs more data =)

[dacoinminster]

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.

[zathras]

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!

[inform]

Nice for this you

[Bitoy]

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.

Doing something new makes this project the most fun programming project I've worked on.   The support from fellow "contestant" is  excellent (And Also the btc  .   Thank you for the opportunity!

[Bitoy]

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!

https://bitcointalk.org/index.php?topic=292628.msg3488484#msg3488484

tachikoma said he might have considered purchase offer as payment.

(If this trans is invalid, the other sends of this buyer is also invalid.)

[zathras]

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!

https://bitcointalk.org/index.php?topic=292628.msg3488484#msg3488484

tachikoma said he might have considered purchase offer as payment.

(If this trans is invalid, the other sends of this buyer is also invalid.)

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.

[Bitoy]

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!

https://bitcointalk.org/index.php?topic=292628.msg3488484#msg3488484

tachikoma said he might have considered purchase offer as payment.

(If this trans is invalid, the other sends of this buyer is also invalid.)

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.

+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.

[Tachikoma]

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.

[Tachikoma]

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

Code:

[{address: 1KZmDQGzGJWYmPP9X3b7TA9dY91KBXgaG4, balance: 20.1}, {address: 1Q1sFqsi8S5DxV5hz6sWLamGBp9To93iG7, balance: 3.1}, etc..]

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/<ADDRESS>

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?

[Bitoy]

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.

[Bitoy]

5ba2c63199d06815a4b385038b9515e21f0f1693818b5d289842f8931107a766 

Receipt Sequence is  95 and Data sequence is 100.   


Is this still valid?

[Tachikoma]

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. 

[prophetx]

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.

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

thanks

[Tachikoma]

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

[rbdrbd]

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)

[Tachikoma]

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.

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.