ChromaWallet (colored coins): issue and trade private currencies/stocks/bonds/..

[LOL]

Anybody want to try this out?

I'm having a surprisingly hard time getting someone to take my money.

{"color_set": ["epobc:8243935d22411c86a3c6372367d84531821045a632a8728cf6b15fc3b24ce4f2:0:289962"], "monikers": ["lol"], "unit": 6000}

Just give me an address and I'll send you coins. I also have a few sell offers up if someone wants to test that.

[1715098112]

1715098112

[1715098112]

1715098112

[1715098112]

1715098112

[1715098112]

1715098112

[opet]

Using the Win32 client, it looks like I somehow broke it already.  The GUI now fails to load, and I'm getting the following:

Code:

http://p2ptrade.btx.udoidio.info/messages?from_timestamp_rel=30
HTTP Error 500: Internal Server Error
Traceback (most recent call last):
  File "c:\python27\lib\site-packages\cx_Freeze\initscripts\Console.py", line 27
, in <module>
  File "ngccc-gui.py", line 22, in <module>
  File "ngccc-gui.py", line 19, in start_ui
  File "E:\ngcccbase\ui\qtui.py", line 110, in __init__
  File "E:\ngcccbase\ui\qtui.py", line 53, in __init__
  File "E:\ngcccbase\ui\qtui.py", line 88, in gotoOverviewPage
  File "E:\ngcccbase\ui\qtui.py", line 82, in setPage
  File "E:\ngcccbase\ui\overviewpage.py", line 39, in update
  File "E:\ngcccbase\ui\wallet.py", line 77, in get_total_balance
  File "E:\ngcccbase\ngcccbase\wallet_controller.py", line 189, in get_total_bal
ance
  File "E:\ngcccbase\ngcccbase\wallet_controller.py", line 177, in _get_balance
  File "E:\ngcccbase\ngcccbase\coindb.py", line 208, in get_result
  File "E:\ngcccbase\ngcccbase\coindb.py", line 185, in get_coins_for_address
  File "E:\ngcccbase\coloredcoinlib\colordata.py", line 136, in get_colorvalues
  File "E:\ngcccbase\coloredcoinlib\colordata.py", line 121, in process
  File "E:\ngcccbase\ngcccbase\services\chroma.py", line 89, in get_tx
  File "E:\ngcccbase\ngcccbase\services\chroma.py", line 82, in get_raw
  File "c:\python27\lib\urllib2.py", line 127, in urlopen
  File "c:\python27\lib\urllib2.py", line 410, in open
  File "c:\python27\lib\urllib2.py", line 523, in http_response
  File "c:\python27\lib\urllib2.py", line 448, in error
  File "c:\python27\lib\urllib2.py", line 382, in _call_chain
  File "c:\python27\lib\urllib2.py", line 531, in http_error_default
urllib2.HTTPError: HTTP Error 500: Internal Server Error
http://p2ptrade.btx.udoidio.info/messages?from_serial=62490
http://p2ptrade.btx.udoidio.info/messages?from_serial=62490
http://p2ptrade.btx.udoidio.info/messages?from_serial=62490

I tried it from a fresh install and it works great; but, as soon as I copy the mainnet.wallet file over from the broken install, it fails to load the GUI and puts out the above errors in the terminal window.

The GUI first broke when I tried to place a SELL order on the P2P Trade tab.

Any ideas on how to recover?

[killerstorm]

Using the Win32 client, it looks like I somehow broke it already.

Well, it has some loose ends... This happens if you received a transaction server doesn't know about. We need to handle this error without blowing it up.

However, I see that transaction 902a7fb4b56e291b194a1aa5ef87190e1d658a84a4f787edbe7325bf17889719 is being requested, and I can't find it anywhere. Might be transaction malleability issue, I dunno.

Any ideas on how to recover?

Well, you can delete coin_data entries in wallet, but it's probably easier to wait for a fix.

[opet]

Using the Win32 client, it looks like I somehow broke it already.

Well, it has some loose ends... This happens if you received a transaction server doesn't know about. We need to handle this error without blowing it up.

However, I see that transaction 902a7fb4b56e291b194a1aa5ef87190e1d658a84a4f787edbe7325bf17889719 is being requested, and I can't find it anywhere. Might be transaction malleability issue, I dunno.

Any ideas on how to recover?

Well, you can delete coin_data entries in wallet, but it's probably easier to wait for a fix.

What exactly am I deleting with those entries?  Would those affect the assets I had, or would those remain intact?

I have the file backed up (post crash), so I guess it's worth a shot.  If it doesn't work, I'll wait for the fix.

Thanks for your efforts!

PS:  trying to create a new receive address on the receive tab doesn't appear to work either.  Nothing happens when you try to do so.

[killerstorm]

What exactly am I deleting with those entries?

Information about unspent transaction outputs got out of sync with blockchain because one of wallet transactions wasn't accepted by the network.

Wallet file is an sqlite database, you can use sqlite3 or sqlitebrowser to open it. If you delete contents of coin_data and coin_spends tables, they will be populating according information about unspent outputs from blockchain.info. (It is an equivalent of `bitcoind -rescan`.) You might need to click 'update' twice until it shows right numbers.

Of course, there is some bug in chromawallet which caused this, I'm investigating...

PS:  trying to create a new receive address on the receive tab doesn't appear to work either.  Nothing happens when you try to do so.

Yep, that page isn't working properly. It creates addresses, but they aren't displayed.

[killerstorm]

New build:

Linux 64-bit: http://killerstorm.xen.prgmr.com/alex/chromawallet-linux-x86_64-0.0.5.tbz
Windows (32-bit): http://killerstorm.xen.prgmr.com/alex/chromawallet-win32-0.0.5.zip

Now if your wallet got "corrupted" like mentioned above, you can do "cw-cli full_rescan" to repair it. (It takes about 10 seconds.)

I haven't addressed the root cause yet, though.

[opet]

That's great!  I'll test the recovery tonight and avoid the P2P Trade tab until you nail down the issue.  Thanks for all you do!

[opet]

New build:

Linux 64-bit: http://killerstorm.xen.prgmr.com/alex/chromawallet-linux-x86_64-0.0.5.tbz
Windows (32-bit): http://killerstorm.xen.prgmr.com/alex/chromawallet-win32-0.0.5.zip

Now if your wallet got "corrupted" like mentioned above, you can do "cw-cli full_rescan" to repair it. (It takes about 10 seconds.)

I haven't addressed the root cause yet, though.

alright, your process worked and helped me recover both the GUI and the assets.  However, there is one very interesting NEW problem.

The transaction that initially broke the wallet and the GUI was a SELL order for 10 of my 100 total "LOL" assets I had in my wallet at the time.  Based on the error log I posted earlier, you stated that you couldn't find the TXID it was looking for -- which I assume may have caused part of the problem I was having.

The NEW problem I'm referring to:  My recovered wallet now shows 110 "LOL" instead of the original and expected 100!  Somehow, some way, the broken TX ended up adding 10 of the "LOL" asset to my wallet even though I did NOT place a buy order -OR- the alternative explanation is that someone may have directly sent me 10 more "LOL" since the last time I successfully opened the wallet.  Is there a local log of received TX I can look at?   (speaking of which, a "Transaction History" tab would be great! )

[killerstorm]

The NEW problem I'm referring to:  My recovered wallet now shows 110 "LOL" instead of the original and expected 100!  Somehow, some way, the broken TX ended up adding 10 of the "LOL" asset to my wallet even though I did NOT place a buy order -OR- the alternative explanation is that someone may have directly sent me 10 more "LOL" since the last time I successfully opened the wallet.  Is there a local log of received TX I can look at?   (speaking of which, a "Transaction History" tab would be great! )

This is interesting, indeed.

I think 'history' command is defunct now, I'll try to add it back tomorrow and we'll see what happened

[LOL]

New build:

Linux 64-bit: http://killerstorm.xen.prgmr.com/alex/chromawallet-linux-x86_64-0.0.5.tbz
Windows (32-bit): http://killerstorm.xen.prgmr.com/alex/chromawallet-win32-0.0.5.zip

Now if your wallet got "corrupted" like mentioned above, you can do "cw-cli full_rescan" to repair it. (It takes about 10 seconds.)

I haven't addressed the root cause yet, though.

alright, your process worked and helped me recover both the GUI and the assets.  However, there is one very interesting NEW problem.

The transaction that initially broke the wallet and the GUI was a SELL order for 10 of my 100 total "LOL" assets I had in my wallet at the time.  Based on the error log I posted earlier, you stated that you couldn't find the TXID it was looking for -- which I assume may have caused part of the problem I was having.

The NEW problem I'm referring to:  My recovered wallet now shows 110 "LOL" instead of the original and expected 100!  Somehow, some way, the broken TX ended up adding 10 of the "LOL" asset to my wallet even though I did NOT place a buy order -OR- the alternative explanation is that someone may have directly sent me 10 more "LOL" since the last time I successfully opened the wallet.  Is there a local log of received TX I can look at?   (speaking of which, a "Transaction History" tab would be great! )

Someone did in fact send you 10 lol-colored coins after the initial 100 that I sent you.

Check out the transactions on blockchain.info - I believe the balance you have is correct.

[opet]

Someone did in fact send you 10 lol-colored coins after the initial 100 that I sent you.

Check out the transactions on blockchain.info - I believe the balance you have is correct.

That would make much more sense!  Noob question: how do you find these CC transactions on blockchain.info?

[LOL]

Someone did in fact send you 10 lol-colored coins after the initial 100 that I sent you.

Check out the transactions on blockchain.info - I believe the balance you have is correct.

That would make much more sense!  Noob question: how do you find these CC transactions on blockchain.info?

You can just search for your "lol" address on blockchain.info, just take away the prefex:

https://blockchain.info/address/1BSKaQZ6Bn7fZG8iuViQtMSnN3UPk9LHYM

You've received 2 transactions. The first was from me for 100 lol, and the second was from someone else for 10 lol. To check if amounts are right, just look at how much was sent to your address. For example, I sent you 0.006 BTC, and if each lol is 0.00006 BTC, then I sent you 100 lol.

[opet]

You can just search for your "lol" address on blockchain.info, just take away the prefex:

https://blockchain.info/address/1BSKaQZ6Bn7fZG8iuViQtMSnN3UPk9LHYM

You've received 2 transactions. The first was from me for 100 lol, and the second was from someone else for 10 lol. To check if amounts are right, just look at how much was sent to your address. For example, I sent you 0.006 BTC, and if each lol is 0.00006 BTC, then I sent you 100 lol.

Cool, I got it.  (It's not often I wake up to extra random coins! LOL)  

thanks for helping me figure out this new toy!

[LOL]

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:

  <color kernel>:<previous txid>:<previous output index>:<genesis output index>

  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.

[killerstorm]

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

Yep, thanks a lot.

• 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.

0.00028 BTC is the total extra amount which buyer needs to add. 0.0001 BTC goes into a fee, and 0.00018 BTC might be necessary as padding for two colored outputs. (Up to 8192 satoshi per output.)

Of course, in many cases padding is not necessary, so buyer might be overpaying, but it is simpler to implement it this way. We'll optimize it later, of course.

• 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

This is a known feature, seller gets 'change' if padding was not needed.

• 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.

It is more like a notification popup, I consider removing it. However, I'm going to add confirmation on cancel action.

• 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.

Yep, this is interesting.[/list]

[WiW]

I'm looking for the private keys in my wallet (or looking for a way to export them). Can anyone give me a hand?

[killerstorm]

I'm looking for the private keys in my wallet (or looking for a way to export them). Can anyone give me a hand?

There is no API for that right now, I'll try to make it soon.

[nyusternie]

@killerstorm

as v0.9 has just been released with OP_RETURN, which I am just now getting a handle on how it all works, is this protocol change something that you plan to implement into colored coins? or feel that it can be advantageous to colored coins?

e.g. OP_RETURN [hash160 of genesis address -OR- genesis tx hash]

what I'm thinking is that you could spend from a colored address / account without creating a colored tx; unless OP_RETURN was used as an indicator. that would be great to prevent accidental spends. this would mean tracking balances by address and not by outputs (which seems easier to me).

you could, in theory, empty an address' balance, then replenish it simply to make a colored tx.

you could also potentially spend to multiple, independent colors within the same tx (using multiple OP_RETURN outputs).

validation would still require a reverse search to verify that the address does in fact have a balance of colored coins.

just some ideas...

[altoz]

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:

<color kernel>:<previous txid>:<previous output index>:<genesis output index>

This allows the asset issuer to generate the color_set and address prefix before the genesis transaction is confirmed or even broadcast.[/li]


[li]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."[/li]


• 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.

[toastee]

So... it's been a month and not much action here. Is this project still alive?