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

[zathras]

I've updated the amendment to include the changes we've discussed.  If viewing in browser you may need to refresh.

Anything we're missing, anything unclear?

Thanks!

Should we perhaps specify the rules what 'peek and decode' means? Other than that it looks good

I've got:

A last resort 'peek and decode' method may be used to identify the data packet in the event of ambiguity following the above rules. This involves decoding each packet and looking for the correct bytes for a simple send (the majority of bytes in a Class A simple send do not change).

Perhaps specify the bytes that we'll want to look for?  Eg first byte must be 01 and so on?

[Tachikoma]

Yeah that was what I meant.

I think currency_id and transaction_type are the most important to check. The change of those two being valid values in a random address are very slim.

[zathras]

hahahahaahaha, duh. Is one way better then the other, or the default?

Don't think it matters as long as we explicitly define which way we're going - for me it's as easy as changing an X to an x in the string format so if there is either that is easier or default for you I'm happy either way

[Tachikoma]

I did some googling and I think using upcase is more dominant. Unless somebody has a reason not to upcase I suggest we use this for now.

[zathras]

I did some googling and I think using upcase is more dominant. Unless somebody has a reason not to upcase I suggest we use this for now.

Great.  Again updated the amendment to add the byte checks & that we run multiple hash passes against an uppercase hex representation of the previous hash.

I've set the byte checks at byte2 to byte8 = 00 & byte9=01 or 02.  Would you say that's sufficient?  The chances on us having to fall back on 'peek & decode' are very slim, and if we do then the chances of then getting a random collission on those bytes with an address that isn't a Mastercoin packet are astronomically low (one in 70,110,209,207,109,376 to be specific). 

[Tachikoma]

In the future new currencies could be created that could be sent using a Class A transaction. So I think in the future the currency id should be one of the created currency ids, for now 01 or 02 should suffice.

[zathras]

In the future new currencies could be created that could be sent using a Class A transaction. So I think in the future the currency id should be one of the created currency ids, for now 01 or 02 should suffice.

I currently have this in the amendment:

NOTE: Class A transactions are restricted to the ‘simple send’ transaction type only. All other Mastercoin transaction types are supported by Class B transactions only. Client implementations should utilize Class B for all transaction types, including ‘simple send’.

I had envisaged us using Class A transactions only for backwards compatibility (for example to allow people to transfer Mastercoins out of certain web wallets) and implementing Class B for everything from now on - thus Class A simple send would only ever need to support currencies 01 & 02.

If we want to allow Class A transactions to be used in future with new currencies I guess we can do so, but personally I'd rather discourage their use (bloat) and simply say simple sends for currencies other than mastercoin (& test mastercoin) must be done via Class B.

[Tachikoma]

Yeah, why not. As long as people understand this limitation.

[Bitoy]

For ECDSA validity (I'll also put a check function into the masterchest library) I took my inspiration from the casascius bitcoin address utility - have a read through some of the pubkey and ECDSA stuff to point you in the right direction.

Thanks!

Thanks zathras.  Will get some ecdsa information there.

[zathras]

Yeah, why not. As long as people understand this limitation.

Yeah that's just my take on it - I envision wallet software encoding & sending Class B for everything, we shouldn't need to support encoding Class A (only decoding).  Nice and simple.

That way Class A transactions are only used for manual sends of Mastercoins (& test) for those that can't sign a user generated raw transaction (web wallets etc)

[grazcoin]

Hi Grazcoin

You are the first to post to the the blockchain using the new multi sig.  Nice work!   ( I was able to parse your transaction  =)   

Data to Parse: 021bf733f7aab3932560cd8e8a3ec11b45ee47f0694a0b61c86ab48e63bba57cd4
OBFUSCATED MASTERCOIN PACKET: 1bf733f7aab3932560cd8e8a3ec11b45ee47f0694a0b61c86ab48e63bba57c
SHA256 HASH: 1af733f7aab3932561cd8e8a3ec1a724a047f0694a0b61c86ab48e63bba57cd0
REFERENCE ADDRESS: 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX
CLEARTEXT MASTERCOIN PACKET: 0100000000000000010000000000bc614e0000000000000000000000000000

01: 1 (01)
Trans Type: 0 (00000000)
Currency ID: 1 (00000001)
Amount for Sale: 12345678 (0000000000bc614e)

Good parsing.
For my parsing, you could check:
https://github.com/grazcoin/mastercoin-tools/blob/master/msc_parse.py

Note: The tx has no "Amount for Sale", but "Amount sent".

[Tachikoma]

Hi Grazcoin

You are the first to post to the the blockchain using the new multi sig.  Nice work!   ( I was able to parse your transaction  =)   

Data to Parse: 021bf733f7aab3932560cd8e8a3ec11b45ee47f0694a0b61c86ab48e63bba57cd4
OBFUSCATED MASTERCOIN PACKET: 1bf733f7aab3932560cd8e8a3ec11b45ee47f0694a0b61c86ab48e63bba57c
SHA256 HASH: 1af733f7aab3932561cd8e8a3ec1a724a047f0694a0b61c86ab48e63bba57cd0
REFERENCE ADDRESS: 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX
CLEARTEXT MASTERCOIN PACKET: 0100000000000000010000000000bc614e0000000000000000000000000000

01: 1 (01)
Trans Type: 0 (00000000)
Currency ID: 1 (00000001)
Amount for Sale: 12345678 (0000000000bc614e)

Good parsing.
For my parsing, you could check:
https://github.com/grazcoin/mastercoin-tools/blob/master/msc_parse.py

Note: The tx has no "Amount for Sale", but "Amount sent".

This transaction is no longer valid if you consider we use the sending address for all transactions now.

[Tachikoma]

I've just updated mastercoin-explorer to support the new key encoding. However it seems that the obfuscation bit is very tricky and even a small difference in interpretation of the spec can cause very different results.

Could somebody please verify this transaction on mastercoin-explorer?

[Bitoy]

With each packet:
   * For sequence number 1 we SHA256 the entire length of the address (which could be anywhere from 27 to 34 bytes), result = 32 byte hash.  
   * For sequence numbers 2 onwards, we take the previous 32 byte hash and SHA256 it again (and again), result = 32 byte hash.  

Code:

SEQNUM=1   {D42C390E52F1110412078A9DB148E7A306924666FB10AAAA9BFFCC2E2ECDE3}44
SEQNUM=2   {000EC2C68806819E67A030E82A6AF98376DAC1065D7FE533DAF251D43AA836}3B
SEQNUM=3   {999722F745CC7EA5559D871285A697513D6D1F69294A472AB71499C280CFDA}72
SEQNUM=4   {23C4AC723733621964260EC4639D9DF3469E983E677B083457F325C6F56FA5}D0
SEQNUM=5   {A2989BBA3E4BF3B2995A8573E19450381C94CDE10F95A157756148217B0E37}1B

hash1 is d42c390e52f1110412078a9db148e7a306924666fb10aaaa9bffcc2e2ecde344

I tried

            Dim sha256 As SHA256 = New SHA256Managed()
            Dim hash2 As Byte() = sha256.ComputeHash(hash1)

hash2 came out as 4266395eef8a3a62fb74ed5ff4d6201573fd51318fce9eaf452eecb3ab9a8ba9

(Will check if the capital letter affect sha256)

[Tachikoma]

(Will check if the capital letter affect sha256)

They do, check out the discussion me and Zathras had today

[dacoinminster]

I think I may have found a bug. I'm working on setting up another giveaway thread (using money left over from the first MSC giveaway thread), and I noticed that there appears to be some disagreement on the balance of the address holding the giveaway funds:

Over 430 MSC are left on MasterChain:
http://masterchain.info/Address.html?addr=15og4WXZPwkMnnsb3dj6HqgTUfcRLx4J9b&currency=MSC

Less than 400 MSC are left on MasterCoin-Explorer and MasterChest
http://mastercoin-explorer.com/addresses/15og4WXZPwkMnnsb3dj6HqgTUfcRLx4J9b
https://masterchest.info/lookupadd.aspx?address=15og4WXZPwkMnnsb3dj6HqgTUfcRLx4J9b

I think that probably some of the transactions aren't being counted by MasterChain for some reason.

Thanks!

[prophetx]

hey Gals and Guys,

I am writing the 2nd weekly newsletter tonight and if you have any suggestions to include anything from the previous week please let me know.

For your reference the blog is here:


http://blog.mastercoin.org/

[Bitoy]

(Will check if the capital letter affect sha256)

They do, check out the discussion me and Zathras had today

We must have a standard for this.  I vote small letters

[dacoinminster]

(Will check if the capital letter affect sha256)

They do, check out the discussion me and Zathras had today

We must have a standard for this.  I vote small letters

Actually, I believe upper-case has been agreed upon:

I did some googling and I think using upcase is more dominant. Unless somebody has a reason not to upcase I suggest we use this for now.

Great.  Again updated the amendment to add the byte checks & that we run multiple hash passes against an uppercase hex representation of the previous hash.

I've set the byte checks at byte2 to byte8 = 00 & byte9=01 or 02.  Would you say that's sufficient?  The chances on us having to fall back on 'peek & decode' are very slim, and if we do then the chances of then getting a random collission on those bytes with an address that isn't a Mastercoin packet are astronomically low (one in 70,110,209,207,109,376 to be specific). 

[superfluouso]

Does anyone have guidance for setting up mastercoin advisor in Mac OS X and/or Ubuntu?