Firstbits: Difference between revisions
→Criticism: Reorder: list problems that affect people against their consent first, before problems only for firstbits users |
more concerns about firstbits |
||
| Line 18: | Line 18: | ||
Not only is it effectively encouraged by the design of Firstbits, but the creator himself is known to have squatted numerous identifiers in this way. | Not only is it effectively encouraged by the design of Firstbits, but the creator himself is known to have squatted numerous identifiers in this way. | ||
This affects all Bitcoin users, even without their consent to Firstbits. | This affects all Bitcoin users, even without their consent to Firstbits. | ||
=== Most good names were rapidly snatched up === | |||
The near zero cost of producing many firstbits addresses encouraged people to go out and mass register whole dictionaries of names. Firstbits addresses cannot be securely transferred because the original party might retain a copy of the private key, so many of these names are likely forever useless, and new firstbits users often have to settle for longer names. | |||
=== Vulnerable to confusion === | |||
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. | |||
=== Contradicts design of Bitcoin === | === Contradicts design of Bitcoin === | ||
| Line 34: | Line 40: | ||
This means that it is impossible to support Firstbits in SPV nodes. | 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. | Eventually, all Bitcoin clients will likely use SPV as an initialization state, which makes it additionally confusing for end users. | ||
=== Encourages the use of centralized services === | |||
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. | |||
== See also == | == See also == | ||
* [[vanitygen]] | * [[vanitygen]] | ||
Revision as of 05:37, 18 July 2013
Firstbits refers to the practice of abbreviating a Bitcoin address such that only enough of the initial characters of the address are given so that the full address can be identified from the block chain. It also refers to the website http://www.Firstbits.net.
The term Firstbits was popularized by the Firstbits website, which was provided with the intent of a "Bitcoin address shortener", working similar to a URL shortener. Firstbits.net performs a lookup service, giving the full address from the block chain from the initial portion of an address. Anyone with access to a complete copy of the block chain can independently perform the same lookup done by Firstbits.net.
Any time a Bitcoin address is used for transactional purposes and appears in the block chain, its firstbits - or the prefix that uniquely identifies that address within the block chain - are considered assigned at that time. If another address is created and used with the same prefix at a later time, the firstbits of that new address will be at least one character longer, as the shorter prefix remains reserved for the address that used it first. No action on the part of any user is required for firstbits to be assigned - any transaction activity (receiving or sending) for an address for the first time results in firstbits becoming automatically assigned.
Unlike Bitcoin addresses, firstbits are deemed assigned in a case-insensitive manner.
The firstbits of the very first address to be used by Satoshi in the genesis block of the block chain will have been "1".
Criticism
Firstbits is considered by many, including most (if not all) Bitcoin developers to be a bad idea. This is for a number of reasons:
Blockchain bloat
Firstbits effectively encourages its users to bloat the blockchain with a dummy send to their address, in order to get the shortest possible firstbits before anyone else. 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. Not only is it effectively encouraged by the design of Firstbits, but the creator himself is known to have squatted numerous identifiers in this way. This affects all Bitcoin users, even without their consent to Firstbits.
Most good names were rapidly snatched up
The near zero cost of producing many firstbits addresses encouraged people to go out and mass register whole dictionaries of names. Firstbits addresses cannot be securely transferred because the original party might retain a copy of the private key, so many of these names are likely forever useless, and new firstbits users often have to settle for longer names.
Vulnerable to confusion
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.
Contradicts design of Bitcoin
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.
Increases storage requirements of light nodes
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.
Incompatible with SPV nodes
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.
Encourages the use of centralized services
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.