Quote from: LOL on March 14, 2014, 05:48:37 AM

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

Code:

01000000021787722d5c520d47c657d2e75c2deb89fbfacd0636f489a30773867b96479769000000008a47304402201dc79a2d74a2e224a42fa693e9f698b8e582e9020bb5bb52cfb230f1ea8e0e29022051302901342fcda60cd57d241b54e2e55d584f17f830545fb81db467c469931c0141044a50c7c228678f2f5d06f55718341dfc55f3fa0e6f8b46b796920ff706ff125d0ddc851c41b5cd9123f67f2e03e6523b38ff6b6f2171a7a64fd554b2a6906c3b3300000033efa02dae9ee709eed8a41ad40219f04c7d8d38cfa20f920007bfc69f459db9000000008c4930460221009acf1529ef89d53dd993a54d9fd350c795fd76003fe2b66ef45bde6288d08db9022100d0cfdfbba1d661eda8d6b0bed9ebaeece649a1a407b5aae90a9761cdbbbe1d820141040043e689b453580b5e80e7b7122ad50b1a0e3df2f38726a897564b5212b1084ce4bb32a429634e66ccb00e2514dc293c73b55f92a8ef1eee807be4c98e7d5bc5ffffffff0570170000000000001976a91434da9a59604fb1852799a0fc09889752c6d8da0088ace0f80800000000001976a91476842dc7f32580144f6422e1d2e5ef876b334ab688ac2fdb0e00000000001976a914da3909b4d37d8202d3d91ffb71ee2797da14027588ac01000000000000001976a91486d2494f1c805be112e630120e902a6eea214f2e88ac00400000000000001976a91486d2494f1c805be112e630120e902a6eea214f2e88ac00000000

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:

:::

Intended color

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.

Hey LOL, killerstorm has asked me to look into the issue with the balance being different in ChromaWallet and on blockchain. Can you provide me with the mainnet.wallet file? You can PM me a convenient way for me to get it.