Zathras, thanks for the filtered version btw. That's exactly what I needed 
This is going to go a long way to getting this thing perfect - fast.
Bonus to Zathras
Topic: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) - page 29. (Read 129207 times)
December 16, 2013, 10:49:00 AM
This is going to go a long way to getting this thing perfect - fast.
Bonus to Zathras
December 16, 2013, 07:46:55 AM
Guys I'm documenting these edge-cases mostly for my own use on Pivotal tracker. Forum posts get lost fast but action should be taken on these transactions.
I use it the following way:
The story name is the transaction id, the labels are the implementations that are affected and the description describes how the transactions should or shouldn't be parsed. If you want to use this system as well please let me know your account name and I will add you.
Zathras, thanks for the filtered version btw. That's exactly what I needed
I use it the following way:
The story name is the transaction id, the labels are the implementations that are affected and the description describes how the transactions should or shouldn't be parsed. If you want to use this system as well please let me know your account name and I will add you.
Zathras, thanks for the filtered version btw. That's exactly what I needed
December 16, 2013, 07:41:37 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?
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?
I'll have to look a bit further into that one (ecb77ee990de29745de949462e1f6e44584c310a0da12c9fbdf86dbe6ffabcfc) - it's detected as a simple send but fails decoding. To be continued...
EDIT: Are you falling back to peek & decode on this one? I make the data address 15efTnSCG13druGmetEp1AULCEqudtCSwq and the reference address 15a4XCuWmx2cCQVf8wZK7mqdvj5uwo1vby. The data address has sequence number 51 while the reference address has sequence number 50. It should be the other way around. This should have fallen to peek & decode, but I have a feeling since the sequence numbers don't look ambiguous, my implementation is taking seqnum 50 (the ref address) and trying to decode it probably resulting in a trapped exception.
Need to set this up as a dummy transaction to watch the decoding in action - I'll try and get some more time to look at this tomorrow.
Thanks
Yeah I'm falling back on p&d on this one.
Quote
D, [2013-12-16T13:41:18.347691 #3558] DEBUG -- : Found data for address 15efTnSCG13druGmetEp1AULCEqudtCSwq
D, [2013-12-16T13:41:18.348294 #3558] DEBUG -- : Looking for data sequence 51 +1 == 52
D, [2013-12-16T13:41:18.349347 #3558] DEBUG -- : Sequence: 148 for 1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P
D, [2013-12-16T13:41:18.349637 #3558] DEBUG -- : Sequence: 50 for 15a4XCuWmx2cCQVf8wZK7mqdvj5uwo1vby
D, [2013-12-16T13:41:18.349896 #3558] DEBUG -- : Sequence: 51 for 15efTnSCG13druGmetEp1AULCEqudtCSwq
D, [2013-12-16T13:41:18.349940 #3558] DEBUG -- : Target address not found attempting peek & decode.
SimpleSend transaction from 1Q1sFqsi8S5DxV5hz6sWLamGBp9To93iG7 for 5.00000000 Mastercoin to 15a4XCuWmx2cCQVf8wZK7mqdvj5uwo1vby.
D, [2013-12-16T13:41:18.348294 #3558] DEBUG -- : Looking for data sequence 51 +1 == 52
D, [2013-12-16T13:41:18.349347 #3558] DEBUG -- : Sequence: 148 for 1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P
D, [2013-12-16T13:41:18.349637 #3558] DEBUG -- : Sequence: 50 for 15a4XCuWmx2cCQVf8wZK7mqdvj5uwo1vby
D, [2013-12-16T13:41:18.349896 #3558] DEBUG -- : Sequence: 51 for 15efTnSCG13druGmetEp1AULCEqudtCSwq
D, [2013-12-16T13:41:18.349940 #3558] DEBUG -- : Target address not found attempting peek & decode.
SimpleSend transaction from 1Q1sFqsi8S5DxV5hz6sWLamGBp9To93iG7 for 5.00000000 Mastercoin to 15a4XCuWmx2cCQVf8wZK7mqdvj5uwo1vby.
December 16, 2013, 07:30:22 AM
a497e4fd11d2223e2129828e44b0d2110b2bb0ec3cb8a0f36bbd28f37a15ceef
Missing on: Masterchain and MyMastercoins
In mymastercoins I'm parsing this as a purchase offer. Since msc purchase offers are not yet allowed the transaction is marked as invalid.
Invalid Transaction.
Date: 11/30/2013 5:35:43 PM
Remarks: Purchase Offer not found.
.
This transaction affects These 2 address
MM=0.00006283 1Mt1tCGyJnD6SHzBgxtg6GRJLUhqQrc4ff MC=5.00006283
MM=10.55548942 15XJoDF4xCUrWX3ES9ftWq3wnGhuRsqrLk MC=5.55548942
Once it is resolved, mymastercoins and mastercoinexplorerer is synched
masterchain interpretation is a bitcoin payment:
https://masterchain.info/btcpayment.html?tx=a497e4fd11d2223e2129828e44b0d2110b2bb0ec3cb8a0f36bbd28f37a15ceef¤cy=MSC
The reason is that the values are different:
0.00006 to 1EXoDusjGw...
0.00006 to 1Mt1tCGyJn...
0.0006 to 1MnZ4jmQ3E..
0.00668292 to 17oDj9dvFL...
I thought all values except for the change have to be the same, or else the tx is invalid for mastercoin protocol.
Yes, you are correct. I will fix this in my implementation. Thanks
December 16, 2013, 06:15:36 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.
OK. I will sync with that rule. It would be good to add it to the spec.
I start with the first consensus conflict on zathras's list, which is the address 12BjxEGAGcLnpXVbJHp4L5FNKh1YNweRn7.
I was digging, and I found the root cause to be the parsing of the following tx:
https://masterchest.info/lookuptx.aspx?txid=725210a6bfea06e4aa9a582602d758db920eff9c720aca380d6e77c08a4108ac
http://mastercoin-explorer.com/transactions/725210a6bfea06e4aa9a582602d758db920eff9c720aca380d6e77c08a4108ac
The sequence numbers in that tx are:
[84, 205, 233]
As far as I understood, we do the peek_and_decode only in the ambiguous sequence and perfect sequence cases, and this case is non of them.
Was there another decision regarding peek_and_decode?
I was digging, and I found the root cause to be the parsing of the following tx:
https://masterchest.info/lookuptx.aspx?txid=725210a6bfea06e4aa9a582602d758db920eff9c720aca380d6e77c08a4108ac
http://mastercoin-explorer.com/transactions/725210a6bfea06e4aa9a582602d758db920eff9c720aca380d6e77c08a4108ac
The sequence numbers in that tx are:
[84, 205, 233]
As far as I understood, we do the peek_and_decode only in the ambiguous sequence and perfect sequence cases, and this case is non of them.
Was there another decision regarding peek_and_decode?
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
My interpretation is that "packet ambiguity" is one of the options described originally in:
https://bitcointalksearch.org/topic/m.3190175
and with example like [84, 205, 233] it is clear that the tx is invalid. This tx contradicts the original sequence number rules - not like in the peek_and_decode case for original ambiguity case, where a plausible explanation that fits the original rules is found.
If we want to simply say that every sequence can be valid (with the help of peek_and_decode) - it should be stated in the spec.
December 16, 2013, 06:04:05 AM
a497e4fd11d2223e2129828e44b0d2110b2bb0ec3cb8a0f36bbd28f37a15ceef
Missing on: Masterchain and MyMastercoins
In mymastercoins I'm parsing this as a purchase offer. Since msc purchase offers are not yet allowed the transaction is marked as invalid.
Invalid Transaction.
Date: 11/30/2013 5:35:43 PM
Remarks: Purchase Offer not found.
.
This transaction affects These 2 address
MM=0.00006283 1Mt1tCGyJnD6SHzBgxtg6GRJLUhqQrc4ff MC=5.00006283
MM=10.55548942 15XJoDF4xCUrWX3ES9ftWq3wnGhuRsqrLk MC=5.55548942
Once it is resolved, mymastercoins and mastercoinexplorerer is synched
masterchain interpretation is a bitcoin payment:
https://masterchain.info/btcpayment.html?tx=a497e4fd11d2223e2129828e44b0d2110b2bb0ec3cb8a0f36bbd28f37a15ceef¤cy=MSC
The reason is that the values are different:
0.00006 to 1EXoDusjGw...
0.00006 to 1Mt1tCGyJn...
0.0006 to 1MnZ4jmQ3E..
0.00668292 to 17oDj9dvFL...
I thought all values except for the change have to be the same, or else the tx is invalid for mastercoin protocol.
December 16, 2013, 05:33:46 AM
I think I might be to blame here, it seems I might have a regression where Purchase Offers fall back to Simple Sends on failure. Will have to check that out.
Thanks!
Thanks!
December 16, 2013, 05:29:59 AM
a497e4fd11d2223e2129828e44b0d2110b2bb0ec3cb8a0f36bbd28f37a15ceef
Missing on: Masterchain and MyMastercoins
In mymastercoins I'm parsing this as a purchase offer. Since msc purchase offers are not yet allowed the transaction is marked as invalid.
Invalid Transaction.
Date: 11/30/2013 5:35:43 PM
Remarks: Purchase Offer not found.
.
This transaction affects These 2 address
MM=0.00006283 1Mt1tCGyJnD6SHzBgxtg6GRJLUhqQrc4ff MC=5.00006283
MM=10.55548942 15XJoDF4xCUrWX3ES9ftWq3wnGhuRsqrLk MC=5.55548942
Once it is resolved, mymastercoins and mastercoinexplorerer is synched
December 16, 2013, 05:03:40 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?
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?
I'll have to look a bit further into that one (ecb77ee990de29745de949462e1f6e44584c310a0da12c9fbdf86dbe6ffabcfc) - it's detected as a simple send but fails decoding. To be continued...
EDIT: Are you falling back to peek & decode on this one? I make the data address 15efTnSCG13druGmetEp1AULCEqudtCSwq and the reference address 15a4XCuWmx2cCQVf8wZK7mqdvj5uwo1vby. The data address has sequence number 51 while the reference address has sequence number 50. It should be the other way around. This should have fallen to peek & decode, but I have a feeling since the sequence numbers don't look ambiguous, my implementation is taking seqnum 50 (the ref address) and trying to decode it probably resulting in a trapped exception.
Need to set this up as a dummy transaction to watch the decoding in action - I'll try and get some more time to look at this tomorrow.
Thanks
December 16, 2013, 04: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?
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?
December 15, 2013, 08:10:01 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
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.
I start with the first consensus conflict on zathras's list, which is the address 12BjxEGAGcLnpXVbJHp4L5FNKh1YNweRn7.
I was digging, and I found the root cause to be the parsing of the following tx:
https://masterchest.info/lookuptx.aspx?txid=725210a6bfea06e4aa9a582602d758db920eff9c720aca380d6e77c08a4108ac
http://mastercoin-explorer.com/transactions/725210a6bfea06e4aa9a582602d758db920eff9c720aca380d6e77c08a4108ac
The sequence numbers in that tx are:
[84, 205, 233]
As far as I understood, we do the peek_and_decode only in the ambiguous sequence and perfect sequence cases, and this case is non of them.
Was there another decision regarding peek_and_decode?
I was digging, and I found the root cause to be the parsing of the following tx:
https://masterchest.info/lookuptx.aspx?txid=725210a6bfea06e4aa9a582602d758db920eff9c720aca380d6e77c08a4108ac
http://mastercoin-explorer.com/transactions/725210a6bfea06e4aa9a582602d758db920eff9c720aca380d6e77c08a4108ac
The sequence numbers in that tx are:
[84, 205, 233]
As far as I understood, we do the peek_and_decode only in the ambiguous sequence and perfect sequence cases, and this case is non of them.
Was there another decision regarding peek_and_decode?
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
December 15, 2013, 06:41:58 PM
I start with the first consensus conflict on zathras's list, which is the address 12BjxEGAGcLnpXVbJHp4L5FNKh1YNweRn7.
I was digging, and I found the root cause to be the parsing of the following tx:
https://masterchest.info/lookuptx.aspx?txid=725210a6bfea06e4aa9a582602d758db920eff9c720aca380d6e77c08a4108ac
http://mastercoin-explorer.com/transactions/725210a6bfea06e4aa9a582602d758db920eff9c720aca380d6e77c08a4108ac
The sequence numbers in that tx are:
[84, 205, 233]
As far as I understood, we do the peek_and_decode only in the ambiguous sequence and perfect sequence cases, and this case is non of them.
Was there another decision regarding peek_and_decode?
I was digging, and I found the root cause to be the parsing of the following tx:
https://masterchest.info/lookuptx.aspx?txid=725210a6bfea06e4aa9a582602d758db920eff9c720aca380d6e77c08a4108ac
http://mastercoin-explorer.com/transactions/725210a6bfea06e4aa9a582602d758db920eff9c720aca380d6e77c08a4108ac
The sequence numbers in that tx are:
[84, 205, 233]
As far as I understood, we do the peek_and_decode only in the ambiguous sequence and perfect sequence cases, and this case is non of them.
Was there another decision regarding peek_and_decode?
What about this problem?
Is there any decision about arbitrary sequence numbers?
December 15, 2013, 06: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
December 15, 2013, 06:34:55 PM
so one of my addresses received 0.1 test mastercoins in the very beginning of november and only one of the sites is showing it
http://mastercoin-explorer.com/addresses/12xdMh16KkH34YKbzoPZmn5Ai6i3jzfVwX
these two do not show the 0.1 tmsc
https://masterchain.info/Address.html?addr=12xdMh16KkH34YKbzoPZmn5Ai6i3jzfVwX
https://masterchest.info/lookupadd.aspx?address=12xdMh16KkH34YKbzoPZmn5Ai6i3jzfVwX
txid d745c45d25c59869915602ae354dcc780cb9c15a669258dc3bf3b931b0e33305
edit: the 4th site does show it as well http://mymastercoins.com/default.aspx?XID=3450
http://mastercoin-explorer.com/addresses/12xdMh16KkH34YKbzoPZmn5Ai6i3jzfVwX
these two do not show the 0.1 tmsc
https://masterchain.info/Address.html?addr=12xdMh16KkH34YKbzoPZmn5Ai6i3jzfVwX
https://masterchest.info/lookupadd.aspx?address=12xdMh16KkH34YKbzoPZmn5Ai6i3jzfVwX
txid d745c45d25c59869915602ae354dcc780cb9c15a669258dc3bf3b931b0e33305
edit: the 4th site does show it as well http://mymastercoins.com/default.aspx?XID=3450
Latest update introduced a bug in test MSC simple sends. Fixed.
December 15, 2013, 04:10:34 PM
so one of my addresses received 0.1 test mastercoins in the very beginning of november and only one of the sites is showing it
http://mastercoin-explorer.com/addresses/12xdMh16KkH34YKbzoPZmn5Ai6i3jzfVwX
these two do not show the 0.1 tmsc
https://masterchain.info/Address.html?addr=12xdMh16KkH34YKbzoPZmn5Ai6i3jzfVwX
https://masterchest.info/lookupadd.aspx?address=12xdMh16KkH34YKbzoPZmn5Ai6i3jzfVwX
txid d745c45d25c59869915602ae354dcc780cb9c15a669258dc3bf3b931b0e33305
edit: the 4th site does show it as well http://mymastercoins.com/default.aspx?XID=3450
http://mastercoin-explorer.com/addresses/12xdMh16KkH34YKbzoPZmn5Ai6i3jzfVwX
these two do not show the 0.1 tmsc
https://masterchain.info/Address.html?addr=12xdMh16KkH34YKbzoPZmn5Ai6i3jzfVwX
https://masterchest.info/lookupadd.aspx?address=12xdMh16KkH34YKbzoPZmn5Ai6i3jzfVwX
txid d745c45d25c59869915602ae354dcc780cb9c15a669258dc3bf3b931b0e33305
edit: the 4th site does show it as well http://mymastercoins.com/default.aspx?XID=3450
December 15, 2013, 03: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.
Hi all,
Consensus checker is 100% completely awesome! We so needed that. I can 'see' things 100 times faster now. Thank you. - Consensus checker - automatically compares the various implementations for consensus (addresses for now, transactions to come) - https://masterchest.info/consensus.aspx
Now, here appears to be a weird problem:
The consensus checker shows:
1LsSF18x1o8hpgbArgoWy9fd65jniNMCfj 73 [blank] 73.0 73.00
However, Masterchest shows:
Total: 0.00000
https://masterchest.info/lookupadd.aspx?address=1LsSF18x1o8hpgbArgoWq9fd65jniNMCfj
That 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 - 1LsSF18x1o8hpgbArgoWy9fd65jniNMCfj & 1LsSF18x1o8hpgbArgoWq9fd65jniNMCfj.
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.
December 15, 2013, 12: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.
-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.
December 15, 2013, 11:44:07 AM
Bitoy,
The new package worked great now showing no duplicate transactions
The new package worked great now showing no duplicate transactions
Ok that's good
Hope more people test it. December 15, 2013, 10:23:37 AM
Bitoy,
The new package worked great now showing no duplicate transactions
The new package worked great now showing no duplicate transactions
December 15, 2013, 09:57:39 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.
Jump to: