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

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¤cy=MSC
http://masterchain.info/Transaction.html?tx=2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bc¤cy=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.

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!)

Thanks!

Good point. I hadn't noticed that limitation.

I think the most commonly used messages will fit in 80 bytes. The ones that don't (mainly the ones that allow for a bit of ASCII in them) should also be the ones that don't get used very often.

Yep, my vote in for investigating OP_RETURN too.  It'll be another couple of months until OP_RETURN is widely supported by the miners, but once we publish some transactions with OP_RETURN and gain confidence the majority of miners will include them (and thus we don't have long lead periods for block inclusion) then we introduce a Class C as you note.

Looking through Gavin's notes he picked 80 bytes to provide for a 64 byte hash of whatever is being stored (eg SHA512) and some extra metadata.  I don't think we need metadata so we could use the whole 80 bytes for Mastercoin transaction data.

I just wanted to point something out though as I think you guys may have overlooked it (sorry if I'm reading your comments wrong & making a bad assumption); the pull that Gavin merged for OP_RETURN is per transaction not per output.  This means each Class C (OP_RETURN) transaction could only have one 80 byte packet and thus a total transaction space of 80 bytes, where as Class B (multisig) as defined in the amendment provides for a total transaction space of 7,650 bytes.  That's a distinction we need to keep in mind - things like 'simple send' would easily fit into a Class C transaction, but some of the larger functions (eg smart property) may require more than 80 bytes transaction space and thus need to stay with a Class B transaction.

Thanks!

Seconded. I will need to look into OP_RETURN though, the fact that he mentioned 80 bytes though sounds promising.

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.

Awesome, good to know

I've added up an intermediate tool. Updating my wallet software all the time is pretty time intensive so I made something that is easier up-to-dateable until we finalise everything.

You can now create a simple send transaction online and sign and broadcast it via Bitcoin-qt.

To do this do the following:

• Get the public key for your Mastercoin address. You can do this by using the validateaddress function in the Bitcoin-qt console.
• Navigate to this page on mastercoin-explorer. and fill in your details.
• Copy the hex string you get.
• Make sure the transaction is what you would want it to be by using decoderawtransaction from the Bitcoin-qt console. Never trust that the software did everything 100%. The site might have been hacked, or I have become evil. Don't skip this step.
• If you are happy with the result sign it with signrawtransaction followed by sendrawtransaction

You require an unspend output big enough to fund the whole transaction.    

The pre of this method is that you don't have to trust a third party tool/application with your private keys.

I would really appreciate it if somebody could test this functionality, it will be hardcode to test until somebody can verify it works

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

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

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

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

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/

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¤cy=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!

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

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)

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?

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

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

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)