FirstBits.com - remember and share Bitcoin addresses

[hannesnaude]

You can transfer a firstbit the same way you can transfers a regular bitcoin address, either send the whole wallet file or the keypair for the address

Yes, you could, but, as mentioned in my post there is no way for the recipient to know that you haven't kept a copy for yourself. Only a fool would accept it.

What do you mean 'extended firstbits addressess'?

The typo on addressess is ironic in the context.

I simply mean a firstbits address where more than the minimum number of characters are supplied as has been repeatedly suggested in this thread in order to obtain some protection against typoz.

A 5-bit checksum (~35 alphanumeric) is pretty good validation of the entire 5 character string. I could imagine replacing the prefix '1' with a firstbits checksum, such that 1kk5k could be x-kk5k. I suggest that the 'checksum' represent LAST character of the full 33+ character address. That would correctly detect 97% of potential errors or 99.9% with two characters.

Indeed a single character provides pretty good protection. I would want to have the checksum as a postfix rather than a prefix, simply because it is optional and it is more intuitive to drop a postfix than a prefix. Any checksum scheme where there are 35 possibilities wil provide a 97% chance of detecting an error so the last character is by no means special. Where the schemes differ is in their ability to detect common errors. The scheme I suggested can detect 100% of single character substitutions. I realized since that it does not handle all single character additions and deletions and detects no transposition errors. This is pretty damn bad. A better suggestion would be something similar to the ISBN scheme that can detect all single character substitutions and transpositions. ISBN has the advantage that unlike firstbits it is dealing with a fixed length payload, so it doesn't need to worry about insertions or deletions.

But generally, I don't see the need for a checksum at all. I've rarely called a wrong number and if money was on the line, I'd triple check, checksum be damned.

Good for you. This is why it's optional. Use it, don't use it.

I don't see a practical way around this 'problem' nor is it eager to be solved.

Implying that you consider the solution I proposed to be impractical. Care to elaborate?

As to "problem" and "nor is it eager to be solved". Again, if it doesn't affect you, good for you. Others feel different, grant them some space.

[BkkCoins]

The only hassle today is that there is currently no way to transfer ownership of such an address. I don't own 1Linux, but if I did, I might be willing to sell said address to BkkCoins if the price was right . Today the only mechanism to do that is to send him the private key, but he would be a fool to accept such a deal since I may well have kept a copy of the key and be in a position to steal any funds he subsequently receives.

I don't see a practical way around this 'problem' nor is it eager to be solved.

This is the same reason I wouldn't use one of these paper wallet or BitBills services. On the up side the new owner of the address can just use it as a transfer address where all funds get moved out to a safe address right away (such automation would be easy to code), thus limiting it's vulnerability somewhat (though not totally safe of course).

[hannesnaude]

This is the same reason I wouldn't use one of these paper wallet or BitBills services. On the up side the new owner of the address can just use it as a transfer address where all funds get moved out to a safe address right away (such automation would be easy to code), thus limiting it's vulnerability somewhat (though not totally safe of course).

Good suggestion. Two remarks.
 
Firstly, note that it gets progressively more risky every time the wallet is passed on, since any or all of the previous owners may try to grab your income. For an account with an fb alias like 1poker or 1bank that may be sold several times and is likely to ultimately handle large amounts of transactions this is completely unacceptable.

Secondly, this can easily get very expensive in terms of transaction fees, since you will always be shifting recently received cash and some of the received txs may well be small.

[dserrano5]

...then I would use half (?) of that money to pay firstbits for having 1linux123 deleted from the database. Then, I tell the other person that he/she can enter 1linux456 into the site and get the "1linux" firstbits.

What makes firstbits great is the fact that there is no centralized database.

Oops, I don't know where I pulled that idea from .

[infested999]

firstbits.com

The guy who has the address that start's with the number "1" is really lucky xD You just have to remember the first digit.

[coblee]

firstbits.com

The guy who has the address that start's with the number "1" is really lucky xD You just have to remember the first digit.

lol, that's probably Satoshi.

[hannesnaude]

The guy who has the address that start's with the number "1" is really lucky xD You just have to remember the first digit.

I believe he is called Satoshi  . As pointed out before on this thread, that's the firstbits address of the wallet that received the coinbase payment from the genesis block. If you could transfer wallets, that would be a valuable one indeed for collectors, akin to the first dollar ever printed.

I've thought about my own proposal for signalling transfer of a firstbits alias a little more and realised a couple of things. It's not required to burn any money in order to generate a unique signaling transaction. Something as simple as inserting a NOP instruction into the pubkey script would make it distinguishable from an ordinary payment without making it impossible to spend the output. A better solution would be to use the OP_DROP instruction and include some data that indicates that this is a transfer.

Even though it is possible to do this without burning money, it may still be better to structure the tx in such a way that the output can't ever be spent, but not for the reason I thought before. The real reason is that if the output is spent, then future versions of the client may well prune this tx from the blockchain, eradicating all record of the transfer and causing the alias to revert to its original owner.

In addition, the proposed scheme effectively only verifies that the current owner of the alias is willing to transfer it, but not that the new owner is willing to receive it. You would be unhappy if 1pervert suddenly started resolving to your publicly known donation address.

So, my updated suggestion is as follows.

The buyer and seller of the alias agree on the price. The buyer then generates a normal payment tx for the agreed amount with some additional data inserted in the pubkey script using OP_DROP, marking it as an alias request. He does not yet transmit the tx on the network, but sends the hash of the tx to the seller (specifically to the key that currently has the alias he wants). The seller generates another payment tx using the hash that was sent to him as the input and sending 1 satoshi to the buyer's address using a crippled pubkey script so the output can never be claimed and the remainder to himself using a normal script. He then sends this tx to the buyer who verifies that everything is as expected and releases both txs onto the network. The firstbits algorithm recognizes this pattern on the blockchain and the alias(es) now resolve to the buyers address.

This sells the alias directly from seller to buyer without requiring trust or escrow.

Comments?

[FreeMoney]

Interesting ideas hannesnaude. I worry about some people implementing the change and some people using the 'pure' system. Calling it something else would help avoid confusion. It's also possible to make a system use something other than the beginning of an address. The end of address is obvious, but other things would work. A (probably bad) example would be to use the block number plus number of the transaction (listed by id, or alphabetically?) so Satoshi's addresses in the gen block that has a firstbits of "1" would have a BlockRankNumber of 1-1 and the second address in the most recent block would be 137009-2. This would probably lead to people packing blocks with even numbers 140000-1 might be a coveted spot, lol. Sorry, this is off your point, just wanted to say that there is room for a lot of different shortening methods. Flavors of firstbits are fine, but confusion would be really bad for the original and for spin offs.

[hannesnaude]

Cool. I thought it would still be early enough to make non-breaking changes to the algorithm (are there allready many other implementations out there?) and didn't think you would be in favour of other flavours of the firstbits idea due to the risk of confusion that you mention.

But if you are not opposed to the idea, I think I might have a go at coding a transferable decentralised address alias. Might I push my luck and ask if you would be willing to opensource the firstbits code? Would make a really nice starting point. 

[coblee]

hannesnaude, although your idea is interesting, I can't see it becoming popular. FirstBits has a nice property of never changing and that anyone can implement a website that provides the exact same service. The fact that a shortened address can change according to your rules makes it such that your are the sole controller of what's "right", of which shortened address points to which public address. In a sense, your service will be no different than a shortener that lets you pick a short vanity address. Why would anyone pay someone else for their shortened address via your service when they can just get their own vanity address here? http://payb.tc/

[hannesnaude]

Hi coblee.

I'm afraid you don't seem to have understood my proposal. The trade involves no third party and everything is still decentralised. The nice property that anyone can implement a website (or client) that provides the exact same service is retained. The only thing that changes is that it becomes possible, but not required, to sell or gift your alias or buy one from someone else. If you don't sell your alias, then it won't ever change.

H

[coblee]

I understand that everyone can implement a website (or client) with your rules. But another website can decide on their own rules on how to "transfer" an address. Since your rules won't be as simple as FirstBits, it will be hard for people to just accept it. As a user, I will just use payb.tc instead of paying someone for an address that only makes sense by your rules. Know what I mean?

[SgtSpike]

I understand that everyone can implement a website (or client) with your rules. But another website can decide on their own rules on how to "transfer" an address. Since your rules won't be as simple as FirstBits, it will be hard for people to just accept it. As a user, I will just use payb.tc instead of paying someone for an address that only makes sense by your rules. Know what I mean?

I think that is why he proposes it be added in to the "official" site early on, so it becomes part of the standard of rules that everyone uses.

But FreeMoney speaks the truth - it would take away from ALWAYS being able to identify the proper firstbits, no matter the site.  If transfers were allowed/implemented into the official site, but another clone site implemented only the basic firstbits technique, without adding in the algorithm for checking whether an address has been transferred, then the firstbits would be confused and owned by the wrong person on that clone site.  Sure, it would be the fault of the clone site for not implementing the full algorithm, but it would still return a valid-looking address, and it would devalue the purpose of having a firstbits address in the first place if no one can trust that they are getting the right address out of it.

[FreeMoney]

Cool. I thought it would still be early enough to make non-breaking changes to the algorithm (are there allready many other implementations out there?) and didn't think you would be in favour of other flavours of the firstbits idea due to the risk of confusion that you mention.

But if you are not opposed to the idea, I think I might have a go at coding a transferable decentralised address alias. Might I push my luck and ask if you would be willing to opensource the firstbits code? Would make a really nice starting point. 

We will post the code soon.

I don't plan to change the algorithm called firstbits at all even though there are no other implementations that I know of.

It's a neat idea (decentralized transferable aliases), but I like the purity and intuitiveness of firstbits. It would be strange to call something "firstbits" if 1mike7 returned 1jkaF92... I think you should work on your idea, but maybe find another way to encode aliases in the chain. It seems like it would be ideal to be able to pick any conforming alias and associate it with your address via some transaction. Then the rule would be the first to make a valid claiming tx gets the requested alias.

A (probably bad) example would be send 11 satoshis to an address then send any amount within 100 blocks and that amount is your alias. You could convert the number to whatever base is all lowercase or lowercase and numbers or whatever. If anyone ever tried to make the same claim it would just be ignored, only the first would count.

To be clear, I am in favor of other people making other systems, just not calling them firstbits. Anything calling itself firstbits should use our exact algorithm and opening the code will help people do that.

[dserrano5]

Bug report: for some reason, copying and pasting an address gave weird results in this machine, so I partially copied it, then pasted it and manually typed the remaining characters. I unavoidably mistyped the last one, and entered "y" instead of "Y". I didn't get the message "This address isn't in the chain", but I got "Your firstbits address is:" instead, without any firstbits address after that message.

[FreeMoney]

Bug report: for some reason, copying and pasting an address gave weird results in this machine, so I partially copied it, then pasted it and manually typed the remaining characters. I unavoidably mistyped the last one, and entered "y" instead of "Y". I didn't get the message "This address isn't in the chain", but I got "Your firstbits address is:" instead, without any firstbits address after that message.

Thanks, will look into it.

[marcusaurelius]

To be clear, I am in favor of other people making other systems, just not calling them firstbits. Anything calling itself firstbits should use our exact algorithm and opening the code will help people do that.

thank you freemoney for keeping with the basic algorithm. i know a lot of people here are all about "marketsmarketsmarkets", but this really is a technical matter, not an economic one.

i also, personally, think that if firstbits.com integrated this, it would dig its own grave. not that you make any money out of it, afaik.

[SgtSpike]

Bug report: for some reason, copying and pasting an address gave weird results in this machine, so I partially copied it, then pasted it and manually typed the remaining characters. I unavoidably mistyped the last one, and entered "y" instead of "Y". I didn't get the message "This address isn't in the chain", but I got "Your firstbits address is:" instead, without any firstbits address after that message.

Bug is fixed, thanks for reporting!

[dserrano5]

Glad to make this a better world .

[jim618]

Hello Firstbits aficionados.

I have posted an idea that combines Firstbits with people's names on the "Development and Technical Discussions" forum.
(I probably should have put it here but did not think of that until too late).
The topic is:

https://bitcointalk.org/index.php?topic=38664.0


The subject line for the idea is:
" Firstnames | Combining people's names with Firstbits for short bitcoin addresses"

I really, really am not trying to hijack this thread but would be very interested in your feedback on this idea.   If you could post any comments on that thread all the comments will be in one place.   

I am hoping if you like Firstbits you will also like the related idea of "Firstnames".

Thanks in advance.