I can "Delete private keys only, make watching-only," without entering in password for that wallet. Selecting the option to print a paper backup does not function, and makes the "Delete" button nonfunctional.

Restoring a watch only wallet via paper backup just temporarily removes the wallet from the UI. Closing and reopening brings it back as a watch only  wallet once again. Watch only wallet has to be deleted for restoration of that wallet with a paper backup.

Please request details if that would be helpful.

I'm getting the following error:


The client is downloading the blockchain headers, however it fails to show a balance in bitcoin or any assets.

Anybody know why she switched from Mastercoin to CounterParty?

Thanks for the response.

If we have immutable data storage available to us why not use it? The current methods of metadata storage are antiquated solutions to challenges posed by new technologies.

The goal I had in mind for contract hashes and Namecoin integration aims quite a bit lower than "issue of identity and trustworthiness check." The contract hash provides a mechanism to immutably define intent at asset issuance. Namecoin integration is simply data storage that is publicly and universally accessible. These two items together allow an individual to definitively determine what an asset represents.

You're right, that they don't inherently provide a means of proving identity or checking trustworthiness. However, they can provide a means by which an issuer can enable an investor to practice due diligence.

For Coinprism, this can also enable revision control - especially given the ability to reissue an asset.

Coinprism includes a link in the transaction that issues an asset using an OP_RETURN output. The link can be user defined, however otherwise directs to a Coinprism hosted page that includes a "contract details" field. Of course, I can't speak for Bytas, though I think that this type of functionality could be valuable.

That said, I have significant problems with the way that Coinprism associates contract details with an asset. First, the definitions are centrally hosted, and can be changed at will. Second, an asset can't be verified to be legit if the URL becomes invalid at some point in time. Further, even if you select a custom URL, you're required to have the http:// and .com.

I think proper implementation of an asset definition at issuance should be the hash of the contract in the OP_RETURN output. Somebody really creative could even store the contract with Namecoin and indexed by the hash of the contract. This is probably just a pipedream of mine though.

I don't know how this is all directly applicable to ChromaWallet given the drastic differences in implementation.

Try adding this instead:

Hi again.

It's clear to me that there is significantly more emphasis placed on development of features and progress towards functional goals than there is on the fundamentals of the Mastercoin system (is Master Protocol applicable here?). What I mean by this is the development of, for example, the distributed exchange and smart property has been prioritized over providing 1.) comprehensive and accurate documentation, 2.) a method of proof of transaction validity, and 3.) a structure for responsible Master Protocol implementation. I feel like this is primarily a matter of responsibility of the Mastercoin Foundation rather than any particular issue in specific. The funds held by the Mastercoin Foundation place it in an interesting position of responsibility. By creating financial incentive, the Mastercoin Foundation acts like an authority, in certain ways, regarding development and direction. The ability to create (significant) financial incentive in an open source project can have huge benefits, however also appears to carry the implication that potentially critical items, for which incentive is not provided, may not be developed at a satisfactory pace. Thus, a state of fundamental financial security in Mastercoin is deferred to an indefinite point in time because the project has been driven by development, because the specification could not be used as a specification.

This lack of preparedness is now framed by the Mastercoin infrastructure, and all bitcoin used in Mastercoin transactions. The bitcoin developers have been said to be patching the bitcoin-plane in mid flight, if you'll allow me to paraphrase Andreas Antonopoulos. I don't think the state of Mastercoin is far off from this description - in fact may be far worse considering that there is no provable method of transaction validation. The application has far outpaced the fundamentals. As the Shepard to Mastercoin development, it should be the primary goal of the Mastercoin Foundation to establish a structure from which the various implementations and features can flourish. Instead, it seems as if the development of the current implementations was sponsored at the unintentional expense of the core framework.

I've made offers to contribute significant amounts of time towards core work on a structure that defines Mastercoin in a manner that is "hard enforceable." The offers have gone unrecognized, my requests for links to discussion unanswered, and my concerns largely blown off. I recognize that I'm not talking to any single entity that represents Mastercoin, however it stands that the community has largely not responded to any of my concerns in any meaningful fashion. I maintain that I would like to work on a structure that will enable the Mastercoin specification to be "hard enforceable." This is an open offer to enter that conversation with anybody who's interested, and to coordinate with any developers/the Mastercoin Foundation if they find that it may be beneficial.

I've put together the following list to address some items that I believe are currently misrepresenting the state of the project.

• Purpose of the specification The purpose of the specification is not currently clear. There are sections that clearly identify supported/recognized functions, and sections that specify transaction types and requirements. There are also sections that are much more "fluffy," with the apparent intent of appealing to readers, or otherwise painting a picture outside the direct goal of defining the Mastercoin ecosystem. Though it may be nice to have an accessible "overview" of Mastercoin, the specification should be largely technical, with verbiage kept to a minimum so as to maintain a focus on the protocol instead of the opinions of the authors.
• State of the specification With implementation largely driven by the results of coordinated development, the specification does not currently serve the purpose of defining either the various implementations, or determining the validity of a Mastercoin transaction. Despite this, the specification is maintained to a certain degree, however the arbiter appears to be consensus. It should be clearly noted what the intent of the specification is, and what purpose the specification currently serves (i.e. documentation trailing development; not to be confused with the previous bullet).
• The term "specification" The word "specification" does not accurately describe the function of the specification. The document should be titled to fill the purpose it is defined as.
• Definition of consensus Until the specification can fill the role of a specification, the factors that determine the validity of a Mastercoin transaction should be identified and detailed. As far as I understand, this is currently consensus between various implementations. Given the decision to discontinue support for the MyMastercoins Wallet, there may soon be one less entity to participate in this consensus. It may prove valuable to define consensus (including any circumstances in which the Mastercoin Foundation does not recognize that which has achieved consensus), and detail a plan to act on in the event of loss of consensus.
• Specification vs. whitepaper Any item that is not recognized as "enabled" or will not be considered valid should be explored in a document more similar to a whitepaper. The specification should define the Mastercoin ecosystem, though that not currently being the case, should act as reference for that which is recognized as valid.
• Risk given flux in specification Holding or transacting in or with Mastercoin can pose a financial risk, due to the fluid nature of that which is considered "valid." A statement should be made or included in documentation regarding the possibility that a transaction will retroactively change states of validity. This statement should also acknowledge the fact that if validity is determined by consensus, there may be circumstances in which the Mastercoin Foundation (or any other party) may not be able to "fix" actions which represent a financial loss in either that of Bitcoin or Mastercoin.

Thoughts and input are welcome.

EDIT:

Thanks dexX7. I appreciate your discussion and ideas.

Can you point me to discussions had on this subject? I'm interested to know if any discussed ideas allow a snapshot to be referenced without developer involvement.
   
Ideally a system could be implemented that only requires a single snapshot at the implementation of a specification revision control system, to validate transactions occurring before that point in time. Of course, more may be necessary if a disaster situation ever occurs in which consensus is violated, or a revision has unintended consequences etc. Regardless, I'd imagine that snapshots are far less manageable than a set of rules that could define validity of transactions in prior revisions, and I fear that snapshots may pose scalability issues.


I feel like this may be challenging in terms of upkeep, and scalability.


I was thinking about something similar as I was submitting my pull request. Maybe it's not necessary to revise the entire specification if only one or two small changes are made. If different sections are broken out one can submit pull requests for items that don't warrant an entire specification revision, and changes can be discussed in a context more relevant to the issue at hand.
   
If we consider the specification a dataset instead of a specific document, it may be reasonable to precisely define a type of transaction as a data point and discrete unit, and consequently revise that definition independently of any other definition. This also allows all changes to a specific definition to be queried, and a "timeline" built of changes relevant to a specific transaction type.
   
Maybe a crazy idea, but why not use Master Protocol itself to store the specification? For the sake of opening up a discussion on the subject, consider if a transaction definition could be stored in the blockchain. Not only is it universally publicly accessible and immutable, but a standardized dictionary could theoretically allow a client to programatically and dynamically verify the validity of a transaction based on the relevant definition at the time. I have experience designing and implementing relational databases and would be thrilled to contribute if others think that this may be worth pursuing. I'm not under the impression that it's an easy task, but then again, neither was a distributed exchange.



I agree. The specification feels too easy to manipulate right now, IMO. The revision procedure should detail the steps taken to ensure that the implications of a change are known, and that there are no unforeseen consequences that could compromise funds or security. This would be a great place to discuss results of test cases which you discuss below.


I think there's a lot of value in a program/script that could scan the blockchain and output a list of x based on parameters y, and z. For example, transactions with outputs to the Exodus address, or more complex, transactions with outputs to Exodus address with a multisignature output that is not definitively spendable by the sending address or 2nd key pair created from associated (hex) private key. A tool of this nature would allow one to determine how "ready" various implementations are to transition to a new transaction definition, for example.
   
If a functional and usable language could be used to write a query, a tool of this nature could be revolutionary for bitcoin protocol layers, let alone for blockchain data analysis.



IMO, this is unnecessary. I don't see any reason why a properly formed transaction definition shouldn't be able to determine validity of all applicable transactions. Archival could imply more limitations than the benefit gained by ease of gathering examples. Maybe your concern here could be appeased with the ability to prove a transaction types definition at block x?

Sorry about that. I actually realized right after that post that I'd been using P2SH interchangeably with multisig in a multitude of places recently. I suppose I'll live with the embarrassment.

But while we're on the subject of multisig, do you mind commenting on the feasibility of a wallet recognizing strange outputs as spendable? That's a pretty broad question, but I didn't want to narrow it down so far as to only be applicable to the multisig example I provided. The reason I ask is largely due to mastercoin. Mastercoin uses 1-of-n multisig outputs as a method of storing data in the blockchain without creating unspendable outputs. The catch is that there isn't a wallet that will recognize or spend those outputs. As far as I'm concerned, they are unspendable by the average user. Anyway, do you find reason or incentive to recognize and support fringe case outputs such as the one in the example? If so, would you consider pursuing a wallet model that aims to recognize and spend all outputs that can be spent? Please note, this isn't a request - I'm just curious what a developer's thoughts are.

Thank you for the awesome work on Armory! I'm excited to use Armory over the coming months.

Quick bug report:

It appears as if I'm unable to open the "Transaction Info" popup on transactions that have a P2SH output as is standard in mastercoin transactions. In previous releases, the P2SH output was just marked as (I believe it was) "strange." It's not a huge deal considering that no wallet recognizes or can spend those outputs anyway, but it would be nice if the popup worked.

Here's an example:


https://blockchain.info/tx/cba042a1e4b4b072084c06e94f84843cdbd17a30f13dd038fabca67baeb20b53

Sorry for another post.

A few different things going on here. This is in response to Class B "output policy."

First of all, it's unclear to me which Class B transactions are valid because the mastercoin implementations do not follow the requirements of the specification. Second, it doesn't matter what the policy is regarding the validity of a Class B transaction, it's only necessary that implementations have consensus, and that consensus is modeled after the specification. Third, despite the overarching importance of that which is described in my previous point, policy regarding validity of Class B transactions should be specified in a manner which is beneficial to the user or minimizes the detrimental impact on the user.

Fourth, the flexibility of Class B transactions directly affects the ability to spend a P2SH output, and the likelihood that it will be spent. Fifth, policy regarding valid Class B transactions should be based on the balance struck between the Mastercoin Foundation's willingness to recognize transactions that are, or may be, directly detrimental to the blockchain, and whatever benefit is found in flexibility. Finally, however valid Class B transactions may be defined, a wallet should always create P2SH outputs that will be spent by the wallet from which it originated.

tl;dr Flexibility is okay. Wallets that create outputs that it cannot or will not spend are not okay.

I propose that if the specification is accurate then only transactions which are not invalidated (or otherwise specifically validated) by the specification are valid.

I'm going to use the same example as my previous post to demonstrate the effect of this. The specification states, "A single transaction must be constructed satisfying the following requirements:"


Excuse me for quoting myself, but this is what follows:


If the specification is accurate it also follows that, because there is no implementation that recognizes Class B transactions with P2SH outputs to uncompressed public keys as invalid, no implementation can be trusted to display the correct mastercoin balance of an address.

Further, a significant sum of bitcoin has been unknowingly traded with parties which may not even know how much mastercoin they have. Given the possibility that this party has a mastercoin balance to cover the trade, there's no guarantee that it was actually sent to the buyer.

It's really tragic for mastercoin if the spec is accurate, because the loss of bitcoin in invalid mastercoin transactions cannot be recovered, and every single wallet/implementation is useless as a method of sending, receiving, trading, or otherwise interacting with the mastercoin network.

I would suggest against maintaining that the specification is accurate.

EDIT: Concerning the invitation to submit a pull request, it's not a matter of the spec simply being outdated. If it's reasonable to consider that the specification can be out of date, the public release of an updated specification can change the validity of mastercoin transactions confirmed in the blockchain prior to the time at which the revision is published. Bitcoin sets a very high standard on the ability to verify the validity of a transaction, and there's no reason that any entity should be able to retroactively change mastercoin balances.

I recognize the invitation as a suggestion to get involved and address items I may have issues with in a structured and accepted manner, however this isn't about redefining a valid Class B transaction. It's about the ability to know an addresses mastercoin balance, to trust that an addresses mastercoin are secure, to feel safe moving or trading mastercoin, and finally to minimize the impact of data storage on the blockchain.

But for the sake of argument, if I did submit a pull request and it was merged, this would just exacerbate the issue I have with my ability to trust the specification as a document that defines mastercoin, and my ability to trust mastercoin as valuable. If the specification does not or cannot define mastercoin (and consequently the security of mastercoin that one owns), I believe it follows that mastercoin is not valuable.

EDIT 2: I expanded my first edit, and clarified a poorly worded sentence.

Easy.

First, define the purpose of the mastercoin specification. Revisions as necessary.

Second, add a section to the specification that details a system of revision control, and how a specification revision affects past and future mastercoin transactions. I'd start with the following bulletpoints:

A specification revision...

• Does not change the validity of any mastercoin transaction prior to the public publication.
• Will not impose changes that cannot or do not take place immediately upon public publication. e.g. define Class B transactions as only valid if OP_RETURN is used for data storage, because no implementation is prepared to make this transition.
• Is considered to define mastercoin, the mastercoin protocol (etc.) until the point in time at which another valid revision is publicly published.
• Is defined as valid when cryptographically signed by the entity that is granted the right to revise the specification.
• Is defined as publicly published when the following has taken place: 1.) The revision and signature is announced and made publicly available, and 2.) The hash of the revision is stored in the blockchain and is signed by the same entity that signed the revision.

And thus established is a method by which an individual can independently prove the validity of a mastercoin transaction at any point in time. The only tricky revision is the first one included in the blockchain, which must establish which transactions up to that point are valid. I say, publicly publish the revision, and then take a "snapshot" of the balances of all mastercoin address greater than 0 as of the block height at which the revision hash transaction was first confirmed. Take a hash of that dataset, store the hash in the blockchain, and define that as proof of a transactions validity up to the point at which the first revision was confirmed.

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.

I appreciate the response.


The "to sender" multisig output should be defined as one of the following in the mastercoin specification:

• Spendable by the address with a compressed public key and a private key in common with the sending address.
• Spendable by the address with an uncompressed public key and a private key in common with the sending address.
• Spendable by the sending address.
• Spendable by the address with a public key opposite that of the sending address (i.e. if sending address is compressed, uncompressed; if uncompressed, compressed), and a private key in common with the sending address.

It doesn't matter which, however it needs to specified and implemented. If the specification happens to make sense, user confusion should be reduced to a minimum. My vote is "Spendable by the sending address." It's a more difficult implementation, but it makes sense.


Share a private key, yes, however do not have same WIF private key, public key, or address. If some mastercoin outputs are spendable by a compressed address, and other outputs are spendable by the corresponding uncompressed address, then both should be represented in the wallet and identified as such.

The implication of a client automatically receiving/signing transactions for both the compressed and uncompressed versions of the key pair is that the mastercoin 'unit of identification' is 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.


I agree with intelligent input selection, however I'd not be inclined to use a wallet that treats two key pairs interchangeably, especially if both pairs were not represented and identified as such.


I agree, should be solved under the hood - provided that only one key pair from a given private key is used (unless of course the user imports the key pair of the other format, in which case they should still be treated as separate "entities"). Dust is a pain to deal with. The more obstacle there is to spending it the less likely it is to be spent.


The depreciation of Class A transactions eliminates unspendable outputs. The implementation of Class B transactions is only marginally better, IMO, because the incentive to make multisig outputs spendable is not worth the time involved - especially for those less bitcoin/mastercoin savvy. I see Class B transactions as a great transition to Class C transactions - but if Class B transactions are not depreciated, and multisig output dust is not properly handled, the implementation of Class B transactions does little to address the intent behind eliminating unspendable outputs. Sure, it technically does 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. Others may disagree, but as far as I'm concerned 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.


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 - let alone the fact that there are only native Windows clients, and those with other OSes must manually handle WIF private keys in order to use the web wallet.

I've been pretty jazzed about mastercoin, however recently it seems esoteric, loose, and out of touch with the user. I bought at exodus last year, I was one of the first to attempt decentralized trades back in mid November, and I was one of the first to succeed on the 15th. Yes, it's groundbreaking, and yes, trades can be made. But mastercoin doesn't have a specification that describes current implementation, the clients privilege Windows users, and the depth of understanding in bitcoin required to spend Class B outputs (i.e. not bloat the blockchain) is a great bar to entry.

For the sake of clarification:

• If the sending address has a compressed public key, will any mastercoin client broadcast a transaction with a multisig output that can be spent by the address with the corresponding uncompressed public key?
• Do any bitcoin or mastercoin clients recognize a Class B transaction multisig output as one that can be spent? i.e. Do the outputs add to the displayed balance, and will the client spend that output?
• The mastercoin spec says, "It is envisaged that in future Master Protocol clients will 'clean up' periodically by redeeming and consolidating unspent multisig outputs." If the sending address has an uncompressed public key, is it speculated that the mastercoin client will also 'clean up' multisig outputs sent to the address with the corresponding compressed public key and vice versa?
• The mastercoin spec states that a Class B transaction must satisfy the following: "Has one or more 1-of-n OP_CHECKMULTISIG outputs each containing at least two compressed public keys, one of which must be the senders address." Does this imply that only addresses with compressed public keys can generate valid Class B transactions? A Class B transaction sent from an address with an uncompressed public key that has a multisig output to the associated compressed public key does not produce an output that can be spend by the senders address.
• Is a Class B transaction valid if the multisig output is to an uncompressed public key?
• Is a Class B transaction valid if the sending address has an uncompressed public key and the multisig output is the corresponding compressed public key? And vice versa?
• Given that the multisig outputs are very small, is it generally understood and recognized that these outputs are not accounted for in (most??) clients, and will not be spent except by manually generating, signing and broadcasting the transaction?
• With the understanding that Class A transactions have been depreciated because they produce unspendable outputs, is there a plan to educate and assist the mastercoin community in spending Class B multisig outputs that would have been unspendable if produced by a Class A transaction?
• When mastercoin transitions to Class C transactions, using the script OP_RETURN for data storage, will there be an effort as a community to spend the multisig outputs from Class B transactions?

You'll have to forgive my questions. However it's not clear to me exactly what defines a valid Class B transaction given that my address has consensus across mastercoin implementations despite having broadcast Class B transactions that should not be valid according to the mastercoin specification.

I recognize that I may be very far out of the loop on this, however I feel that it's irresponsible to implement Class B transactions as a solution to the bloat caused by Class A transactions without an active effort to ensure that those multisig outputs are spent. The issue is exacerbated by the fact that the mastercoin clients are 1.) sending multisig outputs to a compressed public key while the sending address has an uncompressed public key, and 2.) sending multisig outputs to uncompressed public keys (which directly violates the mastercoin spec). I recognize that multisig outputs can be spent, but I don't think they will be spent unless people made aware of the problem, and encouraged to spend them.

I'm finding a couple Class B Mastercoin transactions I've made in which no public key in the multisig output script is that of the sender:

• 204e02988b1a7262d90168dfe4574a69b3ab6617dddfc3737e6a296ec4d17b8f
• 1d1b0f773eb639d13151743b5794914d371284123cf516c7598c7340ddf49716
• 7ca6d02dc71e798919449e36708c1fa001797b1471e42928e2750cc03013283b

Am I missing something here, or are those now unspendable outputs?

I'd love to try it out.

I've played around with ChromaWallet quite a bit the last couple days - hopefully some of my experiences can be valuable.

• P2P trade A p2p trade (8c1926f2e3527153bf06e8ab2c8a417aad3d8e6cd993a4350efbb4050ab961fa) went unconfirmed for over 19 hours, according to blockchain.info. The transaction fee paid was 0.0001 BTC, a reddit post says that it should be 0.00028 BTC.
• P2P trade A p2p trade (f85b6213939c9cbc14538dd24838061179cac2485f50be20a974b819a85e5ee9) has multiple outputs to the sellers bitcoin address. Can provide more instances of this occuring. Buyer ends up overpaying for asset
• P2P trade It appears as if bids and asks are listed without clicking on the confirmation popup. Double clicking an order cancels it without confirmation as well.
• Balances A bitcoin address (1DMkN2dgTHvRYAPgtTZAFsZXKE6rUJDG9E) has a balance of 0.00824875 BTC according to ChromaWallet, and 0 BTC according to blockchain.info. The value displayed in ChromaWallet is the same value of the most recently spent input. I can provide the mainnet.wallet file if this would be useful.
• Balances Address balances are only displayed out to 7 decimal places
• P2P Below is a raw transaction that has an output of 0.00000001 BTC generated by a P2P trade

• P2P There are circumstances in which the client will say that I don't have enough money to fill an ask order. If I manually type out a bid that matches the ask, the trade will attempt to go through.
• Tiny outputs in P2P Small, however standard, outputs do not appear in the wallet (or blockchain.info) until the transaction is confirmed. It will appear as if the trade did not function until confirmation.

I'm a bit confused as to what the current function of the color_set is.

• txid The txid that is broadcast isn't necessarily the txid that is confirmed in a block.
• Block height The block height at which a transaction is confirmed is not known until it has actually been confirmed.
• Genesis identification If the assumption is made that only colored coin transactions are ordered, the color (even if undefined) of an output can by identified by "tracing" outputs back until the inputs are unmatched.
• Concensus on asset definition Giving a colored address may define an intent to receive colored coin generated by a specific transaction output, however there is not necessarily consensus on how the color of those coins is defined. See here (http://imgur.com/a/yRWwG) for an example of two assets in a single wallet that are defined by the same color_set that have different values and names.
• Colored coin recognition Colored addresses can coordinate intent between two parties to transact in colored coins generated in a specific transaction output, however cannot stop one from sending colored coin to an address that doesn't recognize colored coins.

I'm not sure if any of this was intentional, or otherwise what the development roadmap looks like, however I have a few solutions clanking around:

• Identification of the genesis output By identifying the genesis output as:
  
  
  Code:
  Output x of the transaction for which output y from transaction z is an input
  
  a color_set can be defined as:
  
  
  Code:
  :::
  This allows the asset issuer to generate the color_set and address prefix before the genesis transaction is confirmed or even broadcast.
• Intended color An additional output can be added to the genesis transaction that identifies an output, as defined by a color_set, as having been intentionally colored. If the additional output is generated using the color_set as a passphrase, wallets and asset holders can verify the genesis output independently and ensure the correct color_set. A genesis transaction that includes an "intent output" can also imply the asset issuer as the identity that signed the transaction. Identification of an issuing identity may help establish a framework for asset management, such as issuing additional units. A color_set could indicate the output index of the "intent output."
• Immutable color The inclusion of an additional parameter in a color_set can enable asset holders and wallets to verify that an asset definition is as described by the issuer. The new parameter is a hash that is representative of the color that is to be attributed to the colored coins described by the color_set in question. This parameter, along with an the inclusion of an "intent output" can immutably color coins and eliminate vulnerability caused by unauthorized asset redefinitions. Further, this inclusion enables a colored address to be verified as "on the same page" as the issuing identity.