MasterCoin: New Protocol Layer Starting From “The Exodus Address”

[StarenseN]

Hi all,

I just wanted to update you guys with the summary of the first board meeting of the Mastercoin Foundation.

Cheers,
Ron

Awesome, love the insight. Agenda and the decisions don't match up though, kinda hard to match them right now.

The Agenda is a partial list of the stuff we brought into the discussion (not everybody prepared it on the doc, and some things arose mid-discussion).

I'll help with the matching:

Agenda:
1. We decided that the meetings are public.
2. We haven't decided on that, waiting to hear a marketing plan from Social Circle.
3. No actions items here, I just updated updated the board about our blog. We do also plan to review our Twitter & Facebook channels (David opened these a while back), I hope in the next few days.
4.  Regarding Roadmap - Willett is currently managing the project, and doing a great job at it. I suggested we pour some content to our Trello and think about the long term direction, but Willett is just too occupied to do it right now, and I don't believe it's productive to "try and twist his arm about it". We might formulate a roadmap in the future, but right now the focus as I see it is on completing features, not long-term planning.
5. It was decided that bounties are paid in whatever currency the developers/bounty collectors wish.
6. I updated the board briefly about the Nxt alt currency - no action items here.

Hope that helps.
Ron

Thanks for the update. I'm following this closely.

[1713861505]

1713861505

[1713861505]

1713861505

[1713861505]

1713861505

[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/

[dacoinminster]

I've opened up the MSC giveaway thread again. Details here: https://bitcointalk.org/index.php?topic=272577.0

If you want a tiny amount of MSC to play with, go check it out.

[maxmint]

I've opened up the MSC giveaway thread again. Details here: https://bitcointalk.org/index.php?action=post;topic=272577.0

If you want a tiny amount of MSC to play with, go check it out.

It seems you got that link wrong, it has "action=post" in it (or is that on purpose?)
Here the post: https://bitcointalk.org/index.php?topic=272577.0

[vokain]

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/

incredible piece prophetx! and an incredible week to all those involved

[dacoinminster]

I've opened up the MSC giveaway thread again. Details here: https://bitcointalk.org/index.php?action=post;topic=272577.0

If you want a tiny amount of MSC to play with, go check it out.

It seems you got that link wrong, it has "action=post" in it (or is that on purpose?)
Here the post: https://bitcointalk.org/index.php?topic=272577.0

Whoops! Fixed. Thanks.

[dacoinminster]

The MasterCoin Foundation just paid for our silver membership with the Bitcoin Foundation: http://blockchain.info/tx/71557a268cc1e1914a2fa5d64a49e631018689323f3d81004e5017d1a35cdb22

This expenditure was approved by the board in our recent meeting.

[maxmint]

This transaction does not appear on Masterchest:
7aa618833779c5eab099785279f4602c804d4a26382947dbccd23e1bb51e9243

Mastercoin-explorer marks it as valid:
http://mastercoin-explorer.com/transactions/7aa618833779c5eab099785279f4602c804d4a26382947dbccd23e1bb51e9243

Is there something wrong with the transaction? Or is Masterchest delayed?

[abuelau]

I have a probably stupid question and it has probably been answered before but I don't feel like digging 75 pages of this thread, so can someone please help me:

I bought 1 mastercoin last week and sent it to a bitcoin address that already had some BTC.

This is the TX: http://mastercoin-explorer.com/addresses/13gWMV4iiydqRbX1ac6wFqQhK3D58QJihd

So what happens now if I spent all the BTC in that address? Am I also going to be spending my mastercoin? Or can I spend all bitcoins and then load 0.00006 again whenever I want to send mastercoins somewhere else?

I'm confused! 

[zathras]

This transaction does not appear on Masterchest:
7aa618833779c5eab099785279f4602c804d4a26382947dbccd23e1bb51e9243

Mastercoin-explorer marks it as valid:
http://mastercoin-explorer.com/transactions/7aa618833779c5eab099785279f4602c804d4a26382947dbccd23e1bb51e9243

Is there something wrong with the transaction? Or is Masterchest delayed?

Not a delay, masterchest has thrown this transaction out the same as the other one due to sequence numbers forming a perfect sequence:

15NoSD4F1ULYHGW3TK6nBN9ZC1RjkAj3cF has a sequence number of 49
15NoSD4F1ULYHGW3TKBrJy7eJq5nRSLfaH has a sequence number of 48
15HnZysUgaEGG4oz4eEmTozi3m4kxhZu15 has a sequence number of 47

The transaction is still valid though (Tachikoma & I spent some time fleshing out the semantics of what is and what isn't a valid transaction) - I'll have a code change up to masterchest.info over the weekend that will again allow perfect sequence numbers if the change address can be identified by the output amounts (this is how it originally was before output amounts started differing with multisig).

I have an amendment currently being finalized and once all the other guys (Tachikoma, Grazcoin, Bitoy etc) are happy with it we'll ask JR to accept it which should help to really lock in these transaction processing rules.

Thanks!

[zathras]

I have a probably stupid question and it has probably been answered before but I don't feel like digging 75 pages of this thread, so can someone please help me:

I bought 1 mastercoin last week and sent it to a bitcoin address that already had some BTC.

This is the TX: http://mastercoin-explorer.com/addresses/13gWMV4iiydqRbX1ac6wFqQhK3D58QJihd

So what happens now if I spent all the BTC in that address? Am I also going to be spending my mastercoin? Or can I spend all bitcoins and then load 0.00006 again whenever I want to send mastercoins somewhere else?

I'm confused!  

You can safely send BTC from your Mastercoin address, that's not a problem.  You just need to ensure you have sufficient funds to cover the fees at said address at the time you wish to send Mastercoins from it.

[ASICSRUS]

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/

Communications Officer?   ~ looking good!

[maxmint]

This transaction does not appear on Masterchest:
7aa618833779c5eab099785279f4602c804d4a26382947dbccd23e1bb51e9243

Mastercoin-explorer marks it as valid:
http://mastercoin-explorer.com/transactions/7aa618833779c5eab099785279f4602c804d4a26382947dbccd23e1bb51e9243

Is there something wrong with the transaction? Or is Masterchest delayed?

Not a delay, masterchest has thrown this transaction out the same as the other one due to sequence numbers forming a perfect sequence:

15NoSD4F1ULYHGW3TK6nBN9ZC1RjkAj3cF has a sequence number of 49
15NoSD4F1ULYHGW3TKBrJy7eJq5nRSLfaH has a sequence number of 48
15HnZysUgaEGG4oz4eEmTozi3m4kxhZu15 has a sequence number of 47

The transaction is still valid though (Tachikoma & I spent some time fleshing out the semantics of what is and what isn't a valid transaction) - I'll have a code change up to masterchest.info over the weekend that will again allow perfect sequence numbers if the change address can be identified by the output amounts (this is how it originally was before output amounts started differing with multisig).

I have an amendment currently being finalized and once all the other guys (Tachikoma, Grazcoin, Bitoy etc) are happy with it we'll ask JR to accept it which should help to really lock in these transaction processing rules.

Thanks!

I see, thanks for the detailed explanation! Looking forward to your code change implementation.

[jiefangqian]

我发起了一个微博投票【mastercoin中文名投票】，地址 http://t.cn/zRigfVb

[maxmint]

我发起了一个微博投票【mastercoin中文名投票】，地址 http://t.cn/zRigfVb

Pseudo translation:

I launched a Mastercoin poll.

Translated link: http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fvote.weibo.com%2Fvid%3D2481174&act=url

[jiefangqian]

Thanks,very much!

[prophetx]

could one of you guys comment on what this means for MSC? in layman's terms. i would like to add it to the newsletter for this week as it seems relevant and validates the MSC concept.

just 2 or 3 sentences would be sufficient.

https://bitcoinfoundation.org/blog/?p=290

thanks in advance

So, with some reluctance, I recently merged pull request #2738 : “Relay OP_RETURN data TxOut as standard transaction type.”

The idea is to give people a way to do what they clearly want to do (associate extra data with a transaction that is secured by the blockchain), but do it in a responsible way that strikes a balance between “you can put whatever you want into the blockchain” and “you will have to be tricky and inefficient to get your data in the blockchain.”

Pull request #2738 lets developers associate up to 80 bytes of arbitrary data with their transactions by adding an extra “immediately prune-able” zero-valued output.

Why 80 bytes? Because we imagine that most uses will be to hash some larger data (perhaps a contract of some sort) and then embed the hash plus maybe a little bit of metadata into the output. But it is not large enough to do something silly like embed images or tweets.

Why allow any bytes at all? Because we can’t stop people from adding one or more ordinary-looking-but-unspendable outputs to their transactions to embed arbitrary data in the blockchain.

What do I mean by “immediately prune-able?”  The form of the up-to-80-byte transaction output (“OP_RETURN <data>”) is such that it can never be used as an input for another transaction– so it can theoretically be forgotten by everybody except for machines that want to keep a full record of every single transaction (“archive nodes”). That is a big improvement over the various hacks people are using today to associate data with their transactions, and will be more important in the future when we implement code that saves disk space by keeping only unspent transaction outputs and not every old block.

The core code has no easy way of creating these new transaction outputs– you have to create them yourself using the raw transactions API. And there are no plans to display the data in Bitcoin-Qt, so you don’t have to worry about somebody sending you a few millibits and attaching a short-but-annoying message to the transaction.

[Tachikoma]

Basically it gives us an other way to encode Mastercoin data into the blockchain.

J.R.'s original approach was hiding the data in an Bitcoin address. The big downside to this method is that these addresses can never be spend since no private key exists. When using this method you are basically polluting the blockchain with data that can never be removed. (We call these transactions Class A)

The next solution we came up with was using multi-sig transactions. By supplying an public key that can be used when you want to spend the output we can now make sure every output we create is spendable. This stops the pollution problem. (We call these transactions Class B)

What I understand from OP_RETURN is that you can basically add 80bytes of arbitrary data to each transaction. This would give us a perfect way to encode our data in the most harmless way since these outputs are 'Provably Prune-able' and can safely be ignored when parsing the blockchain. (These transactions will most likely be Class C transactions)

I hope this explains it. If anybody spots an error let me know.

[StarenseN]

Basically it gives us an other way to encode Mastercoin data into the blockchain.

J.R.'s original approach was hiding the data in an Bitcoin address. The big downside to this method is that these addresses can never be spend since no private key exists. When using this method you are basically polluting the blockchain with data that can never be removed. (We call these transactions Class A)

The next solution we came up with was using multi-sig transactions. By supplying an public key that can be used when you want to spend the output we can now make sure every output we create is spendable. This stops the pollution problem. (We call these transactions Class B)

What I understand from OP_RETURN is that you can basically add 80bytes of arbitrary data to each transaction. This would give us a perfect way to encode our data in the most harmless way since these outputs are 'Provably Prune-able' and can safely be ignored when parsing the blockchain. (These transactions will most likely be Class C transactions)

I hope this explains it. If anybody spots an error let me know.

Thanks for these explanations (finally I understand something here )

Does it affects the transactions already been done (compatibility) ? Will we need a new way/tool to create MSC transactions ?

[Tachikoma]

Only Class A transactions can be created with a normal Bitcoin client for now. Class B/C will require new applications to support them.