I think that regardless of merits protocol or limitations of protocols, once they become used and stable they merit their place as a BIP.
I'd like to submit OA as is on flavien's repository, and update or reword things once it is there. (so he can ACK easily and we can keep track of changes instead of using mails back and forth)
It would be useful to have other colored coin protocols as well. (EPOBC and Colu)

On Thu, Aug 4, 2016 at 9:37 PM, Flavien Charlon <flavien.charlon@coinprism.com> wrote:
Hi,

> I would love to see an RFC-style standard "multiple-colored-coin-protocol" written by reps from all of the major protocols and that meta-merges the features of these implementations

Alex summarizes the situation well. Efforts to come up with a "multiple-colored-coin-protocol" have failed since the different protocols take different assumptions and different tradeoffs and are built for different use cases. In the end, we ended up exactly in the same situation as the well known XKCD comic strip about standards (https://xkcd.com/927/).

> You can, however, provide a new OA2.0 protocol that improves upon these issues, and assure that upgraded wallets maintain support for both versions.

I don't think there is a point in doing that. This would just result in having yet another "standard", which nobody uses. Open Assets 1.0 took 3 years to get where it is today, and is used by many companies across the industry. It has well over 20 different implementations, some open source, some proprietary.

The goal of this process is to have OA 1.0 becoming the BIP since this is the one people are using.

> I was waiting for clarification on the Author thing, but Nicholas hasn't responded yet. I am unaware of any reason NOT to assign it, and there appear to be no objections, so let's call it BIP 160.

Nicolas is proposing the BIP on my behalf. I'll ACK as needed but he can drive the discussions.

Best,
Flavien

On Tue, Aug 2, 2016 at 6:25 PM, Alex Mizrahi via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
I would love to see an RFC-style standard "multiple-colored-coin-protocol" written by reps from all of the major protocols and that meta-merges the features of these implementations

We actually tried to do that in 2014-2015, but that effort have failed...
Nobody was really interested in collaboration, each company only cared about it's own product.
Especially Colu, they asked everyone for requirements, and then developed a new protocol completely on their own without taking anyone's input.

I'm not sure that merging the protocols makes sense, as some protocols value simplicity, and a combined protocol cannot have this feature.

I don't think there is much interest in a merged colored coin protocol now.
Colu is moving away from colored coins, as far as I can tell.
CoinSpark is now doing MultiChain closed-source private blockchain.
CoinPrism also seems to be largely disinterested in colored coins.

We (ChromaWay) won't mind replacing EPOBC with something better, our software could always support multiple different kernels so adding a new protocol isn't a big deal for us.

So if somebody is interested in a new protocol please ping me.

One of ideas I have is to decouple input-output mapping/multiplexing from coloring.
So one layer will describe a mapping, e.g. "Inputs 0 and 1 should go into outputs 0, 1 and 2".
In this case it will be possible to create more advanced protocols (e.g. with support for 'smart contracts' and whatnot) while also keeping them compatible with old ones to some extent, e.g. a wallet can safely engage in p2ptrade or CoinJoin transactions without understanding all protocols used in a transaction.
 
- in collaboration with feedback from core developers that understand the direction the protocol will be taking and the issues to avoid.  

Core developers generally dislike things like colored coins, so I doubt they are going to help.

Blockstream is developing a sidechain with user-defined assets, so I guess they see it as the preferred way of doing things:
 
As it stands, investors have to install multiple wallets to deal with these varying implementations.

Actually this can be solved without making a new "merged protocol": one can just implement a wallet which supports multiple protocols.



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev