aTriz
|
|
December 15, 2013, 07:52:34 AM |
|
1LjT88X7Zu8BdbqJw8vfRa83NJuzYL9kqm - my address everywhere shows 50~ msc but for some reason the windows wallet shows 40~
Click settings click reparse. Please pm me a screen shot. I did that but I found there is a double transaction, I'll PM you the SS now.
|
|
|
|
zathras
|
|
December 15, 2013, 09:58:54 AM |
|
Hi all, Latest update to masterchest.info is complete. Rolled a bunch of bugfixes and a couple of features from dev into prod, notables: Thanks!
|
|
|
|
Tachikoma
|
|
December 15, 2013, 10:06:30 AM |
|
Awesome additions! Especially like the consensus check, I still have a half finished product so I'm glad yours is working right now! I think we need a way to easily discuss these transactions and explain why we parse them a certain way. Although right now it seems Masterchest has a lot of other values compared to the other implementations. Could you see if there is something obvious that can be done to fix those differences? Could also you perhaps add a filter to hide addresses that match on all implementations?
|
|
|
|
Bitoy
|
|
December 15, 2013, 10:28:07 AM |
|
Nice consensus check.
Starting at address 1RavenHqiZ7euZ1ETKkKP74h5SPLovdF6
Only Mymastercoins column has value on the consensus, but when I checked at the website masterchest and master-explorer have values also for this address.
|
|
|
|
zathras
|
|
December 15, 2013, 10:37:37 AM Last edit: December 15, 2013, 10:50:52 AM by zathras |
|
Awesome additions! Especially like the consensus check, I still have a half finished product so I'm glad yours is working right now! I think we need a way to easily discuss these transactions and explain why we parse them a certain way. Although right now it seems Masterchest has a lot of other values compared to the other implementations. Could you see if there is something obvious that can be done to fix those differences? Could also you perhaps add a filter to hide addresses that match on all implementations? Those addresses where only Mymastercoins had values were a bug (just squashed) - I query all implementations for their list of addresses, it just so happens that Bitoy's is first on the list. There is whitespace in his JSON output so it was throwing off my address matching. A couple of handy trim functions and it's working again. Re filter, I haven't built in parameters into that page for filters (though I do intend to), in the mean time will this do? https://masterchest.info/consensus_tachikoma.aspxNice consensus check.
Starting at address 1RavenHqiZ7euZ1ETKkKP74h5SPLovdF6
Only Mymastercoins column has value on the consensus, but when I checked at the website masterchest and master-explorer have values also for this address.
Yeah see above that was a bug - if it helps I noticed you have some whitespace in your output (eg {"address": "1rdyat8oxM33EUHBaGPvEUBiBgAvXHe5M ", "balance": "0.003"}) and a couple of format issues (eg {"address": "139Dx25QXHBJD1tfLQMwASAAJrWFiM4BPz", "balance": "1E-08"}). Thanks guys EDIT: Looks like the link I was using for Grazcoin's implementation was wrong, corrected.
|
|
|
|
grazcoin
|
|
December 15, 2013, 12:01:59 PM |
|
That's great! Now it is easy to see the mistakes I was just working on wallet side, so the correct parsing got neglected ...
|
|
|
|
Bitoy
|
|
December 15, 2013, 12:47:36 PM |
|
Those addresses where only Mymastercoins had values were a bug (just squashed) - I query all implementations for their list of addresses, it just so happens that Bitoy's is first on the list. There is whitespace in his JSON output so it was throwing off my address matching. A couple of handy trim functions and it's working again. Re filter, I haven't built in parameters into that page for filters (though I do intend to), in the mean time will this do? https://masterchest.info/consensus_tachikoma.aspxThe link above makes checking much easier. Sorry for the spaces. Will update the script and also the numbers.
|
|
|
|
|
|
Tachikoma
|
|
December 15, 2013, 02:57:39 PM |
|
I see no problem in accepting multiple change addresses as long as the data packets all use the same value for the output. I need to see how much of that is actually in the spec and how much was discussed in the forums. But I think multiple chance is fine now as long as the output amount is different from the Exodus reference output.
|
|
|
|
aTriz
|
|
December 15, 2013, 03:23:37 PM |
|
Bitoy, The new package worked great now showing no duplicate transactions
|
|
|
|
Bitoy
|
|
December 15, 2013, 04:44:07 PM |
|
Bitoy, The new package worked great now showing no duplicate transactions Ok that's good Hope more people test it.
|
|
|
|
aTriz
|
|
December 15, 2013, 05:12:18 PM |
|
Quick couple of notes for people testing out the windows wallet, I found that it was fairly easy to get setup but here are some tips just in-case you have any issues. -Make sure you follow the steps that Bitoy has already layed out @ http://www.mymastercoins.com/MyMSCWallet.aspx-Make sure you have none of you're files in your MyMastercoins_1_0_0_1 folder set to read only! (You can do this by Right Click: Properties and make sure the box is un-checked) (Additionally make sure you have Full Control as an Administrator, you can do this as well by Right Click: Properties: Security make sure you have "Full Control") I must say Bitoy did a wonderful job with this and along side the other few dev's in here you are all doing great things for the future of MSC.
|
|
|
|
zathras
|
|
December 15, 2013, 08:05:51 PM |
|
I see no problem in accepting multiple change addresses as long as the data packets all use the same value for the output. I need to see how much of that is actually in the spec and how much was discussed in the forums. But I think multiple chance is fine now as long as the output amount is different from the Exodus reference output.
Yep, I tried to break multiple change outputs in Class A but couldn't, so agreed with the other devs that we can allow it. I'm putting a pull in today once I get past a bunch of back-to-back meetings Grazcoin, this was just for Class A. Class B still requires change to be sent back to the sender & there is no need for allowing multiple change outputs. Consensus checker is 100% completely awesome! We so needed that. I can 'see' things 100 times faster now. Thank you. Now, here appears to be a weird problem: The consensus checker shows: 1LsSF18x1o8hpgbArgoWy9fd65jniNMCfj 73 [blank] 73.0 73.00 However, Masterchest shows: Total: 0.00000https://masterchest.info/lookupadd.aspx?address=1LsSF18x1o8hpgbArgoWq9fd65jniNMCfjThat is, the consensus checker doesn't agree with the results I see directly on Masterchest. Thanks for helping to track all this stuff down. I am sure we will reach perfection - very soon. Please note the two addresses you've noted don't match - 1LsSF18x1o8hpgbArgoW y9fd65jniNMCfj & 1LsSF18x1o8hpgbArgoW q9fd65jniNMCfj. If I look up https://masterchest.info/lookupadd.aspx?address=1LsSF18x1o8hpgbArgoWy9fd65jniNMCfj (the correct address) I see 73.0 MSC. Thanks all P.S. bug noted with my temp tables where data may be provided during building the state. If unexpected data received F5 refresh will correct - I will correct as soon as I can grab some coding time.
|
|
|
|
prophetx
Legendary
Offline
Activity: 1666
Merit: 1010
he who has the gold makes the rules
|
|
December 15, 2013, 09:10:34 PM |
|
|
|
|
|
zathras
|
|
December 15, 2013, 11:34:55 PM |
|
Latest update introduced a bug in test MSC simple sends. Fixed.
|
|
|
|
grazcoin
|
|
December 15, 2013, 11:39:49 PM |
|
I see no problem in accepting multiple change addresses as long as the data packets all use the same value for the output. I need to see how much of that is actually in the spec and how much was discussed in the forums. But I think multiple chance is fine now as long as the output amount is different from the Exodus reference output.
Yep, I tried to break multiple change outputs in Class A but couldn't, so agreed with the other devs that we can allow it. I'm putting a pull in today once I get past a bunch of back-to-back meetings Grazcoin, this was just for Class A. Class B still requires change to be sent back to the sender & there is no need for allowing multiple change outputs. If we allow multiple change in one format (Class A), we should allow multiple change in others as well (Class B). Otherwise, it may be confusing. Like Tachikoma said - I see no problem in accepting multiple change addresses as long as the data packets all use the same value for the output. This holds for Class A and Class B. I already mentioned before possible uses for multiple change (e.g. tx with multiple markers), so I am pro general multiple change. Do we wait for such a tx to to force us to get to a consensus or can we agree beforehand
|
|
|
|
grazcoin
|
|
December 15, 2013, 11:41:58 PM |
|
What about this problem? Is there any decision about arbitrary sequence numbers?
|
|
|
|
zathras
|
|
December 16, 2013, 01:10:01 AM |
|
I see no problem in accepting multiple change addresses as long as the data packets all use the same value for the output. I need to see how much of that is actually in the spec and how much was discussed in the forums. But I think multiple chance is fine now as long as the output amount is different from the Exodus reference output.
Yep, I tried to break multiple change outputs in Class A but couldn't, so agreed with the other devs that we can allow it. I'm putting a pull in today once I get past a bunch of back-to-back meetings Grazcoin, this was just for Class A. Class B still requires change to be sent back to the sender & there is no need for allowing multiple change outputs. If we allow multiple change in one format (Class A), we should allow multiple change in others as well (Class B). Otherwise, it may be confusing. Like Tachikoma said - I see no problem in accepting multiple change addresses as long as the data packets all use the same value for the output. This holds for Class A and Class B. I already mentioned before possible uses for multiple change (e.g. tx with multiple markers), so I am pro general multiple change. Do we wait for such a tx to to force us to get to a consensus or can we agree beforehand Class B enforces a rule that requires change to be returned to sender - the rule is in place because there are no sequence numbers to identify a recipient address in a Class B transaction. Class A does not enforce such a rule so multiple change outputs weren't too much of a change. If we wanted to support multiple change outputs in Class B said rule needs to be deprecated first. What about this problem? Is there any decision about arbitrary sequence numbers? My implementation takes a literal view - the wording of the spec states that in the event of packet ambiguity using sequence numbers or output amounts, then peek & decode can be used. Thus I see this transaction as valid via Peek & Decode. Looking at the consensus check it seems MyMastercoins & Mastercoin-Explorer also consider this valid. Thanks
|
|
|
|
Tachikoma
|
|
December 16, 2013, 09:46:08 AM |
|
I rather have multiple output only be supported for Class A for now since like Zathras said there are no sequence numbers for multisigs. Once we enforce change to multisig when wallets are more feature-rich the problem should go away anyway.
I went through all addresses where I was the odd-one out and fixed most of them except two where I think I actually did it right. It comes down to two missing transactions. They are:
ecb77ee990de29745de949462e1f6e44584c310a0da12c9fbdf86dbe6ffabcfc Missing on: Masterchain and Masterchest
and
a497e4fd11d2223e2129828e44b0d2110b2bb0ec3cb8a0f36bbd28f37a15ceef Missing on: Masterchain and MyMastercoins
Could you look at these and tell me why your implementations don't have these transactions?
|
|
|
|
|