Ninjastic
PostEdited versionsQuotes to this post
Post
Topic
Board Project Development
Re: ChromaWallet (colored coins): issue and trade private currencies/stocks/bonds/..
by
LOL
on 14/03/2014, 05:48:37 UTC
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:
    :::
      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.