Topic: MasterCoin: New Protocol Layer Starting From “The Exodus Address” - page 121. (Read 448462 times)

I'm not sure how this resolves the issue of having to refund a payment if all transactions happen in the same block.

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.

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.

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?

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 . . .

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

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

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

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?