Pages:
Author

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

sr. member
Activity: 449
Merit: 250
Here is a new trans I posted from the wallet

2 byte trans version
1 byte action

fdebcfcaf4d7bceddd206dc1f334d7c5ccb7a6890c0cfe9d7926be6d7d5e2f58

Please check if it is correct.
legendary
Activity: 1260
Merit: 1031
Rational Exuberance
Quote
Treat each sell offer version 0 exactly as a sell offer version 1 with action 1 (new).

There are two edge cases here -
  • version 0 with Amount for sale = 0 (to cancel a sell offer) will produce a version 1 with Amount for sale = 0, which is not valid.
  • version 0 with new values (to update a sell offer) will fail because it will look like an attempt to create a new sell offer while that address has one that's active

Note that this conversation is also taking place on our dev mailing list, and not everything is posted here.

Currently the consensus seems to be the above plus allowing version=0 with amount=0 to represent the cancel action on those old transactions.
newbie
Activity: 4
Merit: 0
Quote
Treat each sell offer version 0 exactly as a sell offer version 1 with action 1 (new).

There are two edge cases here -
  • version 0 with Amount for sale = 0 (to cancel a sell offer) will produce a version 1 with Amount for sale = 0, which is not valid.
  • version 0 with new values (to update a sell offer) will fail because it will look like an attempt to create a new sell offer while that address has one that's active
legendary
Activity: 1260
Merit: 1031
Rational Exuberance

An alternative suggestion which is more backwards compatible but still doesn't complicate the parsing state machine - and therefore it is less bugs prone:
Treat each sell offer version 0 exactly as a sell offer version 1 with action 1 (new).
Then we will still have enough data to check our DEx implementations with, and the only differences from 0.3.5 spec version would be with modified sell offers (there are anyway only VERY few such).
There would be no problem to keep accepting version 0 sell offers also later in production.


I think that sounds perfect.
sr. member
Activity: 284
Merit: 250
Grazcoin,

Below is the msc spec on transaction version.  It looks like we will have to parse depending on the version number.   Previous transactions can't be invalidated.  

What if a user has an older version of a wallet.   It may lead to a fork if the old wallet uses a different version.

Quote

Transaction Definitions
The Master Protocol Distributed Exchange transactions are listed below. Transactions 0, 20, 21, 22 and 50 are to be implemented in the first deployment, per this spec. They are listed first. The other transactions will be fully defined and implemented in future releases.

Each transaction definition has its own version number to enable support for changes to each transaction definition. Up thru version 0.3.5 of this spec, the transaction type field was a 4 byte integer. Since there were only 17 transactions identified, the upper 3 bytes of the field had a value of 0. For all spec versions starting with 0.4, the first field in each transaction message is the 2 byte version number, with an initial value of 0 and the transaction type field is a 2 byte integer. So, each client must examine the first two bytes of the transaction message to determine how to parse the remainder of the message. If the value is 0, then the message is in the format specified in version 0.3.5 of this spec. If the value is at least 1, then the message is in the format associated with that version number.

Note: Master Protocol transactions are not reversible except as explicitly indicated by this spec.




My suggestion is just to invalidate sell offers of version 0, and keep any other transaction without change (all other version 0 of simple send and accept sell offer are valid).

Since the whole DEx is still not activated for MSC, there will be no damage. The balance of test mastercoins may be different if someone uses old software (which is not recommended anyway), but MSC balance will be the same.

The state machine that we have to keep already due to the new/modify/cancel is complicated enough within sell offer version 1 - we have to follow how much was sold on each generation of the sell offer modifications (there could be a long chain of modifications). If we do keep both version 0 and version 1 of sell offers, we *also* have to take care about interoperability between the sell offers of the different versions, e.g.:

  • sell offer version 0 modification on top of new sell offer version 1 - e..g cancel using modify amount to zero valid? then how to parse further modification using version 0 and version 1?
  • sell offer version 1 modification on top of new sell offer version 0 - is another modification using version 0 also valid?
  • we keep the race condition within version 0
  • we extend the race condition by using version 0 on top of previous version 1



An alternative suggestion which is more backwards compatible but still doesn't complicate the parsing state machine - and therefore it is less bugs prone:
Treat each sell offer version 0 exactly as a sell offer version 1 with action 1 (new).
Then we will still have enough data to check our DEx implementations with, and the only differences from 0.3.5 spec version would be with modified sell offers (there are anyway only VERY few such).
There would be no problem to keep accepting version 0 sell offers also later in production.

sr. member
Activity: 284
Merit: 250
Grazcoin,

Below is the msc spec on transaction version.  It looks like we will have to parse depending on the version number.   Previous transactions can't be invalidated.  

What if a user has an older version of a wallet.   It may lead to a fork if the old wallet uses a different version.

Quote

Transaction Definitions
The Master Protocol Distributed Exchange transactions are listed below. Transactions 0, 20, 21, 22 and 50 are to be implemented in the first deployment, per this spec. They are listed first. The other transactions will be fully defined and implemented in future releases.

Each transaction definition has its own version number to enable support for changes to each transaction definition. Up thru version 0.3.5 of this spec, the transaction type field was a 4 byte integer. Since there were only 17 transactions identified, the upper 3 bytes of the field had a value of 0. For all spec versions starting with 0.4, the first field in each transaction message is the 2 byte version number, with an initial value of 0 and the transaction type field is a 2 byte integer. So, each client must examine the first two bytes of the transaction message to determine how to parse the remainder of the message. If the value is 0, then the message is in the format specified in version 0.3.5 of this spec. If the value is at least 1, then the message is in the format associated with that version number.

Note: Master Protocol transactions are not reversible except as explicitly indicated by this spec.




My suggestion is just to invalidate sell offers of version 0, and keep any other transaction without change (all other version 0 of simple send and accept sell offer are valid).

Since the whole DEx is still not activated for MSC, there will be no damage. The balance of test mastercoins may be different if someone uses old software (which is not recommended anyway), but MSC balance will be the same.

The state machine that we have to keep already due to the new/modify/cancel is complicated enough within sell offer version 1 - we have to follow how much was sold on each generation of the sell offer modifications (there could be a long chain of modifications). If we do keep both version 0 and version 1 of sell offers, we *also* have to take care about interoperability between the sell offers of the different versions, e.g.:

  • sell offer version 0 modification on top of new sell offer version 1 - e..g cancel using modify amount to zero valid? then how to parse further modification using version 0 and version 1?
  • sell offer version 1 modification on top of new sell offer version 0 - is another modification using version 0 also valid?
  • we keep the race condition within version 0
  • we extend the race condition by using version 0 on top of previous version 1

sr. member
Activity: 449
Merit: 250
Grazcoin,

Below is the msc spec on transaction version.  It looks like we will have to parse depending on the version number.   Previous transactions can't be invalidated.   

What if a user has an older version of a wallet.   It may lead to a fork if the old wallet uses a different version.

Quote

Transaction Definitions
The Master Protocol Distributed Exchange transactions are listed below. Transactions 0, 20, 21, 22 and 50 are to be implemented in the first deployment, per this spec. They are listed first. The other transactions will be fully defined and implemented in future releases.

Each transaction definition has its own version number to enable support for changes to each transaction definition. Up thru version 0.3.5 of this spec, the transaction type field was a 4 byte integer. Since there were only 17 transactions identified, the upper 3 bytes of the field had a value of 0. For all spec versions starting with 0.4, the first field in each transaction message is the 2 byte version number, with an initial value of 0 and the transaction type field is a 2 byte integer. So, each client must examine the first two bytes of the transaction message to determine how to parse the remainder of the message. If the value is 0, then the message is in the format specified in version 0.3.5 of this spec. If the value is at least 1, then the message is in the format associated with that version number.

Note: Master Protocol transactions are not reversible except as explicitly indicated by this spec.


sr. member
Activity: 449
Merit: 250
That could also be an advantage since it will be easier to sync the test msc Smiley


Great!
So now we have to get the agreement from everyone else.
The disadvantage is that we will not have ready testing data, as there will be no valid DEx transactions.


sr. member
Activity: 284
Merit: 250
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.


Great!
So now we have to get the agreement from everyone else.
The disadvantage is that we will not have ready testing data, as there will be no valid DEx transactions.

sr. member
Activity: 449
Merit: 250
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.

sr. member
Activity: 284
Merit: 250

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¤cy=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.
sr. member
Activity: 284
Merit: 250

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.
sr. member
Activity: 449
Merit: 250
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
sr. member
Activity: 449
Merit: 250
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¤cy_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¤cy_id=2

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

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

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

sr. member
Activity: 266
Merit: 250
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¤cyid=1

Thanks Smiley
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

Quote
$ ./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 Smiley
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
sr. member
Activity: 266
Merit: 250
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 Smiley

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

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.
legendary
Activity: 1106
Merit: 1026
Is there currently any web API available to fetch balance and number of incoming transactions for a specific MSC address?
sr. member
Activity: 449
Merit: 250
Edit

Action=Cancel
8d85b6f6534023f270cedc474dde29dfb168fbbdb3a8b8ecfa9b70d96bdcba41

Action =New
ab68bf2b0cd7fcd1f5acf03b286d565016335448c68737ba39600968b998cd9e
sr. member
Activity: 449
Merit: 250
Posted a Sell Offer with Action=1.

Please advise if this is correct.

1b928ff05d0895dda13b691209948ac453c1b8f5bc59f08925814a2fc853116e
sr. member
Activity: 449
Merit: 250
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 Smiley





Pages:
Jump to: