Topic: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) - page 57. (Read 129207 times)

This is why I am not a fan of flagging a transaction invalid based sequence. This guy was just trying to create a transaction and he had no way that random chance could make it invalid.

As long as we can safely identify the data address then a perfect sequence number is not a problem. I say we simply peak into each address and see if it contains a known Mastercoin message. Currently only SimpleSends are supported so we can just peak into an address, decode it and see if the transaction type is 0 and the and currency_id is within limits and if the sequence number makes sense. If we can say with a certain certainty that this is most likely a simple send then we have our data address and know which sequence the target address should be. This will work for a broken sequence as well. The only problem is the ambiguous sequence. In this case there is simply no way of finding out the correct address and the transaction should be made invalid. Since the random factor can't be solved here we might need to solve it differently and go back a step.

How about we do the following.

• Only allow Simple Sends to be encoded as addresses. All new messages should use pulic keys.
• All outputs that contain Mastercoin data for Class A transaction should have the same output amount, but it doesn't matter how much this amount is.
• Probe each address to see if it's a Mastercoin encoded address using the checks outlined above.

Checks to see if it's a Mastercoin encoded address

• Transaction type is 0
• Currency ID is an existing Currency ID, for now only 1 and 2 are created but this might chance in the future

If we follow these rules then there should always be three outputs. One you can rule out based on the fact that it's Exodus. One of those is the data package and one the target address. In most cases you can probably know which is which even without the sequence number.

I will make some time today to see if this change would affect any existing transactions but I highly doubt it. 

Wasn't quite sure what you meant by this so I thought I'd just note that there is no need to drop or add bytes to/from the inputs of our SHA256 hashing if that's what you mean?  SHA256 hashing will always produce a 256 bit (32 byte) hash regardless of input length.  To clarify my take on things:

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.  
   * We then take the resulting 32 byte hash, grab the first 31 bytes and XOR with the cleartext Mastercoin packet.
Rinse & repeat.

Perhaps that's what you meant, sorry if I'm getting confused or repeating stuff - there's been so much thought & discussion on this stuff it's all kind of a blur!

So for your address of 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B, the first 5 packets should have hashes of (in between { } is what you would XOR with):


Thoughts?

Agreed.  Though I actually think we should make it the sender address for everything because as you note, not all transactions will have a reference address.  We may as well stick with an address we know will always be there.  Unless you guys know of a reason for not using the sender address let's lock that in as our initial source for the SHA256 hashing & I'll update the amendment accordingly.

EDIT: for clarity

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)