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

[killerstorm]

now i get an error that the moniker 'lol' already exists (because the previous one is still there) how do i remove a moniker? And can i rename the asset and use the same 'color' to connect to the same asset under a different name?

You can edit moniker when you add an asset, just call it lol2 or something like that. That name exists only in your wallet, it doesn't affect anything.

Currently there is no button for deleting assets, and doing it via command-line is a bit tedious.

Edit: something else i'm curious about: does this client use the same 'protocol' to color the coins as the website coinprism?

No.

or are those two incompatible? I kinda like the broader definition options on coinprism, but i absolutely hate the fact that it uses a centralised webwallet. :p

We plan to add compatibility with CoinPrism some time later.

What do you mean by broader definition options?

[killerstorm]

I've tried trading with LOL but found two problems:

1. I can't fill his offers due to "Not enough money" problem. (It looks like we messed up check for available balance in p2ptrade page.)
2. When LOL tries to fill my offer it doesn't work because it hits the fee limit. Apparently it is one of those rare cases when buyer has to pay for two paddings + a fee on top of that (i.e. 8192 * 2 + whatever is the fee).

So p2ptrade is basically unusable for now. (Although it worked fine when I was testing it on my asset.) I'll try to fix this ASAP, and also next release will have SPV support.

On the bright side, fee limit seems to work correctly.

[Bytas]

ok thanks

This is some of the metadata that is given allong with coinprism coins.

Code:

{
  "source_addresses": [
    "3JpQpruhC8Vs7LnkatF9WHRh6r1PRC9axz"
  ],
  "contract_url": "https://www.coinprism.com/blockchain/color/3JpQpruhC8Vs7LnkatF9WHRh6r1PRC9axz",
  "name_short": "T.1.1",
  "name": "test",
  "issuer": "Test",
  "description": "test",
  "description_mime": "text/x-markdown; charset=UTF-8",
  "type": "Collectible",
  "divisibility": 0,
  "link_to_website": false,
  "icon_url": null,
  "image_url": null,
  "version": "1.0"
}

[Bytas]

i can see trades now for lol
havn't managed to buy one yet though

[Bytas]

What happens if someone coppies the color set from one of the assets and uses it to issue coins with the exact same color? is that even possible? Does the protocol check that the color is not already in use? I'm quite new to this thing :p

[killerstorm]

i can see trades now for lol
havn't managed to buy one yet though

You might have a better luck trading with me. If you create an offer to buy frobz:

Code:

{"color_set": ["epobc:8a3b99fa2e1169d23aa5c0df6d7626c4d7cf36cf8785bc401be15fd10f7eef0c:0:289172"], "monikers": ["frobz"], "unit": 100}

I'll try to fill it.

[Bytas]

I just bought 10 'lol'

I'll do your's as well

Add my asset please!
If you provide an adress i'll send you one per person because this is awesome to play with!

Code:

{"color_set": ["epobc:e708ac864b7c946771e4dd3baa9e64782654e3d74532e7a75ee80fe2c2896faa:0:301257"], "monikers": ["Bytas' Seal of Awesomeness"], "unit": 1}

[killerstorm]

This is some of the metadata that is given allong with coinprism coins.

We plan to add it at some point, but it isn't high priority, since issuer can easily publish this meta-data on his own web site (or, if anything, on forum).

What happens if someone coppies the color set from one of the assets and uses it to issue coins with the exact same color? is that even possible? Does the protocol check that the color is not already in use? I'm quite new to this thing :p

Color is identified by a hash of the issuing transaction (in ChromaWallet), each transaction will thus create a new color, and so issuing coins of the same color is simply impossible. (Unless you can produce another transaction with the same hash.)

It works differently in CoinPrism: color is identified by address which was used when coins were issued. However, only the original issuer controls private key which is linked to that address, and thus only he is able to issue more coins.

[killerstorm]

Add my asset please!
If you provide an adress i'll send you one per person because this is awesome to play with!

Code:

{"color_set": ["epobc:e708ac864b7c946771e4dd3baa9e64782654e3d74532e7a75ee80fe2c2896faa:0:301257"], "monikers": ["Bytas' Seal of Awesomeness"], "unit": 1}

I've made a bid for your asset.

[Bytas]

oh ok, i understand, different ways to do the same thing.  

EDIT: awesome, sold you one, enjoy! Do you think it is theoretically possible to make a 'blockexplorer' for one of those assets?

[LOL]

What do you mean by broader definition options?

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.

[killerstorm]

EDIT: awesome, sold you one, enjoy! Do you think it is theoretically possible to make a 'blockexplorer' for one of those assets?

Thanks

Yes, it's possible to make a block explorer, in fact we had one, but it isn't being maintained. I gotta check what's the current status...

[Bytas]

I am really looking for a way to collor coins with a certain asset in such a way that everyone is able to retrieve a full document with info about the asset in a decentralised manner.
As lol said, some kind of hash that refers to another blockchain (namecoin, selfmade, ....), or some sort of decentralised data feature (torrents) could be a sollution here. :p

Twister, a twitter clone based on the blockchain and torrents already shows that such a way of sharing data is possible. :p Unfortunately i have no real programming skills myself

Chromawallet is looking damn promissing so far though.

[Bytas]

one more thing i wonder:

Paper wallets for colored coins:
- what do i safe?
- How do i import it again?



General:
- If coins on an adress that is colored are transfered to another adress trough the normal bitcoin client, they lose their color right?

[killerstorm]

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.

Yep, we can add it to ChromaWallet... epobc color kernel (which we use now) has no special meaning for OP_RETURN, so you can just a contract hash (or, really, anything) in there.

But I believe this should be a separate layer, and for now we focus on the core layer.

I doubt we'll have a lot of assets worth buying, so things like automatic discovery are largely unnecessary.

In any case, it is up to investor to perform due diligence, this cannot be automatized in the general case, and checking PGP signature is a small part of it.

Here's what I think is a normal way to issue shares via colored coins: http://www.alefbit.com/investor/issue/

The contract: http://www.alefbit.com/pr/AlefBitIssuance.txt is PGP-signed by the issuer.
Of course, it is meaningful only if one believes that it was really signed by Ariel Horwitz, and that Ariel Horwitz is trustworthy.

Use of contract hashes and Namecoin doesn't really solve the main issue, issue of identity and trustworthiness check, so I don't think it's worth the effort atm.

But it was mentioned more than once, so there is something in it, I guess. Still, PGP integration could be orders of magnitude more useful.

[killerstorm]

one more thing i wonder:

Paper wallets for colored coins:
- what do i safe?
- How do i import it again?

There is no easy way to do it now.

In theory, you get the master key of the deterministic wallet via `cw-cli getval dw_master_key` and write it down on a piece of paper.

Later you can restore it via `cw-cli setval dw_master_key "<key here>"` on a new installation. Then add assets, generate new addresses (as many as there were in old wallet, it won't discover them automatically), and then `cw-cli full_rescan` to fetch history.

However, I haven't really tested it.. And, of course, we'll add a simpler way to do this some time later.

Alternatively, you can get private keys via `cw-cli privatekeys <asset name kere>`. But there is no command to import private keys yet. In this case it's pretty similar to normal Bitcoin paper wallets, but you should remember that it's colored, of course.

General:
- If coins on an adress that is colored are transfered to another adress trough the normal bitcoin client, they lose their color right?

Yes, but user interface won't let you to transfer to a normal Bitcoin address.

[LOL]

Use of contract hashes and Namecoin doesn't really solve the main issue, issue of identity and trustworthiness check, so I don't think it's worth the effort atm.

But it was mentioned more than once, so there is something in it, I guess. Still, PGP integration could be orders of magnitude more useful.

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]

What do you mean by broader definition options?

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.

Coinprism here. Normally, the asset definition is stored on the website of the issuer. When you buy an asset, you are trusting the good faith of the issuer anyway. Sure, the issuer could change the metadata hosted at that URL, but again he could just as well refuse to redeem your coins. The metadata doesn't really have any legal value, if you want it to have a legal value, you need to find a lawyer and have a proper contract drafted.

The fact that the metadata is stored on a "central" server is not actually an issue. Also, in theory, it is possible to put a magnet: url for the metadata, and host in on Bittorrent (though that is not implemented yet).

[LOL]

The fact that the metadata is stored on a "central" server is not actually an issue.

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.

[Coinprism]

The fact that the metadata is stored on a "central" server is not actually an issue.

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.

Well we don't need a special immutable data storage, all you need is a hash of the metadata file. That's easy in theory, but would take more than 40 bytes.