Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: da2ce7 on April 01, 2012, 12:39:04 AM



Title: Adding "Send to Firstbits address" support for Bitcoin (maybe not)
Post by: da2ce7 on April 01, 2012, 12:39:04 AM
Since First-bit addresses are derterministic, I think that they should be fully supported in the Satoshi Bitcoin client.

Unfortunalty, I'm not a c++ coder, I so I cannot develop it myself.
I think this will be a very good system to include in the offical bitcoin client, making life easier for anyone who shares a bitcoin address.


Edit: On talking to some people in #bitcoin-dev, it seems like firstbits, while useful for minimally referencing a bitcoin address, should not be encouraged, as it makes it much easier to scam.


Title: Re: Adding "Send to Firstbits address" support for Bitcoin
Post by: ByteCoin on April 01, 2012, 12:43:02 AM
Since Firstbits addresses are deterministic, I think that they should be fully supported in the Satoshi Bitcoin client.
Since the adoption of Firstbits has demonstrably contributed to useless block-chain bloat and the implementers have "reserved" many of the short addresses before "going public" I suggest that it should not be supported.

ByteCoin


Title: Re: Adding "Send to Firstbits address" support for Bitcoin
Post by: FreeMoney on April 01, 2012, 12:49:44 AM
I don't think it should be in the mainline client. Mainly because a typo causes lost coins and 'bitcoin' shouldn't take risk of blame for that. People should at least realize they are doing something more on the edge.


Title: Re: Adding "Send to Firstbits address" support for Bitcoin (maybe not)
Post by: Pieter Wuille on April 01, 2012, 11:30:20 AM
Firstbits is essentially a scheme for registering a short name for a static bitcoin address. So far so good, but it uses the blockchain to store the registrations. This encourages spamming the blockchain to be the first to use a particular prefix, and is not compatible with pruning (consuming the outputs of the first transaction that used a particular address, may change the firstbits mapping). This problem can be avoided by keeping a separate database of each prefix along forever, but at that point it has no advantages over a third party registration system for address aliases anymore.

Furthermore, it enforces the notion that a single static address should be tied to an identity, instead of using a new address for each transaction. Almost by definition, since a firstbits mapping is intended to last forever.

For these reasons, I would not accept such a patch for the reference client.


Title: Re: Adding "Send to Firstbits address" support for Bitcoin (maybe not)
Post by: CIYAM on April 01, 2012, 11:37:28 AM
On talking to some people in #bitcoin-dev, it seems like firstbits, while useful for minimally referencing a bitcoin address, should not be encouraged, as it makes it much easier to scam.

I think this is a very real problem with the whole "vanity" address concept.  Unless the vanity address is extremely expensive to create due to the number of fixed leading characters it will be just as easy for anyone to create their own address with the same prefix (unless the service will never list another similar vanity address in which case you could still be scammed by the service).



Title: Re: Adding "Send to Firstbits address" support for Bitcoin (maybe not)
Post by: FreeMoney on April 02, 2012, 03:01:38 AM
Firstbits is essentially a scheme for registering a short name for a static bitcoin address. So far so good, but it uses the blockchain to store the registrations. This encourages spamming the blockchain to be the first to use a particular prefix, and is not compatible with pruning (consuming the outputs of the first transaction that used a particular address, may change the firstbits mapping). This problem can be avoided by keeping a separate database of each prefix along forever, but at that point it has no advantages over a third party registration system for address aliases anymore.

Furthermore, it enforces the notion that a single static address should be tied to an identity, instead of using a new address for each transaction. Almost by definition, since a firstbits mapping is intended to last forever.

For these reasons, I would not accept such a patch for the reference client.


You need a full chain for firstbits lookups, you can use a pruned chain if you are just mining. This is another good reason not to include it in the main client.