Hello All.
I’ve drafted a specification to put CashToken metadata in OP_RETURNs.
It’s a two-byte reference system, some PushByte data fields and a few URI variables.
The protocol was necessitated by some contracts, but could also work for users in LoFi contexts.
The full specification is available on GitHub:
The original bitcoin-cash-metadata-registry idea included 3rd party registries.
A registry then can be used to simply deposit your metadata, get a hash back and you can use the bcmr-design to approve the hash on-chain.
There has so far not been much of a need or want to actually build this, even though it could be a profitable business.
Your solution to put the data on-chain sounds like a thing we designed to AVOID with the existing methods and future path.
Yes. BCMR has a specification to manage an identity from a chain of transactions (an AuthChain), where metadata can be updated with on-chain proof later by putting a hash of the new JSON schema in an OP_RETURN created by the AuthHead (end of the transaction chain), with a link to the new metadata URL.
The two systems wouldn’t be mutually exclusive. Someone could start with SMP then switch to BCMR, or use both in parallel. Ideally, it should be possible to pass a outpoint to a function and generate a BCMR json file from a SMP base transaction:
let bcmrBlob = await smp.from(outpoint).asBcmr()
Or, someone may do a small initial project with SMP then scrap it and redo it with BCMR once they had played with the tokens a bit.
SMP doesn’t have identities, or updates after minting. It doesn’t need SSL, or domains, or third parties or large schemas.
Being able to say “test token” and have that data immediately reflected in a test wallet may get people more interested in using CashTokens and taking further steps to invest the time in using BCMR.
In many cases, the OP_RETURN size for a SMP record set might end up being smaller than one BCMR on-chain update.
In terms of future path or ecosystem trajectory, the BCMR spec wasn’t something arrived at through a broad consensus. It’s an application layer standard, and there can be many of those that exist in parallel, competing and complementing one another.
My immediate and long-term problem is that a contract is not going to post json to a registry, or hash a json file. BCMR also introduces a long chain of centralized failure points, that still have an extremely small attack area, as we saw with the otr.cash domain renewal recently.
Someone that just wants to try printing a token on their phone doesn’t want to learn what an Authchain is or manage an identity. When they want to have more valuable tokens, they’ll build an identity and manage more complex authorization.
In terms of actual implementations of BCMR, I’m not seeing a lot of wallets or software use it outside the webapp crowd. I’m not sure if my setup is broken, but it doesn’t seem to be fully implemented in EC, or any other wallet outside Cashonize, Paytaca and Zapit. [EDIT: BCMR works in Electron-cash, but not on my machine.]
I think BCMR is the right path for most projects, and SMR0 might be a good step stool to get there.
I have no intention of chipping for SMR1. There are a lot of things about SMR0 that are deliberately limited to encourage people to move upward to the better system.
I do agree, it is very clunky in places and deserves a version 2.
The way to get consensus on such a version two is likely not to do something totally different that requires wallets and everyone to implement this new thing.
So the reason for me explaining the high level approach that bcmr was aiming for is that your usecase fits in there snugly and and much more in line with the rest of the ecosystem.
Yes, the space is extremely young and practically unsupported.
So let me go a bit deeper into the initial registry idea that Jason and I discussed various years ago already.
Imagine a registry being a company. MyOpenRegistry. Someone will run this and have a website that has a nice short URL with various ways to get data out of the database.
It is easiest to see this as a yellow pages of the bitcoincash space.
One of the main things it does is cache all the metadata (including pictures, not supported in bcmr spec v1 out of the box). So a wallet can get all data from one place.
One obvious feature is that a creator can simply upload their data directly, it’s going to get cached anyway so why not make this registry their official home if they don’t want to host it elsewhere. No cost to the registry owner (bandwidth is practically free…). And this solves your usecase right there. In a way that is totally in line with the bcmr ideas. So wallets can simply use that one place to get all their data.
Additional features (just to be complete, not really relevant to this topic today) it would have is to be able to verify auth-chain owners. So random people can’t claim to be ikea or to be spice-tokens. Only one is the ‘real’ one and the metadata registry would be able to answer that in order to avoid impersonation and theft.
So, while I understand your idea and I always support and welcome permissionless innovation, I’d like to avoid having wallets and websites support a very different direction. Your solution likely needs a server to serve this info, it can then also simply be a bcmr uploaded to that server in the first place…
I’m hoping we can align noses and all go in the same direction, which helps us get to where we want to go faster.
I believe the above SMP proposal is a subset entirely contained within BCMR, and it defers to BCMR in a lot of places on style and best practices.
So anything that can be expressed in SMP can also be published in the BCMR schema. In fact, because SMP has no identities or authorities outside of the minting transactions, which anyone can make, in order for the metadata to be trusted, it would probably have to be converted to BCMR and included by some entity in a registry.
As for servers, with the way this is designed, given a token Category ID, anyone would be able to request the genesis transaction by id and see the metadata associated with the mint in whatever software they liked. With NFTs minted after genesis, there’s a way to refer to new data in the later NFT mint.
Wallets or explorers would display the SMP data, but it should carry a huge asterisk noting that it’s trivial to impersonate any token, and it’s not trusted. Similar to http v https. This would be a way for someone to do a “hello world” with their token, and then figure out how they want to do authorization management later.
Ok, please just acknowledge that you understand my question. Where you work within the bcmr ecosystem in a way that avoids wallets needing to add support for specifically your idea but they can just use your idea within the support for BCMR.
If not the current version, then a next bcmr version. But please avoid ecossytem (wallet / indexers / explorers) fragmentation. Can you get on board with that?
Do note that in cashtokens the category-id is NOT the genesis txid.
The level of support for OP_RETURN messages across wallets and explorers is probably sufficient to make SMP useful for onboarding developers to CashTokens today, without modifications.
An OP_RETURN is so spoofable, unless there’s client-side checks around it, it’s not really that useful as a BCMR replacement. The only authentication is that the data is certainly associated with the token.
I think the ability to start with SMP in EC or mainnet-js then graduate to BCMR with built in tooling could be a pathway a few developers or token issuers take.
Again, if adopted, there would be tooling to convert SMP to BCMR, so registrars could import the data and list the genesis transaction as the authority if an SMP-only token project became popular.
ok, I had to try to keep the noses in the same direction. Seems that isn’t happening.
I mean, I understand its easier to ask wallets to implement something new than it is to build something useful on a server that solves this, so from a pure lazyness point of view this outcome was expected.
Thank you for your explanation, though.