Topic: ChromaWallet (colored coins): issue and trade private currencies/stocks/bonds/.. - page 6. (Read 97085 times)
May 09, 2014, 07:44:52 AM
AlefBit doesn't believe it's dead.
May 07, 2014, 10:10:51 AM
May 03, 2014, 01:54:08 AM
ChromaWallet can be an excellent platform for our "Bitcoin Backed by Gold" project. I look forward to exploring potential synergies.
April 26, 2014, 06:32:48 PM
April 21, 2014, 06:45:39 PM
So... it's been a month and not much action here. Is this project still alive?
Dead. Been dead for a long time actually. Now it is mostly just KillerShitStorm's little hobby project. We get a line or two of code every time he gets a day off. But, it was never really a serious project anyway so no one is surprised. Colored Coins has always been nothing more than an interesting curious concept. April 16, 2014, 11:00:49 PM
So... it's been a month and not much action here. Is this project still alive?
March 19, 2014, 09:48:51 PM
I've played around with ChromaWallet quite a bit the last couple days - hopefully some of my experiences can be valuable.
I'm a bit confused as to what the current function of the color_set is.
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:
a color_set can be defined as:
:::
- 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.[/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.
[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]
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.
March 19, 2014, 05:14:04 PM
@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...
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...
March 14, 2014, 11:47:43 AM
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.
March 14, 2014, 09:36:45 AM
I'm looking for the private keys in my wallet (or looking for a way to export them). Can anyone give me a hand?
March 14, 2014, 04:26:07 AM
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]
March 14, 2014, 12:48:37 AM
I've played around with ChromaWallet quite a bit the last couple days - hopefully some of my experiences can be valuable.
I'm a bit confused as to what the current function of the color_set is.
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:
- 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.
March 13, 2014, 12:46:49 AM
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) 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.
thanks for helping me figure out this new toy!
March 13, 2014, 12:36:41 AM
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?Check out the transactions on blockchain.info - I believe the balance you have is correct.
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.
March 12, 2014, 10:48:19 PM
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? Check out the transactions on blockchain.info - I believe the balance you have is correct.
March 12, 2014, 07:48:47 PM
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.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.
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.
March 12, 2014, 05:35:40 PM
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
March 12, 2014, 03:24:48 PM
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.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.
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!
) March 11, 2014, 01:16:18 PM
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!
March 11, 2014, 10:56:51 AM
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.
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.
Jump to: