I want to use colored coin on LTC or Hcash wallet. Which one should I choose please？

I'm currently implementing the protocol and accepting multi-pushdata OP_RETURN scripts, but only taking the first pushdata ignoring the rest. Should we enforce 1 pushdata only? Should we also enforce canonical pushdata opcode (that is, the most compact for the given data length)? I don't see much value in being liberal here. Especially since we might extend the protocol and desire to have some options being unused to take advantage of.

The main spec defines Asset Address as Base58Check encoding of the hash of the script. However, this spec defines some other kind of address. Is it a deprecated format, or both are proposed?

Personally, it seems to me that wallets capable of managing assets wouldn't need any P2PKH addresses, they can (and should) operate on pure Asset IDs and provide their own mechanism of storing the assets on the user's keys (that could be P2PKH/P2SH/raw multisig or something else). Current spec for addresses based on P2PKH seems very limited to me. I'd expect multisig P2SH to be used by default as the safest option. (Or does the spec allow P2SH, just does not articulate it?)

The OA-capable app maybe does not need any special address format to store assets. It may just know which inputs are cash and which are assets, so it will do the right thing without depending on user-provided string.

What do you think?

Bitcoin introduced the new address format Bech32 used by Segwit.

Addresses such as P2PKH and P2SH are consists of address version, payload and checksum, and Open Assets Address has namespace added to it. But Bech32's address format has no version, it consists of human-readable part, separator and data part(include checksum).

If I want to convert from Bech32 address to Open Assets Address, should Base-58 encoding be applied by using human-readable part instead of version?

Or should we define a new Bech32 based address using the namespace for OA in Bech 32's Humarn-readable part?

Are there any other good idea?

It would be useful to define an asset burn procedure, maybe by proof of burn or another method.

This is a subtle point, but if we're going to use hashing for verifying the asset definition file, then it's probably best that we define a strict ordering and formatting of the JSON so that idiosyncrasies in JSON serialization and/or rendering don't affect the value of the hash.

Given that the asset definition file is JSON, it's likely to be stored as such, and possibly deserialized and re-serialized before being rendered, or after being fetched for verification. JSON as a format doesn't care about indentation, newlines, or field ordering, but the hash operation does care about those things.

Off the top of my head, there are a couple of options:

1. Treat the asset definition file as a raw string. Encourage providers (issuers) to avoid deserializing the string after extracting it from the data store and encourage verifiers to read the raw HTTP body for hash generation.
2. Extend the standard to specify pre-processing before calculating the hash. For example, to verify an asset definition file, the verifier would deserialize the contents, re-render them as a string with sorted keys (or some ordering defined in the standard), strip out unnecessary whitespace (most JSON serializers will do this by default), maybe treat blank strings or null values as if the key was removed, and then take the hash.

According to the spec, I don't need to issue or transfer any assets to update the AD pointer. So do I understand correctly, that this is legal:

1. Send some satoshis to issuance address.
2. Spend that output in a transaction with an OA marker containing new definition pointer.

All inputs and outputs will be uncolored (no transfers and no new assets issued), but the second transaction will nonetheless be valid OA transaction and therefore will be parsed by a compliant client to get the latest Asset Definition from it?

The spec doesn't appear to distinguish between metadata in the marker of an issuance tx vs in a transfer tx.

It seems to me that the metadata of a colored coin should only be associated with issuance. You wouldn't want a later spend of the colored coin to change its metadata, esp since these spends will be outside the control of the coin issuer.

Should something be added to the spec to indicate metadata is only significant in issuance?

Here:
http://blog.coinprism.com/comparison-coinprism-counterparty-mastercoin/

I've noticed that CoinSpark says that all excessive assets are automatically sent to the last non-OP_RETURN output as change. I couldn't find anything like that in OpenAssets doc while that chart mentions something like that.

My personal opinion: we don't need that kind of babysitting that makes asset tracking only more complicated. However, I'd like to clarify that.

I'm new to github and for the life of me can't figure out how to make a pull request or proposal, but I created three proposals to update OA with that I was hoping you might be interested in.

They are:

• Expanding the specification to allow the use of P2SH addresses to issue assets. This is useful for say a corporation issuing assets and shareholders know that multiple members of the board must cooperate in order to issue more.
• Adding "nmc=oa/NAME" to the optional OP_RETURN metadata so that Namecoin names can be used for asset definitions.
• Standardizing the use of compressed keys, since it appears in the specification and in most asset issaunces that I saw on the blockchain that most keys being use are uncompressed.

The proposal mediawikis are at:

https://github.com/7trXMk6Z/openassets_expansion_proposals

Thanks for your time, and excellent work on this fantastic colored coin implementation!

Hello,

Thank you for developing/maintaining the protocol.

1- I think since for example the order of inputs are important for the protocol, it should be made clear that what are the supported signature hash types of Bitcoin protocol, if applicable. (For example I think SIGHASH_ANYONECANPAY | SIGHASH_ALL will enable miners to change order of inputs and make trouble in asset transfer).

2- It is desirable to support other signature types if possible. For example SIGHASH_ANYONECANPAY | SIGHASH_ALL to pay for the transaction fee later, but for example not to enable somebody to waste an input, by modifying transaction inputs.

Thanks

Hey,

I'm embedding "u=http://example.com/xyz" URL (without TLS) into metadata field in the marker, it returns this JSON:

{"asset_ids":["A-REDACTED"],"name_short":"REDACTED","name":"REDACTED","issuer":"REDACTED","type":"Stock","divisibility":0,"version":"1.0"}

And this is not indexed by Coinprism. Could it be that certain HTTP headers are expected, or some fields that are missing are actually required? I double-checked that Asset IDs match (there's no P2SH-based definition). Transaction is confirmed and visible on Coinprism, but asset name is not.

Do most bitcoin / litecoin wallets support the protocol?

Is this available anywhere?

Technical specification for the Open Assets protocol, a Bitcoin based colored coins implementation.