Topic: colored bitcoin tech discussion - page 3. (Read 13197 times)

Each smart property token has its own separate block chain storage, just like individual bitcoins.

Additionally, if you want a fully auditable system -- we do -- then you need a commonly agreed way to make payments to token holders (asset owners) viewable and traceable in the block chain.

That way, you can see which issuers are paying as they claim.

Only the issuer needs to have any block chain bulk, so the Asset Issuer ID, the Bitcoin Address -  are the same thing.

Over in Open Transactions land there has been talk about integrating something similar to killerstorm's (kthbye) colour coined idea.

Here is the pastebin (I wrote, randy copy edited):

http://pastebin.com/raw.php?i=ygVyaBPL

It involves a non-trivial amount of work...  However it will make OT and Bitcoin fundamentally interchangeable!

As I'm thinking of using coloured coins to manage a 180(GH/s) mining asset and pay dividends using them.  Would it be possible to create 10,000,000 coloured (satoshis) coins from BTC1.00 only giving out 180,000 of them and only have dividends paid to the 180,000 given out while the remaining 9,820,000 coloured coins don't receive any dividends until they are given out in transactions.

Yeah, I know. I just meant to say that we do not need to denote "number of units" when we work with physical property like cars: one car is one unit which is controlled with one output. Thus output's value isn't relevant, it can be anything, even zero.


"Multicolored coins" are just as theoretic oddity which can arise from ambiguity in a coloring scheme which doesn't use explicit tagging.

It works for cars...  as long as the car's security system is keyed to anyone who can prove they are the holder of the smartcoin.  Your mobile phone can easily generate an ECDSA-signed message proving this, given the proper key.  And Wired articles like this one show that it is feasible near-term for a mobile phone to be your car key.

It should be straightforward to trace a 1-satoshi output through the chain, to prove to the car's bitcoin API that the mobile phone is last holder of that coin, following standard colored coin rules.

Frankly, multiple colors of coin are not that interesting to me.  The main point is simply proving that (a) a given txout represents car ownership, traceable back to the "root property," and (b) you have the key associated with that txout.

To me, the basics are fairly simple: Within a single bitcoin transaction, you must distinguish between a smart property transfer and payment transfer, and ensure the two don't mix.  You must also ensure smart property transfers don't mix.

LOL.

No, with order-based coloring we won't get into such situation because coloring information is easily destroyed when coins are mixed. You can only get into funny situations only if people make funny coins.

If it's still a problem we can add mandatory tagging, then coin's meaning will be totally unambiguous.

So it's more like same molecules of gold being reused for various types of coins rather than "palimpsests". Perhaps you can find that your Krugerrand's gold is related to gold used in ancient Rome through chemical analysis, but that doesn't make any difference.


Hmm, perhaps we should implement multicoloring and satoshi-tracking just for shits and giggles


Again that's kinda unlikely scenario. To activate a wrong property you need:

1. Somebody to transfer you a coin which controls smart property. Erroneously, since otherwise it is a legit trade. That would be sort of hard because he'll have a separate wallet for smart coin. So, well, one needs to extract private key from that wallet, import it into his main wallet and send it to somebody else. Accidentally. It's probably easier to shot yourself in the head twice accidentally.

2. Property needs to be aware of transfer of ownership. Unless you tell it explicitly, it should be a very smart property which is connected to internet... (In Mike's example, new owner needs to prove to his car that he is indeed a new owner.)

3. Smart property is activated with a message signed with owner. So a new owner needs to

a) know what message unlocks his property
b) sign that message
c) send this message to property

Again, it's unlikely to happen accidentally

Additionally, it's possible to disambiguate transfer of property with OP_DROP message tagging.


Why not, they can all track same coin. But that must be intentional.

I.e. normally one who creates smart property would make a single output tied to it.


Right.

Actually I see colored coins as an extension of smart property protocol. It is smart property when you have one indivisible unit. Its ownership might be controlled with just one output which has 1 satoshi, for example. Or even zero satoshis, apparently you can transfer an output with zero satoshis in it. (See Mike Hearn's "distributed bond market". Bonds are tagged with message, by the way, so no ambiguity is possible.)

With colored coins value of output represents how many units you own. So instead of making 100 outputs each representing one bond, one can make just one output with 100 satoshis in it, with 1 satoshi representing one bond.

So colored coins just allow one to represent ownership of many units in a more compact blockchain format... It makes a lot of sense for things like currencies, bonds... But not for cars, I guess

Sounds like we're going to get a really messy bunch of non-fungible palimpsests, with almost every coin in everyon's wallet coloured hundreds of different colours depending on which of hundreds of thousands or maybe even millions of colour-definitions you try to load into your client at once, with massive numbers of those colour-definitions conflicting with each other and a growing frequency of news articles describing yet another person who had not heard of some obscure but extremely valuable security so sent it as fees to miners instead of running a coinoogle search for any and all possible coin colours they could choose to view their coins a and a coinfroogle search for which of the possible permutions of colours would result in the highest value for their wallet as a whole.

I hope this whole colour mess is not how smart property was envisioned. I had thought smart property had seemed like an actually quite smart idea but if it is like these colours what happens when some poor sod uses what he views as his garage door opening colour only to learn the hard way that someone else had already designated its ancestors as a demolition blasting-cap activation colour?

In short, I had thought the uniqueness of each share ceritificate, automobile ownership etc "colour" would be better preserved, so that when you created a "colour" representing ownership of your car it would not turn out to be someone else's car ownership certificate too.

Or is that intentional, that you can end up for example with many many cars whose ownership is all transfered by the same satoshi or coin or whatever?

Baically I thought how it was to work is blue means my automobile, red means your automobile, green is our next door neighbor's automobile and so on, one "colour" per item of smart property?

-MarkM-

Let's clarify the terminology here.

Coin of mixed heritage becomes uncolored. I.e. if you combine 1 red and 1 blue coins into one output, that output is 2 uncolored coins.

Multicolored coin is a coin whose color heritage can be traced down to more than one color definition. I.e. a coin is both a valid red coin and a valid blue coin.

In theory, client can identify that case and show coin as multicolored. But I don't think we are going to implement this anytime soon, let's just say it is a remote, theoretic possibility.


That third place will get two separate coins (formally speaking, transaction outputs). Depending on whether blue definition is enabled it will either show them as, for example, 1 red and 1 blue or as 2 red.

However, if you turn off blue definition and send it to a fourth place, client will naturally melt these two coins into one. A red one.

If you enable blue color in that fourth place, then it will show it as uncolored because it sees red and blue mixed. Shit.

But that's just because we don't have first class support for multicolored coins in our algorithm. It's certainly possible to make an algorithm which would preserve color here (i.e. this mixed output will be recognized as 2 red coins. Basically, "lowest common denominator").

Moreover, there is even a proposal for satoshi-level coloring. In that case even mixing won't destroy any color information.

But I think for the start a simple order-based algorithm will do fine. Just don't make multicolored coins and switch definitions on and off and you will be OK

If there will ever be a need for multi-colored coins, or if it will turn out that mixing is a real problem we can always make a more advanced algorithm which will stay compatible with the old one. (i.e. order-based coloring.)

Ah, you aren't turning multicoloured coins into a generic mucked up colour then?

I can create a source of red coins, send them two two different places, then invent blue coins, use one place's red coins as the coins to turn into my new colour blue, then send some red and some blue to a third place and that third place will be switchable from being red or "purple" depending on whether I choose for a moment to follow red or to follow both blue and red?

-MarkM-

Color definitions are not exclusive, they can overlap.

Let's say you have 100 black coins. Then you want to buy 1 red coin. But 1 red coin was made out of 1 black coin for some reason.

That is not a problem. If you import red definition and and buy a red coin, your client will tell you that you have 100 black coins and 1 red coin.
The thing is, red color definition affects only coins which were issued through it, and so your black coins will be unaffected.

If red company goes bankrupt, you can erase red definition and then your client will show that you own 101 black coins. Yay!

Perhaps client software should issue a warning when colors overlap, and especially when it affects coins you already own.

If you find some color definition suspicious just don't import it and it will be fine.


The whole point is NOT forcing anybody to do anything. Coloring is essentially a convention, it is very flexible.


Well, client software definitely should protect users from preventable errors. It will choose only uncolored coins whenever you want to issue something.

A special address format will prevent users from sending coins of a wrong color. For example, you want to buy something for 100 "USD coins".
You should first select "USD coins" in currency list, and then you'll enter address merchant have given to you. This address will include information that "USD coins" are requested. Client software will allow you to create transaction only if color definitions match. Otherwise you need to find what's going wrong: perhaps merchant made an error, or he wants a different kind of coins...


Difference between color and taint is that taint is contagious, while color isn't.


It makes absolutely no difference in examples above: even if color is written into blockchain, colors still can overlap, i.e. somebody will recolor some black coins into red coins or something.

It will work exactly the same as with color definitions, but with color definitions you are free to undo that recoloring if you want.


We have considered embedding color meta-information into blockchain.

But it appears that certain protections can be implemented on client-software leel without changing in-blockchain format, and those protections are in fact necessary in any case. So meta-information in blockchain offers very few advantages.

Still, it's not something completely ruled out. For example, tagging with OP_DROP messages might be used... when this txn script will be approved. But it's hard to find benefits.

If anything, tagging in blockchain might make mess with overlapping colors worse because

1. you'll be automatically subscribed to all kinds of bullshit coin issues
2. color tag might be erroneous, then what?
3. you cannot 'undo' color definition

Anyway, the difference between these approaches will be visible only in some obscure corner cases. As long as people simply use client software and do not try to circumvent built-in protection which doesn't allow user to shot himself in the foot they'll be ok.

So I am going to "forget" my Best Grade A Company On The Chain corp because I am considering dabbling in the nanobit-stocks market by picking up a few of your newly made up no-body-shares?

I doubt it.

All you are doing is forcing people to throw away estsblished, valuable shares if they want to participate in the paonzi of the nanosecond market.

Really, check the damn coin is not coloured before trashing it.

Otherwise someonje is going to trade their birthright for a mess of pottage, as the swaying goes, by not understanding the value of the coloured coin they are about to trash to create a worthless pretend stock to see how your system works, and stuff like that. (n short, they will find out the hard way it does not work...)

You seem to be basically using taint, not colour. Taint anyone can claim yeah that output there, that is stolen coins!

Colour should be something in the blockchain itself that announces the genesis of a new colour.

I don't think taint that follows the colour algorithms as to what/how it taints is at all the same thing as an actual colour.

-MarkM-

This isn't a problem because when you issue a new color you essentially redefine meaning of a coin.

It doesn't matter whether coin was previously uncolored, or it was a mix of some colored coins, or it had some color.

Whoever is aware of your color definition will now recognize your coins and will "forget" about previous meaning they had.

For example, if you used a "black" coin output to issue "red" coins, whoever uses your definition will now see it as a red coin, regardless of whether they are aware of "black" coins.

People who are aware only of "black" coins and not "red" ones will effectively see all "red" coins of this issue as "black".

Confusion can happen only in some edge cases, and even then it can be resolved without much effort:

Client software will make sure that you'll get coins only when you know what they are, i.e. to receive red coins you need to import definition of red and ask specifically for red coins. Now somebody owning red coins might deliberately delete "red" definition and client software will revert to previous meaning they had: "black". Now he can sell these coins as black to people who are not aware of "red".

Thus somebody might buy "black" coins which are in fact "red"... But this isn't a problem because:

1. if red coins are more valuable he can simply import definition of red and sell them as red
2. if black coins are valuable he can expect that other people will eventually delete definition of red and will recognize these coins as black

Perhaps there are even uses for this feature... Suppose "black coins" represent shares of a Large Company. This Large Company might want to spin-off one of its divisions. Spin-off's shares will be represented with "red coins" which are made out of "black coins".

In that case spin-off's shares will never be priced below Large Company's shares because they are essentially convertible back to Large Company's shares.

In the same way Large Company can provide guarantees for bonds of its Spin-off..


When coins of different colors are mixed they become uncolored.

If there is no special entry in the blockchain that recognisably inaugurates a colour, you will not even know whether your local pretense that a particular output is a particular colour is actually the case or whether, rather, your purported colour is actually a confused mish-mash of colours already inaugurated earlier in the blockchain.

Maybe that does not matter, maybe it is okay that people who are aware of more colours than you are realise that your company's shares, for example, are actually a mix of 33% company X's shares, 45% company Y's shares, 20% company Z's shares, 1% no-longer-coloured coins and 1% never previously coloured coins?

-MarkM-

That largely depends on issuer's quality standards, i.e. whether he would want to use experimental software with god-awful UI.

Otherwise... I've implemented coloring backend for Armory this week, it just needs a bit polishing. And some wiring to wallets and GUI.

If everything goes fine I'll guess I'll have some proof-of-concept for Armory this week, and maybe some exchange prototype next week.


From what I gather it is an implementation which allows only one color per transaction..  Comment in code:


I had a basic version like this about a month ago, you can find in in form of bitcoind mod here: https://bitcointalksearch.org/topic/chromawallet-colored-coins-issue-and-trade-private-currenciesstocksbonds-106373

But to implement an exchange we need to include coins of different colors (say, colored and non-colored) in same transaction, so that they can be exchanged atomically.

This is more complex, so it took me a while to design an algorithm which does that and find how to implement it efficiently.

So let's just say I'm not impressed with that guy's work, essentially it is just a commandline interface which looks handy, but technically it is functionally equivalent to a basic prototype I've made a month ago...

Coloring is done recursively starting from "genesis transaction output". Genesis transaction outputs are defined in configuration. E.g. you'll have a file saying that "transaction XXXXX output 0 is color YYYY also known as USDcoins".


That's one of ways to do that, but I'm currently for configuration file approach... It doesn't matter much because approaches are compatible with each other: we can start with configuration file (or even colors defined directly in client code! That's what my proof-of-concept does), then, maybe, define a way to import color genesis data directly from blockchain.

Basically a low level color tracking engine is told what it should track by some higher level. Which can be anything: configuration file, blockchain scanner, DHT, RSS feed.. Whatever.


If genesis TXOs are defined via blockchain it's simply not possible to miss it if we have access to a full blockchain.

However I'm currently considering implementation where colors are tracked at will. If you don't care about color green, don't track it. Nobody will send you green coins. But if you need to accept green coins, you import green coin definition and client software performs blockchain scan and starts tracking them.


This is exactly how it works now.

The only question is when computation is done. I think it's a good idea to cache color information in color db so you won't have to rescan blockchain repeatedly.

But it's also possible to run it on demand.


Yes, this is how I think it should work. But it's very likely that you want to define new color using a special client software which would create txo with appropriate amount and will generate definition which refers to that txo. The reason is that software will ensure that you won't accidentally spend your freshly colored coins.

But you can do it using blockexplorer if it's your thing... That's how I made test color definition in code, actually.

How do you know whether any of the inputs are coloured at all?

Don't you have to scan the entire blockchain looking for some special kind of transaction that by convention represents the inauguration of a colour?

Surely if you miss such a transaction you are not properly colour-enabled, and it is only by missing (or forgetting) an inuguration event that you can fail to know what the colours are of all inputs and outputs in the entire blockchain?

Maybe you need a backwards colouring algorithm, that can backtrack each input until it either is clearly a mixed colour or is traced back to the inauguration of its colour or arrives at the genesis block of the blockchain and thus is a pure original uncolouredness?

Or are colours external and ubiquitous, for example such that anyone can point at any transaction anywhere and say that there is the colour I mean, identifying it by the transaction number or possibly the transaction number and output number of that transaction, and like taint they have created specified in that after-the-fact moment a colour within that moment's context?

(Like taint: any time any one can claim any output of any transaction is criminal/illegal/tainted and it is from there traced onwards through the chain.)

-MarkM-

Here's a thread specifically about order-based coloring algorithm: https://bitcointalksearch.org/topic/order-based-coin-coloring-114571

Everybody who is interested in coloring algorithms should watch it as I'll post updates there, not here.

The main difference between a new altcoin to colored bitcoins in order to create/maintain/exchange :
A new altcoin needs sufficient clients/nodes/miners to support its security
To scale mining in altcoin you need miners to support merged mining in that altcoin
You need a client/exchange that support distributed contracts to exchange one coin to another

With colored bitcoin
Colored bitcoins are based on bitcoin (or the chain they are on) security, so transaction are as secure
No need to maintain any mining of its own, miners are agnostic to colored bitcoins
To send/receive colored bitcoin all you need is a client support

I believe there is a need for both solutions, and all altcoins can support colored altcoins, the altcoin is flexible to changes in its blockchain and colored altcoin relies on existing blockchains.
Recoloring, or exchanging one color is simply an atomic bitcoin transfer, one client send another Color X and gets Color Y, with the price discovery of the rate as simple as calculating X/Y.

“That’s been one of my mantras — focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.” Steve Jobs

Thanks. Looks like I do need to read more on this. I want to see how exception and rollback are handled, if something goes wrong and trade fails.