I started a discussion with dexX7 over in the mastercoin announcement thread. He invited me over here due to the technical nature.

I've seen a bit of mastercoin history - I participated in the fundraiser, I attempted a few decentralized trades back in mid November here on this forum, and I was one of the first to complete a trade on the 15th. I consider myself pretty gung ho about mastercoin, however a few items have left me a bit disenfranchised recently. So, if you'll excuse some potentially blunt sentences I'd like to open up discussion on some issues that I feel fairly strongly about.

I'm going to preface this with a quick distinction. As demonstrated below, a private key produces two distinct key pairs. Both key pairs have the same private key, however as they are implemented in a wallet, the private key WIF of key pair #1 cannot spend outputs sent to address #2, and the compressed private key WIF of key pair #2 cannot spend outputs to address #1.


Keep that in mind while I continue.

• Currently different mastercoin implementations generate Class B transactions differently. One includes the sender's uncompressed public key in the P2SH, while another includes the sender's compressed public key in the P2SH.
• I acknowledge that the outputs produced by both implementations are spendable, however I pose that it's not currently reasonable to expect a user to spend them.
• There is not a mastercoin implementation that will always generate a P2SH output that can be spent by key pair associated with the sending address.
• There is a likelihood that the P2SH output will not be able to be spent by a key pair in the sending addresses wallet.
• P2SH outputs from Class B transactions are not recognized, and cannot be spent by any bitcoin or mastercoin wallet currently available(please correct if wrong)
• If mastercoin clients send P2SH outputs to both compressed and uncompressed public keys originating from a single private key, the implication is that mastercoin recognizes a "unit of identity" as being defined by a private key, and thus two key pairs. This isn't compatible with any other client that I'm aware of, can be a privacy leak, and security risk if one of the WIF private keys is compromised. Further, I'd be inclined to think that mastercoin implementations would always need to display and identify both key pairs associated with a private key.
• Class B transactions technically do not create unspendable outputs, however it's a cop out to say that Class B transactions address the concern of blockchain bloat due data storage. If outputs of a transaction are not recognized, cannot be spent, or are otherwise not used in transactions when reasonable, they will not be spent and are subject to loss due to perceived lack of value or understanding.

What I'm trying to point out is that the absence of standardization between mastercoin implementations creates a weird scenario in which it's significantly harder to spend P2SH outputs than it has to be. If a wallet could recognize and spend those P2SH outputs, another weird situation occurs in which the P2SH outputs cannot all be spent without the wallet generating the other key pair associated with a private key. IMO, that's funky and there's no graceful or secure way to handle it.

The next thing I want to bring up is the mastercoin specification. It's not my intent to be a stickler, however I believe it's critical to meticulously maintain the specification, because without the specification there is no mastercoin and there is no value. Yes, the disappearance of the mastercoin specification is an extreme case. So let me provide a lesser example. The mastercoin specification states that a Class B transaction must satisfy the following:


Logical conclusions that follow:

• Only a compressed key pair can broadcast valid Class B transactions.
• There is a mastercoin client that is actively broadcasting invalid Class B transactions.
• Since no mastercoin implementation recognizes a Class B transaction with a P2SH output to an uncompressed public key as invalid, there is a growing chain of invalid transactions that is publicly and unanimously identified as valid.

That which is built to a specification should model that specification as closely as possible with a minimum of interpretation. It appears to me that the the specification is modeled after multiple different mastercoin implementations, is up to interpretation, and does not serve the purpose of defining mastercoin. As such, one could argue that a developer's implementation defines mastercoin and mastercoin is therefore subject to his whim. I am not stating this as my point of view. I say it to demonstrate the importance of the mastercoin specification. The value of mastercoin and the mastercoin protocol rely directly on a specification which defines mastercoin transactions and mastercoin implementation. Yes, it's a slippery slope - if the user can't rely on the specification to define x, when why should it be relied on to define y?


Like I said previously, I've been enthusiastic about mastercoin. However, recently it feels esoteric, loose, and out of touch. I recognize that decentralized trading is groundbreaking, and I recognize that trades are being made.

But I do not think that it is by any means reasonable to think that a client is close to a "high bar for usability" if it doesn't recognize the outputs of a transaction it created, signed and broadcast, cannot spend unspent outputs which it is (cryptographically) capable, and creates multisig outputs that cannot be spent by a key pair in the wallet. Further, there are only native Windows clients, and other OSes have to use a web client and manually handle WIF private keys.

Also, the depth of knowledge required to spend P2SH outputs as they are currently generated is unreasonable to expect in a user. Like I said previously,


If a mastercoin client can't accommodate and expect this perceived lack of value and understanding in a user, it is irresponsible to taut the client as one that has a "high bar for usability."

Mastercoin,

• uses irresponsible implementations of Class B transactions.
• creates outputs that aren't spendable by any wallet.
• greatly privileges Windows users.
• and doesn't have a specification that describes current implementations.

I feel strongly enough about these items that I'd rather see some sort of resolution than sleep like a normal person. I don't feel like it's my place to offer unsolicited solutions to the problems I'm posing, however would be happy to discuss my ideas on the subjects.

And if consensus is that the items I bring up are not problems, take this as feedback from a "long time mastercoin user" that the project feels out of touch, lacks on the PR front, and has direction at the expense of overall quality.