Skip to content

Latest commit

 

History

History
142 lines (88 loc) · 5.2 KB

paper.adoc

File metadata and controls

142 lines (88 loc) · 5.2 KB

Bitname Protocol Specification

Overview

Bitname is a protocol via which arbitrary text (a "name") may be associated with a Bitcoin address, and thus its underlying public key. Unlike existing solutions for this, name registration is temporary—​each service may choose how long each name contract should last. This is accomplished using BIP 68 relative locktimes.

Ownership of a name can be verified independently of the registering service. all necessary information is publically available on the blockchain.

In order to register a name, a specially-formatted transaction is sent, with one of its outputs being to a P2SH address for a script with two branches. In one, the registrant may spend funds immediately. In the other, the registrar may spend funds only after a set period of time. This provides a degree of certainty that services which the registrar promises will be continued—​if they are not, the user may just take their money and leave.

Ownership of names may also be transferred. In order to do this, the current owner essentially makes a revocation transaction, but specifies the outputs to be the start of a new contract with the service. Additional inputs may be provided, allowing the current owner to require payment of some kind from the new party.

Transaction Format

There are three classes of transactions in the protocol: commitment, locking, and unlocking. The former creates a name attestation, while the latter spends funds from it once it has expired.

Commitment Transactions

Inputs

The locking transaction may use inputs from any source, including P2PKH and P2SH addresses. This allows the possibility of using multisignature wallets as sources of funding.

Outputs

0

An OP_RETURN containing the nonce value.

1

A P2PKH to the service’s address.

2

A P2SH for a script of the following form:

6 CHECKSEQUENCEVERIFY
DROP
HASH256
[hash of 256-bit nonce + 2-byte locktime (BE) + 1-byte length of name + name] EQUALVERIFY
[user pubkey] CHECKSIG

The CSV is to ensure that at least 6 blocks have passed, meaning that history cannot be rewritten.

Ths scriptSig for this output will be:

[user sig]
[256-bit nonce + 2-byte locktime (BE) + 1-byte length of name + name]

Note that the name must contain 1-64 URL-safe characters (see RFC 3986)

[3..∞)

Change outputs. These may be of any form.

Locking Transactions

Inputs

The locking transaction must use output 1 of the commitment transaction as input.

Outputs

The outputs must be provided in a specific order. While this violates BIP 69 lexicographical ordering, it ensures that the transaction can be parsed correctly.

The outputs are as follows:

0

A P2PKH output to the service’s set address. This represents the upfront fee for the service. The value should be determined by the service.

1

A P2SH output to the time-lock script’s address. This is the fee that incentivizes the registrar to provide the service as promised. More information about these script contracts will be provided later. The value should be determined by the service.

[2..∞)

Change outputs. These may be of any form.

Unlocking Transactions

The unlocking transaction refers to the transaction spending from the time-lock P2SH address.

The redeem script is of the form:

IF
    0 CHECKSEQUENCEVERIFY
    [user pubkey] CHECKSIG
ELSE
    [absolute time] CHECKLOCKTIMEVERIFY
    DROP
    [service pubkey] CHECKSIG
ENDIF
[user pubkey]

The user’s spending pubkey

[absolute time]

The encoded time lock length

[service pubkey]

The service’s spending pubkey

Note that as of this version, the spending transaction is limited to a single pubkey. This may be changed in later versions.

Spending as the User (Revoking/Transferring Name)

The scriptSig will be:

[user sig] 1

Spending as the Service

The scriptSig will be:

[service sig] 0

The transaction sequence number must also be set to [time].

Protocol Gotchas

Duplicate Names

Alice registers the name 'test' at block N, and the registration is valid for 100 blocks. At block N + 50, Bob registers the same name, also for 100 blocks. Which registration is valid in this case?

In this case, we say that Alice’s registration is valid, and Bob’s is invalid. In fact, it is invalid even after block N + 100, when Alice’s registration has expired. This discourages an attack wherein Bob intentionally registers 'test' for 65535 blocks (the maximum allowed) at block N + 99 and extorts Alice in exchange for revoking his registration.

But what happens if Bob is watching the mempool and decides to DoS Alice? He can publish a transaction registering the same name, and it may be accepted in the same block (especially if Bob happens to be a miner). To discourage this, right now both registrations will simply be ignored. In the future, however, a cleaner solution will be developed, possibly taking ideas from Namecoin.