I would personally work a bit more on the implementation and protocol before focusing-in on the marketing message. I feel like we are still selling an idea without much practical implementation yet.

The biggest problem is still that Mastercoin data is encoded in a very parasitic way. I personally would not want Mastercoin to take off before this major problem is solved. This also means that I think we should be open to the idea that Mastercoin might have different rules on how to parse the blockchain data based on the block it's parsing. This means Mastercoin can adapt to changes in the Bitcoin protocol or when it needs to make internal changes.

I would personally work a bit more on the implementation and protocol before focusing-in on the marketing message. I feel like we are still selling an idea without much practical implementation yet.

I was thinking the same. I would prefer to have a solid protocol and client before making any marketing efforts. I guess there will be some pitfalls along the way which might be quite hard to overcome.

I'm in complete agreement here. I see most of the marketing goals as being fairly far in the future (although putting together a basic website would be nice). I do want to express appreciation to Ola for the work he put into this. We'll get there someday

I definitely want to improve the impact we are having on the block chain (by finding alternate ways to store the MasterCoin data). The coding contest will definitely have some funds for someone who does that well.

I agree that there is absolutely no point to marketing unless Mastercoin is worth marketing for. But certain things like logos and explainer videos can be helpful as long as they are targeting the right people. Specifically- developers who can build great things around this project. Plus, they can be worked on simultaneously by those who aren't developers (designers, etc.) So I would say at this point, some marketing can be helpful and won't be taking away from the main goal.

I'm a graphic designer, so my MO is to jump in when I think I'll be helpful, and then get out of the way asap.

I think, the biggest issue with marketing is making sure

1. It doesn't get ahead of itself. It should be appropriate for whatever stage Mastercoin is at. It needs to take the backseat.

and

2. It's factual- There is good communication between the developers and anyone who wants to 'spread the word' so there are less headaches.

15XJoDF4xCUrWX3ES9ftWq3wnGhuRsqrLk (which had the largest total input) should be the owner of those MasterCoins rather than 1G6F8aMJNp3zMG9L1DxDT3WjiUntJYwYka (which had the largest single input). MasterCoin-Explorer incorrectly credits the latter address with the purchase. I realize I need to be more clear in the spec about how to do this!

I've fixed this individual issue. But I'm going to run through all the transaction this weekend to make sure I got all edge cases.

It looks like first part is fixed, but the last part (15XJoDF4xCUrWX3ES9ftWq3wnGhuRsqrLk vs 1G6F8aMJNp3zMG9L1DxDT3WjiUntJYwYka) still remains.

Very few purchases are affected by this (hopefully last) bug, so I went ahead and put a link to MasterCoin-Explorer.com in the OP

I've been promising the community a month-long coding contest (pre-announcement here: https://bitcointalk.org/index.php?topic=265488.msg3065262#msg3065262), and I was thinking $25,000 would be a good number for total prizes to be awarded. If you don't think that's a good use of project money, please let me know ASAP before I start making promises! My goal is to spur a bunch of progress on the project while also hopefully finding one or two people to hire . . .

Thanks!

-J.R.

P.S. One guy is already making some amazing progress on some web-based MasterCoin tools, including looking up purchases from the Exodus Address, parsing specific MasterCoin transactions, and he even ported my python script for creating send transactions to the web! Check it out if you haven't already seen it: http://mastercoin-explorer.com/

We launched BuyMastercoin on Aug 31st in order to provide a safe and reliable place for people to exchange Mastercoins since after this date you could no longer buy Mastercoins through the exodus address.

Our current format is over the counter yet we plan to launch a real-time Mastercoin exchange soon. We will allow people to buy and sell Mastercoins using dollars, euros, litecoins, altcoins, ripples, bitcoins and more.

We want to help build the Mastercoin ecosystem, especially now that the client is not yet developed and has some time to go. We also look to provide valuable information to the Mastercoin community such as MSC/BTC price charts, and tools for Mastercoin derived markets.

The key phrase here is "hopefully start the discussion going in the right direction" no one is proposing a "focus" on marketing. As someone who as worked as a developer and marketer, I am cautious not to develop tunnel vision by planning for success. I think planning ahead is beneficial. I can't say much for letting day to day operations drive out planning. Waiting till the project is complete before thinking about a plan to get the word out is ill advised at best.

There is a fundamental flaw with the logic saying that "if you build it they will come" if you have bigger competitors who already have an established name and network effect. The network effect concept plays a big role here because it determines how easy and why the customers or users will want to switch or use another technology with similar functionality. A problem with adoption might develop because there is a huge cost involved for customers to switch from one complex system to the next. Case in point bitcoin-litecoin-primecoin.

So like I said, the idea is not to start building a marketing campaign at the moment, because you don't want to "paint the idea". The idea is to have a plan ready to go on, once the usefulness of mastercoin is proven. I don't think its wise to wait till full functionality to start planning

I'm in complete agreement here. I see most of the marketing goals as being fairly far in the future (although putting together a basic website would be nice). I do want to express appreciation to Ola for the work he put into this. We'll get there someday

I definitely want to improve the impact we are having on the block chain (by finding alternate ways to store the MasterCoin data). The coding contest will definitely have some funds for someone who does that well.

What about the suggestions of using op-return to alleviate the UTXO set issue in a customized client? you should stress this in the details of the bounty for development of the client.

Nxter,Bitcoiner,Ether highlevel developer working to improve the world.

I am checking one of the first tx to 1EXoDus address from:https://blockchain.info/address/1PA8qhEzW7to6EeqBAdhVZYGbVj2MfmN2nwhich was 16BTC and it happened 2687249 seconds (around 31.1 days) before 1.9.2013.The bonus is then 10% for a week, which is 10%*2687249/(3600*24*7)=>44.43%[this fits to 4 weeks = 40%]or in dacoinminsters:160000000000+71091243386=231091243386which is:2310.91243386 mastercoins

Can I ask you what time you are using to define the end date? I'm using 1377993600. I think this is the difference between our results.

I am using 1377993600 as well, so I don't understand the difference in the results.

I just assume you took a different timestamp for the tx.It is important to note that the only relevant timestamp in the blockchain is the one of the corresponding block.Any other "Received Time" is node-dependant value (e.g. one may get the tx few seconds minutes or even hours before of after blockchain.info, and there is no way to verify it), and that value should be ignored.

Block 255362 has the timestamp of 2013-09-01 00:00:58 which is after end date, so it should be also refunded.If we change that, this would be already considered as a modification of the spec (and we would like to avoid that, like bitcoin avoids hard forks).

I have seen somewhere the suggestion that some early investors could send valid mastercoins to those addresses.

Heh. For python, yes. I have no idea about pycrypto. I would assume there is something available for Mac.

I will post if find something...

Not sure if pycrypto builds for Mac, but you could always try checking out the source from https://github.com/dlitz/pycrypto (e.g. "git clone https://github.com/dlitz/pycrypto")then change dir to that directory and issue something like "python setup.py", then "python setup.py install" ...standard python module stuff. You may need some extra dependencies.

OK - these instructions were very helpful, I managed to setup pycrypto very easily. Only difference is that the article is a bit outdated and uses the 2.1.0 version of pycrypto.

Here: https://www.dlitz.net/software/pycrypto/ you can find the latest one (2.6) and the instructions are basically the same. You download and uncompress the file, run terminal in the path of the uncompressed folder and use python commands (of course you are supposed to have python installed before that) for building and installing the package.

I just assume you took a different timestamp for the tx.It is important to note that the only relevant timestamp in the blockchain is the one of the corresponding block.Any other "Received Time" is node-dependant value (e.g. one may get the tx few seconds minutes or even hours before of after blockchain.info, and there is no way to verify it), and that value should be ignored.

Thanks for the detailed breakdown. I found a reference in the code where I was not using my constant for the end date and this date was 1 second off. The result is now: "Bought 1600.0 Mastercoins and got a 710.91243386 Mastercoins extra.". Which I think should be the correct amount.

Now I finally have the same output I'm considering parsing the blockchain and get some real data on the transfers happening and actual balances of addresses.

15XJoDF4xCUrWX3ES9ftWq3wnGhuRsqrLk (which had the largest total input) should be the owner of those MasterCoins rather than 1G6F8aMJNp3zMG9L1DxDT3WjiUntJYwYka (which had the largest single input). MasterCoin-Explorer incorrectly credits the latter address with the purchase. I realize I need to be more clear in the spec about how to do this!

Ah; this was unclear to me. I have indeed been using the largest single one, this won't make the implementation easier. I think the spec could use one clear paragraph on how to parse the data with test vectors.

Block 255362 has the timestamp of 2013-09-01 00:00:58 which is after end date, so it should be also refunded.If we change that, this would be already considered as a modification of the spec (and we would like to avoid that, like bitcoin avoids hard forks).

I have seen somewhere the suggestion that some early investors could send valid mastercoins to those addresses.

Although it's true that the spec mentions that all payments after 2013-08-31 will be considered invalid it does not tell us which time to use for this calculation. If we want to be precise then yes 255361 would be the valid answer. However people sending coins on 23:48 did so thinking they send the coins before 2013-08-31, which they indeed did. It seems more fair to use block 255362 since this would include all transactions _send_ before 2013-09-01. (and yes; perhaps 58 seconds of transactions that were sent after)

Although it's true that the spec mentions that all payments after 2013-08-31 will be considered invalid it does not tell us which time to use for this calculation. If we want to be precise then yes 255361 would be the valid answer. However people sending coins on 23:48 did so thinking they send the coins before 2013-08-31, which they indeed did. It seems more fair to use block 255362 since this would include all transactions _send_ before 2013-09-01. (and yes; perhaps 58 seconds of transactions that were sent after)

For now, this really doesn't have much effect. But in about 5 years - this loss of transaction is going to cost someone about 13 million dollars. Better take a moment to get it right. I'd include them. Leaving them out exposes you to a claim later by a fast talking lawyer who will argue ambiguities in the spec should be enforced against the author rather than the investor. He'll win with that line of reason. The writer of the document had the ability to set it correctly - and that failure results in the liability shifting towards him.

Now, no lawyer will touch this case. When it is worth $13 million there will be a long line of shark attorneys at the courthouse filing paper.

I know it is a stupid way to settle the question, but it is worth considering.

After the initial purchase 'user A' creates three simple send transactions for 10 coins to 'user B', 'user C' and 'user D' and relays them over the network. Assuming they all get included in the same block, to whom do the coins go?

After the initial purchase 'user A' creates three simple send transactions for 10 coins to 'user B', 'user C' and 'user D' and relays them over the network. Assuming they all get included in the same block, to whom do the coins go?

Transactions in a block are ordered so it could use the first transaction.

Transactions in a block are ordered so it could use the first transaction.

Or the mastercoins could be destroyed in this case.

How is this order defined; is it defined on the protocol level? If so I was unaware of this.

The miner chooses in which order to put the transactions. (If there are dependencies, a tx must come before those that depend on it.) Once he sets the order it is a fixed property of the block, putting the txs in a different order would result in a different Merkle root and thus invalid block hash.

Transactions in a block are ordered so it could use the first transaction.

Or the mastercoins could be destroyed in this case.

How is this order defined; is it defined on the protocol level? If so I was unaware of this.

The miner chooses in which order to put the transactions. (If there are dependencies, a tx must come before those that depend on it.) Once he sets the order it is a fixed property of the block, putting the txs in a different order would result in a different Merkle root and thus invalid block hash.