Quote from: zathras on October 24, 2013, 11:17:31 PM

Quote from: Tachikoma on October 24, 2013, 07:31:14 PM

Quote from: dacoinminster on October 24, 2013, 07:26:23 PM

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.

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

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!

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.