Hey Tachikoma,

Regarding our discussions over the last couple of days about making the output amounts the same a solid requirement (ie not just a convenience) in Class A transactions...



Would you mind double checking my sanity checks on this?  There is a single fail; a transaction with 4 outputs all the same.  We both already consider that transaction valid by the other rules (eg sequence numbers) so that's a non-issue.

My conclusion is that we can require all the outputs except change to be the same in a Class A transaction without affecting any transactions already done, which is good news


Raw data here https://masterchest.info/files/sameoutputs_duedill.txt

Also of interest may be that almost 40% of simple sends done to date didn't have a change output (that surprised the hell out of me to be honest!)

Tachikoma:

It seems that in 2 of the multisig tx I have sent (this time with obfuscation using the sender address), you mis-parse the receiving address:
http://mastercoin-explorer.com/transactions/a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95
http://mastercoin-explorer.com/transactions/2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bc

My parsing looks this way:
http://masterchain.info/Transaction.html?tx=a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95&currency=MSC
http://masterchain.info/Transaction.html?tx=2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bc&currency=MSC

Can you please check your parsing?

Just a note:
On the first one the public key for the change address in the BIP11 is uncompressed.
On the second one the public key for the change address in the BIP11 is compressed.

I would give a simpler instruction for tx constructing:
Make sure that the address in the BIP11 is the same as the sender's address.
This means that you should use the same format of public key as used at the sender.

It looks like I accidentally deleted or overwrote my post about OP return. Here's what I think I wrote:

Gavin has had us on his mind lately - at the top of his recent blog post about 0.9 bitcoin software, he talks about explicitly supporting projects like ours with OP_RETURN: https://bitcoinfoundation.org/blog/?p=290

It's looking like we'll have a "class C" transaction type soon. OP_RETURN works very well for our current model of sending transactions from a PC and viewing balances on websites which have the entire transaction history.

Once 0.9 is out and miners are widely supporting OP_RETURN, I think we should start using it.

Your tx appears also on http://masterchain.info/index.html?currency=TMSC
The transaction is:
http://masterchain.info/Transaction.html?tx=7a02df33eddfb9dbcc7988f980630297089454f13a8bd059ada4b7842e2d1615&currency=TMSC
or in json:
http://masterchain.info/tx/7a02df33eddfb9dbcc7988f980630297089454f13a8bd059ada4b7842e2d1615.json

(Will check if the capital letter affect sha256)

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

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!

Hi,
Yesterday I made a transaction of 16.5 MSC.

The transaction shows that the mastercoin explorer : http://mastercoin-explorer.com/transactions/9e44d015f0aec437e0ad4e5c4d3dd474918f6dac01fe64edf339d71c09c0d398
But it doesnt show on the mastercoin chest : https://masterchest.info/lookupadd.aspx?address=19b5BiXWZERFoCNhVKiYDf9i829P1W1wiE

What could be the problem? I have been waiting for a day but it still not changed.


Thanks-
Jeroen

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?

d42c390e52f1110412078a9db148e7a306924666fb10aaaa9bffcc2e2ecde344
370ee8c285babbf857761796c0ab5c652db7da17fdd2fea8657809ca8428bd2f
e3ab016c159270d4649ab732d41c7895ad3e05f5b94d611f7a5e19780c6502d2
...etc...

sequence1 = Digest::SHA256.hexdigest("1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B")
sequence2 = Digest::SHA256.hexdigest(sequence1)
sequence3 = Digest::SHA256.hexdigest(sequence2)
..etc..

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.

Sorry guys have to be quick - back to back meetings today.

Long story short according to the current rules that transaction is not valid due to ambiguous sequence numbers, this is why masterchest.info throws the transaction out.

19b5BiXWZERFoCNhVKiYDf9i829P1W1wiE has a sequence number of 94
19UjqqjXmQxyyn4xStA7mWXVkzXwVDgu7Z has a sequence number of 93
19feAR37pguLwDyEMc8oiW2WT4esrgR5z6 has a sequence number of 95


You have a perfect sequence (93, 94, 95) so there is no clear way to identify recipient vs change.  

Tachikoma, we (or just I?) removed the requirement for the outputs to be the same and only used sequence numbers for address identification instead.  This was discussed a while back when you were designing your original multisig and had to use a different amount for the multisig output due to the higher dust threshold with a bigger size of the output (multisig).  I raised the issue of outputs amounts no longer being the same as required by the spec and suggested an amendment that multisig output amounts were specified as exodus output amount*2, but that never got included as it was stated that outputs actually did not need to be the same, it was just a convenience:


So I removed the requirement for outputs to be the same amount to allow for multisig outputs no longer meeting said requirement.  So as it stands now I no longer evaluate what the value is of each vout, only the sequence numbers matter.

I think we need some further discussion on backwards compatibility for these Class A transactions.  Perhaps we need to re-introduce the 'same output amount' rule as a requirement just for Class A transactions as we can then use the amounts to help identify change as per the original spec - at the moment there seems to be some ambiguity around Class A transaction validity between our implementations and we need to clear this up.  You can probably understand now why I'm putting so much effort into having these rules explicitly defined and documented  I do concur that random chance of sequence number collisions should not be a factor in transaction validity.

None of this is an issue in multisig as we require change to be from the sender as a method of removing address ambiguity.