Update AssetIssuanceStandard.md

[kawalgrover]

I've proposed the following change:
This specification mentions 3 additional pieces of data:

"mastercoin_id": "123456",
"coinprism_sources": ["2MyvmsxoCxsnzPapDnK7ZcMxWjU3hqLZkpX"],
"coincolors_id": "f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6"

I think we can safely assume that an asset that is issued is usually done using one protocol. I won't issue a BobsIceCreamToken on both mastercoin as well as Coloredcoin or CounterParty (or for that matter any future meta-framework).

Therefor there is a meta_id (instead of colorcoinid and/or mastercoinid).
meta_source is hopefully self-explanatory.
the coinprism_sources field, I propose be renamed to source_data that any of the other frameworks (mastercoin, and yes coinprism too) can use.

The number of fields remains the same and this is backwards compatible with any thing that already might be built.

[dexX7]

Looks reasonable to me. We might want to get a version field in addition, to indicate how it's going to be parsed.

[gidgreen]

Respectfully, I don't agree. One of the motivations for creating a standard was to allow the same asset (in a financial/legal sense) to be issued on multiple Bitcoin 2.0 protocols. By having a single URL define the asset on multiple protocols, users of that asset will know it is fungible between those protocols.

This allows a user to simultaneously sell X units of asset Y on MasterCoin and buy X units of asset Y on CoinSpark, knowing that they still own exactly the same thing from a legal and financial perspective.

Why would they want to do this? To gain the ability to exchange units of asset Y with another asset Z, which might only be available on one protocol and not the other. Or because one protocol has a better web wallet, or a better lightweight mobile wallet. The general idea is to allow liquidity between protocols.

[dexX7]

@gidgreen: thanks for the feedback, it looks like I missed the point, and assumed it's more about generalization. I don't really like having magic-word fields, which are likely not used at the same time. What do you think of an an array field instead, for protocol specific information or identifiers? Such as:

"identifier": [{
  "protocol": "openassets",
  "key": "value"
}, {
  "protocol": "mastercoin",
  "key": "value"
}]

Just tossing in some labels and values for the idea, might as well make sense to limit it not to "identifier", but "protocol-specific-information" as a more generalized approach.

[dacoinminster]

Please don't wait on me to review/merge this. Someone else will need to hit
the merge button

On Tuesday, February 10, 2015, dexX7 notifications@github.com wrote:

Looks reasonable to me. We might want to get a version field in addition,
to indicate how it's going to be parsed.

—
Reply to this email directly or view it on GitHub
#302 (comment).

[gidgreen]

Part of the spec is "Additional user-defined fields are permitted" so each protocol can decide whether to use @dexX7 's unified mechanism or their own top-level fields with the protocol name as the key prefix. But it's a good idea to have a recommended method to make the JSON more readable, so happy to accept the suggestion on that basis, since it remains possible to support multiple protocols simultaneously within a single asset specification JSON.

[kawalgrover]

Great! I really don't see a use-case where someone will be creating the SAME asset on two different protocols if the protocols follow the asset-issuance standard. The whole idea of the standard is to avoid someone from issuing it in multiple places.

But regardless, @dexX7 proposal encompasses everything, and keeps it elegant and simple.

[dexX7]

@kawalgrover: I really don't see a use-case where someone will be creating the SAME asset on two different protocols ...

For example, but it doesn't exist at this point, there could be a token serving as bridge between protocols, with similar properties, but protocol specific identifiers.

[kawalgrover]

Why would someone want to create a 'token serving as bridge between
protocols by having protocol specific identifiers'? If the protocols follow
the Asset-Issuance 'standard', then they will be identifiable by all the
protocols. Period. Only one identifier would be needed to know on which
protocol it was issued.

Perhaps, I am missing something.

On Sun, Feb 15, 2015 at 5:07 PM, dexX7 notifications@github.com wrote:

@kawalgrover https://github.com/kawalgrover: I really don't see a
use-case where someone will be creating the SAME asset on two different
protocols ...

For example, but it doesn't exist at this point, there could be a token
serving as bridge between protocols, with similar properties, but protocol
specific identifiers.

—
Reply to this email directly or view it on GitHub
#302 (comment).

[gidgreen]

Hi Kawal, I think the part you may be missing is that this web-based asset issuance standard is only part of the process of creating a bitcoin 2.0 asset. The other part is the way in which the issuance is represented by data on the blockchain, and this is completely different for each protocol:

MasterCoin:
https://github.com/mastercoin-MSC/spec#new-property-creation-with-fixed-number-of-tokens

CoinSpark:
http://coinspark.org/developers/asset-genesis-metadata/

CoinPrism / Open Assets:
https://github.com/OpenAssets/open-assets-protocol/blob/master/specification.mediawiki#Open_Assets_Transactions

You could say "well all protocols should do that the same way as well". But (a) these protocols are being developed by separate teams, and (b) each protocol has strengths and weaknesses, which make them suitable for different use cases.

One good example is that MasterCoin's transaction-based offer/acceptance trading mechanism enables completely decentralized peer-to-peer trading, which is great. But it costs a little more to trade and you need to wait for a block to be mined to know if your trade was successful. By contrast colored coin protocols like CoinSpark and Open Assets require some kind of centralized mechanism to match trades, which is a negative, but on the flip side it's cheaper and you can know in a few seconds if you successfully closed a trade (barring deliberate double spends).

So while I see value in multiple protocols co-existing, I do think we should try to maximize compatibility between them. Having an asset which is legally/financial equivalent between protocols seems to me like a positive step in that direction.

[kawalgrover]

Thanks for the explanation @gidgreen !
And also for your patience as I try to wrap my head around all this.

Could we agree for now to merge the changes proposed by @dexX7 .

"identifier": [{
"protocol": "openassets",
"key": "value"
}, {
"protocol": "mastercoin",
"key": "value"
}]

The reason is that I want to use this Asset Issuance Standard and build on top of it. One of the asset types I like is an asset that behaves like a 'credit'. Coupons, GiftCards, Frequent-flier-miles, etc have one thing in common: "Expiration Date".

I would like to propose a Credit Issuance Standard on top of this 'Asset Issuance Standard' that just has one extra piece of meta-data: Expiration Date.

[dexX7]

To my knowledge the primary application using the Asset Issuance Standard is currently Coin Prism, if I'm not mistaken, and the standard is based on the work of @gidgreen and @Flavien, so I'd welcome feedback regarding a decision or recommendation in changing or extending it, though @marv-engine might further weight in regarding the plans of Omni Wallet.

The reason is that I want to use this Asset Issuance Standard and build on top of it.

I would like to propose a Credit Issuance Standard on top of this 'Asset Issuance Standard' that just has one extra piece of meta-data: Expiration Date.

@kawalgrover: actually I'm not entirely sure how to relate this to the intial pull request, which renamed identifier fields, but I see value in providing a generalized blueprint for extensions. It would be awesome, if you could post an example or maybe go into further detail of what you intended at the beginning?

[kawalgrover]

" I'm not entirely sure how to relate this to the intial pull request,
which renamed identifier fields, but I see value in providing a generalized
blueprint for extensions. It would be awesome, if you could post an example
or maybe go into further detail of what you intended at the beginning?"

My initial pull request of renaming identifier fields is NOT related to
creating a credit-issuance standard.

When I looked at the standard, some of those fields did not make sense to
me from a standards perspective and that is why I proposed the change. That
standard is actually pretty awesome and I'm grateful for all the work that
has gone into it. But I want to extend it (by just adding that one extra
field of expiration_date).

However, extending those other fields (coinprism_id, mastercoin_id, etc)
seemed a little convoluted to me and that is why I made a pull request to
clean up the identifier fields. This way a credit/coupon will behave very
much like an asset on the Blockchain that MSC and Colored Coins would
recognize with one extra piece of information that they may or may not care
about.

I am working on a proof of concept. Hopefully next week I'll have something
to show for it.

I'm just learning all these extra technologies and am a bit slow. :)

Hope this makes sense.

On Wed, Feb 18, 2015 at 2:31 PM, dexX7 notifications@github.com wrote:

To my knowledge the primary application using the Asset Issuance Standard
is currently Coin Prism, if I'm not mistaken, and the standard is based on
the work of @gidgreen https://github.com/gidgreen and @Flavien
https://github.com/Flavien, so I'd welcome feedback regarding a
decision or recommendation in changing or extending it, though
@marv-engine https://github.com/marv-engine might further weight in
regarding the plans of Omni Wallet.

The reason is that I want to use this Asset Issuance Standard and build on
top of it.

I would like to propose a Credit Issuance Standard on top of this 'Asset
Issuance Standard' that just has one extra piece of meta-data: Expiration
Date.

@kawalgrover https://github.com/kawalgrover: actually I'm not entirely
sure how to relate this to the intial pull request, which renamed
identifier fields, but I see value in providing a generalized blueprint for
extensions. It would be awesome, if you could post an example or maybe go
into further detail of what you intended at the beginning?

—
Reply to this email directly or view it on GitHub
#302 (comment).

[Flavien]

FYI, here is the asset definition format we use in Coinprism: https://github.com/OpenAssets/open-assets-protocol/blob/master/asset-definition-protocol.mediawiki

[kawalgrover]

Thanks for sharing!

This is definitely simpler and easier for me to follow. I'll go with this
one for now. :)

Thanks again,

• Kawal
  PS: I'm a bit stupid, so I like the KISS principle. :)

On Wed, Feb 18, 2015 at 2:55 PM, Flavien Charlon notifications@github.com
wrote:

FYI, here is the asset definition format we use in Coinprism:
https://github.com/OpenAssets/open-assets-protocol/blob/master/asset-definition-protocol.mediawiki

—
Reply to this email directly or view it on GitHub
#302 (comment).

[marvgmail]

any new news on this PR?

[dexX7]

Please specify "news". There is no Omni application which uses the AssetIssuanceStandard, or anything related (unfortunally..!).

[marvgmail]

@kawalgrover do you plan to make any changes to this PR? Others - is there consensus on it?

[dexX7]

Hi,

in an attempt to clean up the current specification, I'm going to close old and outstanding pull requests. Please note, it's tagged as "old idea", so the work is not wasted and we can potentially review it at some point later.

Please feel free to resubmit it as new pull request, if you still think it's a good idea.