Firstbits: Difference between revisions
more concerns about firstbits |
Remove irrelevant statement that falsely implies Satoshi has anything to do with Firstbits |
||
| (3 intermediate revisions by one other user not shown) | |||
| Line 6: | Line 6: | ||
Unlike Bitcoin addresses, firstbits are deemed assigned in a '''case-insensitive''' manner. | Unlike Bitcoin addresses, firstbits are deemed assigned in a '''case-insensitive''' manner. | ||
==Criticism== | ==Criticism== | ||
| Line 14: | Line 12: | ||
=== Blockchain bloat === | === Blockchain bloat === | ||
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. | ||
This affects all Bitcoin users, even without their consent to Firstbits. | |||
=== Most good names | === Most good names have already been 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 | 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. | ||
=== Vulnerable to confusion === | === Vulnerable to confusion === | ||
| Line 42: | Line 37: | ||
=== Encourages the use of centralized services === | === 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. | 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). | ||
== See also == | == See also == | ||
* [[vanitygen]] | * [[vanitygen]] | ||
Latest revision as of 07:09, 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.
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' 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.
Most good names have already been snatched up
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.
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. 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).