openassets / open-assets-protocol Goto Github PK
View Code? Open in Web Editor NEWTechnical specification for the Open Assets protocol, a Bitcoin based colored coins implementation.
Technical specification for the Open Assets protocol, a Bitcoin based colored coins implementation.
Technical specification for the Open Assets protocol, a Bitcoin based colored coins implementation.
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:
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!
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:
null
values as if the key was removed, and then take the hash.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.
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?
Do most bitcoin / litecoin wallets support the protocol?
Is this available anywhere?
It would be useful to define an asset burn procedure, maybe by proof of burn or another method.
I want to use colored coin on LTC or Hcash wallet. Which one should I choose please?
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.
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?
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:
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?
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.