Firstbits

Firstbits' design encourages its users to bloat the blockchain with a dummy self-send transactions in order to get the shortest possible firstbits before anyone else. The creator of firstbits himself is known to have mass registered numerous identifiers to get many short addresses before other people. The transaction churn created by firstbits registrations increases the size of the blockchain and make operating Bitcoin nodes more expensive and cause them to take longer to perform their initial synchronization. This affects all Bitcoin users, even without their consent to Firstbits.

The near zero cost of producing many firstbits addresses encouraged people to go out and mass register whole dictionaries of names. This is especially true for vanity addresses, where they may be "squatted" like domain names in hopes of selling them to a trademark or obvious company/person they represent. But since Firstbits addresses cannot be securely transferred to a new owner— because the original party might retain a copy of the private key— many of these names are likely forever useless. New firstbits users often have to settle for longer names. An alternative design— for example, requiring progressively higher transaction fees to rate limit registration— could have mitigated this "gold rush", but that isn't how firstbits was designed.

Because firstbits identifiers are short and entered manually it's easy to make a typo or a misreading which gives you another valid firstbits address. A malicious party can intentionally and very cheaply register all the common typos around a popular firstbits address. Normal Bitcoin addresses contain a 32-bit checksum to make typos nearly impossible, but firstbit addresses can have no such protection. As usual for Bitcoin misdirected funds cannot be recovered. The need to use longer versions of short names such as "1baseballs" instead of "1baseball"— which may or may not be the same address depending on if another "1baseball" was used first— further increases the risk of error.

Bitcoin was designed such that addresses should only be used once, for a single transaction. Firstbits, by contrast, encourages people to find and use a single address for multiple transactions. This breaks numerous assumptions of the Bitcoin system (to be addressed on another page), in ways which harm even Bitcoin users who choose not to use Firstbits.

Firstbits requires nodes that support it to keep an unpruned index of every address ever used, which means it will grow forever. Note that all existing indexes required for fully-verifying Bitcoin nodes may be pruned. Since Bitcoin is designed so that every transaction should have a unique address, this index will also grow for every transaction. Thus, even light nodes are required to store an eternally, rapidly growing index for as long as Bitcoin (or at least Firstbits) is used.

SPV nodes, which download data only as they require it for their own wallet's maintenance, never see most transactions and cannot build the Firstbits index at all. This means that it is impossible to support Firstbits in SPV nodes. Eventually, all Bitcoin clients will likely use SPV as an initialization state, which makes it additionally confusing for end users.

Because of the cost and storage of creating and maintaining a separate index for firstbits queries an otherwise secure SPV user may feel pressured to use a centralized service to resolve firstbits prefixes given to him by other parties. There are multiple centralized firstbits resolution services already. If a resolution service is compromised and returns wrong results funds will be sent to the wrong destinations. If users are going to use a centralized service any way a centralized alternative to firstbits can be easily created which lacks most of the above problems (at the expense of being centralized).