Hey Guys,
I think you still need to invalidate the sell offers from 1DYb5Njvcgovt9gUMdMgYkpaQjAEdUooon - the bitcoins desired field is zero and the spec says it must be at minimum 1.
Thanks
Zathras
Ok will invalidate sell offers with bitcoin desired = 0 |
|
|
|
Bitoy, This one's bugging me in the real MSC consensus check, your data is correct but any chance you can avoid using E numbers/notation? It makes my consensus system think there is a mismatch. Address MyMastercoins Masterchain MastercoinExplorer Masterchest
1Btf1fzDsf4HtFeNMjcfwDzCygahfkoq21 3E-08 0.00000003 0.00000003
Thanks  I've update jaddress.aspx but the consensus still sees 3E-08. |
|
|
|
|
After removing the overpayment option (in the Test server):
Only 3 Differences with MasterChain
MM=38.88135379 1EqTta1Rt8ixAA32DuC29oukbsSWU62qAV MCHAIN=45.498
MM=2.2345679 1BKpa19m5Xy9SvSzC5djPWtCfbuynSDwmb MCHAIN=3.00124938
MM=536.90527669 13NRX88EZbS5q81x6XFrTECzrciPREo821 MCHAIN=526.90527669
Only 6 Differences with MasterChest
Note 3 are almost the same only .00000001 difference
MM=38.88135379 1EqTta1Rt8ixAA32DuC29oukbsSWU62qAV MCHEST=49.12022221
MM=2.2345679 1BKpa19m5Xy9SvSzC5djPWtCfbuynSDwmb MCHEST=30.91534621
MM=0.700111 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX MCHEST=0.70458333
MM=4.01088888 1GtTPepFqS8MWZzFKsE62bNowY2LZos8Lq MCHEST=4.0108889
MM=0.09886999 1DYb5Njvcgovt9gUMdMgYkpaQjAEdUooon MCHEST=0.09887
MM=0.082 1G3P5bws8wRVrVfKWxv8F85pRjs9qXyyA6 MCHEST=0.08199999
|
|
|
|
|
Zathras your the sell offer below in masterchest is invalid.
03597f0bc804ecc355b2c4344cd1526c51209f9e3efa6d62192ec4dd923755e6
I think it is valid because if a seller sells more than his number of coins it is assumed he is selling all of it.
Ps. Will fix the consensus E number notations.
|
|
|
|
|
After adding the overpayment fix, reparsing my test server. I got the following differences
Getting shorter =)
MM=4.11111112 1BKpa19m5Xy9SvSzC5djPWtCfbuynSDwmb MCHAIN=6.12345
MM=37.00681057 1EqTta1Rt8ixAA32DuC29oukbsSWU62qAV MCHAIN=35.37455
MM=1 1QFWodNASZv8KRHnhypKaMys5CGRg7GrFQ MCHAIN=0
MM=4.0108889 1GtTPepFqS8MWZzFKsE62bNowY2LZos8Lq MCHAIN=4.01088888
MM=0.70458333 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX MCHAIN=0.700111
Comparison Completed
MM=4.11111112 1BKpa19m5Xy9SvSzC5djPWtCfbuynSDwmb MCHEST=30.91534621
MM=37.00681057 1EqTta1Rt8ixAA32DuC29oukbsSWU62qAV MCHEST=49.12022221
MM=0.082 1G3P5bws8wRVrVfKWxv8F85pRjs9qXyyA6 MCHEST=0.08199999
MM=0.09886999 1DYb5Njvcgovt9gUMdMgYkpaQjAEdUooon MCHEST=0.09887
Will try to check each one tomorrow.
|
|
|
|
https://blockchain.info/tx/0b77033abe7d9c2c06120d5fbd3708bba4a8da39989c9431704c9fd95412d97aThe amount sent is 0.00217778. You missed the last digit. Edit I should have paid 0.0002177776. But since max is 8 digit. It (my wallet) rounded off to 0.000217778. If Someone overpaid. Should we credit the overpayment cancel over payment For me I'm leaning towards canceling since I really wanted to buy only 0.0188888. It's just that I can't pay the exact amount because of the rounding limit But the spec says You must send the appropriate amount of bitcoins before the time limit expires to complete the purchase. Note that you must send the bitcoins from the same address which initiated the purchase. If you send less than the correct amount of bitcoins, your purchase will be adjusted downwards. The remaining coins will be added back to those available in the Sell Offer if it’s still active. If you send more than the correct amount of bitcoins and the Sell Offer has more coins still available your order will be adjusted upwards. So I'll follow the specs. Adjusted upwards because the seller has more coins to sell. 0.01088890 For address 1GtTPepFqS8MWZzFKsE62bNowY2LZos8Lq, in transaction 36f191348998adb993a4d2e4041a0aeb2cc108521d1a48a04c484baa9a1d3216 this is not a rounding error - from my understanding the coins bought value is 0.01088890 rather than the 0.01088888 you guys have. Coins bought is based on bitcoin payment even if over the originally accepted amount, as long as those extra coins are available (and they were in this case). This bitcoin payment was for 0.0021777 BTC, multiplied by the unit price of 0.2 gives us 0.01088890. Hope that makes sense
|
|
|
|
|
Here is a new trans I posted from the wallet
2 byte trans version
1 byte action
fdebcfcaf4d7bceddd206dc1f334d7c5ccb7a6890c0cfe9d7926be6d7d5e2f58
Please check if it is correct.
|
|
|
|
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.
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.
|
|
|
|
That could also be an advantage since it will be easier to sync the test msc
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.
|
|
|
|
|
Summary on Mastercoin wallets
Grazcoin - hybrid web based wallet.
Zathras - masterchest wallet
Omni wallet - saw it in the dev emails.
Me - mymastercoins wallet.
Android wallet to follow soon as windows wallet is stable.
Tachikoma is working on the go implementation of mastercoid. Which will be the basis of all future wallets.
|
|
|
|
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. |
|
|
|
|
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
|
|
|
|
|
Edit
Action=Cancel
8d85b6f6534023f270cedc474dde29dfb168fbbdb3a8b8ecfa9b70d96bdcba41
Action =New
ab68bf2b0cd7fcd1f5acf03b286d565016335448c68737ba39600968b998cd9e
|
|
|
|
|
Posted a Sell Offer with Action=1.
Please advise if this is correct.
1b928ff05d0895dda13b691209948ac453c1b8f5bc59f08925814a2fc853116e
|
|
|
|
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/17b2788700ae59b18abf98549c7524871793a79222f6cdb00fbd327287cc1078TL: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 |
|
|
|
|
Show Posts
