文件列表:

.cspell.json (695, 2023-05-27)
bcmr-v2.schema.json (50238, 2023-05-27)
bcmr-v2.schema.ts (38768, 2023-05-27)
examples.md (6604, 2023-05-27)
examples (0, 2023-05-27)
examples\art-collection.json (4442, 2023-05-27)
examples\decentralized-application.json (4236, 2023-05-27)
examples\fungible-token.json (3991, 2023-05-27)
examples\payouts-or-dividends.json (5925, 2023-05-27)
figures (0, 2023-05-27)
figures\bitauth-identities.svg (94450, 2023-05-27)
package.json (533, 2023-05-27)
reserved-token-symbols-ISO-4217.json (1623, 2023-05-27)
reserved-token-symbols-cryptocurrencies.json (945, 2023-05-27)

# CHIP-BCMR: Bitcoin Cash Metadata Registries Title: Bitcoin Cash Metadata Registries Type: Standards Layer: Applications Maintainer: Jason Dreyzehner Status: Draft Initial Publication Date: 2022-10-31 Latest Revision Date: 2023-05-26 Version: 2.0.0-draft

Table of Contents

- [Summary](https://github.com/bitjson/chip-bcmr/blob/master/#summary) - [Deployment](https://github.com/bitjson/chip-bcmr/blob/master/#deployment) - [Motivation](https://github.com/bitjson/chip-bcmr/blob/master/#motivation) - [Benefits](https://github.com/bitjson/chip-bcmr/blob/master/#benefits) - [Technical Specification](https://github.com/bitjson/chip-bcmr/blob/master/#technical-specification) - [Rationale](https://github.com/bitjson/chip-bcmr/blob/master/#rationale) - [Test Vectors](https://github.com/bitjson/chip-bcmr/blob/master/#test-vectors) - [Implementations](https://github.com/bitjson/chip-bcmr/blob/master/#implementations) - [Feedback & Reviews](https://github.com/bitjson/chip-bcmr/blob/master/#feedback--reviews) - [Acknowledgements](https://github.com/bitjson/chip-bcmr/blob/master/#acknowledgements) - [Changelog](https://github.com/bitjson/chip-bcmr/blob/master/#changelog) - [Copyright](https://github.com/bitjson/chip-bcmr/blob/master/#copyright)

## Summary A standard for sharing authenticated metadata between Bitcoin Cash wallets. ## Deployment This proposal does not require coordinated deployment. Clients can begin implementation upon acceptance of [`CHIP-2022-02-CashTokens`](https://github.com/bitjson/chip-bcmr/blob/master/https://github.com/bitjson/cashtokens). ## Motivation Bitcoin Cash software requires standards for locating and verifying metadata, allowing user-recognizable names, descriptions, icons, ticker symbols, and other information to be associated with on-chain artifacts like identities, tokens, and contract systems. ## Benefits ### Extensible JSON Schema Metadata registries use an extensible JSON schema, ensuring a baseline of compatibility across all ecosystem software while enabling individual vendors and industry groups to create extensions and rapidly innovate. ### Interpretation of NFT Commitments Registries can encode structured information about non-fungible token (NFT) commitment APIs, allowing ecosystem software to parse and understand the contents of any NFT. This enables generalized user interfaces for all NFTs, and application-specific extensions can build on this NFT parsing infrastructure to enable richer experiences – for example: - A table of the user's open orders for a decentralized exchange with sums for "Total Tokens for Sale" and "Total BCH Order Value". - A list of the user's active crowdfunding pledges with information on each campaign and a sum of "Total BCH Pledged". - A view of the user's tickets with times, dates, location, seat, class, gate, etc. prominently displayed. - A gallery of the user's collectable NFTs for a particular game ecosystem with images and other metadata displayed using information encoded in each NFT. ### Decentralized Publishing & Verification Metadata registries can be published by any entity or individual without an approval process. Registries can be authenticated via the Domain Name System (DNS) or via on-chain transactions, enabling strong censorship resistance. ### Contract-Held Identities Identities are held by BCH contracts, enabling identities to employ the same security strategies as those used to secure funds and tokens, e.g. multisignature wallets, offline signers, time-delayed vaults, bounties/honeypots, and more. Identities can modify their security requirements over time, offering built-in support for key rotation and incremental security enhancement. ### SPV Validation of Identities and Claims Identities can be verified by validating only the last transaction in a chain of transactions, so validation can be performed by low-resource clients using lightweight proofs (measured in kilobytes). ### Bootstrapped Trust via DNS Registries may be published via both DNS and on-chain transactions, allowing trust in the registry's identity to be bootstrapped from a domain name that is already known to the user. ## Technical Specification A **Bitcoin Cash Metadata Registry** (BCMR) is an authenticated JSON file containing metadata about tokens, individual and organizational identities, contract applications, and other on-chain artifacts. BCMRs conform to a [Metadata Registry JSON Schema](https://github.com/bitjson/chip-bcmr/blob/master/#metadata-registry-json-schema), and they can be published and maintained by any entity or individual. **Client software** – wallets, indexers, and other software that utilizes metadata – can acquire and authenticate metadata registries using multiple strategies. **Metadata-validating clients** are clients that fully support acquiring and authenticating [chain-resolved registries](https://github.com/bitjson/chip-bcmr/blob/master/#chain-resolved-registries); **DNS-only clients** are clients that support only [DNS-resolved registries](https://github.com/bitjson/chip-bcmr/blob/master/#dns-resolved-registries). ### Embedded Registries **Embedded metadata registries** are built in to published releases of client software, providing a default registry of metadata assembled by the software publisher. It is recommended that all client software include an initially-trusted, embedded registry. Client software may support updating embedded registries [via DNS](https://github.com/bitjson/chip-bcmr/blob/master/#dns-resolved-registries) or [via on-chain transactions](https://github.com/bitjson/chip-bcmr/blob/master/#chain-resolved-registries). ### Manually-Imported Registries Where appropriate, client software may provide advanced users with the ability to manually import registries (e.g. from a file or from an arbitrary URL). Note that malicious registries can mislead users into mislabeling token, identities, and contract applications, leading to loss of value. Implementers supporting manually-imported registries should review the [Guidelines for Client Software](https://github.com/bitjson/chip-bcmr/blob/master/#guidelines-for-client-software). ### DNS-Resolved Registries **DNS-resolved metadata registries** are associated with a particular [Fully-Qualified Domain Name (FQDN)](https://github.com/bitjson/chip-bcmr/blob/master/https://en.wikipedia.org/wiki/Fully_qualified_domain_name); they are acquired and authenticated using [Hypertext Transfer Protocol Secure (HTTPS)](https://github.com/bitjson/chip-bcmr/blob/master/https://en.wikipedia.org/wiki/HTTPS). DNS resolution allows registries to bootstrap trust from domain names that are already known to users. After initially importing a DNS-resolved registry, clients can receive faster updates and prevent targeted attacks by upgrading to [on-chain resolution](https://github.com/bitjson/chip-bcmr/blob/master/#chain-resolved-registries). #### Well-Known URI DNS-resolved metadata registries are published using a [Well-Known URI](https://github.com/bitjson/chip-bcmr/blob/master/https://en.wikipedia.org/wiki/Well-known_URI) with the `https` scheme and a suffix of `bitcoin-cash-metadata-registry.json`. For example, given a fully-qualified domain name of `test.example.com`, the metadata registry must be published at `https://test.example.com/.well-known/bitcoin-cash-metadata-registry.json` and accessed via `GET` request. Registries must allow [Cross-Origin Resource Sharing (CORS)](https://github.com/bitjson/chip-bcmr/blob/master/https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) using `Access-Control-Allow-Origin: *`. If the registry is returned with a `max-age` directive in its [`Cache-Control`](https://github.com/bitjson/chip-bcmr/blob/master/https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control) HTTP header, clients must invalidated and refetch the registry after the stated expiration. If no `max-age` is set, clients should consider downloaded registries to expire after `7` days (`max-age=604800`). #### HTTP Redirect Handling All clients must support the HTTP [`301 Moved Permanently`](https://github.com/bitjson/chip-bcmr/blob/master/https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301) and [`302 Found`](https://github.com/bitjson/chip-bcmr/blob/master/https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302) redirect status response codes when fetching DNS-resolved metadata registries. Clients may handle a status response code of `302` without notifying the user. The registry must be fetched from the alternative URL provided in the `Location` header, and `Location` URLs that do not conform to the [Well-Known URI](https://github.com/bitjson/chip-bcmr/blob/master/#well-known-uri) are acceptable. Clients must handle a status response code of `301` by notifying the user of the permanent redirection. The registry must be fetched from the alternative URL provided in the `Location` header, and `Location` URLs that do not conform to the [Well-Known URI](https://github.com/bitjson/chip-bcmr/blob/master/#well-known-uri) are acceptable. The client must update its records of the canonical Fully-Qualified Domain Name (FQDN) for the metadata registry being fetched; future registry updates must be fetched from the [Well-Known URI](https://github.com/bitjson/chip-bcmr/blob/master/#well-known-uri) using the updated FQDN (even if the returned `Location` URL did not conform to the Well-Known URI). #### Upgrade to On-Chain Resolution DNS-resolved metadata registries may indicate a preference for [on-chain resolution](https://github.com/bitjson/chip-bcmr/blob/master/#chain-resolved-registries) by specifying an [authbase](https://github.com/bitjson/chip-bcmr/blob/master/#authbase) in the `registryIdentity` property of the metadata registry. If a received registry indicates a `registryIdentity` authbase, clients with support for [chain-resolved registries](https://github.com/bitjson/chip-bcmr/blob/master/#chain-resolved-registries) (metadata-validating clients) must update their records to set the indicated authbase as the root of trust for that registry and immediately begin to fetch the registry using [chain resolution](https://github.com/bitjson/chip-bcmr/blob/master/#on-chain-metadata-registry-resolution). Clients without support for on-chain resolution (DNS-only clients) should warn the user that the fetched registry prefers on-chain resolution, but the client only supports DNS resolution. If the DNS-resolved registry includes the [`authchain` extension](https://github.com/bitjson/chip-bcmr/blob/master/#authchain-extension) for the authbase indicated in `registryIdentity`, chain resolution should be [accelerated using the provided authchain data](https://github.com/bitjson/chip-bcmr/blob/master/#authchain-extension). (Note, the registry's authhead transaction must commit to the hash of the published registry, so the registry identity's `authchain` extension is expected to not include the latest authhead transaction.) ### Chain-Resolved Registries **Chain-resolved metadata registries** are associated with a particular **authbase**, a 32-byte, hex-encoded transaction hash (A.K.A. TXID) for which the [**zeroth-descendant transaction chain** (ZDTC)](https://github.com/bitjson/chip-bcmr/blob/master/#zeroth-descendant-transaction-chains) authenticates and publishes all registry updates. Chain resolution offers stronger security and better user experiences than DNS resolution: - **Enhanced identity security** – identities are controlled by unspent transaction outputs, so identity owners can employ the same security strategies used to secure funds and tokens (e.g. multisignature wallets, offline signers, time-delayed vaults, bounties/honeypots, etc.); this avoids many classes of attacks possible against DNS-resolved registries. - **Prevention of targeted attacks** – a hash of the registry is published on the blockchain, so clients can ensure that a received registry is identical to that received by every other client. - **Real-time updates** – identity updates are broadcasted by spending the identity's latest [identity output](https://github.com/bitjson/chip-bcmr/blob/master/#zeroth-descendant-transaction-chains), so clients can detect updates using standard light wallet infrastructure (e.g. [Simplified Payment Verification](https://github.com/bitjson/chip-bcmr/blob/master/https://web.archive.org/web/20100704213***9/https://bitcoin.org/bitcoin.pdf)). #### Zeroth-Descendant Transaction Chains A **zeroth-descendant transaction chain** – also known as an **authchain** – is a chain of transactions where the output at index `0` for each transaction is spent by the following transaction. In the context of authchains, the transaction output at index `0` is known as the transaction's **identity output**. Because all Bitcoin Cash transactions must have at least one output, every valid transaction has a single identity output. The first transaction in an authchain is referred to as the **authbase transaction**; authbase transactions have no distinguishing features, and any valid transaction can serve as an authbase transaction. The final transaction in an authchain is referred to as the **authhead transaction**. By definition, the identity output of the authhead transaction is unspent.  #### Authchain Resolution To resolve an authchain (a [zeroth-descendant transaction chain](https://github.com/bitjson/chip-bcmr/blob/master/#zeroth-descendant-transaction-chains)), clients must recursively identify the transaction that spent the output at index `0` of the current transaction, beginning with the authbase transaction. (Note, this process can be [accelerated using data from `authchain` extensions](https://github.com/bitjson/chip-bcmr/blob/master/#authchain-extension) in registries.) Once validated, clients should retain a mapping of the authbase to the latest identity input to accelerate future resolutions. To track an identity for future updates, clients should monitor the latest identity input for spends (e.g. wallets may monitor tracked identity outputs as if they were UTXOs held by the wallet). ##### Burned Identities Identities for which the authhead transaction includes a data-carrier output (an output beginning with `OP_RETURN`/`0x6a`) as the identity output are considered "**burned**". Identities may be burned to broadcast that the identity is no longer maintained and can be safely forgotten or archived by clients. Other standards may make use of identity-burning data-carrier output to broadcast additional information about the burned identity. Note that identities undergoing name changes or other significant changes to metadata need not burn the identity; updated metadata can be published via [on-chain identity claims](https://github.com/bitjson/chip-bcmr/blob/master/#on-chain-identity-claims). Note also that identities can be seamlessly merged (e.g. after a merger or acquisition) by spending both identity outputs in the same transaction, so burning actively-used identities is rarely necessary. #### On-Chain Identity Claims By including standardized data-carrier outputs in [authhead](https://github.com/bitjson/chip-bcmr/blob/master/#zeroth-descendant-transaction-chains) transactions, identities can broadcast **on-chain identity claims** – public attestations by the identity about various topics. On-chain identity claims can be used to broadcast information like metadata registries, hashes of software updates, [warrant canaries](https://github.com/bitjson/chip-bcmr/blob/master/https://en.wikipedia.org/wiki/Warrant_canary), [tamper-evident logs](https://github.com/bitjson/chip-bcmr/blob/master/https://transparency.dev/), [reusable payment addresses](https://github.com/bitjson/chip-bcmr/blob/master/https://github.com/imaginaryusername/Reusable_specs/blob/16025c2f9f20c9dd16e1619a7a742dad908865f3/reusable_addresses.md), [onion service](https://github.com/bitjson/chip-bcmr/blob/master/https://community.torproject.org/onion-services/) addresses, and other information relating to the broadcasting identity. (Note, metadata registry [extensions](https://github.com/bitjson/chip-bcmr/blob/master/#extensions) offer an off-chain alternative to on-chain identity claims.) [Metadata Registry Publication Outputs](https://github.com/bitjson/chip-bcmr/blob/master/#metadata-registry-publication-outputs) are the only type of on-chain identity claim standardized by this specification. #### On-Chain Metadata Registry Resolution To resolve a metadata registry that is published on chain, clients must first [resolve and validate the authchain](https://github.com/bitjson/chip-bcmr/blob/master/#authchain-resolution) for the registry's identity. Once the registry's authhead transaction has been acquired and validated, the client must inspect the authhead transaction's outputs to locate the [metadata registry publication output](https://github.com/bitjson/chip-bcmr/blob/master/#metadata-registry-publication-outputs), then fetch and verify the registry using the appropriate strategy for that publication output (either [IPFS](https://github.com/bitjson/chip-bcmr/blob/master/#ipfs-publication-outputs) or [HTTPS](https://github.com/bitjson/chip-bcmr/blob/master/#https-publication-outputs)). #### Metadata Registry Publication Outputs Chain-resolved registries are published using **metadata registry publication outputs**, data-carrier outputs that include the hash and – optionally – one or more `utf8`-encoded URIs from which the registry can be downloaded. The locking bytecode of publication outputs must conform to the following structure: ``` OP_RETURN <'BCMR'> [ ... ] ``` Metadata registry publication outputs are identified by the **locking bytecode prefix** `OP_RETURN <'BCMR'>` (`0x6a0442434d52`). Following the locking bytecode prefix, the SHA-256 `hash` (encoded in `OP_SHA256` byte order¹) of the registry contents must be pushed. Thereafter, any number of `utf8`-encoded URIs may be pushed to provide clients with multiple download options². Every transaction can have **zero or one metadata registry publication output**; if multiple outputs share the required locking bytecode prefix, the first (the output at the lowest-value index) is considered the definitive publication output, and later outputs sharing the prefix must be ignored. (Note, even if the first matching output is malformed – e.g. it does not push a `hash` – later matching outputs should not be considered by clients.)

Notes

1. This is the byte order produced/required by all BCH VM operations which employ SHA-256 (including `OP_SHA256` and `OP_HASH256`), the byte order used for outpoint transaction hashes in the P2P transaction format, and the byte order produced by most SHA-256 libraries. For reference, the genesis block header in this byte order is little-endian – `6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000` – and can be produced by this script: `<0x0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c> OP_HASH256`. (Note, this is the opposite byte order as is commonly used in user interfaces like block explorers.) 2. For example, a registry hosted at `https://example.com/.well-known/bitcoin-cash-metadata-registry.json` with a hash of `0x6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000` would be encoded using the locking script: `OP_RETURN <'BCMR'> <0x6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000> <'example.com'>` producing the locking bytecode: `0x6a0442434d52206fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d61900000000000b6578616d706c652e636f6d`.

##### Publication Output URIs Clients may select from any of the pushed URIs to download the registry referenced by a publication output. Following successful download, clients should verify that the hash of the downloaded registry matches the published `hash`. At minimum, all clients must support the [HTTPS](https://github.com/bitjson/chip-bcmr/blob/master/https://en.wikipedia.org/wiki/HTTPS) and [IPFS](https://github.com/bitjson/chip-bcmr/blob/master/https://en.wikipedia.org/wiki/InterPlanetary_File_System) protocols within publication outputs. Additional protocols like `dns`, `ftp`, `git`, `magnet`, `rsync`, Tor (using `.onion` addresses), `ssh`, etc. may optionally be supported by some clients. Publication outputs with no URIs are understood to require that clients request the provided `hash` via a content-addressed resolution protocol, but client support for this behavior is not required (i.e. clients must only support `ipfs://`-prefixed IPFS URIs). ###### HTTPS Publication Outputs URIs without a protocol prefix must be assumed to use HTTPS, and HTTPS URIs without a file path (the URL segment following the hostname, beginning with `/`) must be assumed to use the [Well-Known URI](https://github.com/bitjson/chip-bcmr/blob/master/#well-known-uri) for that domain. E.g. `https://example.com/.well-known/bitcoin-cash-metadata-registry.json` is encoded as `<'example.com'>` (`0x0b6578616d706c652e636f6d`), while a registry hosted at the root of `https://test.example.com/` (rather than at `https://test.example.com/.well-known/bitcoin-cash-metadata-registry.json`) is encoded as `<'test.example.com/'>` (`0x11746573742e6578616d706c652e636f6d2f`). To avoid leaking connection information to registry hosts, clients may choose to download the registry via Tor or via a trusted proxy, VPN, or mirror service. Because the hash of the downloaded registry is verified, sources need not be trusted for registry integrity. ###### IPFS Publication Outputs All clients must support registry download via IPFS. Clients without access to full IPFS nodes may use one or more [HTTP Gateways](https://github.com/bitjson/chip-bcmr/blob/master/https://docs.ipfs.tech/reference/http/gateway/). Gateways need not be trusted, as the downloaded registry may be verified using the published hash. IPFS URIs must include the `ipfs://` prefix. It is recommended that IPFS-distributed registries be published as a single file rather than as part of a larger archive (see [Publication of Static Data](https://github.com/bitjson/chip-bcmr/blob/master/#publication-of-static-data)). ### Metadata Registry JSON Schema Metadata regi ... ...

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：