Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 59110724 for ; Sat, 13 Aug 2016 02:25:27 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com [209.85.220.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 116BB2A1 for ; Sat, 13 Aug 2016 02:25:26 +0000 (UTC) Received: by mail-qk0-f169.google.com with SMTP id l2so3104470qkf.3 for ; Fri, 12 Aug 2016 19:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0KKIPUBgU2KQaxO2YRMmzybRGoPX5gi0KZapFOUA4F8=; b=FfDgvpaC7XHoLODqn6klUM0/u2cCRvfBWiUbSXvrnuOUVHt7dwPsTzsdXS45oDSFqQ JxDVtsZRQPNyEdHBehWM+Kc/jE8JAN/OZ9JIBmRks9GsS03uVYomx2/l2+RbOSNrelCq z0QbLd8W6wt/VYlhNXhv1s7Jo2omNU25PKeMlJlSZVi6/uDd96icB2Kj55IFLTzuhoWf qTRhGWGpDYIJ8XRKKCyj853odbhZgYSVHK1Ow4rqP0d8kxerREReLaokCPsi4e9Xxk1+ UkWJfAinQYirHdSN1GYGEOKnb4JsYh5an4DGmxcGHCPOS3ckjk8dVs7f21ihmv+igZC9 RTTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0KKIPUBgU2KQaxO2YRMmzybRGoPX5gi0KZapFOUA4F8=; b=mLgxX3+6kSGAnABEYwcrpgnHwRynNrydJfjYB7VA+lEEZof4CQ8YrB3d76GnOCsJKg IJDaRFadpBn0inVCEm/wksNLwnWzRWJjT9/WhQyUsmY3VZTZD1ZQjJW6bhlPJkoMamK+ d3H3dLzQtVN6DDb63HG+Dymc0GcCw90TQckBD9DQzAgBIwDb9d5QIVUOpkG3sSNZwD93 lNt4rfz9EfDUyc5Xyjlfjpha8KTU94TQ4O+HQh7zKgbj3ZuaVrohua2Ix7ll2jD71KE0 Emho8Z3Xo3FkbvHyLKuSxGdIDf0YWaBU2EOj+vr9F7y1t4w5Z31hfc5uUs7yKVFh9hRq MYEQ== X-Gm-Message-State: AEkoouswhCcyY0Dmfi9tS0vETGVRezncoEjhhvRvyBIRYaTwc3FquJV3Jkz/nKDHViSNmt2hwkzRFJhxafGE5w== X-Received: by 10.55.122.65 with SMTP id v62mr21014252qkc.120.1471055125229; Fri, 12 Aug 2016 19:25:25 -0700 (PDT) MIME-Version: 1.0 Sender: slashene@gmail.com Received: by 10.55.186.5 with HTTP; Fri, 12 Aug 2016 19:25:04 -0700 (PDT) In-Reply-To: References: <201605260353.06939.luke@dashjr.org> <20160705174636.GA24068@fedora-21-dvm> <201607060122.20593.luke@dashjr.org> From: Nicolas Dorier Date: Sat, 13 Aug 2016 11:25:04 +0900 X-Google-Sender-Auth: _ilpzlf9BYP4T_Mz7N-fa0zuyKo Message-ID: To: Flavien Charlon Content-Type: multipart/alternative; boundary=94eb2c05e0ec2f3ab40539eab66a X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP Number Request: Open Asset X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 02:25:27 -0000 --94eb2c05e0ec2f3ab40539eab66a Content-Type: text/plain; charset=UTF-8 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: >> https://elementsproject.org/elements/asset-issuance/ >> >> >>> 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 >> >> > --94eb2c05e0ec2f3ab40539eab66a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 u= pdate or reword things once it is there. (so he can ACK easily and we can k= eep track of changes instead of using mails back and forth)
It wo= uld be useful to have other colored coin protocols as well. (EPOBC and Colu= )

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

> I woul= d love to see an RFC-style standard "multiple-colored-coin-protoc= ol" written by reps from all of the major protocols and that meta-merg= es the features of these implementations

Al= ex summarizes the situation well. Efforts to come up with=C2=A0a "mult= iple-colored-coin-protocol" have failed since the different proto= cols take different assumptions and different tradeoffs and are built for d= ifferent use cases. In the end, we ended up exactly in the same situation a= s 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 thin= k there is a point in doing that. This would just result in having yet anot= her "standard", which nobody uses. Open Assets 1.0 took 3 years t= o 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 prop= rietary.

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 Autho= r 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 i= t BIP 160.

Nicolas is proposing the BIP on = my behalf. I'll=C2=A0ACK 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 s= tandard "multiple-colored-coin-protocol" written by reps fro= m all of the major protocols and that meta-merges the features of these imp= lementations

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

I&= #39;m not sure that merging the protocols makes sense, as some protocols va= lue simplicity, and a combined protocol cannot have this feature.

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

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

So if somebody is interested in a new proto= col please ping me.

One of ideas I have is to deco= uple input-output mapping/multiplexing from coloring.
So one laye= r 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 mor= e advanced protocols (e.g. with support for 'smart contracts' and w= hatnot) 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.
=C2=A0
- in collabo= ration with feedback from core developers that understand the direction the= protocol will be taking and the issues to avoid.=C2=A0=C2=A0
<= /div>

Core developers ge= nerally dislike things like colored coins, so I doubt they are going to hel= p.

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

Actually this can be solved without making a new "merged pro= tocol": one can just implement a wallet which supports multiple protoc= ols.



_____________________________________= __________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev



--94eb2c05e0ec2f3ab40539eab66a--