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

[aTriz]

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]

Hi all,

Latest update to masterchest.info is complete.  Rolled a bunch of bugfixes and a couple of features from dev into prod, notables:

• Peek & decode support
• Clean up (invalidate) leftover real MSC DEx transactions
• Multi change output support - alpha
• Verification API - addresses only at this stage (https://masterchest.info/mastercoin_verify/addresses.aspx)
• Consensus checker - automatically compares the various implementations for consensus (addresses for now, transactions to come) - https://masterchest.info/consensus.aspx

Thanks!

[Tachikoma]

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]

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]

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.aspx

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.

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]

• Consensus checker - automatically compares the various implementations for consensus (addresses for now, transactions to come) - https://masterchest.info/consensus.aspx

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]

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.aspx

The link above makes checking much easier.

Sorry for the spaces.  Will update the script and also the numbers.

[grazcoin]

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?

[grazcoin]

I start with the first consensus conflict.

The second consensus conflict on zathras's list is the address 139Dx25QXHBJD1tfLQMwASAAJrWFiM4BPz
This is due to accepting simple send with multiple change addresses.
Did it get already into the spec?
There are 3 such transactions. One of them is:
on blockchain.info:
https://blockchain.info/tx/8175fcd0221ee5cda1808f48861bef5c2d5e8b9acf91a7b0fade5768d35f6665
on masterchest.info:
https://masterchest.info/lookuptx.aspx?txid=8175fcd0221ee5cda1808f48861bef5c2d5e8b9acf91a7b0fade5768d35f6665
on masterchain.info - it is an invalid mastercoin tx, so it is parsed as bitcoin payment:
https://masterchain.info/btcpayment.html?tx=8175fcd0221ee5cda1808f48861bef5c2d5e8b9acf91a7b0fade5768d35f6665

If it does get into the spec - are multiple change addresses allowed also in multisig?

[Tachikoma]

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]

Bitoy,

The new package worked great now showing no duplicate transactions

[Bitoy]

Bitoy,

The new package worked great now showing no duplicate transactions

Ok that's good    Hope more people test it.

[aTriz]

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]

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 - automatically compares the various implementations for consensus (addresses for now, transactions to come) - https://masterchest.info/consensus.aspx

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.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.

[prophetx]

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

[zathras]

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

Latest update introduced a bug in test MSC simple sends.  Fixed.

[grazcoin]

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]

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?

What about this problem?
Is there any decision about arbitrary sequence numbers?

[zathras]

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?

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]

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?