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

[jadair10]

And to top it all off, I made an animated intro video using the new logo:
https://vimeo.com/73592269

Tips of any sort are greatly appreciated! My address: 13x2dka6tVhjsNNNomGJjUPi2iJQCb67bw
Depending on what you guys think, I can probably help out more with explanation videos/ branding.

Excellent work. Wow.

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.

I agree with your point above about "explainer videos". In an earlier post I suggested some kahn academy style videos such as this one... http://www.youtube.com/watch?v=QzDO44oZWtE.

And here is a great video on "how to make a khan academy video". http://www.youtube.com/watch?v=QZJAhfaZnUA; not that I need to tell you how to make a video.

[1714163739]

1714163739

[1714163739]

1714163739

[1714163739]

1714163739

[dacoinminster]

In the interest of full transparency, here is the updated expenditure list I sent to the board just now. Hopefully I can process refunds tomorrow.

We've decided to set the cutoff date for investments a couple blocks later in order to accommodate some people who sent before the deadline, but did not get included in a block until after the deadline. Consequently, the expenditure list has changed slightly. Here's the final list of transactions which I hope to execute soon, probably tomorrow:

    13.279 BTC in refunds to investors who missed the deadline (addresses and details here: https://docs.google.com/spreadsheet/ccc?key=0AnnInaIJVqrtdGMteFNOWjBpWTNqd3BYbWUzdGVLMmc#gid=0)
    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, verified by him)
    0.1 BTC to Ron to reimburse his purchase of MasterCoin.org (1HfXDX3ALapNebQC8stTdd5zK7kiCgvX9n)

Total expenditures: 21.379 BTC
Aside from the changes to the refund list, this is the same list of expenditures as before, so I don't expect comments - I'm just keeping you guys in the loop.

Thanks!

-J.R.

If you are expecting a refund, please check the spreadsheet linked above and make sure it looks correct. Thanks!

This transaction has now been broadcast. Considerable money left the Exodus Address, but most of it came back to the same offline wallet as change (14JnZjp1HXgVKy8CKo2VkiD4vQM69nQrFN)

TX can be viewed here: http://blockchain.info/tx/99160b37b3294eebc83bd8ff44849c813d2e9da986a25fb127b0c5915e799c0a

[dacoinminster]

Coding Contest LAUNCHED on this separate thread: https://bitcointalk.org/index.php?topic=292628.0

Here's the quote from the OP of that thread, although note that I'm not planning on updating this quote if I update the OP of that thread:

If you've been living under a rock, you may not know that we recently raised over half a million dollars to build a new protocol layer on top of bitcoin. The new layer is NOT an alt-chain currency - it's built right on top of bitcoin, and is called "MasterCoin" (not to be confused with the alt-chain currency of the same name). You can read all about it here: https://bitcointalk.org/index.php?topic=265488.0

A few days ago, I pre-announced that we would be doing a major coding contest, with total prizes adding up to $25000 (https://bitcointalk.org/index.php?topic=265488.msg3065262#msg3065262). The goals of the contest are to spur development on the MasterCoin protocol layer, and to hopefully find at least one person to be our first full-time hire.

This thread is devoted to that contest. Following are the official rules, subject to change if deemed necessary:

• ALL serious entries will win a prize (although some prizes may be very small)
• Prize money will be divvied up by myself, with input from the community and the board of the MasterCoin Foundation, based primarily on how useful and valuable your code is to the success of our protocol layer
• In addition to the overall impact and value of your code, other important things will be taken under consideration:
  
  • How often you post updates in this thread or the main project thread. Ideally, you should post what you plan to do, and then post extremely frequent updates as you make progress.
  • Ease of use and testability. If you just dump some source code on me at the end of the contest with a bunch of grandiose claims, you may not get much. Ideally, you should be posting demos, screenshots, and/or set up a website demonstrating your code.
  • Collaboration. If you are helping other people working on MasterCoin projects, that will weigh favorably on how much you win. If you release your source code early and other people build on it, that will weigh even more favorably.
  • Breaking new ground, or being redundant. Doing something new is awesome, but you will NOT be penalized for implementing the same thing as someone else. We need redundancy for cross-checking. We have the following feature needs:
    
    • Better ways to store (and then retrieve) MasterCoin data. Gavin has told us there are multiple better ways, and there has been some discussion of how to do it on this thread: https://bitcointalk.org/index.php?topic=284178.0
    • Reusable libraries for parsing MasterCoin transactions in the block chain, and for generating them
    • PC wallets for MasterCoin
    • Web wallets for MasterCoin
    • Implementing advanced features, as defined in the spec. (But please don't implement new features using the existing "data address" method of storing data in the block chain - we need to look for a better way to store our data first)
• Only open-source projects will be considered for a prize. You must release your source code before the end of the contest to be eligible.
• Getting the biggest prize in this contest does NOT guarantee you a job, but having some kind of entry in this contest will help your chances a lot.
• Contest ends October 15th, 2013, with prizes paid out once the dust settles.
• Prizes will total $25000 USD, payable in bitcoins according to the exchange rate at that time.
• Contestants may elect to take some or all of their prize money in MasterCoins if desired. (We'll purchase them on the open market for you, using the bitcoins we would have paid you)

You should be aware that multiple projects eligible for entry into this contest are already started, and have made amazing progress. When I first contemplated a $25000 payout, it seemed like a huge sum, but given how many people are enthusiastically working on MasterCoin projects, you may be disappointed with the prize you get for your efforts. There is a lot of amazing work going forward extremely rapidly, as you can see on the project thread. By the end of the contest, I doubt that anybody's prize will be "fair" for the effort they put in. We'll have to just hope that it is a nice bonus for working on a fun project.

I'll update this post soon with a link to a job description of the full-time job we will be hoping to fill, hopefully we'll fill the position with someone who enters this contest.

 . . . and true to form, I'm now going offline for awhile. I'll try to catch up on any questions about the contest tomorrow.

[dacoinminster]

I added some sidebar links to our subreddit: http://www.reddit.com/r/mastercoin/

If I missed anything important, please let me know.

I can't offer a bounty for it, but if somebody wants to take a crack at a reddit-style logo for MasterCoin, that would be fun to have. Usually such a logo would have the reddit alien in it. Maybe the reddit alien getting irradiated by MasterCoin, since our logo looks kind of like the radiation symbol 

Maybe that's too unprofessional. I dunno . . .

[grazcoin]

Now, breaking down the transaction data, we have:
81 = sequence number, which is one less than the same byte of the reference address, which is 0x82

In spec 1.1 you say:
"the data packet sequence numbers start at n+1 where n is the sequence number of the reference packet if it were treated as a data packet".

On your first ever transaction (quote above) I see that the data has sequence number (81) which is lower than the one of the reference (82).
How come?

[dacoinminster]

Now, breaking down the transaction data, we have:
81 = sequence number, which is one less than the same byte of the reference address, which is 0x82

In spec 1.1 you say:
"the data packet sequence numbers start at n+1 where n is the sequence number of the reference packet if it were treated as a data packet".

On your first ever transaction (quote above) I see that the data has sequence number (81) which is lower than the one of the reference (82).
How come?

Because the spec has an error which I need to fix in the next rev

Here's my explanation of how that happened which I gave to maraoz a couple days ago when he asked me the same thing:

Why does Mastercoin Advisor use a data sequence number lower than the recipient sequence number? Shouldn't it be the successor of the recipient sequence number, as the protocol specifies?

Code:

recipientSequenceNum = ord(recipientBytes[1])
dataSequenceNum = recipientSequenceNum - 1
if dataSequenceNum < 0:
	dataSequenceNum = dataSequenceNum + 256

In order to distinguish data packets from the reference address, the data packet sequence numbers start
at n+1 where n is the sequence number of the reference packet if it were treated as a data packet. Any
additional data packets can continue to use up sequence numbers n+2, n+3, and so on until all sequence
numbers are used except for n-1.
As an example of how this works, let's imagine a MasterCoin transaction that has two data packets. If
the reference address happens to have a sequence number of 62, then the first data packet has a
sequence number of 63 and the second has a sequence number of 64. Note that sequence number 255
is followed by 0.

Aw crap. I meant to update the spec to change how the sequence numbers worked. Thanks for catching that.

When I was writing the code for MasterCoin Adviser, it occurred to me that it might be easier to parse MasterCoin transactions if the first data packet had the first sequence number, then additional data packets following, and then the reference packet last, with the last sequence number. But I never went back and updated the spec to reflect that change. I made that change because I thought it might help if we ever had transactions with data but no reference address.

[moltenmich]

I added some sidebar links to our subreddit: http://www.reddit.com/r/mastercoin/

If I missed anything important, please let me know.

I can't offer a bounty for it, but if somebody wants to take a crack at a reddit-style logo for MasterCoin, that would be fun to have. Usually such a logo would have the reddit alien in it. Maybe the reddit alien getting irradiated by MasterCoin, since our logo looks kind of like the radiation symbol 

Maybe that's too unprofessional. I dunno . . .

  if anyone comes up with anything better, definitely replace it. but this can be a good placeholder for now

[Tachikoma]

I have a proposal for alternative Mastercoin encoding ready and I wanted to discuss the feasibility of my solution. We are going to use a OP_CHECKMULTISIG script with three (or more) public keys to encode the data.

Because we will be using public keys to encapsulate the data we now have 64 bytes to encode data (65 minus one byte for the 04 marker). In order to not polute the blockchain we will always supply a publickey that the sender owns as first signature this way the output can always be redeemed. The other signatures we supply will be data-addresses; these transactions won't be able to be converted to addresses since they are not technically ECDSA x/y coordinates but they should be relayed and mined just fine.

I've created a test transaction on testnet3 (raw) to test this functionality.

miKnddGDQfU6rRYpLp2dhRyttnxH1WUo21 is the exodus that I use on Testnet. I'm sending the coins to myself (miDyBpL3TeeJRbtwdFUsw9mUWUEhN6FyXf) in this example so I send both the change amount and 0.00006 transaction to this address. I also use this address as the first signature for the multisg output so I can redeem this later. If you check the raw transaction you will see that there are two more keys supplied. If you decode these using the encoding standard from the whitepaper (but instead pad with zeros until you have 65 bytes) you will see that I'm doing two transaction for 1 test Mastercoin each.

In theory you could do multiple Mastercoin transactions in one multisig output but I would like to propose to keep it simple and only one transaction per output. If you want to send multiple Mastercoin transactions in one Bitcoin transaction you can create multiple multisig outputs.

Since all current ideas of the whitepaper fit within 126 bytes (2 signatures) and signatures are in fixed order we might not need to add sequences to all signatures but for now let's continue doing it.

I know there are a lot of users with more knowledge of Bitcoin lurking so please let me know if this approach would work within the rules set out by the reference implementation. I'm especially interested in if we can use 1 out of 5 multisig transactions. I tried to make one; and it relayed; but I'm not sure it's actually a valid transaction type.

Please let me know your thoughts so we can continue building cool things on top of Mastercoin

[grazcoin]

basic mastercoin tx parser was added to https://github.com/grazcoin/mastercoin-tools

The parser goes on all 1EXoDus tx, and outputs:
tx_hash,from,to,amount,currency,tx_type
currently only simple send is supported

usage:
python msc_parse.py > outputs/tx_parse.csv

updated result can be fetched:
https://raw.github.com/grazcoin/mastercoin-tools/master/outputs/tx_parse.csv

Tachikoma: can you please verify that we have identical parsing?

[Tachikoma]

I've also had a question about "Purchasing a Currency Offered For Sale" that has been bothering me.

I put an offer out there to sell 100 coins for 5 BTC.

User A and User B both send me 5BTC wanting to buy those 100 coins. User B's transactions gets added above User A's transaction in the block so he receives the Mastercoins.

What happens to the 5BTC from user A that he send to the address?

Tachikoma: can you please verify that we have identical parsing?

Will do this ASAP.

Edit: They match 100%

[grazcoin]

I have a proposal for alternative Mastercoin encoding ready and I wanted to discuss the feasibility of my solution. We are going to use a OP_CHECKMULTISIG script with three (or more) public keys to encode the data.

Because we will be using public keys to encapsulate the data we now have 64 bytes to encode data (65 minus one byte for the 04 marker). In order to not polute the blockchain we will always supply a publickey that the sender owns as first signature this way the output can always be redeemed. The other signatures we supply will be data-addresses; these transactions won't be able to be converted to addresses since they are not technically ECDSA x/y coordinates but they should be relayed and mined just fine.

I've created a test transaction on testnet3 (raw) to test this functionality.

miKnddGDQfU6rRYpLp2dhRyttnxH1WUo21 is the exodus that I use on Testnet. I'm sending the coins to myself (miDyBpL3TeeJRbtwdFUsw9mUWUEhN6FyXf) in this example so I send both the change amount and 0.00006 transaction to this address. I also use this address as the first signature for the multisg output so I can redeem this later. If you check the raw transaction you will see that there are two more keys supplied. If you decode these using the encoding standard from the whitepaper (but instead pad with zeros until you have 65 bytes) you will see that I'm doing two transaction for 1 test Mastercoin each.

In theory you could do multiple Mastercoin transactions in one multisig output but I would like to propose to keep it simple and only one transaction per output. If you want to send multiple Mastercoin transactions in one Bitcoin transaction you can create multiple multisig outputs.

Since all current ideas of the whitepaper fit within 126 bytes (2 signatures) and signatures are in fixed order we might not need to add sequences to all signatures but for now let's continue doing it.

I know there are a lot of users with more knowledge of Bitcoin lurking so please let me know if this approach would work within the rules set out by the reference implementation. I'm especially interested in if we can use 1 out of 5 multisig transactions. I tried to make one; and it relayed; but I'm not sure it's actually a valid transaction type.

Please let me know your thoughts so we can continue building cool things on top of Mastercoin

looks good
I would try to optimize the tx so it has only 2 outpus and not 4:

• 0.00006000 as marker (exodus)
• all the rest (with no separation between another 0.00006000 or change) to the multisig address, where the first multisig address belongs to the multisig sender and the embedded data (which comes from the other addresses) contains whatever we want, including the reference address, but not as a valid redeemer.
  

We have to keep in mind though, that fully spent transactions can be pruned (for keeping the blockchain smaller), and then we lose the mastercoin information.

[Nagant]

I have a proposal for alternative Mastercoin encoding ready and I wanted to discuss the feasibility of my solution. We are going to use a OP_CHECKMULTISIG script with three (or more) public keys to encode the data.

Because we will be using public keys to encapsulate the data we now have 64 bytes to encode data (65 minus one byte for the 04 marker). In order to not polute the blockchain we will always supply a publickey that the sender owns as first signature this way the output can always be redeemed. The other signatures we supply will be data-addresses; these transactions won't be able to be converted to addresses since they are not technically ECDSA x/y coordinates but they should be relayed and mined just fine.

I've created a test transaction on testnet3 (raw) to test this functionality.

miKnddGDQfU6rRYpLp2dhRyttnxH1WUo21 is the exodus that I use on Testnet. I'm sending the coins to myself (miDyBpL3TeeJRbtwdFUsw9mUWUEhN6FyXf) in this example so I send both the change amount and 0.00006 transaction to this address. I also use this address as the first signature for the multisg output so I can redeem this later. If you check the raw transaction you will see that there are two more keys supplied. If you decode these using the encoding standard from the whitepaper (but instead pad with zeros until you have 65 bytes) you will see that I'm doing two transaction for 1 test Mastercoin each.

In theory you could do multiple Mastercoin transactions in one multisig output but I would like to propose to keep it simple and only one transaction per output. If you want to send multiple Mastercoin transactions in one Bitcoin transaction you can create multiple multisig outputs.

Since all current ideas of the whitepaper fit within 126 bytes (2 signatures) and signatures are in fixed order we might not need to add sequences to all signatures but for now let's continue doing it.

I know there are a lot of users with more knowledge of Bitcoin lurking so please let me know if this approach would work within the rules set out by the reference implementation. I'm especially interested in if we can use 1 out of 5 multisig transactions. I tried to make one; and it relayed; but I'm not sure it's actually a valid transaction type.

Please let me know your thoughts so we can continue building cool things on top of Mastercoin

Man, that was fast and bold. Big respect!

[Tachikoma]

I have a proposal for alternative Mastercoin encoding ready and I wanted to discuss the feasibility of my solution. We are going to use a OP_CHECKMULTISIG script with three (or more) public keys to encode the data.

Because we will be using public keys to encapsulate the data we now have 64 bytes to encode data (65 minus one byte for the 04 marker). In order to not polute the blockchain we will always supply a publickey that the sender owns as first signature this way the output can always be redeemed. The other signatures we supply will be data-addresses; these transactions won't be able to be converted to addresses since they are not technically ECDSA x/y coordinates but they should be relayed and mined just fine.

I've created a test transaction on testnet3 (raw) to test this functionality.

miKnddGDQfU6rRYpLp2dhRyttnxH1WUo21 is the exodus that I use on Testnet. I'm sending the coins to myself (miDyBpL3TeeJRbtwdFUsw9mUWUEhN6FyXf) in this example so I send both the change amount and 0.00006 transaction to this address. I also use this address as the first signature for the multisg output so I can redeem this later. If you check the raw transaction you will see that there are two more keys supplied. If you decode these using the encoding standard from the whitepaper (but instead pad with zeros until you have 65 bytes) you will see that I'm doing two transaction for 1 test Mastercoin each.

In theory you could do multiple Mastercoin transactions in one multisig output but I would like to propose to keep it simple and only one transaction per output. If you want to send multiple Mastercoin transactions in one Bitcoin transaction you can create multiple multisig outputs.

Since all current ideas of the whitepaper fit within 126 bytes (2 signatures) and signatures are in fixed order we might not need to add sequences to all signatures but for now let's continue doing it.

I know there are a lot of users with more knowledge of Bitcoin lurking so please let me know if this approach would work within the rules set out by the reference implementation. I'm especially interested in if we can use 1 out of 5 multisig transactions. I tried to make one; and it relayed; but I'm not sure it's actually a valid transaction type.

Please let me know your thoughts so we can continue building cool things on top of Mastercoin

looks good
I would try to optimize the tx so it has only 2 outpus and not 4:

• 0.00006000 as marker (exodus)
• all the rest (with no separation between another 0.00006000 or change) to the multisig address, where the first multisig address belongs to the multisig sender and the embedded data (which comes from the other addresses) contains whatever we want, including the reference address, but not as a valid redeemer.
  

We have to keep in mind though, that fully spent transactions can be pruned (for keeping the blockchain smaller), and then we lose the mastercoin information.

Good point, reducing the outputs sounds like a good idea. I am personally using bitcoin-ruby as backend so pruning won't be a problem. (Although having 40GB worth of blockchain data ain't pretty neither).

Do you know if '1 out of X' transactions where X is higher then 3 are fully valid transactions?

[grazcoin]

I've also had a question about "Purchasing a Currency Offered For Sale" that has been bothering me.

I put an offer out there to sell 100 coins for 5 BTC.

User A and User B both send me 5BTC wanting to buy those 100 coins. User B's transactions gets added above User A's transaction in the block so he receives the Mastercoins.

What happens to the 5BTC from user A that he send to the address?

First of all don't sell 100 coins for 5 BTC. Let's say you sell 100 coins for 50 BTC ;-)

The BTC from A land also on the seller's address, so according to the current spec, the seller should refund it, which is indeed a problem.

Solutions:

• If the payment would have been done using some mastercoin-derived-currency (even with BTC face value), the protocol could have automatically handle the refund.
• Using multisig based escrow - the funds are sent by the buyer to 2-of-3 address (buyer,seller,escrow) + marker output. If the buyer sees that he is the only buyer (e.g. after 6 confirmations), he signs the tx and the seller signs it, and the protocol interpret it as a closed deal. In this case any later buyers could get their funds back by seller or escrow signature. If there is some disagreement, the escrow signs the needed tx (refund to buyer or funds to seller).
  For this we need:
  
  • trusted escrow address (it cannot steal the funds, just decide to which side the funds go to)
  • everyone's public key which may be a problem (not anyone like to share their public key)
  • some communication channel to transfer the half-signed tx.

[grazcoin]

Do you know if '1 out of X' transactions where X is higher then 3 are fully valid transactions?

It seems that maximum is m-of-20 in the current code base (where m<=20):
https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L882

[Tachikoma]

Do you know if '1 out of X' transactions where X is higher then 3 are fully valid transactions?

It seems that maximum is m-of-20 in the current code base (where m<=20):
https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L882

According to #bitcoin-dev the only supported ones are n-of-3... I think we need to test it out before deciding on the final spec.

[dacoinminster]

I added some sidebar links to our subreddit: http://www.reddit.com/r/mastercoin/

If I missed anything important, please let me know.

I can't offer a bounty for it, but if somebody wants to take a crack at a reddit-style logo for MasterCoin, that would be fun to have. Usually such a logo would have the reddit alien in it. Maybe the reddit alien getting irradiated by MasterCoin, since our logo looks kind of like the radiation symbol 

Maybe that's too unprofessional. I dunno . . .

  if anyone comes up with anything better, definitely replace it. but this can be a good placeholder for now

That is AWESOME. Thanks Mich! I put it up.

[dacoinminster]

I've also had a question about "Purchasing a Currency Offered For Sale" that has been bothering me.

I put an offer out there to sell 100 coins for 5 BTC.

User A and User B both send me 5BTC wanting to buy those 100 coins. User B's transactions gets added above User A's transaction in the block so he receives the Mastercoins.

What happens to the 5BTC from user A that he send to the address?

First of all don't sell 100 coins for 5 BTC. Let's say you sell 100 coins for 50 BTC ;-)

The BTC from A land also on the seller's address, so according to the current spec, the seller should refund it, which is indeed a problem.

Solutions:

• If the payment would have been done using some mastercoin-derived-currency (even with BTC face value), the protocol could have automatically handle the refund.
• Using multisig based escrow - the funds are sent by the buyer to 2-of-3 address (buyer,seller,escrow) + marker output. If the buyer sees that he is the only buyer (e.g. after 6 confirmations), he signs the tx and the seller signs it, and the protocol interpret it as a closed deal. In this case any later buyers could get their funds back by seller or escrow signature. If there is some disagreement, the escrow signs the needed tx (refund to buyer or funds to seller).
  For this we need:
  
  • trusted escrow address (it cannot steal the funds, just decide to which side the funds go to)
  • everyone's public key which may be a problem (not anyone like to share their public key)
  • some communication channel to transfer the half-signed tx.

Buying MasterCoins with bitcoins on the distributed exchange is actually a two-step process:

1) Signal your intent to buy, paying a transaction fee specified by the seller to prove you are serious
2) If you are recorded in the block chain as the first one to signal your intent to buy, THEN you send payment within the specified time window of your signal

If you don't send payment within the time window, the MasterCoins become available for sale again. In this way, you don't risk sending payment and not being first.

This is the current logic in the spec, but I probably wasn't clear enough. Here's the actual wording from the spec, with certain bits relevant to this question highlighted:

Selling MasterCoins for Bitcoins
Say you want to publish an offer to sell 1.5 MasterCoins for 1000 bitcoins. Doing this takes 33 bytes, which fits into two data payments:

1.   Transaction type = 20 for currency trade offer for bitcoins (32-bit unsigned integer, 4 bytes)
2.   Currency identifier for sale = 1 for MasterCoin (32-bit unsigned integer, 4 bytes)
3.   Amount for sale = 150,000,000 (1.50000000 MasterCoins) (64-bit unsigned integer, 8 bytes, should not exceed the number owned, but if it does,  assume the user is selling all of them)
4.   Amount of bitcoins desired = 100,000,000,000 (1000.00000000 bitcoins) (64-bit unsigned integer, 8 bytes)
5.   Time limit = 10 (10 blocks in which to send payment after counter-party accepts these terms) (8-bit unsigned integer, 1 byte)
6.   Minimum bitcoin transaction fee = 10,000,000 (require that the buyer pay a hefty 0.1 BTC transaction fee to the miner, discouraging fake offers) (64-bit unsigned integer, 8 bytes)

Selling MasterCoins for Other MasterCoin-Derived Currencies

Say you want to publish an offer to sell 2.5 MasterCoins for 50 GoldCoins (coins which each represent one ounce of gold, derived from MasterCoins and described later in this document). For the sake of example, we'll assume that GoldCoins have currency identifier 3. Doing this takes 28 bytes, which fits into two data payments:

1.   Transaction type = 21 for currency trade offer for another MasterCoin-derived currency (32-bit unsigned integer, 4 bytes)
2.   Currency identifier for sale = 1 for MasterCoin (32-bit unsigned integer, 4 bytes)
3.   Amount for sale = 250,000,000 (2.50000000 MasterCoins) (64-bit unsigned integer, 8 bytes, should not exceed the number owned, but if it does,  assume the user is selling all of them)
4.   Currency identifier desired = 3 for GoldCoin (32-bit unsigned integer, 4 bytes)
5.   Amount of GoldCoins desired = 5,000,000,000 (50.00000000 GoldCoins) (64-bit unsigned integer, 8 bytes)

Changing an Offer

Say you decide you want to change the number of coins you are offering for sale, or change the asking price. Simply re-send the offer with the new details. If your change gets into the block chain before someone accepts your old offer, your offer has been updated.

If you decide you want to cancel an offer, simply send the offer again, but enter the number of coins for sale as zero.

Purchasing a Currency Offered For Sale
Say you see an offer such as those listed above, and wish to accept it. Doing so takes 16 bytes, which fits into 1 data payment:
1.   Transaction type = 22 for accepting currency trade offer (32-bit unsigned integer, 4 bytes)
2.   Currency identifier you are purchasing = 1 for MasterCoin (32-bit unsigned integer, 4 bytes)
3.   Amount you are purchasing = 130,000,000 (1.30000000 MasterCoins) (64-bit unsigned integer, 8 bytes, should not exceed number available for sale, but if it does, assume buyer is purchasing all of them)

The reference address should point to the seller's address, to identify whose offer you are accepting.

If you are purchasing with bitcoins, make sure your total expenditures on bitcoin transaction fees while accepting the purchase meet the minimum fee requested!

You will need to send the appropriate amount of bitcoins before the time limit expires to complete the purchase. Note that you must send the bitcoins from the same address which initiated the purchase. If you send less than the correct amount of bitcoins, your purchase will be for that amount. Update 9/8/2013: In order to make parsing MasterCoin transactions easier, you must also include an output to the Exodus Address when sending the bitcoins to complete a purchase of MasterCoins. The output can be for any amount, but should be above the dust threshold.

If you are purchasing with MasterCoin or a MasterCoin-derived currency such as GoldCoins, your purchase is complete as soon as you accept the offer (assuming you are recorded in the block chain as the first to accept the offer). If you have less than the correct amount on hand, your purchase will be for that amount.

Note that when only some coins are purchased, the rest are still for sale with the same terms.

If you guys have any ideas about how to make the spec more clear on these points, I'd love to hear them.

Thanks!

[dacoinminster]

I simply can't express how awesome this is that you guys are making such fast progress. I need to do some investigation (and learning) into the proposed methods for storing our data in alternate ways. What I've seen so far looks very promising.

All indications are that Tachicoma has a well-deserved big payday coming, and grazcoin has earned some non-trivial cash too

The next month should be very interesting.

[dacoinminster]

Here's a PM I got this morning with some questions:

Hi JR,
Great job on mastercoin and thanks for the 10 mastercoin reward for my efforts in giveaway thread. I am Red from China and working as translaton currently in a JV. Caught the btc virus in April!
As the mods of investment subforums in several leading btc forums in China, I feel obliged to pass the information out about the progress of mastercoin so I translated the encoding contest into chinese and posted in the my weibo, blogs and forums:

http://www.btcpie.com/blog_2013/09/
http://8btc.com/forum.php?mod=viewthread&tid=781&page=1#pid1457
http://blog.sina.com.cn/s/blog_d3b90b760101cflx.html
From the response I got, few people really understand what mastercoin is and its capability, including me. I got some questions:
1. what is the difference between test mastercoin and regular mastercoin?
2. what if we couldn't find a new way to store mastercoin transaction data?
3. The total amount of mastercoin will be around 500k?

Cheers,
Red

Hey Red,

Great questions. I've posted your questions here so that everyone can see the responses:

1. Test MasterCoins and regular MasterCoins have identical capability, but Test MasterCoins are intended to be used for testing new features before people use them with real MasterCoins
2. I am very confident at this point that we will find a better way. If we couldn't find a way, we could keep using the current method (and the bitcoin core devs would probably hire someone to kill me)
3. The total amount purchased can be seen at http://mastercoin-explorer.com/ (Total bought via Exodus    MSC 563,162.36), and an additional 10% will be released slowly to the Exodus Address over the coming years, to be used similar to other Exodus Address funds to pay for expenses related to this project.

Thanks!