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

[ripper234]

the project should buy...

the Foundation does not...  ...purchase hardware or otherwise pays for operational costs

Got it.  Agreed.  But the project is much larger than the foundation.  The foundation should just continue doing what it does.  But there might be another aspect of the project which could support such a transaction.  Otherwise, 'open source' projects would be severely weakened by an inability to put in place hardware needed to advance the goals.  Maybe the 'foundation' could propose schemes by which this sort of matter might be handled.  

I am thinking a Master Protocol Advancement Corporation incorporated in Haiti where prosecutors are less likely to be concerned with its activities - the corporation being non-profit and operational for getting things done which need to be done - without exposing the foundation to any tricky situations .

I appreciate the intent, but frankly my opinion is that this is not a real concern in practice.
Just like the Bitcoin Foundation doesn't sponsor exchanges or wallets, because there isn't a need for this - we are working to create a similar ecosystem around the Master Protocol, where interested parties will have other motivation to run our wallets and block explorers.

As an example we can give the wonderful masterxchange (thanks guys!) that got that initiative up & running without ever being approached or supported by us (except for a security bounty we volunteered to pay after the fact). We will support similar initiatives and improvements going forward as part of the $15,000 monthly innovation budget (+ bonus Dev MSC), but ultimately entrepreneurs will need to spring up and build the stuff.

Things are in the work...

[ripper234]

BTW why has this thread been exiled to the Marketplace sub-category ??!!

Can we get someone to move it to the alt section?

We need a Bitcoin 2.0 subcategory on bitcointalk.
Any contributions towards creating that category will also rewarded as part of the monthly general innovation fund.

[Nagan]

I'm finishing up my last couple days at my day-job, and my first day full-time on Mastercoin is Thursday. I can't wait!! At the top of my priority list is paying out 3k+ MSC to everybody who has earned bounties so far. I'll post exact amounts later this week once I am full time.

That's some great news! We were thinking that you already abandoned us here on bitcointalk

Actually, I think that communication channels were bit diluted recently, and community has to be constantly informed on progress. Otherwise it's just money, without real people.

[Bitoy]

Tachikoma,

Will mastercoind have a -daemon?

(I'm trying to build a new wallet using " bitcoind.exe - daemon" but can't get it to sign a transaction. )

[ripper234]

I'm finishing up my last couple days at my day-job, and my first day full-time on Mastercoin is Thursday. I can't wait!! At the top of my priority list is paying out 3k+ MSC to everybody who has earned bounties so far. I'll post exact amounts later this week once I am full time.

That's some great news! We were thinking that you already abandoned us here on bitcointalk

Actually, I think that communication channels were bit diluted recently, and community has to be constantly informed on progress. Otherwise it's just money, without real people.

We have a full on dev update post every week at blog.mastercoin.org (check out the latest post for a chance to win $3000 + extra Dev MSC if you refer good developers our way)

BTW we have a skype group if anyone's interested to more realtime updates.
You can pm dominik.zynis, ryan.keenan.11, or me at ripper234 and ask to be added to this group.

[ripper234]

Everyone - please take a look at this important post on how monthly bounties are going to function from this month onward.

Comments welcome, we also reserve some BTC to anyone who helps defining the parameters of the grading system (see details in the post).

[dacoinminster]

Everyone - please take a look at this important post] on how monthly bounties are going to function from this month onward.

Comments welcome, we also reserve some BTC to anyone who helps defining the parameters of the grading system (see details in the post).

Note that I incorrectly said we were going to do 50k at first followed by 100k, which was incorrect (it will always be 100k). I have corrected my earlier post.

[Bitoy]

Here is my interpretation of the Sell Action. Comments are welcomed =)

A New transaction is valid only if there is no previous sell offer or the previous sell offer is a cancel.

An Update transaction is valid only if there is a previous sell offer with "Available Amount for Sale" (Original Amount less Amount already sold) >0.

A Cancel transaction is valid only if the previous sell offer is an update or new. 

[zathras]

Here is my interpretation of the Sell Action. Comments are welcomed =)

A New transaction is valid only if there is no previous sell offer or the previous sell offer is a cancel.

An Update transaction is valid only if there is a previous sell offer with "Available Amount for Sale" (Original Amount less Amount already sold) >0.

A Cancel transaction is valid only if the previous sell offer is an update or new.  

Hey bud,

Further to our discussion on email - yeah the forum is starting to look a little subdued - at the mo I have a lot of discussions over email with various parties and I attend the conference calls to sync up on the latest etc and there is of course github discussion on various pulls - but not much is now discussed here on the forum.  I want to make sure people know we're still pegging away getting ready for the DEx launch though, so figured I'd reply to your last email here instead.

Re above - I agree we need a set of defined rules like this, though we need to add in modifiers such as reserved funds etc.  Perhaps a matrix of actions & expected results should be defined - though this may be better suited to Marv's test plan?

On the signing problem you're having with the test transaction you did with my library - that took me an hour to figure out which I now feel a bit silly about haha - it's actually ridiculously simple - the input has been spent which is why the reference client is refusing to sign.  This shouldn't happen because you'd usually create, sign and then broadcast a message for the user in one go.  In this case, between the time you created the transaction & now, the input has been spent.  

If you look up the transaction the library chose for the input in blockchain.info, that should demonstrate what I mean:
https://blockchain.info/tx/17b2788700ae59b18abf98549c7524871793a79222f6cdb00fbd327287cc1078

TL:DR; just call the library again using the same details and it'll create a new message for you using a new unspent input.  That should then sign OK.  Hope that makes sense!

Thanks
Zathras

[Bitoy]

On the signing problem you're having with the test transaction you did with my library - that took me an hour to figure out which I now feel a bit silly about haha - it's actually ridiculously simple - the input has been spent which is why the reference client is refusing to sign.  This shouldn't happen because you'd usually create, sign and then broadcast a message for the user in one go.  In this case, between the time you created the transaction & now, the input has been spent.  

If you look up the transaction the library chose for the input in blockchain.info, that should demonstrate what I mean:
https://blockchain.info/tx/17b2788700ae59b18abf98549c7524871793a79222f6cdb00fbd327287cc1078

TL:DR; just call the library again using the same details and it'll create a new message for you using a new unspent input.  That should then sign OK.  Hope that makes sense!

That makes sense(my bitcoin wallet is 8 days late).  So  the  block chain with the unspent transaction has to be downloaded before a new transaction can be signed  (then sent) by bitcoind.

Thanks for looking.   Sorry for the one hour setback.  Let's go back to coding

[Bitoy]

Posted a Sell Offer with Action=1.

Please advise if this is correct.

1b928ff05d0895dda13b691209948ac453c1b8f5bc59f08925814a2fc853116e

[Bitoy]

Edit

Action=Cancel
8d85b6f6534023f270cedc474dde29dfb168fbbdb3a8b8ecfa9b70d96bdcba41

Action =New
ab68bf2b0cd7fcd1f5acf03b286d565016335448c68737ba39600968b998cd9e

[dexX7]

Is there currently any web API available to fetch balance and number of incoming transactions for a specific MSC address?

[zathras]

On the signing problem you're having with the test transaction you did with my library - that took me an hour to figure out which I now feel a bit silly about haha - it's actually ridiculously simple - the input has been spent which is why the reference client is refusing to sign.  This shouldn't happen because you'd usually create, sign and then broadcast a message for the user in one go.  In this case, between the time you created the transaction & now, the input has been spent.  

If you look up the transaction the library chose for the input in blockchain.info, that should demonstrate what I mean:
https://blockchain.info/tx/17b2788700ae59b18abf98549c7524871793a79222f6cdb00fbd327287cc1078

TL:DR; just call the library again using the same details and it'll create a new message for you using a new unspent input.  That should then sign OK.  Hope that makes sense!

That makes sense(my bitcoin wallet is 8 days late).  So  the  block chain with the unspent transaction has to be downloaded before a new transaction can be signed  (then sent) by bitcoind.

Thanks for looking.   Sorry for the one hour setback.  Let's go back to coding

All good mate - I was worried the library had a serious bug so I'm glad it's something simple

Yep - the library uses the listunspent RPC call to the reference client to determine which unspent inputs are available for the sending address.  If the blockchain is not fully downloaded then yeah these unspent inputs won't be fresh.

[zathras]

Is there currently any web API available to fetch balance and number of incoming transactions for a specific MSC address?

Balances:

Example - just filter the output for your chosen address to get the balance.

https://masterchest.info/mastercoin_verify/addresses.aspx

Transactions:

Example - just replace address with the one you want to query.

https://masterchest.info/mastercoin_verify/transactions.aspx?address=1DYb5Njvcgovt9gUMdMgYkpaQjAEdUooon&currencyid=1

Thanks
Zathras

EDIT: Forgot to mention, if using web API's please make sure to use a consensus methodology to protect against a rogue implementation & provide fault tolerance.  Example below.  Thanks

$ ./getmscbal.sh 1J7tvKQLbfwqiXKUdaMpsAgHUTaYWucPLv
Requesting balance for address 1J7tvKQLbfwqiXKUdaMpsAgHUTaYWucPLv...

Checking masterchest.info...
Balance returned from masterchest.info is 151.7087092
Checking mastercoin-explorer.com...
Balance returned from mastercoin-explorer.com is 151.7087092
Checking masterchain.info...
Balance returned from masterchain.info is 151.7087092
Checking mymastercoins.com...
Balance returned from mymastercoins.com is 151.7087092

Consensus check: Balances match
Consensus balance: 151.7087092

Script source:

Code:

#!/bin/bash

# Script to query the four major implementations and request balance for address supplied as $1
# Zathras Feb/2014

# Logic is rinse repeat, so drop in a function to filter down to just balance
function getbal {
# Note workaround the fact some implementations add whitespace into json output by replacing ": " with ":"
temp=`echo $json | sed "s/},/\n/g" | grep "$add" | sed "s/: /:/g" | sed 's/.*"balance":"\([^"]*\)".*/\1/'`
echo ${temp##*|}
}

# Grab parameter and throw into $add var
add=$1

# Grab verification API json from each implementation and then filter with above function to get balance
# Store balance in vars $bal1 to $bal4 so we can compare for consensus
echo Requesting balance for address $add...
echo
echo Checking masterchest.info...
json=`curl -s -X GET https://masterchest.info/mastercoin_verify/addresses.aspx`
bal1=`getbal`
echo Balance returned from masterchest.info is $bal1
echo Checking mastercoin-explorer.com...
json=`curl -s -X GET http://mastercoin-explorer.com/mastercoin_verify/addresses?currency_id=1`
bal2=`getbal`
echo Balance returned from mastercoin-explorer.com is $bal2
echo Checking masterchain.info...
json=`curl -s -X GET https://masterchain.info/mastercoin_verify/addresses/0`
bal3=`getbal`
echo Balance returned from masterchain.info is $bal3
echo Checking mymastercoins.com...
json=`curl -s -X GET http://www.mymastercoins.com/jaddress.aspx`
bal4=`getbal`
echo Balance returned from mymastercoins.com is $bal4
echo

# Check consensus
if [ "$bal1" == "$bal2" ] && [ "$bal1" == "$bal3" ] && [ "$bal1" == "$bal4" ] && [ "$bal2" == "$bal3" ] && [ "$bal2" == "$bal4" ] && [ "$bal3" == "$bal4" ]
then
echo "Consensus check: Balances match :)"
echo "Consensus balance: "$bal1
else
echo "Consensus check: BALANCES DO NOT MATCH!!! :("
fi

[Bitoy]

Is there currently any web API available to fetch balance and number of incoming transactions for a specific MSC address?

Here are 2 APIs that you use
1. http://www.mymastercoins.com/jaddress.aspx
Optional Parameters
Address (if blank, it will show all Addresses)
Currency_ID (1 is MSC, 2 is TMSC, if blank it defaults to 1)

Ex.
http://www.mymastercoins.com/jaddress.aspx?address=1MaStErt4XsYHPwfrN9TpgdURLhHTdMenH

http://www.mymastercoins.com/jaddress.aspx?address=1MaStErt4XsYHPwfrN9TpgdURLhHTdMenH&currency_id=2


2. http://www.mymastercoins.com/jtransactions.aspx

Required Parameters
Address

Optional Parameters
Currency_ID (1 is MSC, 2 is TMSC, if blank it defaults to 1)
DateFrom (starting date, mm/dd/yyyy format)
DateTo (ending date, mm/dd/yyyy format)


Ex.
http://www.mymastercoins.com/jtransactions.aspx?Address=1MaStErt4XsYHPwfrN9TpgdURLhHTdMenH&currency_id=2

http://www.mymastercoins.com/jtransactions.aspx?Address=1MaStErt4XsYHPwfrN9TpgdURLhHTdMenH&currency_id=1&datefrom=01/28/2014

http://www.mymastercoins.com/jtransactions.aspx?Address=1MaStErt4XsYHPwfrN9TpgdURLhHTdMenH&currency_id=1&datefrom=01/28/2014&dateto=02/10/2014

As advised by Zathras, always use consensus checking to confirm balances and transactions.

[Bitoy]

MyMastercoins Wallet v 2 preliminary testing is done.  Below is the transactions created by the wallet. More testing next week.

2/14/2014 4:57:57 PM   
0b77033abe7d9c2c06120d5fbd3708bba4a8da39989c9431704c9fd95412d97a      
Valid   Payment: 0.00217778 btc for 0.01088888 TMSC

2/14/2014 3:51:17
36f191348998adb993a4d2e4041a0aeb2cc108521d1a48a04c484baa9a1d3216   
Valid   Purchase Offer: 0.01088888 TMSC

2/14/2014 2:59:48 PM   
3411bd30165c86cde4b1fb99434acfc49aaaa5e7a13dcaf2d13d052a5aace097
Valid   Simple Send: 1.088 TMSC

2/14/2014 2:01:38 PM   
effcb1a90f15b39ef2295d8b1d5b3fa5c4a156936b5cfcb770ca68ac1e7ace0e
Valid   New Offer to Sell: 10 TMSC for 2 btc

[grazcoin]

2/14/2014 2:01:38 PM   
effcb1a90f15b39ef2295d8b1d5b3fa5c4a156936b5cfcb770ca68ac1e7ace0e
Valid   New Offer to Sell: 10 TMSC for 2 btc

When parsing the above transaction, the data script is:
00010000001400000002000000003b9aca00000000000bebc20014000000000000

Transaction Version is the 0000
Transaction Type is 20

I assume you wanted to use the updated sell offer:
According to https://github.com/mastercoin-MSC/spec/#sell-mastercoins-for-bitcoins :
Transaction version = 1
Action = 1 (New offer)

The action is indeed 1, but the transaction version is 0 (the first 2 bytes from 00000014), as described in:
https://github.com/mastercoin-MSC/spec/#transaction-definitions
"the first field in each transaction message is the 2 byte version number"

Am I correct?

If so, that this transaction is invalid (action 1 is not defined on sell offer version 0).
I didn't check the other transactions you mentioned yet.

[grazcoin]

2/14/2014 2:01:38 PM   
effcb1a90f15b39ef2295d8b1d5b3fa5c4a156936b5cfcb770ca68ac1e7ace0e
Valid   New Offer to Sell: 10 TMSC for 2 btc

When parsing the above transaction, the data script is:
00010000001400000002000000003b9aca00000000000bebc20014000000000000

Transaction Version is the 0000
Transaction Type is 20

I assume you wanted to use the updated sell offer:
According to https://github.com/mastercoin-MSC/spec/#sell-mastercoins-for-bitcoins :
Transaction version = 1
Action = 1 (New offer)

The action is indeed 1, but the transaction version is 0 (the first 2 bytes from 00000014), as described in:
https://github.com/mastercoin-MSC/spec/#transaction-definitions
"the first field in each transaction message is the 2 byte version number"

Am I correct?

If so, that this transaction is invalid (action 1 is not defined on sell offer version 0).
I didn't check the other transactions you mentioned yet.

So is it my mistake or Bitoy's ?

According to my parsing, one could see that the transaction version is 0000:
https://masterchain.info/selloffer.html?tx=effcb1a90f15b39ef2295d8b1d5b3fa5c4a156936b5cfcb770ca68ac1e7ace0e&currency=MSC

I think we should invalidate that tx then (due to incompatible version and action).

And then there is the question if we keep version 0 sell offers or not - since then there may be version 0 sell offers which are modified by version 1 or the opposite. My suggestion - invalidate all version 0 sell offers now.

[Bitoy]

Thanks Grazcoin,

You are correct.
I didn't  add a version number in the transaction.   And the parser ignored the version number.  Will update this.

If version is 0, we should treat it as version 0, ignoring the action byte.   The transaction should still be valid.  

Btw if we allow version 0, won't that defeat the purpose of having an action byte?


+1 on invalidating all version 0 offer to sell.

2/14/2014 2:01:38 PM   
effcb1a90f15b39ef2295d8b1d5b3fa5c4a156936b5cfcb770ca68ac1e7ace0e
Valid   New Offer to Sell: 10 TMSC for 2 btc

When parsing the above transaction, the data script is:
00010000001400000002000000003b9aca00000000000bebc20014000000000000

Transaction Version is the 0000
Transaction Type is 20

I assume you wanted to use the updated sell offer:
According to https://github.com/mastercoin-MSC/spec/#sell-mastercoins-for-bitcoins :
Transaction version = 1
Action = 1 (New offer)

The action is indeed 1, but the transaction version is 0 (the first 2 bytes from 00000014), as described in:
https://github.com/mastercoin-MSC/spec/#transaction-definitions
"the first field in each transaction message is the 2 byte version number"

Am I correct?

If so, that this transaction is invalid (action 1 is not defined on sell offer version 0).
I didn't check the other transactions you mentioned yet.