color definition -> asset definition

[Alex Mizrahi]

We need to revamp color definition infrastructure, largely because there were several problems with additional issues.

Albert gave us a great idea: separate notion of color and asset. Color exists in context of coloring algorithms, asset is a meaning we associate with a set of colors.

Transaction outputs are of color X if they can be traced back without mixing to a genesis of color X which is a single transaction output. 

Making "one color = one genesis TXO" a rule simplifies things.

Color descriptor (color_desc) can be a string like:

"<txhash>,<outindex>,<block_number>".

Block number is needed because transactions with same txhash are possible: https://en.bitcoin.it/wiki/BIP_0030

txhash should be hex encoded and little-endian, i.e. in same format as used by block explorer.

Next, color_set is just a JSON array of color_desc's in which color_descs are sorted as strings.

color_set_hash is a hash of a deterministic serialization of this JSON object.

color_asset is a JSON object consisting of color_set, contract and signature. (Also known as "asset definition")

To issue colored coins, issuer creates a contract object which describes what it is about, make transaction with desired amount of satoshis and then signs contract and color_set together.

When he needs to issue more coins representing same asset, he will add genesis tx outs to color_set and sign a new color_asset.

Client can periodically look for update of asset definition retrieving it from a certain location. If definition was updated, client can either update a locally used asset definition automatically according to a certain policy, or it might ask user whether to trust a new definition.

We do not want to trust asset issuer's signature blindly, thus new asset definition will be used only:

1. If it is endorsed by other parties, e.g. signed both by an issuer and by exchange/notary/insurer. 

2. After some timeout, e.g. 48 hours. This gives an asset issuer has time to notify investors about potential theft of private key.

color_asset_class is a collection of color assets which user thinks are more-or-less fungible.

That is, if we have GOLD coins from several different issuers which are equally trustworthy, user will want to see all of them as GOLDcoins.

color_asset_class consists of metadata (name, unit...) and list of color_assets together with scaling factors which map them all to same units.

E.g. Issuer1 might represent 1 g of gold with 50000 satoshi.

Issuer2 might represent 1 oz of gold with 100000 satoshi.

User wants to see how many grams of gold he wants. Client software is supposed to do conversion automatically.

----

When users trade with each other, they need to communicate what issues of colored coins they have or want.

color_set_hash can be used as a short identifier.

When client doesn't recognize color_set_hash, he needs to fetch whole color_set.

color_set can be then put into a cache, so most of the time color_set_hash is enough.

If user wants to buy something with gold coins, but merchant doesn't accept the kind of gold coins user has, trade can be done using exchanger. (Using p2ptrade protocol.)

Client software will post an offer like:

{ A: { color_set: <user's color_set>,

         value: <how many gold coins user wants to convert, in satoshi>}

  B: { color_set: <merchants's color_set>,

         value: <how many gold coins merchant needs as a payment, in satoshi>}}

          

[Albert Hendriks]

See also 

https://github.com/bitcoinx/colored-coin-tools/wiki/Define-coloring

Albert

          

--
You received this message because you are subscribed to the Google Groups "Colored bitcoin - BitcoinX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinX+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[jspilman]

Lots of great info here! And here too: https://github.com/killerstorm/colored-coin-tools/blob/master/colordefs.py

Some additional thoughts – I’m still absorbing everything that’s out there, so sorry if this is duplicative:

Data structure:

   - A JSON serialization is very useful, especially for discussing the details in email

   - I assume we need a binary format, since can we be sure JSON stringify is 100% deterministic across all implementations? I think better to define the hash/signature over a binary data  structure

   - For example, TxHash is BE anytime you are dealing with the binary data, but tends to printed to a hex string reversed

Issuance:

   - Genesis Issuance – Doesn’t support creating new issues for the same asset without changing the definition

   - If you put a publicKey in the definition, you can detect any issuance of the asset as any spends from a hash160(publicKey * contractHash) address

Value Accounting:

   - Doesn’t the definition have to include how to calculate total units issued?

      - Satoshi per unit + Base Satoshi? (for fixed accounting)

      - Total Units per color_descr (for fractional accounting)

   - Minimum divisible unit

      - Implicit for fixed accounting

      - Can explicitly specify a lower limit for fractional accounting, outputs resulting in shares below that threshold are uncolored, regardless of odd/even Satoshi – this does not destroy color.

Coloring rules:

   - Safer to assume the coloring rules (order based, odd/even satoshi, etc.) could *possibly* change over time

      - How about a field to specify the coloring rule ID for each genesis, it can just be a 4 byte version field.

      - Obviously this requires an agreed upon ‘enum’, but that’s a lot better than not saying anything and having to guess

   - Now after typing this, I wonder if it’s better to actually specify the color rules to follow (ideally implicitly) within each transaction... 

      - Significantly more complicated, but could be very powerful to be able to have selectable coloring rules and choose whichever is best for each transaction.

      - For example, buy a large amount of color X with fixed satoshi, then re-spend using fractional rules to free up all the “metal”

Color Identity / Description:

   - Asset code / short string

   - Asset description / ‘Contract Details’ – is there a longer description that’s part of the colordef?

Issuer Identity:

   - Contact information?

   - Published definition URL?

   - PGP key? X509 certificate with chain?

What timestamp do you use to start the 48 hour (or whatever) clock after issuing a new asset?

   - Create the color genesis outputs, get them on the block chain has to happen before you write the definition (for genesis issuance)

   - You could spend from the color genesis to (publicKey * contractHash) which by definition has to happen after the definition is written, to “start the clock”

   - Putting a clock on new issues could create liquidity problems, DoS attacks, if the issuer doesn’t have enough in ‘reserves’ and price is spiking

Fungible Assets:

   - The meta-data required for the wallet to detect fungible assets could be at the color_asset level, doesn’t have to be at the asset_class level. Specify an asset_class_id in the color_asset. It’s more scalable this way, but you need issuers to coordinate their asset_class_id.

   - As an issuer, I want to get to say who my issues are fungible with (by cross signing each others definition files)

      - For example, if I build trust and a market for my color, I don’t want Joe Blow issuing colors which look ‘like’ mine in the wallet

   - As a purchaser, I want to get to say who I want to treat as equivalent (white-listing)

      - Since it all comes down to trust, you have to give the user a say in who they are trusting to be a reliable market maker

   - So I think you need both to be true, before the wallet can actually do the calculations behind-the-scenes and expose the fungible assets as a common currency

Upgrading Issuance: (future work)

   - If you need to change the base satoshi value, or the coloring rule, you make a colordef with an explicit ‘parent_asset_hash’, an exchange rate, and an exchange bot’s publicKey

   - For example, if ‘DUST’ definition goes down over time, you can ‘reclaim metal’ through re-issue and an exchange bot

   - If this is standardized in the definition, then wallets can do it automatically

[jspilman]

Sorry I said this backwards. I think all the internal data fields in bitcoin are little endian when you're building the byte arrays to be hashed. For example, to generate the block header, hashPrevBlock is treated as little endian with zeros on right.  Printing the Tx hash as a hex string is typically big-endian -- putting the zeros on the left side. Blockchain.info and Blockexplorer show the printed value as a big endian hex string.  To be consistent with bitcoin hashing, we should treat any data being hashed as little endian 256-bit integer, with zeros on the right, and print them to screen as big endian 256-bit integers.

See: https://en.bitcoin.it/wiki/Block_hashing_algorithm

   - For example, TxHash is BE anytime you are dealing with the binary data, but tends to printed to a hex string reversed 

 

txhash should be hex encoded and little-endian, i.e. in same format as used by block explorer.

 

[Alex Mizrahi]

Lots of great info here! And here too: https://github.com/killerstorm/colored-coin-tools/blob/master/colordefs.py

Well, this thing will be obsoleted, I think...

 

   - I assume we need a binary format, since can we be sure JSON stringify is 100% deterministic across all implementations?

I hope we can do it without binary format... If you use JSON library, then, of course, it isn't deterministic.

But it is possible to make deterministic stringification. (Like you see in colordefs.py)

I really don't see how it is any less deterministic than binary format.

 

   - For example, TxHash is BE anytime you are dealing with the binary data, but tends to printed to a hex string reversed

Well, it is an array of bytes when you're dealing with binary data. It is just reversed in block explorer etc.

 

   - If you put a publicKey in the definition, you can detect any issuance of the asset as any spends from a hash160(publicKey * contractHash) address

We were going to ditch "issuing address" concept. 

1. Issuer's private key might get stolen, and thief can issue and sell some very valuable coins at issuer's (or investors' expense). For this reason spends shouldn't be considered valid immediately, but adding a timeout will add considerable complexity to implementation.

2. It makes implementation more complex as genesis inputs need to be tracked.

3. It is harder to deal with situation when issuer's key was actually stolen.

    With discrete genesis outputs user has an option to select asset definition he trusts

4. One genesis txout per color model seems to be able to resolve some edge cases.

 

Value Accounting:

   - Doesn’t the definition have to include how to calculate total units issued?

Well... It references genesis tx outs, so that shouldn't be a problem, I guess.

 

   - Minimum divisible unit

      - Implicit for fixed accounting

I'd say it is a client configuration rather than a feature of asset definition.

 

Coloring rules:

   - Safer to assume the coloring rules (order based, odd/even satoshi, etc.) could *possibly* change over time

Change in coloring rules would require a "hard-fork" for coloring clients. So it is safer to use same rules for eternity :)

However, from what I see order-based coloring is compatible with everything (which isn't order-based).

So it won't be a problem to use it as a least common denominator.

Say, if you want to swap retepian :) contract with a colored coin, colored coin inputs/outputs should go first, following by reteptian contract and uncolored coins.

So coloring algo will see retepian contract as uncolored.

 

      - How about a field to specify the coloring rule ID for each genesis, it can just be a 4 byte version field.

Are we trying to make this Byzantine?

One rule is easier to implement and is safer.

MAYBE you will be able to get two rules to work together, but if you have more it gets harder and harder. (Combinatorial explosion.)

I mean, if coloring rules interact in unexpected ways, somebody will lose his coins...

I think safety trumps any other considerations.

 

   - Asset description / ‘Contract Details’ – is there a longer description that’s part of the colordef?

I think it is good to add some summary, but an actual contract might be on 10 pages, I'm not sure it should be a part of asset definition, perhaps it's better to include URL and a hash of contract.

Issuer Identity:

   - Contact information?

   - Published definition URL?

   - PGP key? X509 certificate with chain?

I'd rather have Bitcoin public key. It is possible to associate it with a mnemonic via blockchain.

 

What timestamp do you use to start the 48 hour (or whatever) clock after issuing a new asset?

Since we know block number of genesis txout, we can count 288 blocks from it.

But it isn't critical since it is a client configuration. Client might as well trust it immediately, for example, if it is also signed by an "exchange".

 

   - Putting a clock on new issues could create liquidity problems, DoS attacks, if the issuer doesn’t have enough in ‘reserves’ and price is spiking

Do you mean that issuers will depend on ability to use newly-issued coins immediately?

They shouldn't depend on this.

Also it should be possible to override waiting interval, so somebody can arbitrage this by buying freshly issued coins and selling old ones.

 

Fungible Assets:

   - The meta-data required for the wallet to detect fungible assets could be at the color_asset level, doesn’t have to be at the asset_class level. Specify an asset_class_id in the color_asset. It’s more scalable this way, but you need issuers to coordinate their asset_class_id.

Wallet shouldn't automatically assume that assets are fungible because different issuers might have different reputation. Say, some USDcoins might trade at 50 cents on dollar... or less.

But yes, it's possible to get rid of asset_class.

The way I see it, it might be exchange's role to assign asset_class_id.

Basically, exchange selects issuers whose assets seem to be reputable, download their asset definitions, modify them by adding asset_class_id, sign them and offer for download from users.

Instead of downloading asset definitions from individual issuers, user might just download the whole shebang from exchange he trusts.

Of course, paranoid users might tweak it manually :)

Upgrading Issuance: (future work)

   - If you need to change the base satoshi value, or the coloring rule, you make a colordef with an explicit ‘parent_asset_hash’, an exchange rate, and an exchange bot’s publicKey

   - For example, if ‘DUST’ definition goes down over time, you can ‘reclaim metal’ through re-issue and an exchange bot

   - If this is standardized in the definition, then wallets can do it automatically

Yep.

[Jeremy Spilman]

Great feedback, thanks.

 

Serialization:

 

   I don’t feel strongly either way.  I have no problem dealing with the binary, and it seems more explicit. If you’re hashing a string, better specify the formatting and character encoding of every single field!

 

Issuing Address:

 

   Private keys for issuing assets can be kept entirely offline.  You can issue from a P2SH address with a 3-of-3 multisig redeemScript, and/or you can split keys internally in the organization between CEO, CFO, and external auditor with Shamir Secret Splitting. If an “attacker” can issue your color, it’s a really good reason to liquidate and never trust that color again. More likely it’s the issuer stealing from their customers and then saying “sorry, it wasn’t us!”

 

However, I don’t understand the ‘edge case’ comment, because I think the end-result of either approach is identical. In either case you will end up with the exact same list of { blockNum, txId, outindex } and whatever rules you want to apply from that point onward (e.g. waiting period) it’s the same code. Multiple definition files seems totally redundant.

 

I would strongly disagree that watching the block chain for spend-from-address is complex – in fact what could be more simple! I think it’s complex to have to publish, distribute, and then get exchanges and maybe even individual clients to whitelist individual definitions over and over for the same color. If you are issuing GOLDcoin, it’s not like you can issue 100kg on Day 1, you need to prove reserves, which increase with adoption, and so regular, periodic issuance inline with market adoption should be expected. A spike in demand (which is unpredictable and subject to herd mentality) could mean even more frequent issuance. I’m trying to envision these long data tables where someone is supposed to check off the set of issues they trust for the same color on a daily/weekly basis. Sounds like a usability nightmare. It’s like having a different symbol each week you want to trade AAPL stock, eventually there are a thousand APPL.1, APPL.2... Are the exchanges supposed to keep separate order books for each issuance of the same color?

 

IMO, a single definition, then effectively announcing issuance on the blockchain (spend-from-address), allows everyone to detect the issuance fairly. Everyone can say definitely exactly how many units of the color exist. All issues of the same color should be by definition fungible.

 

I’ve been watching the discussion about open orders on the blockchain, I think its silly since nothing can stop private parties from negotiating in private, and also all trades are public after they are made anyway. But, I can see justification in open issuance on the blockchain. For a given color, it should be trivial to *prove* exactly how much is issued. You should not have 1 exchange thinking there are X units, and another exchange thinking there are Y units, because they have a different set of definition files.

 

I don’t think the waiting period should be chosen by the client.  I like ‘wait X blocks’, but it should be in the definition. Most importantly, the issuer must be contractually responsible for units issued from its address after the waiting period has elapsed. We should have a second publicKey which lets you retract an issuance.  Spend from (publicKeyRetract * txID) is a retraction, and a retraction must be on the blockchain at least 144 blocks (or some value in the definition) before the issue would have become valid.

 

So that’s issuance, what about redemption?  You could just destroy the color by merging them with some uncolored coins, but how do you tell the difference between true redemption (taking units off the market) and inadvertent de-coloring, which the issuer would be required to correct? Again, the idea is everyone should be able to calculate the total float at any time. Perhaps better to have another address where any coins sent there are redeemed, and float is reduced.

 

Value Accounting:

 

   Perhaps I’m missing something.  If your genesis transaction has amount = 1BTC of GOLDcoin, what are the units, and how many satoshi per unit? Don’t you need to specify that in the definition?  If it’s USDcoin, how many Satoshi to the dollar? Certainly that’s not client configuration...

 

  How exactly does handling a base Satoshi amount work?  If each output must have 6000 Satoshi due to network restrictions, I assume you would combine exactly 6000 uncolored coins with X amount of colored coins in a single output, to have a colored output worth exactly X colored coins, right?  But that ‘6000’ number, or whatever it is, has to be in the definition so everyone follows the right rule. At first glance, I don’t see how a tracking algorithm handle arbitrary client-chosen ‘base’ amounts.

 

Color Tracking:

 

   If we put a color_rule_id field, then I think it’s a soft fork. Older clients just don’t recognize newer color definitions using an unrecognized coloring rule, but nothing breaks for them for existing colors. If we don’t even HAVE a color_rule_id, then it definitely is a hard fork, because the only way to fix a bug is to say ‘any assets issued after block number X should be colored this way from now on’ and you have to get everyone to change in sync.

 

It’s easy enough to start with order based coloring equals ‘0’ and support nothing else to start.  You want even the initial client code to be able to check that the field is zero before trying to trade them.  That way you clients won’t try to trade something they don’t support if we ever need to change the color tracking in the future.  I guess more generally, you could just put a version number on the entire definition, and increment it any time you have any kind of non-backward-compatible change.

 

[Tamas Blummer]

On Thursday, May 2, 2013 2:53:00 PM UTC+2, Alex Mizrahi wrote:

We need to revamp color definition infrastructure, largely because there were several problems with additional issues.

Albert gave us a great idea: separate notion of color and asset. Color exists in context of coloring algorithms, asset is a meaning we associate with a set of colors.

I am not convinced, that this is a great Idea. Please point me to the reasoning. I think a color is meaningful only if associated with terms that describe what it stands for and terms is nothing else then definition of the asset. You can also turn this around and see the same terms means same asset, same color that is fungibility of financial assets. Once terms are changed in any subtle way holdings of assets are not fungible, colors not mergeable.

 

Transaction outputs are of color X if they can be traced back without mixing to a genesis of color X which is a single transaction output. 

Making "one color = one genesis TXO" a rule simplifies things.

Color descriptor (color_desc) can be a string like:

"<txhash>,<outindex>,<block_number>".

Block number is needed because transactions with same txhash are possible: https://en.bitcoin.it/wiki/BIP_0030

txhash should be hex encoded and little-endian, i.e. in same format as used by block explorer.

The motivation and effect of BIP30 is exactly to disallow same transaction hash. 

BTW only coinbases have a practical chance to produce same hash without being a double-spend too.

 

Next, color_set is just a JSON array of color_desc's in which color_descs are sorted as strings.

color_set_hash is a hash of a deterministic serialization of this JSON object.

color_asset is a JSON object consisting of color_set, contract and signature. (Also known as "asset definition")

To issue colored coins, issuer creates a contract object which describes what it is about, make transaction with desired amount of satoshis and then signs contract and color_set together.

When he needs to issue more coins representing same asset, he will add genesis tx outs to color_set and sign a new color_asset.

Client can periodically look for update of asset definition retrieving it from a certain location. If definition was updated, client can either update a locally used asset definition automatically according to a certain policy, or it might ask user whether to trust a new definition.

We do not want to trust asset issuer's signature blindly, thus new asset definition will be used only:

1. If it is endorsed by other parties, e.g. signed both by an issuer and by exchange/notary/insurer. 

2. After some timeout, e.g. 48 hours. This gives an asset issuer has time to notify investors about potential theft of private key.

color_asset_class is a collection of color assets which user thinks are more-or-less fungible.

WHAT? There is "no more or less fungibility" in finance!

[Tamas Blummer]

Please also consider that having an expiry (maturity) of an asset greatly supports future scalability. There is no need to propagate coloring for events passed or bonds matured. 

On Thursday, May 2, 2013 2:53:00 PM UTC+2, Alex Mizrahi wrote:

[Alex Mizrahi]

I am not convinced, that this is a great Idea. Please point me to the reasoning. I think a color is meaningful only if associated with terms that describe what it stands for and terms is nothing else then definition of the asset.

It is just a change in terminology, basically we just rename color to colored asset.

User's will never see "colors" in user interface of their client.

 

You can also turn this around and see the same terms means same asset, same color that is fungibility of financial assets.

There is a purely technical reason to avoid mixing coins which correspond to different genesis txouts.

I'll explain it in details in a next message, but basically we know a lot of messy edge cases which can be prevented this way.

So again, we do not change semantics, we just:

1. Prevent software from mixing coins which descend from different genesis txouts to avoid potential problems.

2. rename "color" to "colored asset".

 

 

The motivation and effect of BIP30 is exactly to disallow same transaction hash. 

Please read BIP 30 carefully: it only disallows same transaction hash _within one block_.

They can still exist in different blocks.

 

BTW only coinbases have a practical chance to produce same hash without being a double-spend too.

No: you can spend from this coinbase to exactly same address to produce another tx with same hash.

We are working with crypto stuff, relying on "It rarely ever happens" is not an option.

If it is possible for an attacker to exploit this, then we need to protect against it.

 

color_asset_class is a collection of color assets which user thinks are more-or-less fungible.

WHAT? There is "no more or less fungibility" in finance!

Well, coins from different issuers are not fungible because they carry different counter-party risk.

However, user might treat those coins as if they we fungible.

[Alex Mizrahi]

Please also consider that having an expiry (maturity) of an asset greatly supports future scalability. There is no need to propagate coloring for events passed or bonds matured. 

Sorry, I think it is a bad idea to mix together coloring which is basically just tracking of ownership/accounting and business stuff.

Suppose that issuer have defaulted on his obligations. Now people take contract and go to courts. Colored coins they own now can be used as a proof that issuer owes them money, and courts can order to seize his assets to compensate bond holders.

But, ouch, coloring server thinks that this color is already irrelevant and stops differentiating between these bonds and uncolored coins. So investor cannot even see how many bonds he holds!

If he happens to spend from this wallet, his valuable bonds can be send as uncolored Bitcoins or mixed together.

Sure, it is possible to retrieve your address from this client and look it up on block explorer.

But why exactly should users go through this mess if their client is perfectly capable of continuing showing them bonds as bonds?

There is absolutely no reason to expire coins. It doesn't increase load on server significantly because in the model you're using one txout has one color, so at most you need as many database entries as many txouts are there. You keep txouts in database anyway, aren't you? Who cares if database requires 10% more space?

But, of course, if user thinks that there are no chances to get compensation from issuer, he should be able to tell client to stop differentiating coins of that color so that at least metal value can be recycled.

In general, I think that color server/client should be a tool for people to use (for ownership tracking and accounting), it shouldn't act as if it was a bank, i.e. it shouldn't try to interpret the meaning of contracts.

Also issuer (or other parties) should have no power over client software.

Asset definition just says "I, issuer, agree to this, this and this."

User can then instruct his client to track this asset. However, client works for user, not for issuer, so user can override anything.

How would you feel if there was a tag in an MP3 file which can be set to auto-delete file at some time?

Perhaps a person who created this MP3 file genuinely thinks that this podcast will be of no value in a couple of weeks, so auto-deleting it will save user's disk space.

But it should be up to user to decide whether he wants to keep file or not.

[Alex Mizrahi]

On Fri, May 3, 2013 at 2:26 AM, Jeremy Spilman <jer...@taplink.co> wrote:

Great feedback, thanks. 

Thank you too. You brought up a very interesting topic, and I think it we need to discuss it thoroughly.

It was brought up before and I think we need to consolidate information on this matter.

However, for the start, I think it would be great to create a minimal specification first.

You probably heard about "worse is better" philosophy, I'm afraid it is very relevant here, as there is a competition, for example, from Ripple.com, and if we wait to create a perfect spec and a perfect implementation, relevance of colored coins might get small even if they are solid.

I believe even a minimal thing can be useful in many niches. Maybe not for issuing billions worth of gold money. :)

However, of course we should not sacrifice long term functionality. If it is possible to start with minimal stuff and improve on it, it would be awesome. But sometimes cost/benefit analysis is necessary: if implementing something is hard and we can live without it, so be it.

 

I would strongly disagree that watching the block chain for spend-from-address is complex – in fact what could be more simple!

Well, FWIW it is already implemented in ArmoryX. It is indeed not very complex.

 

I think it’s complex to have to publish, distribute, and then get exchanges and maybe even individual clients to whitelist individual definitions over and over for the same color. If you are issuing GOLDcoin, it’s not like you can issue 100kg on Day 1, you need to prove reserves, which increase with adoption, and so regular, periodic issuance inline with market adoption should be expected. A spike in demand (which is unpredictable and subject to herd mentality) could mean even more frequent issuance. I’m trying to envision these long data tables where someone is supposed to check off the set of issues they trust for the same color on a daily/weekly basis. Sounds like a usability nightmare.

Well, there are several use cases:

1. Commodity trader: finds a reputable exchange, let's call it BTCME, which lists commodities he is interested in. He will instruct his client to trust everything which comes from BTCME as long as it isn't destructive (i.e. it doesn't modify semantics of coins he already owns). Of course, BTCME is responsible for finding reputable issuers, checking their reserves, checking their issues etc. There isn't even a need for timeout, although some paranoid trader might instruct client to apply it.

2. Long-term gold investor, wants to buy 100 kg of gold: He will manually inspect trustworthiness of each issuer on BTCME, buy gold from them... and that's it. No reason to watch issues.

3. Shareholder: Buys 15% of MacroSoft. One day his client says him "Hey, MacroSoft issued more shares". Dafuq? He calls MacroSoft executives and asks them what happened.

So, you see, it isn't "one size fits all", there are probably dozens of different uses of colored coins and they might require different user interface and client logic.

[Tamas Blummer]

On Friday, May 3, 2013 10:14:04 AM UTC+2, Alex Mizrahi wrote:

I am not convinced, that this is a great Idea. Please point me to the reasoning. I think a color is meaningful only if associated with terms that describe what it stands for and terms is nothing else then definition of the asset.

It is just a change in terminology, basically we just rename color to colored asset.

User's will never see "colors" in user interface of their client.

 

Yes, user will not see colors. They will see terms sheets describing what they hold and colors happen to be linked with them and be undivorcable to be meaningful.

 

You can also turn this around and see the same terms means same asset, same color that is fungibility of financial assets.

There is a purely technical reason to avoid mixing coins which correspond to different genesis txouts.

I'll explain it in details in a next message, but basically we know a lot of messy edge cases which can be prevented this way.

So again, we do not change semantics, we just:

1. Prevent software from mixing coins which descend from different genesis txouts to avoid potential problems.

2. rename "color" to "colored asset".

 

 

The motivation and effect of BIP30 is exactly to disallow same transaction hash. 

Please read BIP 30 carefully: it only disallows same transaction hash _within one block_.

They can still exist in different blocks.

 

This is plain wrong. I suggest you to read a couple of times the sentence quoted:

Specification

To counter this problem, the following network rule is introduced:

• Blocks are not allowed to contain a transaction whose identifier matches that of an earlier, not-fully-spent transaction in the same chain.

This rule is to be applied to all blocks whose timestamp is after a point in time that is yet to be decided.

 

BTW only coinbases have a practical chance to produce same hash without being a double-spend too.

No: you can spend from this coinbase to exactly same address to produce another tx with same hash.

We are working with crypto stuff, relying on "It rarely ever happens" is not an option.

If it is possible for an attacker to exploit this, then we need to protect against it.

This is why BIP30 is there to disallow even the unlikely.

 

 

color_asset_class is a collection of color assets which user thinks are more-or-less fungible.

WHAT? There is "no more or less fungibility" in finance!

Well, coins from different issuers are not fungible because they carry different counter-party risk.

However, user might treat those coins as if they we fungible.

Issuer is certainly part of the terms. I have seen a lot of term sheets but never ever one with issuer not specified. Have you seen one.

I am sorry Alex, but I have the feeling tht you do not even attempt to listen to my arguments that are both funded by 

long experience of finance and deep understanding of the Bitcoin protocol I gained while implementing it from sractch.

This project is heading to nowhere with your attitude.

 

[Yoni Johnathan Assia]

Hi All,

I thought that the seperation to color and asset was to enable "assets" to include multiple single colors.
This could support 2 streight forward expansions :
Have multiplle issuers to the same asset, a ripple like implementation over bitcoinx would allow several issuers to issue a USDCoin and have different colors each but have user X look at them as one asset (offcourse this requires more client side work)
Enable more felxibility in additional issuance of a specific asset, such that not all its colors are the same.

From my understanding it simply creates an additional meta data to the color definition, to allow future flexibility, specifically multi issuance color.

Tamas, Alex,
Can you help me understand the gap in definition ? Is it a semantics issue or a design issue ?

--

[Alex Mizrahi]

• Blocks are not allowed to contain a transaction whose identifier matches that of an earlier, not-fully-spent transaction in the same chain.

 

This is why BIP30 is there to disallow even the unlikely.

BIP 30 says that transaction with same hash can appear once previous one is fully spent.

Have you read the source code?

https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1592

// Do not allow blocks that contain transactions which 'overwrite' older transactions,
// unless those are already completely spent.


    if (fEnforceBIP30) {
        for (unsigned int i=0; i<vtx.size(); i++) {
            uint256 hash = GetTxHash(i);
            if (view.HaveCoins(hash) && !view.GetCoins(hash).IsPruned())
                return state.DoS(100, error("ConnectBlock() : tried to overwrite transaction"));
        }
    }


It checks whether duplicate transaction has any unspent outputs. 

If there are unspent outputs then block is rejected, otherwise it is accepted.


If you still disagree we can ask Pieter.

[Alex Mizrahi]

From my understanding it simply creates an additional meta data to the color definition, to allow future flexibility, specifically multi issuance color.

That's about right. Here's what it means for the implementation:

Colored coin implementation essentially consists of two parts:

1. (low-level) color-tracking engine: it can tell what is the color(s) of a particular coin (transaction output)

2. (high-level) wallet: it is responsible for actual handling of user's money: 

    keeping track of it, sending, user interface etc.

In the first version colors used by color-tracking engine were directly used by wallet.

This makes wallet simpler, but it means that all high-level semantics needs to be supported by color-tracking engine, which might be problematic. It might be seen as an impedance mismatch.

But now, I think, we can decouple these things: color-tracking engine should just do its thing according to the rules. But wallet can perform additional processing, for example, mapping colors it gets from color tracking engine to assets, and showing user balance summarized by asset rather than by color.

This additional processing is absolutely necessary to have multi-issuer assets. At least I see no other reasonable ways.

It can affect the way assets are issued too, I'm going to describe it in a comprehensive overview of options we have.

 

Tamas, Alex,
Can you help me understand the gap in definition ? Is it a semantics issue or a design issue ?

It depends on how you look at it...

1. It can be seen as semantics issue as wallets are not required to offer advanced features, they can just directly show colors to users. Wallet isn't required to be able to work with all "color definitions".

2. On the other hand, we probably want some standard features from wallet, then it is a design issue.

3. It also affects how colored coin asset will be issued.

I should note that I haven't yet described all implications, so it is too early to make conclusions.

[Jeremy Spilman]

Alex mentioned a couple days ago,

color tracking edge cases of “mixing coins which correspond to different genesis txouts.” 

The simplest case is you have two inputs which trace back to the same genesis.  Obviously these can be mixed into a single output, because they are by definition fungible, so no client would ever mistake the output as uncolored.

 

What if you mix inputs tracing back to different genesis?  I assume the problem arises if there is not universal agreement that those two genesis are actually fungible. One color tracker thinks you just mixed two different assets, and get an uncolored output. Another color tracker saw inputs as fungible and thinks the output is still a valid asset.

 

Either you need a universal (in the block chain) way to ensure everyone knows exactly which genesis are fungible, or you simply state, ‘inputs from different genesis must not be combined into a single output’.  I think spend-from-address does provide ‘single source of truth’ which allows inputs from different genesis to be combined safely, but in any case, it’s just an efficiency improvement.  You can still do everything you want even if you keep fungible coins with different genesis in separate outputs, it just may be marginally less efficient.

 

If we say a ‘color’ is exactly one genesis, then of course next thing is to map one-or-more colors into an ‘asset’, and attach a single issuer and term sheet to the asset.

Asset issuer must be able to strictly state that all colors of a given asset are fungible – actually, that’s exactly what they are doing by attaching the same term sheet.

While it’s technically possible to differentiate between such coins based on their genesis, it’s like differentiating between bitcoins based on when they were mined – no exchange actually works that way, and therefore there’s no arbitrage opportunity.

 

However, there’s another level of ‘fungible’ that can occur, this idea of the Ripple use case where assets from different issuers are treated as fungible. I think this is a user interface detail – if user wants to see a single line-item in their wallet which is actually multiple different issuers’ assets underneath, and place a single bid/ask which can be fulfilled by any of those assets, certainly one day there may be a wallet and an exchange which can support it. The obvious difficulty is that every individual will have non-overlapping sets of assets which they consider fungible, which makes for interesting order-fill algorithms to say the least.

 

The one thing I would ask is, keep this higher level of notion of users being able to ‘trust-as-fungible’ separate from the baseline notion that one-or-more genesis of a single asset is fungible.

 

 

 

 

 

 

 

[Tamas Blummer]

Alex,

The only probable case that two transactions have the same hash is if they are coin bases. In any other case a source hash is part of the transaction therefore it is extremely unlikely that it has the same has and is not a double spend. The likelihood that the hash is identical while it is not a double spend or coin base is as low as the likelihood of finding a block with the same hash of the genesis.

Therefore the condition that a tx has to be fully spent to re-use tx hash is only relevant within reason for coin bases. Using your approach for color definition is only relevant if you insist on using coin bases as color genesis.

Using a coin base as color genesis is however an extremely unlikely business case since the issue size is fixed by rules of Bitcoin.

In summary, you are bending reason and ignoring my arguments for a slightest deviation of your "standards".

[Tamas Blummer]

Let me try again to make my points on what need to be changed in the color definitions. I raised these previously and were repeatedly ignored without convincing counter arguments by Alex.

1. The genesis transaction should be identified by its hash not block offset. I wrote in a previous mail why this is permissible. The reason for this is that using Block and offset implies that full blocks have to be available on the verifying side to figure what the offset means. Pruned blocks or block headers are not sufficient. The primary objects of Bitcoin are transactions a sequence of transactions together with block header and pruned blocks (SPV) could prove a color allocation if transaction hash is the genesis, while it would not be sufficient if it was the index.

2. There should be a maturity on the definition. This is both a a requirement practical for implementations, since they can stop propagating color for an event in the past and financial requirement since maturity is part of the wast majority of financial terms.

3. The color has to be uniquely linked with the terms it represents, since without terms there is no meaning to a color. Because of this one-to-one relationship it would also be wise to use the term's hash as the color's name or unique identifier.

4. Fungibility of assets is given if they have the same terms, that again supports identifying colors with hash of the terms, so they can be merged if identical even if they are descendants of separate color genesises.

[Jeremy Spilman]

>1. The genesis transaction should be identified by its hash not block
>offset

Everyone agrees pointer to genesis will include Tx Hash and out index. Alex
suggested additionally including a block_number aka ‘height’ to address the
BIP30 corner case, fine, let’s move on. I don’t know what you’re talking
about ‘offset’, no one suggested trying to pick genesis as the n’th
transaction in a block, if that's what you mean?

> 2. There should be a maturity on the definition

I understand the use case for a ‘maturity’ property, and of course it makes
perfect sense for issuer to specify a maturity in their terms. However,
there’s a big difference between ASCII text in the “terms”, and some
property in the color definition which changes how all color trackers and
wallets should behave. Alex wrote a long response on this, I’m sorry if you
missed it. What you’re actually talking about is an auto-destruct feature,
presumably based on a UTC timestamp, which in theory would only be used for
an asset where the value was absolute zero after that point. ‘Maturity date’
may say when principle is due, that doesn’t mean principle is necessarily
paid at that instant. For some bonds, redemption amount may not even be
possible to calculate until maturity. There's no legal reason the holder of
record can't change after the maturity date. Or a company in bankruptcy may
be negotiating a haircut with bond holders over the final principle payment.
In any case, you don’t want wallets automatically melting assets based on a
timestamp. Let’s keep ‘maturity’ in the “terms” and let the color tracker
remain blissfully ignorant. Users can always melt an asset whenever they
choose.

> 3. The color has to be uniquely linked with the terms it represents, since
> without terms there is no meaning to a color. Because of this one-to-one
> relationship it would also be wise to use the term's hash as the color's
> name or unique identifier.

Are you talking about specifically how to display the name of the coin in
the wallet UI? I think it's an implementation detail that can be left to the
exchange/wallet designer.

> 4. Fungibility of assets is given if they have the same terms, that again
> supports identifying colors with hash of the terms, so they can be merged
> if identical even if they are descendants of separate color genesises.

When you say ‘merged’ do you mean multiple inputs into a single output on
the block chain? Or just from a user interface perspective? Please see my
email earlier today on this topic. Single output on the block chain is a
single color. A multi-genesis color requires a universal point-of-truth for
identifying the genesis outputs, like using a spent-from-address. There may
be other issues I haven't considered, so I'm also waiting to see what Alex
writes on this.

[Alex Mizrahi]

1. The genesis transaction should be identified by its hash not block offset

Everyone agrees pointer to genesis will include Tx Hash and out index. Alex suggested additionally including a block_number aka ‘height’ to address the BIP30 corner case, fine, let’s move on. I don’t know what you’re talking about ‘offset’, no one suggested trying to pick genesis as the n’th transaction in a block, if that's what you mean?

There is another reason to add block height: it can be a hint for thin clients who traverse blockchain backwards looking for genesis. 

They can simply assume that all outputs before this height are uncolored.

I'm not sure whether this optimization is necessary, but it doesn't hurt.

[Tamas Blummer]

On Sunday, May 5, 2013 8:12:22 AM UTC+2, Jeremy Spilman wrote:

>1. The genesis transaction should be identified by its hash not block
>offset

Everyone agrees pointer to genesis will include Tx Hash and out index. Alex
suggested additionally including a block_number aka ‘height’ to address the
BIP30 corner case, fine, let’s move on. I don’t know what you’re talking
about ‘offset’, no one suggested trying to pick genesis as the n’th
transaction in a block, if that's what you mean?

The corner case he is addressing is absurdly low probability. One could as well

be worried of keys with same address (that is in fact much much more likely since 

only 160 bits in contract to 256 in tx hash).

His latest argument of using the height for optimization of scans is weak.

Yes I was afraid of even worse. Thanks for putting this straight.

> 2. There should be a maturity on the definition

I understand the use case for a ‘maturity’ property, and of course it makes
perfect sense for issuer to specify a maturity in their terms. However,
there’s a big difference between ASCII text in the “terms”, and some
property in the color definition which changes how all color trackers and
wallets should behave. Alex wrote a long response on this, I’m sorry if you
missed it. What you’re actually talking about is an auto-destruct feature,
presumably based on a UTC timestamp, which in theory would only be used for
an asset where the value was absolute zero after that point. ‘Maturity date’
may say when principle is due, that doesn’t mean principle is necessarily
paid at that instant. For some bonds, redemption amount may not even be
possible to calculate until maturity. There's no legal reason the holder of
record can't change after the maturity date. Or a company in bankruptcy may
be negotiating a haircut with bond holders over the final principle payment.
In any case, you don’t want wallets automatically melting assets based on a
timestamp. Let’s keep ‘maturity’ in the “terms” and let the color tracker
remain blissfully ignorant. Users can always melt an asset whenever they
choose.

Yes, to use your description it is a self destruction feature, that however

corresponds quite often with business terms of the color. Should there be

a mismatch, so the color need to be re-issued before terminating. The

self destruction however is needed to contain pollution with colors that

got irrelevant long ago. 

 

> 3. The color has to be uniquely linked with the terms it represents, since
> without terms there is no meaning to a color. Because of this one-to-one
> relationship it would also be wise to use the term's hash as the color's
> name or unique identifier.

Are you talking about specifically how to display the name of the coin in
the wallet UI? I think it's an implementation detail that can be left to the
exchange/wallet designer.

No, I am talking about the unique identifier of the color on the lowest level.

The hash of the terms appears to be the right thing for me.

 

> 4. Fungibility of assets is given if they have the same terms, that again
> supports identifying colors with hash of the terms, so they can be merged
> if identical even if they are descendants of separate color genesises.

When you say ‘merged’ do you mean multiple inputs into a single output on
the block chain?  Or just from a user interface perspective?  Please see my
email earlier today on this topic. Single output on the block chain is a
single color.  A multi-genesis color requires a universal point-of-truth for
identifying the genesis outputs, like using a spent-from-address. There may
be other issues I haven't considered, so I'm also waiting to see what Alex
writes on this.

Assume an instrument is re-issued e.g. a Bond is tap-ed, that means 

there is a new genesis of the same color, should those meet in a transaction

then they should have the same color and be able to merge. This is

I refer to with fungibility and that served well with color id derived from terms. 

[Jeremy Spilman]

> The corner case he is addressing is absurdly low probability.

We're not concerned about collisions. The attack is not 'trusted issuer X'
identifies a genesis of hash = H, and then an attacker can craft their own
transaction with the same hash = H. That would require a second pre-image.
I think the corner case is 'malicious issuer Y' identifies a genesis by
hash, but it turns out that specific hash can be easily reproduced on the
block chain.

>The self destruction however is needed to contain pollution with colors
>that got irrelevant long ago.

There's nothing stopping an exchange from delisting an asset, or a wallet
from melting an asset, based on their own policy. I don't think "pollution"
is the right analogy -- no one is forcing anyone to track a color they don't
care about. Again, of course expiration will happen, I just don�t think it's
a fundamental property of color tracking.

> No, I am talking about the unique identifier of the color on the lowest
> level. The hash of the terms appears to be the right thing for me.

Could you be more specific of how you think the hash should be used? You
want it on the block chain somewhere? Or perhaps just a way for multiple
parties to identify which asset they are trying to trade.

> Assume an instrument is re-issued e.g. a Bond is tap-ed, that means there
> is a new genesis of the same color, should those meet in a transaction
> then they should have the same color and be able to merge. This is
I refer to with fungibility and that served well with color id derived from
terms.

I think the key problem with merging coins from multi-genesis is to ensure
there is universal agreement those coins have the same terms. You still need
a way to map terms, or 'color id', onto a set of genesis transactions. I
suggested defining genesis as "spend-from-address" to solve this, not sure
what you think of that. Having a color id derived from the terms could be
useful, but I don't think it solves this particular problem.

[Tamas Blummer]

On Sunday, May 5, 2013 11:06:47 PM UTC+2, Jeremy Spilman wrote:

> The corner case he is addressing is absurdly low probability.

We're not concerned about collisions. The attack is not 'trusted issuer X'
identifies a genesis of hash = H, and then an attacker can craft their own
transaction with the same hash = H.  That would require a second pre-image.
I think the corner case is 'malicious issuer Y' identifies a genesis by
hash, but it turns out that specific hash can be easily reproduced on the
block chain.

We agree that random collision is not likely. An attacker would have to

create a transaction that is first of all valid under the Bitcoin rules. One of the

rules is that it has to refer an unspent source, therefore it can not refer 

a the source of the original as that would be a double spend and rejected. 

Therefore finding a transaction with different source (that is with a content

differing at least in 256 bits) but with the same hash is an effort only 

comparable with mining on maximal difficulty. Not feasible.

 

>The self destruction however is needed to contain pollution with colors
>that got irrelevant long ago.

There's nothing stopping an exchange from delisting an asset, or a wallet
from melting an asset, based on their own policy. I don't think "pollution"
is the right analogy -- no one is forcing anyone to track a color they don't
care about. Again, of course expiration will happen, I just don�t think it's
a fundamental property of color tracking.

A node might pre-compute coloring until reaching the height the color definition

expires. Such pre computation would dramatically speed up queries of output 

colors, but is only feasible on the long run if there is a rule to expire 

and that rule does not require knowledge of terms just definition.

> No, I am talking about the unique identifier of the color on the lowest
> level. The hash of the terms appears to be the right thing for me.

Could you be more specific of how you think the hash should be used? You
want it on the block chain somewhere?  Or perhaps just a way for multiple
parties to identify which asset they are trying to trade.

The hash of the terms would be the unique identifier to refer to a color. By the same

argument transaction hashes are a good identifier for transactions.

> Assume an instrument is re-issued e.g. a Bond is tap-ed, that means there
> is a new genesis of the same color, should those meet in a transaction
> then they should have the same color and be able to merge. This is
I refer to with fungibility and that served well with color id derived from
terms.

I think the key problem with merging coins from multi-genesis is to ensure
there is universal agreement those coins have the same terms.

Yes, this is why hash of terms is the right way to refer to a color. 

 

You still need
a way to map terms, or 'color id', onto a set of genesis transactions.  

This is not an incremental problem with multiple genesises of the same color,

but a question even for a single genesis.

 

I
suggested defining genesis as "spend-from-address" to solve this, not sure
what you think of that. Having a color id derived from the terms could be
useful, but I don't think it solves this particular problem.

I do not like spend from address since it adds complexity to address a feature

we could have just by repeating the rules of the genesis transaction. 

The color definition could list several genesis transactions, or we might 

have several subsequently issues creating the same color 

(identified by same terms -> same id) 

There are use cases for multiple genesises e.g.  issue size increased

or an issue has to be split. 

Increase:

An asset with particular terms might be so popular, that issuer decides

to create more of it. The new genesis transaction has to create a color

that is fungible with descendants of the earlier to be really the same.

If in addition the color's identifier is the hash of its terms, then fungibility

is given by terms.

Split:

Assume a color refers to an event that needs to be rescheduled to

take place at two time points or locations. The issuer could retrieve current

allocation of the color and issue new colors with genesises matching any of

the current allocations.