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

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

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!

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

[1715454349]

1715454349

[1715454349]

1715454349

[murraypaul]

The problem now becomes how to refund the initial transaction fee of the failed bids.
You haven't removed the problem, you've just made the amounts concerned smaller.
And you have doubled the bitcoin transaction fees you need to pay.
And every Mastercoin transaction has to pay a small amount to you (the Exodus address) for the privilege?
So each transfer has to pay Bitcoin fees*2 plus a small Exodus fee?
(Actually Bitcoin fees*3 , as the seller presumably needs another transaction to actually move the Mastercoins.)

[dacoinminster]

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

Well, the buyer is supposed to wait until they are confirmed as the first to broadcast the intention to buy those coins. If they send payment too soon, then yes, they would lose their money unless the seller decided to be nice.

The problem now becomes how to refund the initial transaction fee of the failed bids.
You haven't removed the problem, you've just made the amounts concerned smaller.
And you have doubled the bitcoin transaction fees you need to pay.
And every Mastercoin transaction has to pay a small amount to you (the Exodus address) for the privilege?
So each transfer has to pay Bitcoin fees*2 plus a small Exodus fee?
(Actually Bitcoin fees*3 , as the seller presumably needs another transaction to actually move the Mastercoins.)

The actual amount of the fees is considerably higher for bitcoin/mastercoin distributed exchange than for mastercoin/childcoin (even higher than you are imagining). This is because the seller actually sets a minimum fee which the buyer most pay to lock up the coins from other buyers. The fee goes to the bitcoin miner - it's gone forever. If we don't have something like this, a malicious actor could shut down the whole distributed exchange by spamming fake "intent to buy" messages.

There is a tradeoff here. If the market decides that these fees are too burdensome, there may be room for a centralized exchange website. I expect that the fees will not be too bad, especially compared with the huge risk of trusting an exchange to hold your coins.

If we find that bitcoin miners start spamming intent-to-buy messages to drive up prices, we may need to destroy coins instead. Perhaps the protocol should let the seller choose whether the fee goes to the miner or gets destroyed.

Another possibility would be to have the buyer put some MasterCoins up as collateral that they are making a serious buy offer, but this of course presents a problem for the first-time MasterCoin buyer

Yet another possibility would be to have the seller put up some additional MasterCoins as collateral that they will do refunds properly. Then the seller could collect the fees directly instead of going to the miners or destroying them. That seems rather complicated though.

I think we should implement the spec as written, and see how it plays out.

[murraypaul]

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

Well, the buyer is supposed to wait until they are confirmed as the first to broadcast the intention to buy those coins. If they send payment too soon, then yes, they would lose their money unless the seller decided to be nice.

From your earlier message:

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

Now you have to refund the transaction fees, if two or more people bid.
You haven't solved the problem, simply shifted it to the original transaction fee, rather than the full amount.
Unless the seller gets to keep all the transaction fees?

[dacoinminster]

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

Well, the buyer is supposed to wait until they are confirmed as the first to broadcast the intention to buy those coins. If they send payment too soon, then yes, they would lose their money unless the seller decided to be nice.

From your earlier message:

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

Now you have to refund the transaction fees, if two or more people bid.
You haven't solved the problem, simply shifted it to the original transaction fee, rather than the full amount.
Unless the seller gets to keep all the transaction fees?

Sorry - I think we both posted at the same time. See my message right before yours

Fees currently go to the bitcoin miner, and are not recoverable under the current spec.

[murraypaul]

Does the spec enforce that the seller actually has the coins they are offering to sell?
If not, any malicious actor can poison the market by repeatedly making offers they have no intent to fullfill, causing potential buyers to repeatedly lose transaction fees as they attempt to purchase.
This all seems pretty unattractive compared to existing exchanges like Cryptsy, where ownership of the coins is enforced, and fees are only charged on completed transactions.

[dacoinminster]

Does the spec enforce that the seller actually has the coins they are offering to sell?
If not, any malicious actor can poison the market by repeatedly making offers they have no intent to fullfill, causing potential buyers to repeatedly lose transaction fees as they attempt to purchase.
This all seems pretty unattractive compared to existing exchanges like Cryptsy, where ownership of the coins is enforced, and fees are only charged on completed transactions.

Yeah, anybody parsing MasterCoin transactions would not display sell orders from people who don't own the coins. And of course, we don't have this problem with the distributed exchange between MasterCoin and its child currencies.

The burden of these fees falls on the buyer, who is using bitcoins which are not subject to MasterCoin rules.

[dacoinminster]

Here's an email I got from somebody worried about MasterCoin clones:

On Thu, Sep 12, 2013 at 4:28 PM, John ----- wrote:

    Hi JR,
    I just listened to your talk with the bitangles and am concerned with your current protection against being "forked", which is probably the wrong word choice, but provides a nice pun for what could happen with the introduction of alt-MasterCoins.
    Bitcoin would not have the same first mover advantage if an alt-coin was created two months after Bitcoin. The moment someone sees any value to Mastercoin, then they will either consider buying Mastercoin on the open market, or copy the source code and create their own Exodus address.
    Thoughts???
    John -----

MasterCoin is vulnerable to clones, although the problem fades as the MasterCoin project continues to gain momentum.

It's helpful to try to imagine the uphill battle a clone would face. Who would launch it? The number of people who have the reputation to launch something like this isn't huge. Would anybody take them seriously? If you were an investor, would you send money to a cloned project with it's own Exodus Address?

A clone would have to offer some MAJOR innovations, and they would have to move very fast. In all likelihood, we would blatantly steal any innovations we saw in somebody else's clone, which I have said multiple times, in an attempt to discourage people from trying it

[jadair10]

Here's an email I got from somebody worried about MasterCoin clones:

On Thu, Sep 12, 2013 at 4:28 PM, John ----- wrote:
    Hi JR,
    I just listened to your talk with the bitangles and am concerned with your current protection against being "forked", which is probably the wrong word choice, but provides a nice pun for what could happen with the introduction of alt-MasterCoins.
    Bitcoin would not have the same first mover advantage if an alt-coin was created two months after Bitcoin. The moment someone sees any value to Mastercoin, then they will either consider buying Mastercoin on the open market, or copy the source code and create their own Exodus address.
    Thoughts???
    John -----

MasterCoin is vulnerable to clones, although the problem fades as the MasterCoin project continues to gain momentum.

It's helpful to try to imagine the uphill battle a clone would face. Who would launch it? The number of people who have the reputation to launch something like this isn't huge. Would anybody take them seriously? If you were an investor, would you send money to a cloned project with it's own Exodus Address?

A clone would have to offer some MAJOR innovations, and they would have to move very fast. In all likelihood, we would blatantly steal any innovations we saw in somebody else's clone, which I have said multiple times, in an attempt to discourage people from trying it

JR,
You don't have to mask my name. I only send via email so not to sound like a troll, but more like a subconscious. I do accept tips if you value any of my opinions (a shot out to Adam B. Levine's Project Watershed).

Why do you think that MasterCoin's vulnerability to clones fades as the project gains momentum? I suspect you are right, but... According to BitcoinMagazine, Tonal Bitcoin, the first alt-coin, did not come out for 2 years after Bitcoin. I did not read why Tonal Bitcoin failed. I do not think Mastercoin will be granted anywhere near that amount of time before something nefarious is attempted.

Does anyone else have any thoughts on this or other attack vectors that Mastercoin investors should try to protect themselves against?

[murraypaul]

It's helpful to try to imagine the uphill battle a clone would face. Who would launch it? The number of people who have the reputation to launch something like this isn't huge. Would anybody take them seriously? If you were an investor, would you send money to a cloned project with it's own Exodus Address?

Well, without meaning to be rude, they sent money to you, didn't they?

[dacoinminster]

It's helpful to try to imagine the uphill battle a clone would face. Who would launch it? The number of people who have the reputation to launch something like this isn't huge. Would anybody take them seriously? If you were an investor, would you send money to a cloned project with it's own Exodus Address?

Well, without meaning to be rude, they sent money to you, didn't they?

Yes, but I mean to point out that not many people would have sent me money if I was blatantly copying something that already existed. I think most of the money was raised because people recognized that this project is breaking new ground.

That said, a really compelling competitor is pretty high on the list of things that could go wrong. Our best bet is to keep up the current breakneck speed

[murraypaul]

Yes, once you actually have something working, it becomes easier to defend.
At the moment, all there really is is money and some ideas.
Other people have money, and can just steal the ideas.

[Tachikoma]

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.

Fount the answer in the bitcoind code.

Code:

bool IsStandard(const CScript& scriptPubKey)
{
    vector<valtype> vSolutions;
    txnouttype whichType;
    if (!Solver(scriptPubKey, whichType, vSolutions))
        return false;

    if (whichType == TX_MULTISIG)
    {
        unsigned char m = vSolutions.front()[0];
        unsigned char n = vSolutions.back()[0];
        // Support up to x-of-3 multisig txns as standard
        if (n < 1 || n > 3)
            return false;
        if (m < 1 || m > n)
            return false;
    }

    return whichType != TX_NONSTANDARD;
}

Seems we hit the first bump in the road. I suspect that our publickeys can't be parsed as valid ECDSA coordinates so transaction is not getting processed by nodes on real-net, 'ERROR: CTxMemPool::accept() : nonstandard transaction type'. The reason it worked on testnet is that testnet does not do strict checking before accepting a transaction. I will research to see if there is a way to somehow encode the data in a way that it looks like a valid publickey. I'm trying to figure out why it's not passing the tests.

I would appreciate it if somebody could replicate my tests, perhaps I simply made an error somewhere when crafting my raw transactions.

In order to replicate my tests please create a transaction with one input, two outputs. One ouput with a change address and one with a multisig script with 1 actual publickey, so you can redeem the output, and two data encoded publickeys.

Code:

{"hash":"0e2183cf1d5943c130e9594c44ba3981fe046ceee8851444f4407de6da3232a7","ver":1,"vin_sz":1,"vout_sz":2,"lock_time":0,"size":371,
"in":[{"prev_out":{"hash":"c9fc3f6f8dc828d11eab3196393f13e8c147f835d2d0568df26009aba9617a6e","n":0},"scriptSig":"3046022100ca5d8934c8acf7060e0826e52b55c7e28ae18ab2d22bd9f65b8e44f16856c6c5022100fc69c5d003607aa4114f8eae8026c549aff542ed452ac9af85328ea2b0a292f701 04ea5fbd95738d81e3857067e8156b0887aad60ba2018c21807705c0e5cd4ee9f5187d56e6a827b5c7f54721c46c9c372bdc929a16f3331c3290fdbebc55a7572e"}],
"out":[{"value":"0.23668000","scriptPubKey":"OP_DUP OP_HASH160 e8c6391242865cb288487d938f87d40706381c12 OP_EQUALVERIFY OP_CHECKSIG"},{"value":"0.00006000","scriptPubKey":"1 04c5ac10feed00d99b6571bb42567d43e255b8ace9adf078908e3c4827f954d9188fb464fba3911efc10ac8d1936a088f4682795b40e60aa87b43601339ec76808 045200000001000000020000000000000001000000000000000000000000000000 042600000001000000020000000000000001000000000000000000000000000000 3 OP_CHECKMULTISIG"}]}

Edit: Found an error in my first transaction because I was denoting it as a full publickey while I was actually using compressed ones. This one is valid according to my own tests but bitcoind doesn't like it still. The code responsible for flagging a tx as non-standard can be found here.

Code:

{"hash":"e2fd41377f1fb432e9ebe5fe681a127572f0e157e326598bd217e2117e3104f5","ver":1,"vin_sz":1,"vout_sz":2,"lock_time":0,"size":338,
"in":[{"prev_out":{"hash":"c9fc3f6f8dc828d11eab3196393f13e8c147f835d2d0568df26009aba9617a6e","n":0},"scriptSig":"304502204b08c27d0286660dfde1ee5e79060d57409f3a8eff52e5fddda3c28bf8a9e1b0022100cd5b6591bfcedd6c0cf48a8cece0d1e27baecc723fe1c81d84a7d85d4e88fd8701 04ea5fbd95738d81e3857067e8156b0887aad60ba2018c21807705c0e5cd4ee9f5187d56e6a827b5c7f54721c46c9c372bdc929a16f3331c3290fdbebc55a7572e"}],
"out":[{"value":"0.23668000","scriptPubKey":"OP_DUP OP_HASH160 e8c6391242865cb288487d938f87d40706381c12 OP_EQUALVERIFY OP_CHECKSIG"},{"value":"0.00006000","scriptPubKey":"1 02c5ac10feed00d99b6571bb42567d43e255b8ace9adf078908e3c4827f954d918 025200000001000000020000000000000001000000000000000000000000000000 022600000001000000020000000000000001000000000000000000000000000000 3 OP_CHECKMULTISIG"}]}

[AlexMc]

Would it not be a good idea for dacoinminster to create a Testnet Exodus address?  Surely it should be under his control, or that of the oversight board.

[bytemaster]

Question, when am I going to receive my 3 BTC tip?

[Tachikoma]

I've got some time to work on the multsig again and it seems that there is something wrong with the change address output in my transaction. When removing it I successfully send a multsig transaction using Mastercoin encoded data. Working on how to properly encode Mastercoin data using all 1-out-of-3 transactions now.

[Tachikoma]

There are two types of multisig outputs available at the moment that are useful for us.

• 1-out-of-3
• 1-out-of-2

While technically I can think of no reason to not support any 1-out-of-n transactions, the reference client won't relay or mine these for now. It also seems then if you use uncompressed public keys they are not valid ECDSA points which means that we are stuck with compress public keys for now until somebody finds a way to use uncompressed ones.  

What this means is that we can use a maximum of 128 bytes per multisig-output (two compressed public keys of 64 bytes each). Since the first public key will always be one of our own public keys so we can redeem the output.

Grazcoin suggested we could use the public key to encode the Bitcoin address of the receiver. However I think this might be more trouble then it's worth. If you convert a Bitcoin address to a hex string you would end up with a 68 byte string. Which is just over the length of one public key. It would make parsing the much harder since you are guaranteed to need two ouputs for every transaction.

I would like to suggest that we keep the original spec and use one output for the receiving address.

We also need to rethink the sequence number. Since we always know what the target address is we no longer have to use a sequence number based on the receiving address and since public keys are kept in order in a multisig output (although I would appreciate if somebody could confirm this) we don't need sequences on a per public key basis, we need them per output.

We can just use a integer that counts up from zero, per multisig output, making sequencing much easier in the new situation.

A simple encoded simple send would look like (and forgive my horrible photoshop skills):



A complete tx could look something like this:

Code:

{"hash":"c4551b2e0b8470cc3e03212f823cb9a66580c512aa66ac71a4bfc0a6500dd1eb","ver":1,"vin_sz":1,"vout_sz":2,"lock_time":0,"size":305,
"in":[{"prev_out":{"hash":"c9fc3f6f8dc828d11eab3196393f13e8c147f835d2d0568df26009aba9617a6e","n":0},"scriptSig":"3046022100cb314569b0b194c2e510a101c5a6d9ec5a95a9a8cfc4009bd8f11affbec1b835022100b6e8b08be3b42e037a18f497a595996c40c49e83b114dc360601fdb3526e4d8001 04ea5fbd95738d81e3857067e8156b0887aad60ba2018c21807705c0e5cd4ee9f5187d56e6a827b5c7f54721c46c9c372bdc929a16f3331c3290fdbebc55a7572e"}],
"out":[
{"value":"0.00006000","scriptPubKey":"OP_DUP OP_HASH160 e8c6391242865cb288487d938f87d40706381c12 OP_EQUALVERIFY OP_CHECKSIG"},
{"value":"0.00006000","scriptPubKey":"OP_DUP OP_HASH160 exodusaddressshouldbeinsertedhere OP_EQUALVERIFY OP_CHECKSIG"},
{"value":"0.00006000","scriptPubKey":"1 02c5ac10feed00d99b6571bb42567d43e255b8ace9adf078908e3c4827f954d918 020000000001000000020000000000000001000000000000000000000000000000 2 OP_CHECKMULTISIG"}]}

I appreciate some feedback on this spec before I start writing code

[Ola]

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.

Fount the answer in the bitcoind code.

Code:

bool IsStandard(const CScript& scriptPubKey)
{
    vector<valtype> vSolutions;
    txnouttype whichType;
    if (!Solver(scriptPubKey, whichType, vSolutions))
        return false;

    if (whichType == TX_MULTISIG)
    {
        unsigned char m = vSolutions.front()[0];
        unsigned char n = vSolutions.back()[0];
        // Support up to x-of-3 multisig txns as standard
        if (n < 1 || n > 3)
            return false;
        if (m < 1 || m > n)
            return false;
    }

    return whichType != TX_NONSTANDARD;
}

Ran into this problem also when I was working on an application to try to implement 3 of 4 scheme. I had read somewhere that the maximum is 20 outputs also, but I guess only 3 is supported thus far by miners. Thanks to all you guys pushing this project forward I wish I could dig in and help but I got a full plate. I can be a continuous voice of encouragement for all its worth.



The mastercoin project translated into Chinese on weibo forum is pretty super exciting

The actual amount of the fees is considerably higher for bitcoin/mastercoin distributed exchange than for mastercoin/childcoin (even higher than you are imagining). This is because the seller actually sets a minimum fee which the buyer most pay to lock up the coins from other buyers. The fee goes to the bitcoin miner - it's gone forever. If we don't have something like this, a malicious actor could shut down the whole distributed exchange by spamming fake "intent to buy" messages.

There is a tradeoff here. If the market decides that these fees are too burdensome, there may be room for a centralized exchange website. I expect that the fees will not be too bad, especially compared with the huge risk of trusting an exchange to hold your coins.

If we find that bitcoin miners start spamming intent-to-buy messages to drive up prices, we may need to destroy coins instead. Perhaps the protocol should let the seller choose whether the fee goes to the miner or gets destroyed.

Another possibility would be to have the buyer put some MasterCoins up as collateral that they are making a serious buy offer, but this of course presents a problem for the first-time MasterCoin buyer Smiley

Yet another possibility would be to have the seller put up some additional MasterCoins as collateral that they will do refunds properly. Then the seller could collect the fees directly instead of going to the miners or destroying them. That seems rather complicated though.

I think we should implement the spec as written, and see how it plays out.

All good forethought, I have been thinking about some of those potential problems too. I have several semi planned out solutions if any of some of the problems you mention arise. like the spam problem and centralized solution or the need for a blockchain escrow (integration at Coinsigner). I am bringing some more press to mastercoin this week. Just because I think it is necessary for more people to know about the project.

[milkyman]

There was a lot of critics about the Mastercoin network, in particular due to the many generated un-prunable transactions that are necessary to transmit the data between Mastercoin users.

I have an idea how to solve this problem, but this would require some changes to the protocol. Basically, instead of sending Bitoins to a data address without known private key (which is the current Mastercoin implementation), data can also be transmitted by sending Bitcoins to addresses that other Bicoin users own. To do so, a 'directory' of addresses has to be generated first. Each address can store a few bytes of data - and by sending tiny amounts of Bitcoins to these addresses, the pieces of data can be connected (similar to the current Mastercoin implementation). In this presented implementation, each address can store about 3 bytes. Therefore, to have enough data for a Mastercoin transaction, about 6 - 12 Bitcoin transactions have to be sent.

However, there is an important advantage in this implementation: Users that 'own' these addresses can later send all their earned Bitcoins to a single address. As a result, the millions of addresses are fully spent, and the whole system becomes prunable.

In contrast, in the current Mastercoin system, all the data addresses will remain with 0.00006 BTC stored and have to be saved in the blockchain forever.


Here's the implementation:

First, a global list of length 58^4 = 11316496 and width = 30 is created, and each cell can contain a Bitcoin-address. Let us index these cells with (n,#). The size of the list is a few GB, which is well managable to keep in lots of copies among all Mastercoin users.

Now to the actual idea: The cells (1,#) must contain addresses with the last four characters being -1111. The cells (2,#) must contain addresses -1112, and so on. Finally, the cells (11316496,#) must contain addresses with the last 4 characters -zzzz.

Now, every Bitcoin user that finds a key pair can publish the corresponding address in this list. To this end, he has to prove that he owns the private key of this address, to prevent people 'scamming' the list. Assumed, he found an address ending with -1113, he publishes it and it will be written into cell (3,1). Now let's assume > 29 other users also find addresses ending with -1113 and publish them. Then, all these addresses are alphabetically ordered and written into cells (3,1), (3,2), ... (3,30). Addresses with index > 30 are discarded. Obviously, with time, it becomes harder and harder to 'win' a cell in the list, because an address with low alphabetical index has to be found to kick out another one.

Since it is attractive for users to 'own' cells in the list, the time will come the list is complete, meaning that every cell has an address written in it. Of course, after completing the list, new addresses with lower index can still be published, and the list will be continuously updated.

Last, how can a string of data be transmitted?
First, the data is converted into base58 and chopped into pieces with length 4. Example: 3HZ28xpWUhq4... -> 3HZ2, 8xpW, Uhq4... The addresses (taken from the global directory) to send bitcoins to must have the following properties:

1.) They have to end with -3HZ2, -8xpW, -Uhq4...
2.) The addresses have to be in alphabetic order: (...-3HZ2) < (...-8xpW) < (...-Uhq4) < ...

Point 2 is important to connect the data pieces in the right order. It should be possible to find such an alphabetic order, since there are 30 different available addresses for each piece of data.


So, what you think... Assumed that Bitcoin miners feel threatened by the current Mastercoin implementation and stop to confirm transactions that have an Exodus recipient, this implementation could be a solution, since it harms the Bitcoin network less.


edit: follow-up here: https://bitcointalk.org/index.php?topic=284178.msg3166749#msg3166749

[dacoinminster]

There are two types of multisig outputs available at the moment that are useful for us.

• 1-out-of-3
• 1-out-of-2

While technically I can think of no reason to not support any 1-out-of-n transactions, the reference client won't relay or mine these for now. It also seems then if you use uncompressed public keys they are not valid ECDSA points which means that we are stuck with compress public keys for now until somebody finds a way to use uncompressed ones.  

What this means is that we can use a maximum of 128 bytes per multisig-output (two compressed public keys of 64 bytes each). Since the first public key will always be one of our own public keys so we can redeem the output.

Grazcoin suggested we could use the public key to encode the Bitcoin address of the receiver. However I think this might be more trouble then it's worth. If you convert a Bitcoin address to a hex string you would end up with a 68 byte string. Which is just over the length of one public key. It would make parsing the much harder since you are guaranteed to need two ouputs for every transaction.

I would like to suggest that we keep the original spec and use one output for the receiving address.

We also need to rethink the sequence number. Since we always know what the target address is we no longer have to use a sequence number based on the receiving address and since public keys are kept in order in a multisig output (although I would appreciate if somebody could confirm this) we don't need sequences on a per public key basis, we need them per output.

We can just use a integer that counts up from zero, per multisig output, making sequencing much easier in the new situation.

A simple encoded simple send would look like (and forgive my horrible photoshop skills):



A complete tx could look something like this:

Code:

{"hash":"c4551b2e0b8470cc3e03212f823cb9a66580c512aa66ac71a4bfc0a6500dd1eb","ver":1,"vin_sz":1,"vout_sz":2,"lock_time":0,"size":305,
"in":[{"prev_out":{"hash":"c9fc3f6f8dc828d11eab3196393f13e8c147f835d2d0568df26009aba9617a6e","n":0},"scriptSig":"3046022100cb314569b0b194c2e510a101c5a6d9ec5a95a9a8cfc4009bd8f11affbec1b835022100b6e8b08be3b42e037a18f497a595996c40c49e83b114dc360601fdb3526e4d8001 04ea5fbd95738d81e3857067e8156b0887aad60ba2018c21807705c0e5cd4ee9f5187d56e6a827b5c7f54721c46c9c372bdc929a16f3331c3290fdbebc55a7572e"}],
"out":[
{"value":"0.00006000","scriptPubKey":"OP_DUP OP_HASH160 e8c6391242865cb288487d938f87d40706381c12 OP_EQUALVERIFY OP_CHECKSIG"},
{"value":"0.00006000","scriptPubKey":"OP_DUP OP_HASH160 exodusaddressshouldbeinsertedhere OP_EQUALVERIFY OP_CHECKSIG"},
{"value":"0.00006000","scriptPubKey":"1 02c5ac10feed00d99b6571bb42567d43e255b8ace9adf078908e3c4827f954d918 020000000001000000020000000000000001000000000000000000000000000000 2 OP_CHECKMULTISIG"}]}

I appreciate some feedback on this spec before I start writing code

First of all, I have to admit that I don't understand the inner working of bitcoin well enough yet to tell you if there is a problem with this method. (I'm working on it!) What you propose sounds reasonable to me, although I did receive this PM from a concerned party which seems to indicate there may be some hidden gotchas:

https://bitcointalk.org/index.php?topic=265488.msg3164831#msg3164831

I was reading the above post describing efforts to come up with a new Mastercoin tx scheme; there are a lot of issues with the above, in particular misconceptions about how Bitcoin works, as well as missed opportunities to add censorship resistance. In addition there are potential upcoming changes to Bitcoin that could seriously harm your protocol - changes that may end up getting more support than otherwise because they do exactly that.

I'd can create a complete specification taking all these issues into account, including explaining those issues are exactly and what trade-offs (and alternatives) were involved in coming up with the spec. In short I plan to answer the question "How do you implement a blockchain on top of Bitcoin in a robust, low-resource, and censor-proof way?"

If you are interested let me know and we can work out a set of concrete deliverables: specification document, design rational, and (optionally) example code written in Python with python-bitcoinlib implementing the proposed specification. Any contract would be fixed price, no-cure-no-pay, with a third party approved by both parties acting as escrow in a 2-of-3 multisig transaction deciding if I had in fact completed it successfully. Jeff Garzik has done work along these lines in the past (pybond) and may be able to take on that role.

I'm not revealing the source, since it was a PM, but it was someone who I believe to have a pretty good grasp of the inner workings - better than my own understanding at any rate. It's also someone who is not particularly enthusiastic about this project, so I imagine their price for the work described would be more than we would be willing to pay. I of course invited them to participate in the contest, but I doubt they will.

I suggest we give Tachikoma's method a shot and see what happens. It may be that we have to change our encoding method again if our skeptical friend is right and future bitcoin changes make this method unworkable. Of course, if anybody has a better idea, I'd love to hear it.