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

[Luckybit]

I'm cross posting a question here for more visibility and further discussion. I like Mastercoins and colored coins and think they are the next frontier for crypto-currencies. I hope they both succeed. My main confusion seems to be one of value. Colored coins are essentially priced to be lowest BTC value that the network will confirm. They are just clever movements of BTC. Mastercoins on the other hand have scarcity built in from the exodus address and are traded.

Alt-mastercoins are a real possibility. Traditional alt-currencies needed miner support to thrive. The larger the miner support, the stronger the security. Coins like Mastercoins get their security for free from the BTC network. Because the project is open source anyone can alter the project and create alt-mastercoins. They don't need any miner support at all and instantly will get the same security and features.

Could an Alt-Mastercoin exist that doesn't doesn't need scarcity? One that uses a "generation address" and to enter the alt-mastercoin ecosystem you just send BTC to it? It would make using all of Mastercoin's features dirt cheap with all the advantages of a tradition Mastercoin. Almost a colored coin/mastercoin hybrid.

I'm just wondering if the scarcity is unenforceable as a more free alternative will just take away market share after all the development is done? Although the exodus address was useful for funding development, I'm skeptical it will behave like a traditional crypto-currency and grow to extreme values.

The important thing to note about Mastercoin is momentum. It has the momentum. It has around half a million dollars from crowd funding to provide incentives for developers to actually build it. Owning the coins is like owning stock in Mastercoin and that provides incentive for developers and anyone else to prefer it over Colored Coin.

That is the mistake of Colored Coin. Colored Coin is like GNU Hurd which was the basis for Linux but most people don't know about it because it never had the same kind of developer support, marketing, or incentives to draw people to it.

When all is said and done speculators require incentives to do things. Mastercoin is being designed to attract speculation. Colored Coin is being designed by technical programmer types but since there wont be anything to trade initially and no crowd funding, and no momentum, in my opinion it's going to be left in the dust.

What would you choose as a developer or investor? Would you choose Colored Coin which by design will never be as powerful as Mastercoin? Which does not have momentum? But which I suppose could produce a simple solution to solve a simple technical problem? Or would you go with the momentum? If Colored Coin can capture the momentum and actually do a good job explaining what Colored Coin is then people will use it but it still isn't going to catch on fire like Mastercoin will.

Mastercoin will allow people to make bets and that feature alone will attract a very dedicated following. For example if Mastercoin works as intended we could bet on anything from which team will win the superbowl, to whether or not difficulty will double, to whether or not AsicMiner will be able to achieve 10% of the hash rate and we'd be able to do it in a completely decentralized manner. On top of that anyone who owns Mastercoins now is going to prefer using Mastercoin over Colored Coin because their Mastercoins gain value over time while Colored Coin is at best a platform which no one really has a stake in so who would care about it if everyone were a rational actor?

I know people are not rational and there will be plenty of people who like Colored Coin for ideological reasons. I can even think of some reasons why I might prefer Colored Coin and I own Mastercoins. One reason is that Colored Coin works on altcoin blockchains and Mastercoin works only with Bitcoin. There would be no real benefit to building an alternative fork of Mastercoin on top of Bitcoin if the original Mastercoin works as it should. There will definitely be demand for Colored Coin and perhaps Bitshares and Hops, and the market is going to be big enough where all of them will succeed on different blockchains but on the Bitcoin blockchain we will see Mastercoin dominate because it's basically build into it the blockchain and you cannot really beat that. Colored Coin is not built into the blockchain and that is both it's strength and weakness.

It's a strength because for Litecoin we'd have to use Colored Coin so perhaps they can create a niche around Litecoin and other altcoins. For Bitcoin it's going to either be Mastercoin ,  Bitshares,  or both but I don't think Colored Coin will be able to compete when both Mastercoin and Bitshares have lots of cash to build with and attract speculators with interest, dividends, and other kinds of incentive mechanisms which Colored Coin lacks.

I don't even see how you could build something like Mastercoin without some kind of coin which people would have to buy with Bitcoins. How would you get people to buy something with Bitcoins? People buy Mastercoins because they can be used to create new currencies. Those new currencies require backing in the form of escrow so that the supply can be controlled.

It's not just that Mastercoins are scarce, it's that they are incredibly valuable because they can allow so many possibilities but I suppose you could do some of it with Colored Coin or with some alternative to Mastercoin but it's all about speculation and liquidity,  once Mastercoin gets established its not going to be so simple to just clone it. If it were that simple then Bitcoin would have a difficult time competing with Litecoin because Litecoins are cheaper.

[Peter Todd]

I ran up 20,000 compressed pubkeys from random, then used the last byte rotation method to try and make them valid ECDSA points.  

Seems to have worked for all 20,000 - but my ECDSA point validity testing is being done with code from the Casascius Bitcoin Address Utility and there is a line in there that is making me wonder whether the validatePoint() and other check functions are giving me the whole picture on whether the keys are valid:

Code:

// todo: ensure X and Y are on the curve

You can find the results here.  Tachikoma, when you're back and have a bit of time would you mind taking the '*RAW' file and running some of those pubkeys through your Mastercoin::Util.valid_ecdsa_point? function and see what results you get?  They are the corrected keys with the last byte rotated and all 20,000 are supposed to be valid.

You're on the right track, although be warned that the assumption that modifying a single byte until the X point is on the ECDSA curve is always possible may be invalid; my understanding is that there's no upper-bound known on the gaps between valid points on the curve. Having said that, a decent assumption is, as you've already figured out, they are randomly distributed and about half of all randomly chosen 256-bit integers are valid X points.

Stepping back for a moment, keep in mind that censorship isn't as simple as just "block invalid X points" - censoring any data that looks like it isn't random is quite possible too. I've been told that some pools are already implementing this with rules that block transactions where the data encoded in them is too "compressible" or has too many ASCII characters. What you need to be doing, at minimum, is encrypting the data you are embedding too. As I suggested in the Bitmsg thread a good way to do this is to use a cipher, taking the first CTxIn's prevout.hash + prevout.n + nSequence + nLockTime, hashing all them together to create an initialization vector, and then using that IV with some type of cipher. The resulting encrypted data is just as likely as passing randomness tests as any other pubkey, and doing so doesn't have any real performance impact. (encryption is fast!) Of course, for Mastercoin, this isn't really encryption as encryption, more encryption for the purpose of steganography, but for that purpose it's still effective.

Once we've settled on using encryption we can then make use of it to give a very robust way of ensuring the data in question looks like valid public keys. Essentially what you want is a chained block cipher mode, but one where each PUSHDATA corresponds to one block; another equally valid version is to have a stream cipher where the cipher is re-keyed on every PUSHDATA.

Now lets say we've split our Mastercoin message into a series of PUSHDATA's, forming plaintext P_0 to P_n. We also have our steam cipher E_k for key k, where the k is well known. (could be SHA256('MasterCoin Rocks!'); it's not a secret) We compute the cipher text as C_i = E_k(P_i XOR C_{i-1}), C_0 = IV. (AKA CBC mode)

Now, what what we do is for every C_i we test if it's a valid pubkey, if not we modify P_i until it is, just like you were doing above. Given that ~50% of all X points are valid pubkeys the probability of not being able to find a valid one is 2^-256, essentially impossible, and because the IV is different for every message there's no danger of an attacker finding a specific one that doesn't work for everybody. (by finding some region where a large number of X points are invalid and constructing some kind of asset or something where trading in it is likely to result in messages hitting that case)

AES works on 128-bit blocks, while a compressed pubkey makes for a 256-bit block, so you'll have to make the iterator being modified be at the beginning rather than end of a block. You'll also need a crypto library that can save state, allowing you to back-up two blocks whenever you need to modify the iterator. That said if you put the iterator in the second block, you only need to back-up a single block, and it's rather unlikely for a 128-bit prefix to have no 128-suffixes that are valid pubkeys; you'll probably get away with it, but be warned that I'm not a cryptographer.

A more general "stuff-data-in-the-blockchain" solution would also allow for stuffing in any PUSHDATA, specifying which PUSHDATAs happened to be valid with, say, the low-order bits of the nValue in each CTxOut. In this case you'd want a rule that handles 33-byte PUSHDATA's specially, dropping the first byte and the iterator byte from the plaintext output. I've actually got code that does most of this; I might go publish it as a general purpose library for censorship-resistant embedding of data in the blockchain.

Also in case you guys aren't already aware, currently the IsStandard() rules consider any PUSHDATA from 33 bytes to 120 bytes as standard, and there is nothing checking that pubkeys are valid at all. (including the first byte that determines compressed/uncompressed) For instance my OpenTimestamps timestamper stuffed timestamps into bare CHECKMULTISIG scriptPubKeys by setting the first byte of the pubkey to zero to be sure it could never be spent.(1)

1) Note that because the IV is constructed from a one-way-function, and CBC-mode encryption is also a one-way-function, we can be sure that no attacker could ever come up with a way to get you to create a pubkey for which they knew the secret key for. In theory an XOR stream cipher mode doesn't have this guarantee.


Disclosure: Someone contacted me privately and offered to pay me to help you guys out, although they didn't realize at first how far along you guys were in understanding the problem. I assume they were a Mastercoin investor, but I don't know and they asked to remain anonymous. All the same, I hope this helps.

[dillpicklechips]

There would be no real benefit to building an alternative fork of Mastercoin on top of Bitcoin if the original Mastercoin works as it should.

Once the project is mature, someone just has to clone it and people can have all the features of Mastercoin without having to purchase expensive Mastercoins. It would be a cheaper alternative. That's what I'm getting at. It's not like the BTC vs LTC wars. A competitor immediately has the same security. It's not exactly a whole new crypto-currency like the originals. You are essentially betting on people being loyal to Mastercoin. And why would someone who is about to do an IPO care? Offer shares on the original Mastercoin or use the cheaper alt-mastercoin where the fees are pretty much as cheap as BTC transactions will allow? They should be loyal to a certain software package or website? If a company decides to use the alt-mastercoin, they just direct the investors to another download site so they can begin right away. This alt-mastercoin would probably even have compatibility to manage old mastercoin transactions as well. Wouldn't users flock to the package that manages both? And wouldn't businesses and users use the one that's cheapest?

The more expensive Mastercoin gets the more there is an incentive for a cheaper alternative. This cheaper alternative would be best to wait until Mastercoin is mature. After people have invested time and money. It would totally destroy investors who are heavily invested in Mastercoin as an investment as apposed to an actual tool for trade. That's what worries me. People promising wealth on a tool. That's what it is. It's moving BTC around. The BTC is here to stay. The tools on top will change.

There will definitely be demand for Colored Coin and perhaps Bitshares and Hops, and the market is going to be big enough where all of them will succeed on different blockchains but on the Bitcoin blockchain we will see Mastercoin dominate because it's basically build into it the blockchain and you cannot really beat that. Colored Coin is not built into the blockchain and that is both it's strength and weakness.

Colored coins are built into the blockchain! Just like Mastercoin.

I don't even see how you could build something like Mastercoin without some kind of coin which people would have to buy with Bitcoins. How would you get people to buy something with Bitcoins? People buy Mastercoins because they can be used to create new currencies. Those new currencies require backing in the form of escrow so that the supply can be controlled.

Exact same thing can be done with colored coins. Just define the new currency as 1 satoshi = 100 units new currency residing in address x. Define that no new BTC sent to that address are valid. All completely done without Mastercoin.

once Mastercoin gets established its not going to be so simple to just clone it. If it were that simple then Bitcoin would have a difficult time competing with Litecoin because Litecoins are cheaper.

Miners are a HUGE form of momentum. That's what keeps us on BTC. If we could invent a currency with the same security as BTC instantly, BTC would be threatened. With mastercoin or colored coins that scenario is not only possible but likely. That's why a huge valuation for mastercoins makes no sense.

[zathras]

I don't think we should use invalid ECDSA points if at all possible though as we'd be making it blindingly easy to censor mastercoin; the bitcoin devs could simply enforce ECDSA point validity checking on multisig pubkeys and we'd be in trouble.

This is already being implemented, in fact.  Nothing to do with mastercoin.

Thanks Jeff, this is very helpful to know

I ran up 20,000 compressed pubkeys from random, then used the last byte rotation method to try and make them valid ECDSA points.  

Seems to have worked for all 20,000 - but my ECDSA point validity testing is being done with code from the Casascius Bitcoin Address Utility and there is a line in there that is making me wonder whether the validatePoint() and other check functions are giving me the whole picture on whether the keys are valid:

Code:

// todo: ensure X and Y are on the curve

You can find the results here.  Tachikoma, when you're back and have a bit of time would you mind taking the '*RAW' file and running some of those pubkeys through your Mastercoin::Util.valid_ecdsa_point? function and see what results you get?  They are the corrected keys with the last byte rotated and all 20,000 are supposed to be valid.

You're on the right track, although be warned that the assumption that modifying a single byte until the X point is on the ECDSA curve is always possible may be invalid; my understanding is that there's no upper-bound known on the gaps between valid points on the curve. Having said that, a decent assumption is, as you've already figured out, they are randomly distributed and about half of all randomly chosen 256-bit integers are valid X points.

Stepping back for a moment, keep in mind that censorship isn't as simple as just "block invalid X points" - censoring any data that looks like it isn't random is quite possible too. I've been told that some pools are already implementing this with rules that block transactions where the data encoded in them is too "compressible" or has too many ASCII characters. What you need to be doing, at minimum, is encrypting the data you are embedding too. As I suggested in the Bitmsg thread a good way to do this is to use a cipher, taking the first CTxIn's prevout.hash + prevout.n + nSequence + nLockTime, hashing all them together to create an initialization vector, and then using that IV with some type of cipher. The resulting encrypted data is just as likely as passing randomness tests as any other pubkey, and doing so doesn't have any real performance impact. (encryption is fast!) Of course, for Mastercoin, this isn't really encryption as encryption, more encryption for the purpose of steganography, but for that purpose it's still effective.

Once we've settled on using encryption we can then make use of it to give a very robust way of ensuring the data in question looks like valid public keys. Essentially what you want is a chained block cipher mode, but one where each PUSHDATA corresponds to one block; another equally valid version is to have a stream cipher where the cipher is re-keyed on every PUSHDATA.

Now lets say we've split our Mastercoin message into a series of PUSHDATA's, forming plaintext P_0 to P_n. We also have our steam cipher E_k for key k, where the k is well known. (could be SHA256('MasterCoin Rocks!'); it's not a secret) We compute the cipher text as C_i = E_k(P_i XOR C_{i-1}), C_0 = IV. (AKA CBC mode)

Now, what what we do is for every C_i we test if it's a valid pubkey, if not we modify P_i until it is, just like you were doing above. Given that ~50% of all X points are valid pubkeys the probability of not being able to find a valid one is 2^-256, essentially impossible, and because the IV is different for every message there's no danger of an attacker finding a specific one that doesn't work for everybody. (by finding some region where a large number of X points are invalid and constructing some kind of asset or something where trading in it is likely to result in messages hitting that case)

AES works on 128-bit blocks, while a compressed pubkey makes for a 256-bit block, so you'll have to make the iterator being modified be at the beginning rather than end of a block. You'll also need a crypto library that can save state, allowing you to back-up two blocks whenever you need to modify the iterator. That said if you put the iterator in the second block, you only need to back-up a single block, and it's rather unlikely for a 128-bit prefix to have no 128-suffixes that are valid pubkeys; you'll probably get away with it, but be warned that I'm not a cryptographer.

A more general "stuff-data-in-the-blockchain" solution would also allow for stuffing in any PUSHDATA, specifying which PUSHDATAs happened to be valid with, say, the low-order bits of the nValue in each CTxOut. In this case you'd want a rule that handles 33-byte PUSHDATA's specially, dropping the first byte and the iterator byte from the plaintext output. I've actually got code that does most of this; I might go publish it as a general purpose library for censorship-resistant embedding of data in the blockchain.

Also in case you guys aren't already aware, currently the IsStandard() rules consider any PUSHDATA from 33 bytes to 120 bytes as standard, and there is nothing checking that pubkeys are valid at all. (including the first byte that determines compressed/uncompressed) For instance my OpenTimestamps timestamper stuffed timestamps into bare CHECKMULTISIG scriptPubKeys by setting the first byte of the pubkey to zero to be sure it could never be spent.(1)

1) Note that because the IV is constructed from a one-way-function, and CBC-mode encryption is also a one-way-function, we can be sure that no attacker could ever come up with a way to get you to create a pubkey for which they knew the secret key for. In theory an XOR stream cipher mode doesn't have this guarantee.


Disclosure: Someone contacted me privately and offered to pay me to help you guys out, although they didn't realize at first how far along you guys were in understanding the problem. I assume they were a Mastercoin investor, but I don't know and they asked to remain anonymous. All the same, I hope this helps.

Paid or not Peter this is extremely helpful, thank you (though it will take multiple readings for me to even remotely try to understand it all!). 

JR, without wanting to be badgering I feel this is the most critical issue for mastercoin right now.  How we store data in the blockchain is fundamental and should be locked away as early as possible (and ideally written into the spec).  As you made that the number one goal of the first coding contest I'm guessing you feel the same   Tachikoma's work is great but perhaps we could refine it somewhat - in development we're spitting out invalid ECDSA points in multi-sigs some of the time and as Jeff has raised above, pubkey checking is on the way regardless of mastercoin.

As I've mentioned before I view the miners as our critical issue and if some of the major pools are doing things like looking for obvious compressable/text data as Peter notes, perhaps some further investigation into steganography (an apt analogy I think) would be in order - obfuscating the data we're storing in the pubkey (IMO) seems quite achievable and spotting our padding ("000000000" etc) isn't going to be hard.

Thoughts?

[maxmint]

Masterchest.info seems to be missing the 2 most recent Mastercoin transactions (each 50 MSC).
Both mastercoin-explorer.com and masterchain.info are showing these transactions.

I guess that's just a delay with masterchest.info and not a problem with the actual transactions, right?

[Bitoy]

Maybe we can just do random padding (instead of all 0 paddings).  Then just test if its valid.

Another option is to ask bitcoin foundation to allow msc data transaction.   ( like telcos buying cell phone frequency from the government.)

[HammerFist]

When all is said and done speculators require incentives to do things. Mastercoin is being designed to attract speculation. Colored Coin is being designed by technical programmer types but since there wont be anything to trade initially and no crowd funding, and no momentum, in my opinion it's going to be left in the dust.

What would you choose as a developer or investor?

This implicitly suggests that Mastercoin is not being designed by technical programmer types.  I claim BS.  That Mastercoin has brilliant funding - doesn't exclude the possibility that great programmers will use excellent technique in its development.  Why don't those colored coin proponents just get on the train.  Colored Coin is dead.  Now just move the talent that was unfunded at colored coin over to help the Mastercoin project.

What is the issue here?  Why do colored coin guys have to be such haters?

[zathras]

Masterchest.info seems to be missing the 2 most recent Mastercoin transactions (each 50 MSC).
Both mastercoin-explorer.com and masterchain.info are showing these transactions.

I guess that's just a delay with masterchest.info and not a problem with the actual transactions, right?

Sorry guys, should be all resolved now (and yes they look like valid transactions).

Masterchest-engine threw an exception that wasn't trapped so it was waiting for acknowledgement.  Root cause; running the whole thing (SQL 2008R2 included) on a t1 micro instance on AWS (~600MB RAM, yes I was asking a bit much ).  I'll clean up the exception handling in that routine and bring it down and clone to a more powerful instance when I have a mo.

Maybe we can just do random padding (instead of all 0 paddings).  Then just test if its valid.

Padding is just the most obvious example   I'd been focusing so heavily on making the keys ECDSA valid points I hadn't considered other forms of censorship & if Peter is correct about what the pools are doing, then ideally we obfuscate the whole key so it's indistinguishable from any other.

Another option is to ask bitcoin foundation to allow msc data transaction.    like telcos buying cell phone frequency for the government.

JR has stated a core goal of remaining censorship resistant which necessitates a design that does not require any permission/allowances (though of course it would be fantastic to have their support).  As for the 'buying' aspect, we're paying fees just like any other user of the blockchain - we'd like a miner to include our transaction and we thus pay them a fee to do so.  As reward halving decreases the amount of bitcoins mined per block, transaction fees are going to be an increasing part of a bitcoin miner's revenue stream so more transactions for bitcoin is not necessarily a bad thing if done the right way (which is exactly what we're trying to do).

Thanks!

[HammerFist]

we're paying fees just like any other user of the blockchain - we'd like a miner to include our transaction and we thus pay them a fee to do so. 

Exactly.  I am baffled as to why the bitcoin foundation wants to limit use.  Who cares if Mastercoin ends up doing a million transactions per second - we pay the same as anyone else.  Are they admitting that the blockchain cannot support high volume use? - then bitcoin is doomed. 

[HammerFist]

You're on the right track, although be warned...
All the same, I hope this helps.

Wow!  This guy is huge.  We need him on board. 

Peter - if you give me a MSC address I'll kick down 50 MSC just for that very useful post.  Further, I'll challenge other MSCers to do the same next time we get this kind of excellent feedback which certainly makes this project go down a better path.

[Luckybit]

Once the project is mature, someone just has to clone it and people can have all the features of Mastercoin without having to purchase expensive Mastercoins.

The same could be said about Bitcoin. The momentum means businesses will be built up around Mastercoin and everyone will be looking at what Mastercoin is doing. Free isn't as good as profitable and people want to make money. Bitcoins are expensive but people buy them as an investment because the price continues to rise up. You could release a version of Bitcoins now and start over but all the businesses built around it and all the current Bitcoin stakeholders aren't going to put their support into that.

It would be a cheaper alternative. That's what I'm getting at. It's not like the BTC vs LTC wars. A competitor immediately has the same security. It's not exactly a whole new crypto-currency like the originals. You are essentially betting on people being loyal to Mastercoin.

I'm betting that if you own Mastercoins and they are rising in price you're going to stick to it. So yeah you'll be loyal if you own Mastercoins because it's like owning stock. New people might not care about owning Mastercoins but the latest software updates will go to Mastercoin first and whatever copies it will always be playing catch up.

I'm not saying its impossible. In theory a large corporation could try to create a corporate Mastercoin and launch it as a free alternative but other than that I don't see how you can get the momentum without paying people to develop it. You're saying a bunch of programmers developing it for free will be as motivated as people who work on Mastercoin for a living. If you got a lot of Mastercoins and you don't have to worry about money anymore you're going to do a better job programming than a part time hobbyist. My argument is that momentum will build to a point where the people who are established early in Mastercoin will never have to work doing anything but improve Mastercoin. I'm betting that those people will be loyal and will be dedicated to keeping the value of the Mastercoin stock high. I consider the Mastercoins as a type of stock. I also think you will need some kind of coin whether it be free or not, and I don't see why anyone would switch to a new coin due to it being free for the reason that a new coin if its free cannot be seen as an asset. An asset is something you can purchase and watch its value increase over time, while if the coin were free it's not really an investment so how would it attract speculators in the first place?

The reason is Mastercoins are something people can use to track the value of the Mastercoin project. The ability to attract the value of the project has value to speculators. If Mastercoin didn't have a price and it were built up using Colored Coin or some alternative we would just have a user defined currency or smart property created within Colored Coin called "Mastercoin" which people would be trading to determine the true value of the Mastercoin project. Speculators are going to want to speculate on that regardless. So even if a new competitor or Colored Coin came about we would still have people trading Mastercoins within Colored Coin or within that competitor product. I don't know that the price would be as high with competition if the competition were able to keep up with the development but someone would for sure create a way to track the value of the project because that is the reason why these technologies are built.

Update 9/8/2013: Items 6-8 above were added in response to the “bytemaster/d’aniel attack”, which
becomes possible once malicious actors are able to short these currencies. The attack only works on
currencies with underfunded escrows, and consists of a malicious actor creating a competing GoldCoin
with a healthy escrow fund, which the market would presumably prefer over the GoldCoin with the
unhealthy escrow fund. The malicious actor could then profit by shorting the unhealthy GoldCoin until
people panicked and fled for the healthy version. More information about unhealthy escrow funds can
be found in the next section.

Unhealthy Escrow Funds
What if the price of MasterCoins falls 95%, and the value of the escrow fund is now only 5% of the target
value of all GoldCoins? Using the battery analogy, this escrow fund now has less “charge” and is
therefore less capable of intervening to correct prices.
If the currency creator had set the minimum escrow size to 100% the escrow fund would never get into
this situation because it would simply dissolve and pay out to currency stakeholders as soon as the
escrow fund value dropped to parity, with zero or minimal losses. For currencies which are set up to
allow continued operation once unhealthy, the protocol responds by adjusting the aggression factor
accordingly. In the example of GoldCoins backed by only 5% given above, the 1% aggression factor
would be multiplied by 5% to get 0.05%, meaning that the adjustments will be of much smaller
magnitude, and it will take a lot longer to get to 100% aggression.
Note that escrow funds holding funds worth more than their currency do not get more aggressive. That
is, if the GoldCoins escrow fund is worth twice the value of all GoldCoins in existence, the aggression
factor is still 1%.

For instance within The MastercoinClone you could create a bet as to what you think the price of the original Mastercoin will be within 6 months. You could speculate on that and back it with empty MastercoinClones but I see problems with having it be empty value. I think it's better if everything in the system has a price/value, especially when you're trying to create escrows. Nothing would stop a clone of the clone from doing the same thing to TheMastercoinClone and then creating prediction bets on the price of the original Mastercoin and the Mastercoinclone. This could go on forever until the price of all clones and the original reach 0. So that might be a legitimate threat if it went like that because then the clone makers would be able to profit from a race to 0. Ultimately it would just be a transfer of value from the original Mastercoin into a new group of speculators betting that Mastercoins will be worth 0 Bitcoins.

The most important feature of MasterCoins is the built-in support for users to create their own
currencies out of existing MasterCoins. For the purposes of demonstrating how user currencies will
work, we will use an example currency called “GoldCoins”, which are intended to track the value of one
ounce of gold, and which may be stored, transferred, bought, and sold similarly to MasterCoins.
Stability Concept
So how do we drive the value of these GoldCoins to their target value, when demand for them may
surge and decline? The price of GoldCoins is decided by the balance of supply and demand. Since we
can’t control the demand for GoldCoins, we must control the supply. The key to accomplishing this is to
use an escrow fund which holds MasterCoins

The escrow fund operates like a battery on the power grid, charging when there is excess energy then
discharging where there isn't enough. When there are too few GoldCoins (GoldCoin price is too high),
the escrow fund releases new GoldCoins, and the escrow-battery “charges” by holding MasterCoins in
escrow. When there are too many GoldCoins (GoldCoin price is too low), the escrow fund purchases
some of the excess GoldCoins, thereby “discharging” the escrow-battery as it releases the stored
MasterCoins.

Can you tell me how you could create an escrow with a coin which isn't backed by anything of value? Mastercoins are backed by Bitcoins but not only by Bitcoins. The value of the Mastercoins allow you to create an escrow and to my understanding the whole system works around that, I don't even know if you can do it if it were free.

And why would someone who is about to do an IPO care? Offer shares on the original Mastercoin or use the cheaper alt-mastercoin where the fees are pretty much as cheap as BTC transactions will allow?  

For an IPO maybe you're right but thats not all Mastercoin can do. Colored Coin can do that and you have a point. Mastercoin can let you create a bitUSD. How do you create a bitUSD if it doesn't have something to give it value?

If Mastercoins have no value, if they are empty, how would we use them to create something which has value like bitUSD?
While I don't fully understand Mastercoin yet, it seems to make sense that in order to create value you must have something of equal or of greater value. Value doesn't just come from thin air. So Mastercoins have value and you can put that value behind anything and create an altcoin but if it didn't have value then how do you guarantee that the usercoins or altcoins created have value and how do you manage the price? bitUSD has to track exactly to the price of USD which means that it has a fairly precise value. So just like a scale something backing it has to precisely track the real world value of USD and I don't know how you do that without having something behind it. I don't see how Mastercoin could be completely free because some Bitcoins will have to be used to give it value at some point but I could be wrong.

They should be loyal to a certain software package or website? If a company decides to use the alt-mastercoin, they just direct the investors to another download site so they can begin right away. This alt-mastercoin would probably even have compatibility to manage old mastercoin transactions as well. Wouldn't users flock to the package that manages both? And wouldn't businesses and users use the one that's cheapest?

Provide more detail on how escrow can be done with a completely free Mastercoin.
Mastercoin allows users to create user defined currencies by using Mastercoins as escrow. This means value isn't created or destroyed as far as I can tell. It's transferred from the Mastercoin into the user defined coin. How do you do that if Mastercoins are completely free and anyone can have as many as they want?

The more expensive Mastercoin gets the more there is an incentive for a cheaper alternative. This cheaper alternative would be best to wait until Mastercoin is mature. After people have invested time and money. It would totally destroy investors who are heavily invested in Mastercoin as an investment as apposed to an actual tool for trade. That's what worries me. People promising wealth on a tool. That's what it is. It's moving BTC around. The BTC is here to stay. The tools on top will change.

It wont get expensive. People will just use less of them. The question is what makes you think it can be done completely for free? How do you do escrow or back a currency for free? If you're creating goldcoin how can you do that with a free Mastercoin? If it's possible to do that then you have a point.

Colored coins are built into the blockchain! Just like Mastercoin.

That isn't true. Colored Coins are not exclusively built into the Bitcoin blockchain and do not work the same way. Which implementation of Colored Coins are you talking about?

Exact same thing can be done with colored coins. Just define the new currency as 1 satoshi = 100 units new currency residing in address x. Define that no new BTC sent to that address are valid. All completely done without Mastercoin.

If just 1 satoshi were used then it would definitely be cheaper than Mastercoin. But would it be better?
Let's say you want to make a bet, how do you make a bet if you don't risk anything? How exactly will those user defined currencies which start out like that gain any value? Explain to me where the value would come from if not backed by something else? If people don't have to spend any valuable Mastercoins to give value to it then where does the value come from?

Explain your system in detail please.

Miners are a HUGE form of momentum. That's what keeps us on BTC. If we could invent a currency with the same security as BTC instantly, BTC would be threatened. With mastercoin or colored coins that scenario is not only possible but likely. That's why a huge valuation for mastercoins makes no sense.

Miners provided security but Bitcoin mining isn't as decentralized as Litecoin. It's not the only reason people stay on the Bitcoin blockchain. People are using Bitcoin because more businesses accept Bitcoin whether Bitcoin is better or not.

The argument you're making is that a stream of Mastercoin clones will come along and reduce the value of Mastercoin down to nothing. The clone, and the clone of the clone, and the clone of that clone, etc. The bigger problem would be whether or not the Bitcoin blockchain could handle all that traffic.

[Peter Todd]

Another option is to ask bitcoin foundation to allow msc data transaction.    like telcos buying cell phone frequency for the government.

JR has stated a core goal of remaining censorship resistant which necessitates a design that does not require any permission/allowances (though of course it would be fantastic to have their support).  As for the 'buying' aspect, we're paying fees just like any other user of the blockchain - we'd like a miner to include our transaction and we thus pay them a fee to do so.  As reward halving decreases the amount of bitcoins mined per block, transaction fees are going to be an increasing part of a bitcoin miner's revenue stream so more transactions for bitcoin is not necessarily a bad thing if done the right way (which is exactly what we're trying to do).

Keep in mind that the Bitcoin Foundation does not control Bitcoin, right now at least. As an example at least %8.5 of the hashing power right now, Eligius, won't accept transactions to SatoshiDice or the  "correct horse battery staple" address. Eligius also uses non-standard fee rules, and will mine transactions with output values less than the dust limit. BTC Guild, 27% of the hashing power, also ignores the dust rules. I take advantage of this for timestamping stuff all the time, and there are enough nodes and miners out there that ignore the dust rules that all I have to do to get those transactions mined is disable the IsDust() test on my client.

The Bitcoin Foundation "officially" allowing mastercoin transaction may or may not have any effect at all on whether or not you can get them mined. Most likely IMO is you'll always be able to get them mined, regardless of what form they take, although it might take awhile and you may have to pay a fair bit to do so. It's possible that won't be true in the future though: Gavin has advocated that miners only accept blocks that contain nearly only transactions that they themselves would have mined, and further more contain nearly only the transactions that they were going to mine themselves. The logic behind this works on a number of levels: for instance if you only mine blocks that contain the transactions you yourself would have mined, you can make zero-conf transactions safer because miners who mine double-spends (even accidentally due to an attacker tricking them into doing it) will get their blocks rejected. Another aspect is how it can help shut out miners who mine "too few" transactions in their blocks, maybe because they have a low-speed internet connection and can only afford to mine the highest profitability, highest fee transactions. It also makes it easier to impose top-down rules on miners, perhaps because some transactions are considered "spam" or there's a desire to impose blacklists. (remember how you only need support of 50% of the hashing power to impose rules via block discouragement; right now that's BTC Guild, GHash.IO, and Eligius having control) Gavin also said he wants a very fast 6-9 month cycle of deliberate hard-forks, something that would very much centralize control around the Bitcoin Foundation.

More immediate inconveniences are how bare CHECKMULTISIG scriptPubKeys may be made non-standard in the near future in the reference client. (I've advocated this myself) I think you can say most of the dev team supports the idea to keep data out of the UTXO set, and make it more expensive to get data into the blockchain at all. Gavin and Mike don't like that idea last I heard, but don't assume their opinion actually counts for much. You should support stuffing Mastercoin data in P2SH transactions. (by that I mean the scriptSig spending a P2SH txout) Doing this also makes you immune to gmaxwell's P2SH^2 idea, and the overhead isn't big.

Speaking of, so a good way to think about this stuff is that there's always some cost to put data in the blockchain. Now if you are doing a standard transaction, the way Bitcoin intended, your cost is FeePerKB * 1. If you're doing something else, like a MasterCoin transaction where you need to go to a bunch of effort to encode it, your cost is FeePerKB * k. The overhead associated with, say, stuffing data into bare CHECKMULTISIG's makes your k higher, so you're basically paying more per transaction that if you were doing plain-old Bitcoin transactions.

Colored Coins have a real advantage here, because they are standard transactions and the data they need to represent matches that model perfectly. MasterCoin transactions on the other hand aren't, so you're paying a premium. Fortunately they're likely to be more valuable per transaction, so the premium is affordable, but you don't want to make a standard that isn't flexible.

Colored Coins have another big advantage too: they aren't global. In MasterCoin every transaction must be visible to every other MasterCoin user, which conversely means that every transaction is identifiable, and thus censorable with blacklists. Colored Coins are independent of each other, so those blacklists need to include up-to-date genesis transactions for every colored coin out there, and logic to follow them. Even worse is that some colored coin schemes hide what transactions are involved completely, preventing you from knowing anything at all unless you were a participant in the particular transaction. Now if you used a commit + reveal scheme, Mastercoin could be more censorship resistant, but there's a lot of issues with making such schemes work. (I'll try to talk about them in my paper that killerstorm mentioned eventually)

Finally, one last point: scalability. It'd be really convenient for some people in this community if we could set transaction costs to "reasonable" level - perhaps a penny each - through top-down control (like I mentioned above) regardless of what transaction volume Bitcoin sees. The problem with this idea is there will always be limits on maximum transaction volume due to the limits of technology, even without a blocksize limit. Stuff like Mastercoin, Colored Coins and timestamping, is really scary to these people because it involves use-cases with transactions that can easily be far more valuable to their users than standard payment-oriented transactions; people routinely pay $20 per trade brokerage fees when trading stocks without blinking an eye. Given that blockchain space is a market, it's easy to see how these very high value uses could crowd out the low-value payments that some people in this community are more interested in. Heck, just look at how the Multibit and Android Bitcoin wallet developers refuse to even add the ability to set transaction fees based on the idea that it's ridiculous to have people "fight" for block space, and that miners should just create bigger blocks. (even at the expense of their own profitability) Every application for the Bitcoin system that isn't payment-oriented is a threat to these people unfortunately, which is probably why they push so hard for things like insecure merge-mining systems.

[Peter Todd]

You're on the right track, although be warned...
All the same, I hope this helps.

Wow!  This guy is huge.  We need him on board. 

Peter - if you give me a MSC address I'll kick down 50 MSC just for that very useful post.  Further, I'll challenge other MSCers to do the same next time we get this kind of excellent feedback which certainly makes this project go down a better path.

Thanks for the offer, but part of the deal with that anonymous patron was that I remain un-invested in Mastercoin and thus preserve my independence. It's the same thing I did with Litecoin for their 0.8 audit: I didn't accept any Litecoins up front as payment until my audit was complete on the basis that if I found something bad, the readers of the audit would want me to have no incentives not to reveal the problems.

[zathras]

Another option is to ask bitcoin foundation to allow msc data transaction.    like telcos buying cell phone frequency for the government.

JR has stated a core goal of remaining censorship resistant which necessitates a design that does not require any permission/allowances (though of course it would be fantastic to have their support).  As for the 'buying' aspect, we're paying fees just like any other user of the blockchain - we'd like a miner to include our transaction and we thus pay them a fee to do so.  As reward halving decreases the amount of bitcoins mined per block, transaction fees are going to be an increasing part of a bitcoin miner's revenue stream so more transactions for bitcoin is not necessarily a bad thing if done the right way (which is exactly what we're trying to do).

Keep in mind that the Bitcoin Foundation does not control Bitcoin, right now at least. As an example at least %8.5 of the hashing power right now, Eligius, won't accept transactions to SatoshiDice or the  "correct horse battery staple" address. Eligius also uses non-standard fee rules, and will mine transactions with output values less than the dust limit. BTC Guild, 27% of the hashing power, also ignores the dust rules. I take advantage of this for timestamping stuff all the time, and there are enough nodes and miners out there that ignore the dust rules that all I have to do to get those transactions mined is disable the IsDust() test on my client.

The Bitcoin Foundation "officially" allowing mastercoin transaction may or may not have any effect at all on whether or not you can get them mined. Most likely IMO is you'll always be able to get them mined, regardless of what form they take, although it might take awhile and you may have to pay a fair bit to do so. It's possible that won't be true in the future though: Gavin has advocated that miners only accept blocks that contain nearly only transactions that they themselves would have mined, and further more contain nearly only the transactions that they were going to mine themselves. The logic behind this works on a number of levels: for instance if you only mine blocks that contain the transactions you yourself would have mined, you can make zero-conf transactions safer because miners who mine double-spends (even accidentally due to an attacker tricking them into doing it) will get their blocks rejected. Another aspect is how it can help shut out miners who mine "too few" transactions in their blocks, maybe because they have a low-speed internet connection and can only afford to mine the highest profitability, highest fee transactions. It also makes it easier to impose top-down rules on miners, perhaps because some transactions are considered "spam" or there's a desire to impose blacklists. (remember how you only need support of 50% of the hashing power to impose rules via block discouragement; right now that's BTC Guild, GHash.IO, and Eligius having control) Gavin also said he wants a very fast 6-9 month cycle of deliberate hard-forks, something that would very much centralize control around the Bitcoin Foundation.

More immediate inconveniences are how bare CHECKMULTISIG scriptPubKeys may be made non-standard in the near future in the reference client. (I've advocated this myself) I think you can say most of the dev team supports the idea to keep data out of the UTXO set, and make it more expensive to get data into the blockchain at all. Gavin and Mike don't like that idea last I heard, but don't assume their opinion actually counts for much. You should support stuffing Mastercoin data in P2SH transactions. (by that I mean the scriptSig spending a P2SH txout) Doing this also makes you immune to gmaxwell's P2SH^2 idea, and the overhead isn't big.

Speaking of, so a good way to think about this stuff is that there's always some cost to put data in the blockchain. Now if you are doing a standard transaction, the way Bitcoin intended, your cost is FeePerKB * 1. If you're doing something else, like a MasterCoin transaction where you need to go to a bunch of effort to encode it, your cost is FeePerKB * k. The overhead associated with, say, stuffing data into bare CHECKMULTISIG's makes your k higher, so you're basically paying more per transaction that if you were doing plain-old Bitcoin transactions.

Colored Coins have a real advantage here, because they are standard transactions and the data they need to represent matches that model perfectly. MasterCoin transactions on the other hand aren't, so you're paying a premium. Fortunately they're likely to be more valuable per transaction, so the premium is affordable, but you don't want to make a standard that isn't flexible.

Colored Coins have another big advantage too: they aren't global. In MasterCoin every transaction must be visible to every other MasterCoin user, which conversely means that every transaction is identifiable, and thus censorable with blacklists. Colored Coins are independent of each other, so those blacklists need to include up-to-date genesis transactions for every colored coin out there, and logic to follow them. Even worse is that some colored coin schemes hide what transactions are involved completely, preventing you from knowing anything at all unless you were a participant in the particular transaction. Now if you used a commit + reveal scheme, Mastercoin could be more censorship resistant, but there's a lot of issues with making such schemes work. (I'll try to talk about them in my paper that killerstorm mentioned eventually)

Finally, one last point: scalability. It'd be really convenient for some people in this community if we could set transaction costs to "reasonable" level - perhaps a penny each - through top-down control (like I mentioned above) regardless of what transaction volume Bitcoin sees. The problem with this idea is there will always be limits on maximum transaction volume due to the limits of technology, even without a blocksize limit. Stuff like Mastercoin, Colored Coins and timestamping, is really scary to these people because it involves use-cases with transactions that can easily be far more valuable to their users than standard payment-oriented transactions; people routinely pay $20 per trade brokerage fees when trading stocks without blinking an eye. Given that blockchain space is a market, it's easy to see how these very high value uses could crowd out the low-value payments that some people in this community are more interested in. Heck, just look at how the Multibit and Android Bitcoin wallet developers refuse to even add the ability to set transaction fees based on the idea that it's ridiculous to have people "fight" for block space, and that miners should just create bigger blocks. (even at the expense of their own profitability) Every application for the Bitcoin system that isn't payment-oriented is a threat to these people unfortunately, which is probably why they push so hard for things like insecure merge-mining systems.

Again, thanks for the additional information.  Reflecting on your suggestions for hiding the data inside a valid looking public key, playing devils advocate for a moment any approach we use must be decode-able by other mastercoin clients and thus can be decoded by any mining entity (such as a mining pool) who actively wished to identify and block mastercoin transactions regardless of the obfuscation steps we took.  Simply put, because mastercoin transactions are public that would suggest they can't be completely hidden from miners.

If mastercoin was more of a 1-to-1 kind of system then I can see the value of a steganography-like approach as no-one other than the involved parties needs to see the data.  But with a system with a public ledger like mastercoin, inherently transactions have to be decode-able by anyone - and that of course includes miners.

If that reasoning is sound, then is there value in encryption/additional obfuscation past a valid ECDSA key that looks random? 

[Peter Todd]

Again, thanks for the additional information.  Reflecting on your suggestions for hiding the data inside a valid looking public key, playing devils advocate for a moment any approach we use must be decode-able by other mastercoin clients and thus can be decoded by any mining entity (such as a mining pool) who actively wished to identify and block mastercoin transactions regardless of the obfuscation steps we took.  Simply put, because mastercoin transactions are public that would suggest they can't be completely hidden from miners.

If mastercoin was more of a 1-to-1 kind of system then I can see the value of a steganography-like approach as no-one other than the involved parties needs to see the data.  But with a system with a public ledger like mastercoin, inherently transactions have to be decode-able by anyone - and that of course includes miners.

If that reasoning is sound, then is there value in encryption/additional obfuscation past a valid ECDSA key that looks random? 

Well, the problem is you want blocking Mastercoin to be something that has to be done explicitly, through blacklists; that's politically more difficult to do than measures that are aimed at parasitic consensus systems in general.

One issue I forgot to mention is that address re-use may be discouraged in the future - transactions that pay scriptPubKeys that have been used recently might be discouraged. That every Mastercoin transaction pays to the 1exodus address is a problem. (though it does mean you can make an SPV client for mastercoin, at least SPV at the bitcoin level)

[murraypaul]

Once the project is mature, someone just has to clone it and people can have all the features of Mastercoin without having to purchase expensive Mastercoins.

The same could be said about Bitcoin. The momentum means businesses will be built up around Mastercoin and everyone will be looking at what Mastercoin is doing. Free isn't as good as profitable and people want to make money. Bitcoins are expensive but people buy them as an investment because the price continues to rise up. You could release a version of Bitcoins now and start over but all the businesses built around it and all the current Bitcoin stakeholders aren't going to put their support into that.

The same isn't true of a Bitcoin replacement, as you would start off with no miner or pool support, and would have to offer some sort of incentive to have people mine your coins instead of Bitcoin.
Mastercoin is sitting on the Bitcoin blockchain, with no infrastructure of its own.
That could be cloned instantly, and have exactly the same infrastructure support.

[Bitoy]

Another option is to ask bitcoin foundation to allow msc data transaction.    like telcos buying cell phone frequency from the government.

JR has stated a core goal of remaining censorship resistant which necessitates a design that does not require any permission/allowances (though of course it would be fantastic to have their support).  As for the 'buying' aspect, we're paying fees just like any other user of the blockchain - we'd like a miner to include our transaction and we thus pay them a fee to do so.  As reward halving decreases the amount of bitcoins mined per block, transaction fees are going to be an increasing part of a bitcoin miner's revenue stream so more transactions for bitcoin is not necessarily a bad thing if done the right way (which is exactly what we're trying to do).

Thanks!

Maybe we can pay a higher mining fee ( on msc transactions) so that they will include it

[Luckybit]

Once the project is mature, someone just has to clone it and people can have all the features of Mastercoin without having to purchase expensive Mastercoins.

The same could be said about Bitcoin. The momentum means businesses will be built up around Mastercoin and everyone will be looking at what Mastercoin is doing. Free isn't as good as profitable and people want to make money. Bitcoins are expensive but people buy them as an investment because the price continues to rise up. You could release a version of Bitcoins now and start over but all the businesses built around it and all the current Bitcoin stakeholders aren't going to put their support into that.

The same isn't true of a Bitcoin replacement, as you would start off with no miner or pool support, and would have to offer some sort of incentive to have people mine your coins instead of Bitcoin.
Mastercoin is sitting on the Bitcoin blockchain, with no infrastructure of its own.
That could be cloned instantly, and have exactly the same infrastructure support.

My argument is it would not have the same momentum. Infrastructure without incentive or momentum wont be sustainable.

Mastercoin's crowdfunding provides incentive to develop it. Mastercoins are like stock/shares in the Mastercoin project allowing us to track the value of the Mastercoin protocol to the community and discover a price.

The issue of how to encode Mastercoin in the blockchain, blockchain bloat from altcoins trying to use the Mastercoin model, those are real issues. But I don't think Mastercoin owners will ever deem their Mastercoins worthless and I don't think Mastercoins are worthless because they have a function.

The criticism was that Mastercoin prices could fall through the floor but if that happened how would you have an escrow? So if someone released a Masterclone with free Mastercoins which do not have to be purchased how would the escrow work? What would back the goldcoins so that the supply of the gold coins can be precisely controlled?

If there are too many goldcoins they get destroyed. If there are too few goldcoins they get created. The escrow is the source of value for gold coins and the escrow gets it's source of value from Mastercoin which gets it's source of value from whatever people used to purchase the Mastercoins or whatever work people did to earn them. So if you made a clone system where you have infinite Mastercoins and they are distributed for free then how would you use those worthless Mastercoins as a source of value for the escrow? I don't understand how it would be possible.

I do think Mastercoins might be highly volatile but I don't see how it could easily fall below 1BTC per Mastercoin. I don't see how something built on top of Bitcoin and can hold the value of Bitcoin, Litecoin, Primecoin, USD or anything else, and which has far more functionality and potential market cap than BTC could be worth less than 1 BTC. The only way would be if the clone of Mastercoin somehow could duplicate the escrow system with empty Masterclones and I don't know if that is possible.

Basically why would I trust a currency created with an escrow of infinitely divisible valueless coins when Mastercoins have a price and I know exactly how much they are worth and that tells me how much it weighs on the value scale. So 1 Mastercoin is equal to 4 gold bars? Now the escrow system can work. Just like if you had a vault with fake gold in it you could probably fool a bunch of people into trusting it but if you know the original Mastercoin vault has real gold in it why would you choose the vault you know has fake gold? Because it's cheaper?

It's almost like going off the gold standard. Mastercoin represents the gold standard because it's based on real value that developers, investors and the community as a whole put into it. The Masterclone would just be some copy without being backed by anything of real value so it could be considered cheap money but it doesn't seem very intuitive to me why people would choose that.

[Tachikoma]

A lot happened while I was gone! Loads to read up on so I might be premature with my responses.

I am not against making the public keys look as much like 'real' keys as possible but in the end I wonder how much it will really help. If pools want to stop mining Mastercoin then can do so by simply ignoring any transactions that include a Mastercoin Exodus output. They wouldn't even need to check the public key.

However since we want to create valid public keys anyway we can just as well use Retep's proposed method instead of brute-forcing our way to a valid key.

With the message from jgarzik I think we should formalise the requirements for public keys and require that they are valid ECDSA points. This means that the following transactions would become invalid.

Code:

9db8fb5171b586baa73754720644e3ad600f82dfa336985e9d8eafe39ead065d     
da71fcbeb3b9b2e36b497bf31c27f4a5f8ced772762a9484164087370ff5e47a
826c4eb686b7c8b31acb2cb6f62e3397ba881b989fe71d2a46f2debdecabd7de
a54e950cfd3793668922b40be9d46005dd7fdee84f0f6c6ab8c4c372b2e06d32
72b135a3d97a478b4c3dc8766c39e9f758ad7b81a34f8ed092affcf603ff39bb
7e57ac70cc0a1a4eacce92dfff9a1362a017433bb1d1167d654325dce76d9b7c
3e3d345974ab7764830498694fa10ef2a9b688a4694556ee5a36d520fb5ff3ca
6b8a15f5dcc2f7a463a795ab105abcadf442669a96ddb20021b383523155196d      
dc87d24a1d5c490525dcb6162165c95cf4b1fbbb8bfcacb649962270dfd3d3f1
fc442e22d1d54333cd73a006195bef85a004bf3ee8b896a090c1f8f910268e7c
7fd9422f4ba0ac216581fa4f2d5f1f10575e1596691f5ac20a958ac1a6c07284

I think it's safe to retroactively make these changes since I believe these are all test transactions made by developers.

Before continuing overall development we should probably let J.R. make some decisions how we want to continue; brute-force a valid looking key based on the current spec or rewrite it to use Retep's system.  

@Tachikoma: There's an issue with this transaction on mastercoin-explorer:
http://mastercoin-explorer.com/transactions/afa3193c43bdc0554554f1a1fae2428f30dd0bfdea28627f178a49281455d79a
It does not show the correct "To" address.

It looks like masterchest.info shows correct data:
https://masterchest.info/lookuptx.aspx?txid=afa3193c43bdc0554554f1a1fae2428f30dd0bfdea28627f178a49281455d79a

Do you know what's up here?

It looks like a valid transaction.

19ejn7TuHM1MhjuhfT99T7125yHikznf4H sequence number 94 (5E) is the change address
115eZwFLjHS2NWS1feH55LU7bKG45QsbBU sequence number 0 (00) is the reference address
1QFKJvAyJ1EBJ1iFDjgAzMULpGWLaivP7c sequence number 255 (FF) is the data address

The reference address sequence number should be data address sequence number+1, but since the data address sequence number is 255 the next sequence number for the ref address is 0 (ie 256=0, 255+1=0).

From the spec:

Note that sequence number 255 is followed by 0.

I've coded for this scenario (as had mastercoin advisor) which is why the transaction looks OK in masterchest.info.  Probably just that Tachikoma hasn't had time to code for this case yet in mastercoin-explorer.

I had a bug in my code that somehow did something weird with sequences. It should be fixed now and this transaction should properly show. Thanks for the report

[jgarzik]

Note that http://eligius.st/~wizkid057/newstats/pushtxn.php will push a non-standard, fee-bearing transaction into Eligius-mined blocks.

Thus there is no requirement to fit the mold of a "standard" transaction that is relayed by most.

Typically the development process looks like

• Design the best transaction format
• Write software, prove it works on testnet
• Test on mainnet through manual miner submission, like the Eligius URL above
• Now you have a proven use case, and time has passed proving that your concept remains interesting to some user base somewhere
• Submit a patch to bitcoin/bitcoin.git, adding that transaction as a standard transaction

Some of these steps may be done in parallel, of course.