OP_UNIQUE

Description

OP_UNIQUE is an attribute or attribute opcode that associates a piece of miner-enforced unique data with a TXO. In a manner similar to how the UTXO set prevents doublespends, all blockchain validators must keep a UUDO (unspent unique data output) set to disallow any transaction that associates an already-associated piece of data from being committed in a block. Therefore, implementation of OP_UNIQUE is a consensus change.

A transaction may spend a UUDO UTXO to give up “ownership” of the unique data, or atomically spend a UUDO UTXO and create another OP_UNIQUE tagged output with the “spent” data to transfer ownership of the data to a new constraint script.

The motivating purpose of OP_UNIQUE is to create human friendly identities, but since it is a general service, other uses will emerge.

Attribute Opcodes

An attribute opcode is a workaround that solves the problem that there is no way to associate arbitrary data with TXOs in the current bitcoin transaction format. The only flexible space is in the output constraint script. Therefore, we must use that space. We do so by creating an opcode that is a no-op when executed, but marks and types the data immediately preceding it. This “attribute” data can then be easily read by transaction parsing code, and used within consensus.

To simplify execution, we specify that an attribute opcode must appear at the beginning of a UTXO script, before any instructions that are not data pushes or other attribute opcodes.

If the transaction format ever changes, attribute opcodes would be converted to typed data that is associated with a TXO (an attribute).

Human Friendly Identities

All bitcoin wallets will accept OP_UNIQUE data of the following format as identity:

<4 bytes little endian unsigned integer =1><identity data>

In scripts, this information is wrapped in a PUSHDATA instruction, so the length of the identity data is known. The full script attribute would look like:

OP_PUSHDATA(<uint32(1)><identity bytes>), OP_UNIQUE, OP_DROP

If the first 4 bytes of the data is not the little endian unsigned integer 1, then this UUDO is not identity data and should be ignored when searching for identities.

Light Client Support

Blockchain validators can serve light clients SPV proofs that a UUDO exists within the blockchain. A dishonest validator can at worst serve a proof to a UUDO that has already been spent (transferred to someone else). Avoiding this attack can happen similarly to UTXO validation today: light clients poll multiple random validators to discover the dishonest validator. But this countermeasure can be defeated by an eclipse attack.

If UTXO commitments are added to consensus, light clients can be served UTXO commitment proofs, solving the problem of serving spent UTXO proofs.

In sum, the security model for OP_UNIQUE transactions is no worse than normal bitcoin transactions.

Connecting External Identities To Blockchain Identities

This problem is often stated as connecting a “real” identity to a blockchain identity. But, consider that there is no “real” identity — there are simply various protocols, services and governments that also have identities, via accounts and birth certificates.

The problem is therefore connecting identities between services. If the external provider is aware of this blockchain, it can make connections to the OP_UNIQUE UUDO in a few ways — for example, it could spend a small sum with a known signature to the UUDO. It could also include the UUDO proof in a well known, program-accessible location in its service (in a web site for example). For “hosted” solutions like facebook, twitter, etc, the proof can be placed in a posting.

Conversely, OP_UNIQUE transactions can “claim” external identities by placing such a claim in OP_RETURN data within the transaction.

Cross Validation

Since any identity can permissionlessly make a claim on another identity, its important to check the identity provider that you trust for proof of the identity you do not trust. For example if you want to pay xyz.com, you need to access xyz.com to find a UUDO proof. You CANNOT look up the name “xyz.com” in the blockchain, and see if it has the OP_RETURN data “https://xyz.com”. However, you could look up “xyz.com” in the blockchain to find the link to “https://xyz.com/bch_identity_validation”, and then follow that link to get the identity proof.

The “better” user wallets will search for these identity interconnects and provide UI feedback based on their existence. It may even make sense to disallow spending to identities that look too similar to the most popular external identity providers in your culture, yet do not provide cross-validation.