Re: [bitcoin-dev] BIP Number Request: Open Asset

[Nicolas Dorier via bitcoin-dev]

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.char...@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
>>
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Number Request: Open Asset

[Alex Mizrahi via bitcoin-dev]

>
> 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

Re: [bitcoin-dev] BIP Number Request: Open Asset

[Erik Aronesty via bitcoin-dev]

> As said, Open Asset is not a draft proposal and is already used in the
wild since 2014. We can't easily modify the protocol by now for improving
it.

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

It seems like OA's stance has *always *been to focus on integration, rather
than fixing the core protocol and then, by virtue of having the largest
integration, saying things like "it's too late to turn back now".Colu
and Chromaway/EPOBC also have stuff "in the wild".

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 - in collaboration with feedback from
core developers that understand the direction the protocol will be taking
and the issues to avoid.   HTTP/TCP/IP MCCP/BTC

As it stands, investors have to install multiple wallets to deal with these
varying implementations.   Merging them into one "meta-specification"
fairly soon might be in the best interests of the community and of future
shareholders.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Number Request: Open Asset

[Nicolas Dorier via bitcoin-dev]

Sorry, I completely forgot about having submitted the BIP as I was busy at
this time.
Thanks for the review.

Open Asset is actually not an abandoned project and is a protocol already
used in production with multiple implementation.
Wallet: https://www.coinprism.com/
Implementation C#: https://github.com/NicolasDorier/NBitcoin with heavy
documentation (
https://programmingblockchain.gitbooks.io/programmingblockchain/content/other_types_of_asset/colored_coins.html
)
Implementation Ruby: https://github.com/haw-itn/openassets-ruby/
Usage stats: http://opreturn.org/

Concerning whether or not we can put my name in the BIP, I'll ask the
original author that I know personally.

> Quite a bit ugly, giving a meaning to an input's pubkey script like that.
> But more problematically: how can this work with other pubkey scripts?
> Particularly relevant now that this old script format is being deprecated.
> Another possible problem is that I don't see a way to provably guarantee
an
> asset issuance is final.

Yes, with open asset it is not possible to do provably limited issuance.
The scriptPubKey can be anything, not necessarily P2PK.
If you can spend the scriptPubkey, then you are the issuer.

> And the assets attached to its inputs are destroyed? Or?

Correct, if you spend a colored output incorrectly, it is effectively
destroyed.

> Is it intentional that the first case is "parsable", and the second
"valid"?
> I think these need to be better specified; for example, it is not so
clear how
> to reach if the OAP version number is something other than 1: is that
> parsable? valid?

The terminology is correct we are parsing PUSHDATA, if there is a parsable
pushdata, the output is considered valid.
If there is multiple valid output, then we take the first one.

> What determines the asset id? How would one issue and/or transfer multiple
> asset ids in the same transaction?

You can't issue more than one asset type in a transaction. (as the asset
issued is defined by the scriptPubKey of the first input)
For multiple transfer it is possible, imagine a transaction with the
following 3 inputs and 6 outputs:

Inputs: {0, 10a, 20b}
Outputs: {5, OP_RETURN; 7; 3; 11; 9)

Inputs1: 0
Inputs2: Enqueue 10a in the queue ( {10a} )
Input3: Enqueue 20b in the queue ( { 20b, 10a} )

Output1: Before OP_RETURN, so is issuance whose color is defined by the
scriptPubKey of Input1. (say c)
Output2: No color (marker)
Output3: Dequeue 7a ( {20b, 3a} ), color output with a.
Output4: Dequeue 3a ( {20b} ), color output with a
Output5: Dequeue 11b ( {9b} ), color output with b
Output5: Dequeue 9b ( {0} ), color output with b

Finally, outputs color are
Outputs: {5c, OP_RETURN; 7a; 3a; 11b; 9b)

> What if I have a transaction with 5 outputs, the marker output at
position 3,
> and all 4 other outputs are to receive assets? Does the marker output get
> skipped in the list (ie, the list is 4 elements long) or must it be set to
> zero quantity (ie, the list is 5 elements long)?

Marker output is skipped (explained in the example)

> Addresses are not used for spending bitcoins, only for receiving them.
The way
> this BIP uses inputs' pubkey script is extremely unusual and probably a
bad
> idea.

Actually there is no "issuance address", just the AssetId is defined by the
scriptPubKey of the issuer.

> As I understand it, this would require address reuse to setup, which is
not
> supported behaviour and insecure.

Yes, it requires address reuse for issuing.

> Won't an older client then accidentally destroy assets?

Correct. Actually we prevent users sending asset to wallet which does not
support OA via another address scheme described in another document (
https://github.com/OpenAssets/open-assets-protocol/blob/master/address-format.mediawiki
)

As said, Open Asset is not a draft proposal and is already used in the wild
since 2014. We can't easily modify the protocol by now for improving it.

PS:
https://github.com/OpenAssets/open-assets-protocol/blob/master/specification.mediawiki
is
more readable than a mail.

Nicolas,

On Tue, Jul 5, 2016 at 7:14 PM, James MacWhyte  wrote:

> I'm curious to hear the answers to the questions Luke asked earlier. I
> also read through the documentation and wasn't convinced it was thought out
> well enough to actually build something on top of, but there's no reason it
> can't get a number as a work-in-progress.
>
> I hope it does continue to get worked on, though. The lack of response or
> discussion worries me that it might become an abandoned project.
>
> On Tue, Jul 5, 2016, 18:32 Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Tuesday, July 05, 2016 5:46:36 PM Peter Todd wrote:
>> > On Thu, May 26, 2016 at 03:53:04AM +, Luke Dashjr via bitcoin-dev
>> wrote:
>> > > On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-dev
>> wrote:
>> > > >   Author: Flavien Charlon 
>> >
>> > What's the status of this BIP? Will it be 

Re: [bitcoin-dev] BIP Number Request: Open Asset

[Alex Mizrahi via bitcoin-dev]

> I'm curious to hear the answers to the questions Luke asked earlier. I
> also read through the documentation and wasn't convinced it was thought out
> well enough to actually build something on top of,
>
There are many colored coin protocols in use. OpenAssets is probably the
most popular one, but it has many critical flaws IMHO.
https://github.com/bitcoinx/colored-coin-tools/wiki/OpenAssets-deficiencies


> but there's no reason it can't get a number as a work-in-progress.
>
The protocol is not a work-in-progress, it is already in use, you cannot
change it without breaking stuff.
The doc can be improved, though. There is a lot of fluff but the actual
important stuff gets just few ambiguous sentences.

I hope it does continue to get worked on, though. The lack of response or
> discussion worries me that it might become an abandoned project.
>

The original author, Flavien, have abandoned it, he now does a private
blockchain thing, OpenChain.
There are others who still use OpenAssets, e.g. Nicolas, but the protocol
can't be changed.

There are other colored coin protocols in existence/in development, though.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Number Request: Open Asset

[James MacWhyte via bitcoin-dev]

I'm curious to hear the answers to the questions Luke asked earlier. I also
read through the documentation and wasn't convinced it was thought out well
enough to actually build something on top of, but there's no reason it
can't get a number as a work-in-progress.

I hope it does continue to get worked on, though. The lack of response or
discussion worries me that it might become an abandoned project.

On Tue, Jul 5, 2016, 18:32 Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tuesday, July 05, 2016 5:46:36 PM Peter Todd wrote:
> > On Thu, May 26, 2016 at 03:53:04AM +, Luke Dashjr via bitcoin-dev
> wrote:
> > > On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-dev
> wrote:
> > > >   Author: Flavien Charlon 
> >
> > What's the status of this BIP? Will it be assigned?
>
> 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.
>
> Luke
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Number Request: Open Asset

[Peter Todd via bitcoin-dev]

On Thu, May 26, 2016 at 03:53:04AM +, Luke Dashjr via bitcoin-dev wrote:
> On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-dev wrote:
> >   Author: Flavien Charlon 

What's the status of this BIP? Will it be assigned?

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev