Higher-level token standards using CashTokens

Just wanted to start a topic for discussion about higher-level token standards for CashTokens.

An excerpt from this post:

3 Likes

CashTokens Metadata Protocol

I’m currently working on a proposal for handling and authenticating metadata about CashTokens – the primary goal is to have a common standard for describing and representing various kinds of tokens in user’s wallets.

This is probably the most urgent higher-level standard needed since wallet developers need to be developing user interfaces for handling tokens. We want to be able to standardize on how wallets display a token’s name, symbol, icon, etc.

This related issue is also tracked by on the CashToken’s repo, where there’s already been some discussion: https://github.com/bitjson/cashtokens/issues/50

In short, I’m working on a Bitcoin Cash version of Token Lists (from the Ethereum ecosystem). This has proven to be a fairly successful strategy for distributing and authenticating metadata about tokens, and it is both simple and reliable. There’s even a multi-chain standard aimed at EVM-based coins. While we’re not EVM-based, matching our own standard closely with these existing systems should make implementation much easier for wallets – especially for wallets that already support tokens on other chains.

I’ll link the proposal here as soon as I finish a draft.

5 Likes

Looking forward to it man! Hopefully Electron Cash can be one of the early wallets offering either the creation or at least the display of token metadata.

1 Like

The high level question is where this information is stored and what follows is how the user can fetch the data.

Which basically is a boolean question of: does this need a new indexer ?

New indexers will lead to centralzation and censorship (see Tornado), a problem seen in most of the ETH infrastructure which is anything but decentralized.

As far as I am aware the ONLY sane way to avoid this centralization is to have the metadata in the genesis transaction and then add a p2p message to fetch a transaction by txid (since all full node implementations support txid-index).

Reading the introduction to Introducing Token Lists there is this very true statement;

As the decentralized finance movement continues to remove gatekeepers, it is imperative that new systems for discovery and reputation do not devolve into centralized gatekeeping.

But then we continue with their solution, and like so much of the ETH ecosystem, they claim to be decentralized but are not.

The idea is simple - any project on Ethereum that maintains a list of ERC20 tokens hosts this list publicly following a standard JSON schema. Projects attach their reputation to lists by hosting them on a domain they control.

[snip]

For example, an interface could automatically display any tokens that are on at least m out of n reputable lists. Or it could display all tokens across a set of lists, but display trust scores based on the number lists an asset is on. Or it can build in a list explorer that allows any user to import the lists that they want to trust.

What are problems with this:

  1. it creates a permissioned system. You need to get listed on a “reputable” list in order to be visible in wallets. The enire premise of removing gatekeepers not been hit in that project.
  2. The proposal to have various people run lists is going to hit the problem that this is not cheap. As usage grows, it will centralize. As reputation becomes important you will get network effects creating an even stronger centralization force.
  3. An individual can only check if a list is correct or false by either checking another list or themselves creating a list (which is expensive). Which fails the basic concept of the truth being the blockchain. Why is this important? Because they created a new layer which can be corrupted and made political.

My thinking is that the first quoted part is the most important one. One they got right but then failed to actually solve:

it is imperative that new systems for discovery and reputation do not devolve into centralized gatekeeping.

One imprvement to this I would add is this:

Keep as basic truth the blockchain and merkle-proofs and separate features that will cause centralization like reputation and curating.

If you conflate the storing of metadata with the need of a reputation system then you will stop wallets from being able to fetch basic data about a coin unless its been permissioned to be shown in wallets. The only thing that can not be censored is data on the blockchain. Depend on “lists” and you introduced the ability for censorship, KYC and all that stuff.

I’m writing this as I know this will come back to bite us and I have to have done the best I could to document this now. Hopefully Jason will reconsider my proposal from the linked bug report before the deadline.

1 Like

Jason reached out yesterday and we had a phone call to talk about the problems and possible solutions.

I’m happy to say that we basically are saying and thinking the same thing. He also agreed that using the ETH “Token Lists” may have been a bit confusing as an example for a solution.

I’ll let him explain the ideas for recording the metadata on chain in detail, but here is the short short version.

We can define a ‘metadata-baton’ (not entirely unlike an NFT), in a way that we can implement it with basic transactions. Using things like OP_RETURN we can add metadata and the baton allows one to decorate the identity with more details in follow-up transactions, or change things in some follow-up transaction.

The idea of a baton means you have a series of linked transactions which together make up this identity. They can get mined as normal. You can’t really burn the identity with a not-supporting wallet, but you do want to keep the private key that owns the identity separate for obvious reasons.

Some thoughts on the protocols that this post is actually about:

  • A token metadata is basically an identity. And then I think that we had this fun experiment called “Keybase” (still running, but now owned by zoom) which probably means we can steal various ideas from them.

  • An identity can be associated in real life with another identity or an external site. I could have a public persona on-chain and that public key can be used to verify a file on my website attesting that identity owns my domain. This can be linked back into my chain for external verification.

  • BIP69 sorts outputs for anonymity. (Supported by BCHN, Flowee Pay and likely others). The good thing is that the lowest amount output is output zero, which is almost always what you want to be locked up in your personal chain anyway. The bad news is that op-returns outputs should have zero in the output field, so they will be sorted first.
    I would suggest to make the validation of the chain do more work and allow skipping of the op-return output to carry the baton forward. Because any other option I can come up with will just lead to invalid chains or loss of the baton.

  • I’m thinking it would be useful / a good suggestion that wallets or identity managers use a different HD private key for almost every transaction while carrying the baton.
    The advantage of regularly swapping out private keys that own the identity is that it can for the most part solve the “are we looking at the most recent” problem by having a requirement to sign a challenge with the most recent key. Making it instantly clear when two sides disagree what the tip is.

  • Payment protocol upgrades we’ve been talking about on Payment Protocol will benefit from the inclusion of a full-identity-chain in some way or another. So likely they would both want to use the same formatting, or include it as a binary-blob. IDK.

  • While any 3rd party observer can use the blockchain to identify and trace / update the worldwide total set of identities (search-engine style), I think its important to focus on the idea that most websites / companies are not forced to do so. Instead the protocols should allow the customer to provide the chains to the company (for login, for instance).
    In most cases a simple merkle-proof check is enough exposure to the blockchain, then.

3 Likes

Hi all! I just shared a draft proposal here:

2 Likes