A public letter to ColoredCoins.org/Colu

[Alex Mizrahi]

I'd like to inform you that I no longer wish to be a part of coloredcoins.org and its "Community Board of Directors".

The reason for this is that this "Board of Directors", whatever it is, doesn't function.

I was listed as a team member on ColoredCoins.org web site since its creation in 2013, and back then we actually had discussions about the standardization and implementation efforts.

However, this community process was slow (too many people talking, too few working), and for this reason I and Henrik Hjelte organized a company (BitContracts.org, which later became ChromaWay) to focus the implementation efforts. However, we still were public with what we are doing, all our software was developed on github and all our decisions were documented in the bitcoinx mailing list.

In the late 2014, Amos Meiri invited us to get involved in a new standardization process.

We were excited about it, as it was a real chance to defragment the colored coins community.

However, there was no process, so to speak... They asked us about a list of requirements, which we provided. And that's it.

There was no discussion, we got no information about an upcoming "standard" or anything. We have repeatedly asked if we can attend the next meeting, but the meetings never occurred.

And nobody have ever asked my opinion as the member of the board, particularly, there was no voting process. (And what opinion could I provide if I had no information?)

Later it became apparent that ColoredCoins.org is just a PR arm of Colu. The domain name was previously used by the open-source project, and the text is now copyright Colu. Nominally there were more people involved in ColoredCoins.org, but those who weren't associated with Colu had no actual involvement.

It's worth noting that I'm not the first member of this "board" to leave it, but I just want to make things clear to avoid possible misunderstanding.

Our software (coloredcoinlib, ngcccbase, cc-wallet-core) was designed from ground up to support multiple color kernels at the same time. During the research phase we implemented five different kernels, for example. We plan to add support for different kernels/protocols according to their technical merits, regardless of "standardization" claims.

In normal language the word “standard” stipulates either that more than one actor is involved, or a market-share that is dominant. Neither seems to apply to the work on coloredcoins.org.

I was the first person to start working on Colored-coins back in 2012, and the one to start and lead it as an open-source project for several years. The work we do at ChromaWay is still open-source and you can follow our work on github. That is the way open-source should work in our opinion, you release early and can follow and contribute to the progress.

--

Alex Mizrahi and ChromaWay team

[me...@bitcoin.org.il]

It's sad that it had to come to this, but I completely understand.

I don't know all the facts and I'm open to be persuaded otherwise, but it does seem that what Colu is doing, is either a hostile takeover of an Open brand, or ostensibly indistinguishable from one.

[Amos Meiri]

Dear Alex

I don't want to start an "email spam exchange" about who is right or wrong, we were there before, i respect you and it didn't work out the last time (i will not answer to "all" on your next email).

 

Non of the content in Colored Coins is mentioning COLU more than ChromaWay or other implemantations, so the "PR" for COLU is exactly the same as for your company. all of the content and future code in Colored Coins is going to be open source. Following your request we will remove you from the website.

During the process of working with you we were feeling there is no partner and suggestions for meetings or improvements  in regards to your protocol were not an option. This is why we decided to build a new implementation for Colored Coins that we will publish by end of month and is going to be 100% open source including other tools, all of them are open source for the community to review and develop on top. 

You are right, you are the first developer to work on Colored Coins, I am sad you do not want to take part in it and i wish you good luck with your new company,

Meni - I would love to meet and talk. As a disclaimer it's important to mention you are an official adviser for Chroma Wallet, Alex's company.  

Bests,

Amos

--

Amos Meiri

Founder&CEO

COLU

[me...@bitcoin.org.il]

I don't have a stake in Alex's company, nor do I receive any compensation from them. My role in this space has always been a wildcard offering help to various colored coins teams. Some have welcomed my help more than others.

[Alex Mizrahi]

You are right, you are the first developer to work on Colored Coins, I am sad you do not want to take part in it

I'm still taking part in colored coins, just not ColoredCoins.org. 

Largely because it turned out to be impossible to take part in it: we received no information about your upcoming protocol, and our requests to talk about it were dismissed. So how exactly could we "take part" in it? You gave us no chances.

If you take a look at our github page (https://github.com/chromaway/) you can notice that we are still working on ngcccbase, a colored coin wallet which I started in 2013, as well as on other colored coins projects.

So we are working on colored coins, just not on your brand of it.

 

and i wish you good luck with your new company,

Thanks. FYI our company is 4 times older than yours.

[Amos Meiri]

We would love to get your help, will email you in privet for a meeting.

On Fri, May 8, 2015 at 6:18 PM, <me...@bitcoin.org.il> wrote:

I don't have a stake in Alex's company, nor do I receive any compensation from them. My role in this space has always been a wildcard offering help to various colored coins teams. Some have welcomed my help more than others.

[Gideon Greenspan]

Hi Amos,

We (CoinSpark) appreciate this initiative to create a standard and are happy to be involved. It would therefore be extremely helpful if you could publish a draft of the protocol you are working on, as soon as possible, so that an open commenting process can begin.

I am concerned that without this kind of process, this "standard" will leave the image of Colored Coins in a worse situation than before, since there is a risk of all three existing protocol developers (CoinSpark, ChromaWallet/EPOBC, CoinPrism/Open Assets) never actually supporting it.

As I'm sure is also the case with Colu, some of us are talking to serious customers and already building systems for real-world deployment. Having a single standard will help lift all of our boats. But I haven't even mentioned this upcoming standard to our customers yet, since I have no idea when it's coming out, how it's going to look, and what features it will support.

If you don't want an open process, that's completely fine. But In that case it would be better to simply call it the "Colu protocol", and then there will be four :)

Best regards,

Gideon Greenspan

Founder and CEO

Coin Sciences Ltd

http://coinspark.org/

[Yoni Johnathan Assia]

Coloredcoins is an idea, and idea is bigger than one standard or one protocol, its the idea of coloring coins on the blockchain to represent assets.

Coloredcoins inspired many projects, from counterparty to mastercoin,  to ethereum, its community was here and was involved in coloredcoins.

This is an open discussion where different participants try different things, Alex is one of the most talented bitcoin 2.0 developers on the place, but he is very protective of his ideas and didn't even consider Vitalik ideas and spec - it happens to the best of us.

The Colu team was formed to build a business for themselves on top of coloredcoins, and they raised money from VCs to do so - they have a strong incentive to make coloredcoins an open source protocol and for it to become a standard - because their business is based on it.
They have been working for the past couple of months on spec and code base that they plan to release soon for a closed group first, and be happy to get feedback and work with everyone to improve it.

Ideally with time all bitcoin 2.0 protocols will converge to one coloredcoins standard - but that will depend on adoption by users, clients and companies that support it.

It will soon be stronger for any bitcoin 2.0 to say it is (supports) coloredcoins, since once there are clients of any of the coloredcoins companies here - they will need to be compatible with other clients here.

Building compatibility around different protocols is not difficult, bridges   could be built either internally or externally.

Financial institutions data has to be connected, that's the basic idea of coloredcoins, so at one point each company will have clients that want to be connected to another company - that would require compatibility.

To sum up - what must happen will happen.

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

[Flavien]

I have to agree with Alex and Gideon on this: the decision process around that new protocol is hardly open.

Also, like Gideon wrote, a new protocol makes little sense as it only increases fragmentation.

Open assets has been gaining momentum in the Bitcoin ecosystem in the past year, but it is now also reaching a critical mass of corporate supporters outside of Bitcoin (NASDAQ, Gyft, and more to come), so it would make more sense to back it instead.

[Alex Mizrahi]

didn't even consider Vitalik ideas and spec

This isn't true. The problem was that Vitalik started writing it without prior discussion. He was barely aware of topics which we discussed in this mailing list for ~1 year before he started writing this spec, and he just didn't have time to do it properly, he wanted to complete everything in 1-2 months. I just found it very disappointing that the spec was being written in a haphazard way.

As for his ideas, he had a plenty of them; and I actually considered 3 or so color kernels he designed, and they just weren't good... As far as I know, none of implementations adopted his ideas.

[Alex Mizrahi]

 

Open assets has been gaining momentum in the Bitcoin ecosystem in the past year, but it is now also reaching a critical mass of corporate supporters outside of Bitcoin (NASDAQ, Gyft, and more to come), so it would make more sense to back it instead.

It could make a lot of sense if it didn't have several significant flaws...

[Gideon Greenspan]

On Tuesday, May 12, 2015 at 1:52:45 AM UTC+3, Alex Mizrahi wrote:

 

Open assets has been gaining momentum in the Bitcoin ecosystem in the past year, but it is now also reaching a critical mass of corporate supporters outside of Bitcoin (NASDAQ, Gyft, and more to come), so it would make more sense to back it instead.

It could make a lot of sense if it didn't have several significant flaws...

Alex, every protocol will have flaws, because there are trade-offs. For example Open Assets is a much simpler protocol than CoinSpark but as a consequence there are several things it can't do. Whether that makes it better or worse depends on what the market cares about. I'm attaching (what I believe is) a fair comparison of the 5 different existing protocols for transacting assets over the bitcoin blockchain, including the 3 colored coins ones, Counterparty and MasterCoin/Omni. (Of course let me know if anything needs correcting.) Each protocol has some criteria under which it is the "winner" and others under which it is the "loser".

So the question we should really be asking is: what is important to the market? Does one of the existing protocols, or some combination of the existing protocols, provide that feature set? If so, let's get behind that and refocus on building the products and services that the market really cares about, and which it will pay us for. Honestly, our customers couldn't care less about how we encode color transfers in bits, bytes or satoshis, and we shouldn't care much about it either.

As startups it is a waste of time for us to focus on competing with each other, for the next decade at least. Agreeing on a single standard will increase our collective opportunity a great deal, since the colored coins brand still presents a very confused message to the outside world. It just seems that, so far, no one has managed to run the standardization process successfully. I'm still hoping that Colu will step up.

Gideon

[amos meiri]

We (COLU) are taking your emails seriously and plan to improve with the process of our new implementation and how we work and share with the community.   

We will send an email the next couple of days explaining more about what we are going to release, to who and when. 

I do promise the part we are building for ColoredCoins.org, investing lots of resources the last couple of month will be 100% open source.

We do want to work with the other teams as part of ColoredCoins.org and if in the end of the process we will have different implementations, we might need to try and support all of them.   

 

I agree with Gideon that all of us will benefit from one standard. 

--

[Alex Mizrahi]

 

For example Open Assets is a much simpler protocol than CoinSpark but as a consequence there are several things it can't do. Whether that makes it better or worse depends on what the market cares about. I'm attaching (what I believe is) a fair comparison of the 5 different existing protocols for transacting assets over the bitcoin blockchain, including the 3 colored coins ones, Counterparty and MasterCoin/Omni. (Of course let me know if anything needs correcting.) Each protocol has some criteria under which it is the "winner" and others under which it is the "loser".

You're lumping color kernel features and software features together. Usually, only color kernel is consensus critical, other parts are much easier to improve and update.

For example, metadata encoding. 

Currently ChromaWallet doesn't embed any metadata into the blockchain. 

However, EPOBC lets you to use OP_RETURN because OP_RETURN has no special meaning and won't invalidate the transaction.

In fact 1.5 years ago I implemented an experimental version which could embed metadata into the blockchain:

https://groups.google.com/d/msg/bitcoinx/AmJeZfSKn5I/yc1mHBSq5ckJ 

"Each smart property instance can have a piece of data attached to it, 

it is recorded in genesis transaction using OP_RETURN script, for 
example: "

Then, correct me if I'm wrong, but "Scalable SPV" is a wallet feature which can be used with any kernel, in principle.

"Asset tied to issuer domain", "Contract notarized in genesis" are features of genesis metadata and wallet.

"Integrated messaging" is a wallet feature.

"Decentralized exchange" can be a wallet feature.

All in all this table might be useful when you're selling your software to customer, but pretty useless and misleading when we consider fundamental properties of protocols under assumption that software can be improved, optional features can be added and so on.

BTW while we're at it, I'm not sure what you meant but "Protection from other wallets" but I'm pretty certain you got it wrong. :)

[Kawal Grover]

That is a great chart Flavien. Thanks for sharing.

And I am looking forward to seeing what kind of standardization process comes out of the efforts COLU is putting in.

I personally would REALLY love to see the idea of expiration-dates built on the tokens. i.e, someone creates a coupon on top of the block chain that expires after 1 year. During this one year it is transferable anywhere but after that year is up, it will get transferred to the owner (or something like that).

Thanks,

- Kawal.

[Gideon Greenspan]

Hi Alex,

Thank you for your reply and comments on the comparison document.

 

For example, metadata encoding. 

Currently ChromaWallet doesn't embed any metadata into the blockchain. 

However, EPOBC lets you to use OP_RETURN because OP_RETURN has no special meaning and won't invalidate the transaction.

By that row I meant "where does the protocol encode the metadata required to specify asset transfers?" I've changed the heading to make it clearer, and put in "Satoshi quantity" for EPOBC.

 

Then, correct me if I'm wrong, but "Scalable SPV" is a wallet feature which can be used with any kernel, in principle.

What I mean by "asset independence" is that it's possible to track the movements of one asset while ignoring all other assets. I've changed the row title to make this a bit clearer.

"Asset tied to issuer domain", "Contract notarized in genesis" are features of genesis metadata and wallet.

Yes, but I'm referring to what the protocols currently support as part of their spec and implementation. Indeed any protocol could add this if it wants.

 

"Integrated messaging" is a wallet feature.

Not exactly. It's a protocol feature, at least in CoinSpark. Again, of course any protocol could add this if it wanted. 

"Decentralized exchange" can be a wallet feature.

I meant here "on blockchain decentralized exchange" so I've clarified that row title.

  

All in all this table might be useful when you're selling your software to customer, but pretty useless and misleading when we consider fundamental properties of protocols under assumption that software can be improved, optional features can be added and so on.

Yes, I accept that. It's a comparison of the protocols as currently implemented, which is of course all the customer cares about, as I keep saying!

But certainly many rows in the table depend only on the protocol itself, so you can focus on those if you prefer.

BTW while we're at it, I'm not sure what you meant but "Protection from other wallets" but I'm pretty certain you got it wrong. :)

You are right, this was a mistake on my part. What I had meant was "allow a wallet to receive multiple assets using a single address while protecting it from accidentally sending assets to other wallets that don't support the protocol". But that's too complicated so I focused on the narrower meaning, in which I believe ChromaWallet should also get a check symbol, so I've added it.

Attached is an updated comparison - please let me know if you spot any other errors.

Gideon

[Alex Mizrahi]

Then, correct me if I'm wrong, but "Scalable SPV" is a wallet feature which can be used with any kernel, in principle.

What I mean by "asset independence" is that it's possible to track the movements of one asset while ignoring all other assets. I've changed the row title to make this a bit clearer.

Then EPOBC has this feature.

https://github.com/chromaway/ngcccbase/wiki/EPOBC_simple#transfer-transactions

However, if client is interested only in a single color (e.g. it only care about 'gold'), then the procedure can be simplified: all non-gold outputs will have null colorvalue. Then step 3 can be simplified: instead of identifying colors of all inputs, it is enough to check that all matching inputs have non-null gold colorvalue. This can affect thin client scalability and proof sizes.

  

Yes, I accept that. It's a comparison of the protocols as currently implemented, which is of course all the customer cares about, as I keep saying!

Our customers ask what we can implement for them.... If existing open source software satisfied their needs, why would they pay us? :)

For example, they want to give users an ability to transfer the assets without having any bitcoin balance in their wallet, as a need to maintain bitcoin balance seriously hampers usability. This is something I talked about back in 2012, however we implemented this feature only now.

 

You are right, this was a mistake on my part. What I had meant was "allow a wallet to receive multiple assets using a single address while protecting it from accidentally sending assets to other wallets that don't support the protocol". But that's too complicated so I focused on the narrower meaning, in which I believe ChromaWallet should also get a check symbol, so I've added it.

In that case Counterparty and Mastercoin have this feature as well, in fact their wallets tend to use a single address for everything.

As for ChromaWallet, it's a bit more complex, as UX protects user from receiving assets he's not aware of. :)

cc-wallet-core in fact uses the same Bitcoin address, but adds different prefixes to signify what asset user expects to receive.

I think it's better to remove this line as it is a basic feature implemented by everybody.

 

Attached is an updated comparison - please let me know if you spot any other errors.

OK, aside from what I mentioned above, for EPOBC we have 

Python https://github.com/chromaway/ngcccbase/

and Go https://github.com/monetas/gochroma

libraries.

As for "available wallets", if you mean that in the sense "what user can download and run" then it is indeed Windows/Linux. But it also runs on Mac (actually I have binary builds too, just didn't bother to publish them).

Also we have web and mobile wallets, but they aren't ChromaWallet but wallets built for specific applications, I'm not sure how you count that...

[Gideon Greenspan]

Hi Alex,

Then EPOBC has this feature.

https://github.com/chromaway/ngcccbase/wiki/EPOBC_simple#transfer-transactions

So in EPOBC if a null color value is mixed with a colored value, it becomes null? Is this a change from how it used to work in the past? It seems definitely different from Open Assets.

Anyway if this is true I am confused. Let's say we need padding = 1024 satoshis (first power of 2 over 546). We have one UTXO with 1026 satoshis, i.e. 2 asset units. We then want to split it into two parts, each of which will have to be 1025 satoshis, i.e. 1 asset unit each. So we need to bring 1024 satoshis from somewhere else, presumably uncolored. Won't that destroy the color? What did I misunderstand?

For example, they want to give users an ability to transfer the assets without having any bitcoin balance in their wallet, as a need to maintain bitcoin balance seriously hampers usability. This is something I talked about back in 2012, however we implemented this feature only now.

How do you create a transaction to transfer an asset without using bitcoin, in a world of anti-dust thresholds? 

 

You are right, this was a mistake on my part. What I had meant was "allow a wallet to receive multiple assets using a single address while protecting it from accidentally sending assets to other wallets that don't support the protocol". But that's too complicated so I focused on the narrower meaning, in which I believe ChromaWallet should also get a check symbol, so I've added it.

In that case Counterparty and Mastercoin have this feature as well, in fact their wallets tend to use a single address for everything.

Yes, but they use bitcoin addresses, so that means you can send Counterparty or MasterCoin assets to a regular bitcoin address, no?

 

OK, aside from what I mentioned above, for EPOBC we have 

Python https://github.com/chromaway/ngcccbase/

and Go https://github.com/monetas/gochroma

libraries.

OK - added. Actually CoinSpark has Go as well so I added that in!

 

As for "available wallets", if you mean that in the sense "what user can download and run" then it is indeed Windows/Linux. But it also runs on Mac (actually I have binary builds too, just didn't bother to publish them).

Also we have web and mobile wallets, but they aren't ChromaWallet but wallets built for specific applications, I'm not sure how you count that...

I was counting what's actually available to download and use, of course.

I'll publish another update shortly but I'm just trying to understand my questions above?

GIdeon

[Gideon Greenspan]

Oh I think I see - when matching inputs to outputs you discard all inputs from non-transfer-tagged transactions, right? This is also something that changed at some point, no? If so I think I understand it. Please confirm and I'll update the comparison.

Gideon

[Alex Mizrahi]

Oh I think I see - when matching inputs to outputs you discard all inputs from non-transfer-tagged transactions, right?

Perhaps it is easier to explain in example:

Inputs:

1. 1025 satoshi, 1 gold

2. 1025 satoshi, 1 gold

3. 1030 satoshi, 6 silver

4. 10000 satoshi, uncolored

Outputs:

1. 1026 satoshi, 2 gold

2. 1025 satoshi, 3 silver

3. 1026 satoshi, 2 silver

4. 1025 satoshi, 1 silver

5. 3976 satoshi

(5000 satoshi were paid as a fee)

As a first step, we compute a set if inputs matched by every output:

1. [1, 2]

2. [3]

3. [3]

4. [3]

5. [4]

Then we check colorvalues of matched inputs. 

When we're computing output 1 colorvalue, we check only inputs 1 and 2, both of which are gold.

Thus we do not care that there are also silver and uncolored inputs.

Also, we process each output separately. If the first input is uncolored, it will make the first output uncolored.

However, that won't affect outputs 2-4, they will still be silver.

 

This is also something that changed at some point, no?

Here's a brief history of OBC family of kernels:

1. Initially a color could have more than one genesis transaction, which was a major PITA as it made computations subjective.

2. This was fixed in Spring 2013 by Albert Hendriks who recommended to use a single genesis per color and use a notion of assets to group semantically related colors.

3. "The theory of colored coins" described a color computation process which is done on a single color at a time:  https://github.com/bitcoinx/colored-coin-tools/wiki/colored_coins_intro 

This kind of OBC was implemented in NGCCC.

Also OBC is defined on output-level granularity.

4. POBC had a bit more strict validation rules, but I think that only affected the complexity of implementation.

    It was still compatible with "one color at a time" concept.

5. EPOBC went back to "one output at time" model which was used in OBC.

So it was kinda always like that, but POBC was a bit confusing, maybe that's where you got this idea from.

Or maybe it was one of Vitalik's kernels.

[Alex Mizrahi]

 

So in EPOBC if a null color value is mixed with a colored value, it becomes null?

Yes.

 

Is this a change from how it used to work in the past?

No, even OBC worked that way.

 

It seems definitely different from Open Assets.

Yes.

The difference is that in OBC and EPOBC input-output matching is independent of colorvalues, thus we don't need to know all input colorvalues.

But in OpenAssets matching is colorvalue-dependent, and thus it needs to validate transaction as a whole. (Strictly speaking it could be more forgiving, but that doesn't really matter...)

 

Anyway if this is true I am confused. Let's say we need padding = 1024 satoshis (first power of 2 over 546). We have one UTXO with 1026 satoshis, i.e. 2 asset units. We then want to split it into two parts, each of which will have to be 1025 satoshis, i.e. 1 asset unit each. So we need to bring 1024 satoshis from somewhere else, presumably uncolored.

Yes.

 

Won't that destroy the color?

No.

When we compute output's colorvalue, we consider only matching inputs. In your example, outputs 1 and 2 will be matched by input 1.

Thus an uncolored input 2 won't affect coloring. 

I.e. you can add arbitrary uncolored inputs and outputs after the colored ones without affecting coloring.

Colored and uncolored coins can get mixed only if software is broken.

 

How do you create a transaction to transfer an asset without using bitcoin, in a world of anti-dust thresholds? 

There is a special service which provides uncolored bitcoins to cover fees and padding, potentially in exchange for colored coins.

 

Yes, but they use bitcoin addresses, so that means you can send Counterparty or MasterCoin assets to a regular bitcoin address, no?

Yes... But it's much less of a problem in the Mastercoin world, as it's enough to obtain a private key to recover assets. It's only a problem if assets were send to a shared wallet.

[Gideon Greenspan]

Alex,

Thanks for your replies. So I've uploaded here what I think is a final valid comparison - please let me know if if anything else is wrong. It's great that EPOBC has asset independence - I wasn't aware of that and I think it's an key criterion for long-term scalability.

Gideon

[Alex Mizrahi]

asset independence - I think it's an key criterion for long-term scalability.

It certainly helps, but it's not by itself enough for applications in which coins change hands rather often, and thus can accumulate a long history. (E.g. currency/payment system.)

There are several possible ways to tackle it, including improvements on color kernel level.

I.e. a color kernel based on follow-the-satoshi mechanism might require a proof size proportional to the height of the transaction graph, i.e. O(log N) instead of O(N).

I see a way we can make a EPOBC-like kernel with these properties, but am not convinced that it's a good idea...

[Data Mentahan]

My name is Maggie Lawson, and I am very enthusiastic to join the Internet of Think study program at STIKOM University. I am very interested in the world of technology and how software can help solve real world problems.

Since young, I have had a passion for programming. I started learning my first programming language at the age of 18, and since then, I have never stopped learning and developing my skills. I've worked on several small projects and worked on several applications Slot Demo Indonesia, which helped me understand the software development process from start to finish.

I am very interested in learning concepts like web development, mobile app development and database management. I also believe that collaboration is the key to creating great software, and I am passionate about working in teams to tackle complex challenges.

While at university, I hope to deepen my understanding of various programming languages, software development methodologies, and also understand how to solve problems in software development effectively. In addition, I plan to engage in group projects and practicums to gain deeper practical experience.

Outside of academia, I enjoy exploring side projects, learning about the latest trends in the tech industry, and participating in developer communities. I also believe that continuous learning is the key to staying relevant in the rapidly changing world of technology.

I really enjoyed meeting my classmates, lecturers and professionals in the software industry. Let's explore this exciting world together and collaborate to create innovative solutions.