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

[TomHirsch]

I would personally work a bit more on the implementation and protocol

I was thinking the same.

My feelings exactly.  Let's spend all of our time making this thing great; rather than running around telling people it is great. 

If we are successful and it actually becomes great - there will be no need whatever for a marketing campaign.  Forget the damn logos and twitter and fluff.  Let's build it before we paint it. 

[1715122571]

1715122571

[1715122571]

1715122571

[1715122571]

1715122571

[dacoinminster]

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.

[moltenmich]

I'm on the fence with the "build it before we paint it" view.

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.

[dacoinminster]

OK I did find one outstanding issue with mastercoin-explorer - it still counts the same address multiple times in one purchase. For instance, on this transaction:

http://blockchain.info/tx/52a875a46d7973760974b2ae8fa7bb71bfe7d06e0be8fd2bf2e20eaca182dbd7

When I enter the purchasing address (196V2uB471HoMHwbkQRQRiwd3aYpU6RtWg), I get "Bought 210000.0 Mastercoins and got a 88206.42361111111 Mastercoins extra."

The buyer sent 420 BTC with 5 inputs of 100 BTC each and 80 BTC change, which should have been 42000 MasterCoins plus a bonus. 42000*5 = 210000 which implies each input is being counted.

Probably related is the bug in the handling of this purchase: http://blockchain.info/tx/37992e445c33dd74a1e4e00dabb6a66f16a5d39977a1f5fd1a6c0154e884eee2

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

[dacoinminster]

For maximum transparency, here's a message I just sent to the oversight board:

Here are the details for the first proposed expenditure from the Exodus Address:

    51.8585 BTC in refunds to investors who missed the deadline (addresses and details here: https://bitcointalk.org/index.php?topic=265488.msg3095312#msg3095312)
    3 BTC bounty to bytemaster (1Nou27Zt2k3yTFHw6yePg3A1df2ohCTFFb per his PM to me) as a bounty for their work exposing a flaw in my spec. (details here: https://groups.google.com/d/msg/mastercoin/EQgEHvKJBh4/4VeE3a02I3QJ)
    3 BTC to d'aniel as part of the same bounty. D'aniel requested that his prize go to forum member gmaxwell: 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB, request is here: https://bitcointalk.org/index.php?topic=284178.msg3041300#msg3041300)
    2 BTC to mich for the awesome logo (13x2dka6tVhjsNNNomGJjUPi2iJQCb67bw, found in his forum signature - I've asked him to verify)
    0.1 BTC to Ron to reimburse his purchase of MasterCoin.org (Ron, I need a BTC address from you)

Total proposed expenditures: 59.9585 BTC

For now, I'm NOT reimbursing myself for the $80 netbook I purchased for an offline wallet, or for the $860 laptop I purchased for development, especially since my wife uses that laptop more than I do

If I don't hear anyone dissenting, I'll process these payments next week, possibly Monday.

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/

[buymastercoin]

I am the official forum user for http://www.BuyMastercoin.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.

Visit us at http://www.BuyMastercoin.com and subscribe for news updates and to sign up for our beta.

For up to date pricing information or to receive an exact price quote please email us through our contact form.

Thank you.

-BuyMastercoin.com Team

[Ola]

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.

I am sure you all have heard of bitshare, bitcoinx e.t.c?  https://docs.google.com/document/d/1RLcjSXWuU9vBJzzqLEXVACSCdn8zXKTTJRN_LfoCjNY/edit?pli=1, https://github.com/InvictusInnovations/BitShares...they are making progress and I am sure there will be more competitors: The point is the reason you are working to make this successful is that hopefully this catches on and immense value is created. Problem is "catching on" does not happen by coincidence especially when there are competitors who might be at an advantage by being the first movers and capitalizing on the network effect.

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

"failing to plan is planning to fail"--alan

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.

[grazcoin]

I am checking one of the first tx to 1EXoDus address from:
https://blockchain.info/address/1PA8qhEzW7to6EeqBAdhVZYGbVj2MfmN2n
which 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=231091243386
which 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.

Here is my detailed calculation:
===================
1. check https://blockchain.info/address/1PA8qhEzW7to6EeqBAdhVZYGbVj2MfmN2n
2. The relevant tx is https://blockchain.info/tx/546a406a131089e7c2f27d34a93a4d27441d98d096404d6737c5ad5b5e61a09b
3. That tx was included in block 249498 which has timestamp (in the blockchain) of 2013-07-31 21:32:31
4. converting the block timestamp to epoch: 1375306351
5. calculate difference between tx and end date: 1377993600-1375306351=2687249 sec
6. calculate bonus percent: 10%*2687249/(3600*24*7)=44.432027116%
7. calculate total amount of mastercoins: 1600000000*100*(1+0.44432027116)=231091243385.6 -> 2310.91243386

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.

[grazcoin]

I'm cool with that. I'm guessing block 255362 transactions would get a bonus of zero? It's possible that if you just used the same math, they'd actually get a small negative bonus!

Assuming we accept investments through block 255362, here is my proposed refund list: https://docs.google.com/spreadsheet/ccc?key=0AnnInaIJVqrtdGMteFNOWjBpWTNqd3BYbWUzdGVLMmc&usp=sharing

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.

[ripper234]

Willet, can you add a link to the FAQ to the op?

[klee]

In order to use this source code, you will need to install python 2.7 and also pycrypto for python 2.7, which I got here: http://www.voidspace.org.uk/python/modules.shtml#pycrypto

This is for Windows only! Any Mac version?

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.

EDIT: These instructions at http://dearauthor.com/ebooks/how-to-install-python-and-pycrypto/ may work.

Hey thanks a lot - will try to see if I can make this work!

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.

Now let's see if I can send some MSC...

[Tachikoma]

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

Here is my detailed calculation:
===================
1. check https://blockchain.info/address/1PA8qhEzW7to6EeqBAdhVZYGbVj2MfmN2n
2. The relevant tx is https://blockchain.info/tx/546a406a131089e7c2f27d34a93a4d27441d98d096404d6737c5ad5b5e61a09b
3. That tx was included in block 249498 which has timestamp (in the blockchain) of 2013-07-31 21:32:31
4. converting the block timestamp to epoch: 1375306351
5. calculate difference between tx and end date: 1377993600-1375306351=2687249 sec
6. calculate bonus percent: 10%*2687249/(3600*24*7)=44.432027116%
7. calculate total amount of mastercoins: 1600000000*100*(1+0.44432027116)=231091243385.6 -> 2310.91243386

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.

I'm cool with that. I'm guessing block 255362 transactions would get a bonus of zero? It's possible that if you just used the same math, they'd actually get a small negative bonus!

Assuming we accept investments through block 255362, here is my proposed refund list: https://docs.google.com/spreadsheet/ccc?key=0AnnInaIJVqrtdGMteFNOWjBpWTNqd3BYbWUzdGVLMmc&usp=sharing

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)

[TomHirsch]

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.  

[Tachikoma]

I have come across a theoretical problem.

Suppose 'user A' bought 10 coins from Exodus.

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?

[Meni Rosenfeld]

I have come across a theoretical problem.

Suppose 'user A' bought 10 coins from Exodus.

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.

Or the mastercoins could be destroyed in this case.

[Tachikoma]

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.

[Meni Rosenfeld]

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.

[Tachikoma]

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.

Awesome, thanks for the information. I will look into this

[grazcoin]

Answers to both issues you addressed below can be found in the blockchain, and for the protocol, there is actually nothing else (with consensus) but the blockchain.
You claim that the sending time of the tx which were included in block 255362 is before midnight but there is no way to prove it, as the timestamps are not in the blockchain. Those tx could have been available to my node only after midnight. I could easily report that tx from block 255363 or even later were seen on my node and claim that they were sent before midnight (although blockchain.info node saw them later). I see no reason to prefer blockchain.info node over my node.
Looking at the blockchain also answers your seconds question.
I would suggest a general guideline saying that we check the tx according to their order in the blockchain, and whenever a tx is invalid or it doesn't have enough funds, it is ignored.

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)

I have come across a theoretical problem.

Suppose 'user A' bought 10 coins from Exodus.

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?

[Tachikoma]

The problem is that we don't have a voting mechanism to deal with decisions such as which block to use as end block. I think we probably need a Linus arch-type guy/girl who decides how to interpret the spec on such matters. For now it would make sense that J.R. has final say on these matters until an official coder is appointed or there is a mechanism in place where we can decide on such questions democratically.