Bitcoin Forum

FirstBits.com (http://firstbits.com) tells you how much of a Bitcoin address* you need to remember to uniquely identify it, usually only 4-7 characters. Share this 'firstbits' address and friends can find your whole address easily.

This is perfect for when the person paying you does not have immediate access to a computer and you trust them to pay you later.

Meeting someone to make a cash<-->BTC exchange? Just remember your firstbits. Say it and your partner can have your address in their client in seconds.

Here is another potential use. A shop displays an address for you to pay, you need only type the firstbits address into your phone, no need for typing 33 characters or taking a picture of a QR code.

I'm sure people will come up with uses I haven't thought of. I expect that the ability to pass addresses like this will open up some new possibilities.

*Your address must already be in the chain in order to have a firstbits address. You can send a token amount to yourself at any address to get it in the chain.

edit: Firstbits addresses are case-insensitive. This makes them a lot easier to remember and say and doesn't make them much longer on average.

usefull

I'm wondering a bit about the case-sensitivity... I pasted in your donation address and got 1kk5k (all lowercase).

How does one easily expand those first bits to a full address? I thought blockexplorer searches for example were case-sensitive.

Nevermind. I see that you can just search for it on your site.

Shouldn't you list more results if there any?

Specifying only the first 4 'bits' for addresses in my book mostly gives me a wrong result. This can be misleading and dangerous if users are not aware how it works.

It is not always 4 'bits', it depends on what other similar addresses have entered into the blockchain prior to that one. to find out how many your particular address needs, just type it in the box and it will tell you. As for it being dangerous to the naive user, thats the case with most things in life and is simply unavoidable.

Freemoney, let me know if my explanation is wrong. And thanks alot for making this, I've thought for a while something like this would be very useful!

Good question.

You cannot guess your firstbits address. You need to enter it and find out (or search the chain yourself).

A firstbits address is the starting string that is sufficient to distinguish an address from all addresses before it in the chain. This way a firstbits can never change. Listing all matches would not tell you which was yours anyway.

Perhaps a warning is appropriate.

The main use I have in mind is a person learning one of their firstbits like they learn their phone number and using it for casual payments. It is not as great for people or situations where you need a new address each time.

That's right. Case does not matter. I should have mentioned that in my first post. We decided that it is too hard to remember and say uppercase and lowercase.

Forgot to say SgtSpike is the programmer and does excellent work.

Casual payments are definitely one of the first uses that comes to mind.

I know that one of my firstbits addresses is 18tkn.  And I have memorized that address.  Now, no matter where I am, if someone needs to pay me bitcoins, we can hop on the website, grab the full address, and they can pay me.  I think this will work really great for casual payments, as FreeMoney said.  Businesses could also potentially use it for payments, maybe people meeting up for craigslist transactions might find it handy, and certainly non-profits that take donations could make good use of it.

Erm, what if someone happens to generate an address later that has the same first few characters as your address?  Surely that would change your firstbits?

No it wouldn't. The newly generated address would be longer when converted in firstbits, that's all.

One caveat: you guys should not generate the FirstBits alias if the address is not found in the chain, and explain to the user why you can't give him his FirstBits alias.

If you generate a FirstBits alias for an address that hasn't been stored in the chain yet, there is a possibility of collision with someone doing the same thing.

edit:
A nice use case for this will be combining it with the vanity addresses. If people could have a public address like "1joan" or similar, it could be terrific.

Of course. An address must be in chain in order to have a firstbits, maybe I shouldn't have made that smaller font in the OP.

We do not generate the FirstBits address if the address is not found in the chain, for the very reason you mentioned.  A bit of an explanation on that front might be warranted though - right now, we only tell the user that the address is not in the block chain, and there isn't any mention of why only blockchain addresses are included in the "About Firstbits" page either.

Sorry, my mistake. I had clicked the "new" address button in the client to test. I didn't realize it had given me an address that had been used to collect change in a previous transaction  ;)
Tried it again with a really new address, and it worked.

Oh, interesting... I didn't know that the client would do that either, good to know.

That's right. I'd hate for people to use it wrongly, but I think warnings and extra explanation are just going to confuse anyone who can't do it correctly. I would like to hear other opinions though. In general if you aren't sure about what you are doing just don't press send on your client.

This looks like it'll make it possible to actually memorize an address.  Cool!

Another possible use might be forum signatures.  Since a forum signature here is limited to 300 chars, in the interest of saving chars, you might write:

FB: 18tkn
or
FirstBits: 18tkn

Instead of:

18TKNbSLTrd3a2W8mtoH5uNzFhWRWNcuHU

Either one would be significantly shorter, but would still allow you to ask for donations to that address in your forum signature.

Yeah, and tweets, whats the limit there?

140 chars limit on tweets - good point!

Clever! I entered "1" and got the generation address from the genesis block. :)

How come the firstbits string is all lower case?

It's a lot harder to say and remember 1-uppercase B-lowercase C-3-uppercase D.

Yes, I get that, but I was puzzled by the loss of information. I guess it's technically not the "first bits" of the address, since you lose some bits by lowercasing the address. :)

A suggestion: make the decoded address a link to blockexplorer. Makes it easier to check that you got the right one.

EDIT: Another thought... isn't the "1" at the beginning unnecessary since it's always the same? Drop it and the short version becomes even shorter.

The link to block explorer is a good idea.

I was actually torn between the purity of keeping the caps and the risk of typos / ease of use factor. It makes addresses need to be less than 1 char longer on average.

The 1 identifies a string as a Bitcoin related address and isn't any harder to remember.

Thanks for the feedback.

True, but I think it could be dropped for the same reason that people no longer start with "h t t p colon slash slash w w w dot" when they say the address of a web site.

foo, I would say it is more akin to someone dropping ".com" from the end of a web address, then expecting people to still know what the address was for.

Putting a 1 before it should clue people in to the fact that it's the start of a bitcoin address, just like saying "firstbits.com" immediately tells someone that it is a website.  Saying "go to firstbits" wouldn't tell a person much.

Idea/Suggestion:
Redirection of URL of type http://firstbits.com/1kk5k - to a page with the expanded address. (or to the main page with and perform the search)
This way people could link to their firstbits easily.

Of course if you start doing that then no need to limit it to shortened addresses... http://firstbits.com/givememoney could work just as well :p

So maybe take it with or without the "1"? Seems reasonable. Ah, no, not possible. 11feh and 1feh problems.  

If this could somehow be tied into an SMS system, we could have a very viable way to buy something at a coffee shop with Bitcoin.  SMS is more or less universal to all phones, while most prior thought has involved an app on a smartphone.

Working on this.

This is what firstbits avoids. You don't need our special database to convert full<--->firstbits. You just need the chain and the rule. So someone can clone it or make a chrome extension or a phone app and they don't need us to keep their database current, just the chain.

This is great! Love it! Enough to suggest that it be built right into clients.

+1

was just about to mention this.

Another suggestion: I realize you want to keep it pure, but how about adding an extra character as a checksum? It's very easy for the payer to mess the address slightly by writing it down wrong or hearing something wrong. A one character checksum would drastically reduce the chances of sending money to the wrong account.

Adding an additional character of your firstbits address will accomplish the same thing (miniscule chance of a typo), but without ruining the purity.

Example:
One of my firstbits address:  18tkn
The same address, but more protected against typos:  18tknb
The same address, but VERY protected against typos:  18tknbs

Basically, once you own a firstbits address, you also own all of the firstbits addresses beyond the minimum chars necessary to uniquely define the address.  And each added character would add in typo protection just like a checksum would (it will probably be a long, long time before any address is created that is only one character off of 18tknbs).  It is then just up to the individual handing out the firstbits address how much "typo-resistance" they want to give their address, versus having it shorter and easier to remember.

I'm glad you like it. I'm sure it won't be in the main client for a long time if ever.

But I heard Bitcoin is open source so maybe we can get someone to make the modification!

I did think about the checksum idea and like spike says we went with the option to add more digits from the address.

The main problem with checksums is that you can't make it optional because another address will show up that has the checksum digit as part of itself. Requiring our arbitrary checksum would hinder wider acceptance and I think. And you can get more typo protection than a checksum provides if you really want it by adding 3 or 4 characters.

I wouldn't give my firstbits to my grandmother over the phone, but if I had to I would give 3 extra chars.

Yeah, SgtSpike's reply was great, good points all around. I'm a true believer now :)

Returned addresses now link to their blockexplorer page. You could add security by telling the payer the first block the address appeared in and having them check.

Hi,
could you implement something like:
http://firstbits.com/1env4g

other than that great service, consider donating

Just created my vanity firstbits address and came here to ask for that feature. I saw that it's a popular demand, then went to try it and found that it works! :)

If it returned a text/plain result containing only the address (instead of a full featured HTML page), it wouldn't be that difficult to integrate with the bitcoin client. Just an HTTP request and there you go! (I couldn't do it tho, my second language isn't C++).

You're not storing the results anywhere, so using the same algorithm the exact same result for any given address could be obtained even with a machine that never went online and got the blockchain transfered via sneakernet? Awesome! :D


Though, is there the risk the order of very recent addresses will be rearranged as the whole network acknowledges things from different directions or does that order gets stable fast enough for that only be a concern with major blockchain forks?

This is implemented.

http://firstbits.com/1kk5k

That's right.

A reorg could cause problems. Likely the problem would be a simple "not found" at worst, but if screwing up people's firstbits was the point of the attack someone could slip a different one in earlier. This is not protected against now. One way would be not counting an address as "in" the chain until 6 or 10 blocks or something and refusing to return an address until then, probably better is a simple warning that the address is near the tip of the chain. Or even less obtrusive would be to watch for a reorg and only warn when one recently happened.

The api is up.

http://firstbits.com/api/?a=1kk5k

Can't promise it'll stay if it gets overused though, be gentle.

Somewhat longish, but better than nothing. Thanks!

Better than nothing, sheesh  ;D

Nothing is what we had before :) (besides parsing HTML—ouch).

Yeah, I was just feigning insult that you would consider it anywhere near "nothing". I guess you want firstbits.com/api/12345?

Feigned or not, I admit my statement wasn't very bright.

Haha, no problem. I appreciate the link in your sig.

AWESOME SITE WOW !  ;D

I get so happy when I see devs making useful sites like this one.

Donated to you! Hope others do as well.

Thanks! Glad you like it.

Making addresses shorter online is cool, but has anyone had a chance to use it in the real world? I've memorized a few of mine and now I'm just waiting for someone to offer me bitcoins on the street  8)

I'm in Spain and I guess it'll take some time for bitcoin to hit the streets, but I'm already prepared for that ;D.

Is there an estimative of how long this idea will remain useful for people that aren't memory savants?

One question, when you put an address that is too short (say 1k) why does not show all the addressed with that first characters? Should you get a warning when your address has the potential of being confused with another one?

The service isn't designed to do that. It returns the first address (as it appeared in the block chain) that starts with "1k", ignoring case.

1k points to the first instance of an address beginning with 1k in the blockchain, the first one is always only one, so there isn't others that can be confused.


Though, how would the system deal if two addresses sharing the same bunch of initial characters are seen for the first time in the same block? Are the order of addresses in blocks predictable, like they're sorted "alphabeticly" or somthing ?

Ah, sorry, that should have been said. Ties in a block are by tx ID.

Like others said. The beauty of this is the the first will always be first so you don't have to worry about other matching later, they will have the longer firstbits.

Allright, I get it! thanks.

There is room for 1.8 billion that have 6 chars after the '1' and 63.6 billion that have 7 chars. I think a mix of letters and numbers is not much harder than a phone number and people used to store dozens of those in their heads.

This is brilliant. 

How about a page that takes a list of addresses and outputs their firstbits ordered by size?  This will become more useful as more addresses come into existence and you want to find your address with the most memorable firstbits.   Only downside I can see it the resource hit to your server.

Speaking of which, the fact that it's a third party service seems like one of the only downsides.  If the site became popular and was compromised it could have far reaching and costly repercussions.  Actually I think that the best place for this is in the client itself.  This could change when not everybody has easy access to the full blockchain.   Online wallets should implement their own versions (or perhaps you'd package it up as a library?).  This is all further down the road of course.

How about a warning if the first entry of an address was in the latest X blocks?  That's the only time I can see where it might be possible for a firstbits address to change.  I can't see how it would be a worthwhile attack and it's highly unlikely to happen by accident so I'm probably being unnecessarily tedious, but waiting a few blocks does seem like the current bitcoin accepted model. 

Again, this is a great idea and the I like the simplicity of the site.

 
Thanks!


Our site makes it easy, and it's the only one right now, but our site is not required. The rule we follow is simple and the only database you need is the block chain. It could be bad if we were compromised and people didn't realize and were tricked into sending incorrectly, but when discovered people can switch to a copycat, I hope there will be many using the exact same rule to avoid confusion.


This is a good idea. We're not going to do it yet though, working on other things and like you say, resource considerations. If anyone wants to put it together themselves they can use our api to test and then maybe we can help make sure you get the exact same rule implemented easily.

 
I'm thinking on this. Will probably go with a warning that there has recently been a split. The simple fact that your address is recent shouldn't cause alarm and so the warning will be ignored.


Yep, not going to clutter it up. Feel free to test out our firstbits.

yeponlyone, I'm glad you are neither the developer nor the OP. Otherwise, I'd ask what UX or software company you work for so I can short it.

I happened to have a 1+7 (Base58) sub-string and I trust that FirstBits.com came up with the correct address, but at 1+4 (Base58 - 1B2oH) it was incorrect and does not indicate that it may be incorrect/collision. This is a serious user experience flaw and in my opinion unreliable and thus unusable for money until that is fixed. At some point in the future 1+7 might not be likely unique. Who knows? Certainly FirstBits.com is not warning me!

As for 'bits' in quotes or otherwise, since this is the topic, let's be accurate. 4 base58 characters are roughly 24 'bits'. And as of today, I wouldn't trust FirstBits until well after 40 'bits'.

Otherwise, to the OP, this is a great endeavor. I think this is superior to address shorteners, though it would be nice to use the first-bits in a url such as http://firstbits.com/1xxxxx. I could foresee using this in the future (as soon as the collision is indicated). Best of luck to you.

Maybe I need to add some explanation to the front page. I thought it was obvious that you can't just guess how much to put in. You need to put the full address in to find out what your firstbits address is. You have a guarantee that the string returned will identify your Bitcoin address.

I would not even assume 1+8 is safe, you need to check.

That works now.

firstbits.com/1kk5k (http://firstbits.com/1kk5k)

Great work. A+

Suggestion is to pay to register a name with an address that shows up on your site.

I 'own' "187g". when someone asks for my address to pay, I would say "Bob's lemonade stand at '187g' ", and it is confirmed on your site with the full address: 187G5EpRm7rYs6M7X5QDEZpqvw5iVQvXtF and "Bob's Lemonade Stand".

"1mtbk" would show up as "Meze Grill", etc

I think you are misunderstanding the use of the site.

Firstly, only addresses that have been used in a transaction in the blockchain will appear on the site.  If you haven't used an address before, it will not show up if you put the full address in the text box, and there will be no relevant firstbits to use.

Secondly, if the 1+4 doesn't match your particular address, then that means that someone else's address that also has the same firstbits (starts with 1b2oh) had a transaction in the blockchain before yours.

If you want to see the minimum required firstbits for your address, enter the full address in the box, and it will tell you.  It is not necessarily unique - it just means that your address was the first address to use that particular preceding combination of characters (case insensitive) in the block chain.

One of my bitcoin addresses, 18TKNbSLTrd3a2W8mtoH5uNzFhWRWNcuHU, was the first address to use 18tkn in the blockchain.  So now and forever, 18tkn will identify my address.  If another address comes along that starts with 18tkn, then their firstbits will have to be one character longer in length in order to identify their own address (18tknx, for example).

Hopefully that clears things up for you?

Also, www.firstbits.com/18tkn already works.  ;)

EDIT:  I see that others have responded, but I'll leave this more detailed response in case you need it.

I think you do need explanation. But the URL will help a lot. I expect people will add their first/shortest URL to their signatures, etc, so subsequent first time users won't likely hit the site 'raw'. Then you can mention "Test your address here for the shortest unambiguous or earliest minimum." (that wording needs work, but one sentence should do it).

As TTBit mentions, I think someone could claim an address with a short message "Netrin lives here" and you can easily and anonymously verify ownership upon receipt of a precise payment from that same address within 24 hours.

That is a good idea. Do you think it is important to verify that someone actually owns the address to tag it? I see confusion being the worst 'attack' from buying someone's spot and putting something weird.

Anyone who wants to build stuff like this is more than welcome and I'll help make sure you get the algorithm exactly the same.

Some ideas:

Take a long list of addresses, return the firstbits in order of length or alphabetic or whatever.

Make a firefox or chrome extension that watches what you type and 'auto completes' a firstbits to a full address. You will need to type a terminal character for this to work. Ex: type "1hu56." and 1hu56Skwi99qmgnwRrQdd4TnMmwz8 shows up for you.

Web wallet like instawallet with built in firstbits conversion.

It can be hard for people to get a payment to come from a particular address if they have a wallet with lots of addresses in it. And people will usually want a particular address to be labeled.

Haha, could do this. Take a large fee and return it to the address in question. If you want to mislabel an address it'll cost you 8BTC. That's obviously not optimal, I'm joking.

I was perhaps quick to jump on this comment. Yes, I misunderstood the 'first in chain' rather than 'first to register' or 'minimal unambiguous'. But the thrust of my comment was against the disregard for unavoidable dangers to naive users.

The minimal precedence is not immediately obvious and should be explained. I meant no attack on the site, only the previous comment, blaming the user's ignorance.


Yes, I grok it now. The 'ah ha' moment came to me when someone mentioned firstBit=1 as the Genesis block. I first thought, 'oh how quaint', then realized it was a first-in-minimal-out queue. I expect explaining that in ten words or less might take as much effort as coding it. :)

Don't allow to search for "Meze Grill", just the firstbits. I would think the owner of '1mtb' (who is not Meze Grill) might register "Meze Grill", but as long as the owner is aware, or registers a new address, he's fine.

I like the idea of paying 1 btc to register the name, firstbits sends back 0.90 btc to the address in question. firstbits gets the 0.10 fee.

Yeah, I was thinking payment would be enough, but sure if someone payed 1.0 bitcoins and you returned 0.9 (and kept 0.1), then you and the real owner would get 'paid' for the DoS-type attack. But it's certainly less administration/interface just to confirm upon receipt from the address in question.

I think it is a flaw in the bitcoin client that we can not easily (1) extract keys from our wallets and/or (2) send from specific addresses. It's supposed to be an 'anonymous' currency but all these simultaneous splitting/merging transactions blows any cover or even just managing 'accounts'. I have a dozen wallets for these types of manipulation... but I digress.

I would vote for it. No one stops me from using the vanity patch for creating an address that starts like Wikileaks' one, then registering it at firstbits as "Wikileaks donations address".

Besides this, I don't know much about namecoins but registering an address to a name may fit namecoin's purpose quite nicely. I understand namecoin is no more than a set of "A --> B" relationships.

It's not really a flaw, it's just something that hasn't been written yet, but will.

I think namecoin is no good because whoever gets there first is the 'legit' naming. This is okay for web pages because you get a name first and then publish to it. But it's not good for marking firstbits because you usually already have one that's known and you have to beat everyone else to tagging it.

I'd vote for wild wild west. Bounce 1 btc off of firstbits.com, and you can name it whatever you want. Go for max growth and see what users demand.

really cool idea.  I am assuming firstbits returns the earliest known address if there are several others that match the search. this way u avoid collisions with new addresses as they are added to the chain.


actually now that i think about it, what happens with addresses not in the block chain? for example, if a businesses had to generate a new address for every transaction and used your service.  unless you are saving every search address, its possible u would return the same firstbit address for different bitcoin addresses.

Yes, it returns the address that appears earliest in the blockchain if multiple addresses match the query.

The address must have been used in the blockchain in order to appear.  You cannot use firstbits for a brand new address.

Doesn't work well for creating address on the fly. This is a good way to remember a static payment address when there.

I am curious as to what people think about services like this... does this take away or add to Bitcoin mass adoption?

This essentially "de-anonymizes" the highly obfuscated nature of Bitcoins' native addresses which, like most aspects of Bitcoins, is a virtue and a vice.

Says the man with a bitcoin address in his sig...

Just sayin.  :)

Since it is completely optional I don't see how it could take anything away from adoption. It is a tool people can use if it makes Bitcoin easier or better for them. And it isn't more information than a full address anyway. Reusing a firstbits is the same as reusing a full address. Publishing a firstbits is the same as publishing a full address.

It does nothing to de-anonymize, but perhaps de-mystify, which can only be good for mass bitcoin adoption. As FreeMoney points out FirstBits.com is completely voluntary and takes absolutely no different action whether you participate or not. It's results present facts. The 'first bits' just are. The fact that you have a height in meters and or feet makes no additional assertion upon your identity because there is nothing connecting the scalar to the identity. Just as '1' uniquely identifies an address in the genesis block against all other transaction before it (in this case none). Whether FirstBits.com existed or not does not change this fact that no other address has this property.

;D
That's what I get for playing devil's advocate... rightly put in my place!

Firstbits.com is giving away some money. http://forum.bitcoin.org/index.php?topic=24514.0

I would like to see the 'first bit' concept accepted as a standard. Blockexplorer should use it as well as the clients. Since the clients have a copy of the entire block chain (at least now and for the foresable future) the 'first bit' standard could be universal. And any clients which do not have the entire block chain will rely on a trusted server which does.

A "first bits" unambiguously refers to an address which unambiguously refers to a private key which unambiguously refers to a slice of the transaction history and ownership of bitcoin value.

I think it would be a great addition to blockexplorer or similar and I really want a web wallet with integration, but firstbits does have the disadvantage of no checksum, one typo and your money is gone. So I think it needs something else before it's fit for the main client.

I agree.


I disagree. The 34-some string requires a checksum because it is so darn long. A 1+4 or 5 character (of size 34 domain) does not need a checksum (like a phone number). I expect we'll have a MIME type so that firstbits.com/1xxxx resolves a very well defined string (perhaps a meta tag). I've seen discussion of a bitcoin:123456789012345678901234567890+payment format. But the key advantage of firstbits is not verbosity, but brevity.

As for UX, if the user comes in through a URL, I see no reason to present much more than the fully resolved address. But if the user uses the form/input, then more likely than not, he's playing with his own address. I'd highly recommend you explain what the user is seeing. It has not tiny-url-ed the address (as many like me initially assumed). Even now that I know how it works, I'm still manually typing in 1+8 characters and cutting one then another until I find the minimum. Its a trivial, but strange, procedure (partly because the client doesn't yet let me 'copy-paste' from the transaction history).

I would expect the interface to dynamically inform me of the number of collisions (always showing me the 'firstbit') as I type, cuz I'm probably typing with the full string at my side, otherwise, I would have used a link.

netrin - input the FULL bitcoin address that you wish to shorten, and it will automatically find the shortest firstbits that can be associated with that address.

Example:  http://firstbits.com/18TKNbSLTrd3a2W8mtoH5uNzFhWRWNcuHU

EDIT:  The cutoff is at 24 chars.  Anything longer than 24 chars, and it knows that it is not a firstbits address, but a full bitcoin address, so it converts the input to the shortest possible firstbits address.  Anything shorter than 24 chars, and it knows that it is a firstbits address, and will look for the associated full bitcoin address.

Hey, this is an awesome concept. I applaud you guys for coming up with it.

Removing the cases is a good thing because it would be hard for people to have to deal with upper and lower cases. There might be one gotcha though. Do you handle 2 addresses with the same characters but different cases properly. I know this is a rare edge case, but make sure you handle it. For example, 1abcdefghijklmnopqrstuvwxyz and 1abcdefghijklmnopqrstuvwXYZ should not both match to the same firstbits 1abcd. The first one in the block chain should match to 1abcd and then second one should match to 1abcde. Just a thought.

They won't match, don't worry.  Whichever comes first will be the only one to match.  All comparisons/queries are made without regard to case.

A phone number doesn't need a checksum because the worst case scenario is "Uh, who?".

I'm not going to add a checksum, I'm just aware of the risk and don't know if it would be appropriate to add to the 'official' client, but hey if it gets popular and everyone wants it maybe they'll do it.

You aren't getting it and that means I need to rethink the page wording. Enter a firstbits address and you get the one and only Bitcoin address that is the earliest to start with that string. Enter a Bitcoin address and you get the string that differentiates it from all earlier addresses in the chain - it's firstbits address.

You do not need to try over and over like you describe.

Showing the number of matches would be a lot of work for no benefit and possible confusion. All addresses start with "1" but only one has the firstbits "1" - the generate address in the genesis block. The number of collisions is not relevant.

Cool.

I was going to say - what this really needs is a Firefox Search plugin that makes it so the web site doesn't need to be there, or get hammered, it just goes to the block chain.

But then I remembered my "Add To Search Bar" add-on and tried that. Sure enough one -right-click and FirstBits is now a search entry on the Firefox Search Bar. I can drop an address in there and it does the magic.

Though a real plugin would bypass the web site, saving server  load. And it could add a context menu to do the lookup too.

BTW I think an extra character is a good idea for "future proofing". Maybe the web page should show it as a second alternative, as in "safer version". In my case it's just as easy to recall,

18M5c or 18M5cm (eighteen M5 centimeter)

Maybe a "verbalizer" string would be cool. How to remember it.

If you find the first partial version of an unused address and add two more correct characters would you be reasonably safe to use that for a new address? It seems to me quite safe. Not sure of the probability though.

Seems pretty safe unless you were the target of an attack. The chance of a problem has to do not just with the number of extra chars, but the length and time and rate at which new addresses are entering the chain.

 

Yes, I see. If someone ran an address gen they could claim an address before you used yours. Probably a bad idea then. Just would be useful to shorten a fresh address. So it's only maybe safe if you don't use it publicly. You keep it in your head as a ready to use address but never publish it.

But another thing, does the lookup in "block explorer" search in oldest first order or most recent first order. Because if the latter it seems someone could gen a new address that matches your address prefix and use it to get it in the chain. If it searches and finds the match more recent it would find that one as the single match. But you thought of that I'm sure...

It starts with the earliest so a new address that matches does not change any previous address' firstbits.

How does this work exactly? Your search bar now knows to convert an address to it's firstbits? Or it assumes the firstbits.com/ and takes you to the page?

I guess this "Add To Search Bar" plugin takes the actual url of the form action and adds that as an url in the search bar. It doesn't show me the url though - it's embedded in the search bar.

Here's the home page for the add-on
https://firefox.maltekraus.de/extensions/add-to-search-bar

I just see a form field and right click on it to turn it into a search bar item.

Ah, the page makes it clear. That is pretty cool.

pretty cool:

http://img194.imageshack.us/img194/1421/31491808.jpg

One reason why it's good to have a favicon :)

I like it.

In opera you can just make a new search with the url http://www.firstbits.com/?a=%s and whatever keyword you want. So for example typing "b 1kk5k" would take you to http://www.firstbits.com/?a=1kk5k.

And a bash function for the geeks out there:

Oh! Some brat already took 1Linux. Grrr.

Firstbits seems to be down for maintenance right now. No problem with that, but /api/?a=foo still works ;). /api/foo and /foo don't.

Hmmmm still down

Verification is getting close to complete.  We may be able to bring the site back online tonight (PST timezone).

Good news

yup yup

Site is finally back up!  Sorry for the delay.

Two addresses of mine, which have already 7 confirmations, still don't appear in the chain according to firstbits. Maybe the bitcoin instance running there was offline during the downtime period and isn't up to date?

Edit: It's working. Seems I needed to post something here :).

It might take 6 confirms plus a few minutes. Let me know if it takes longer.

If the check-sum ever happens I just want to give idea out. It could be the first character in firstbit address. So it can't mess up the later addresses. Not sure how it should be calculated, but it is logical solution if checksum is needed.

Shortening a hash, especially a Bitcoin address is just asking for trouble.

I think the convenience of being able to remember and say enough info to rebuild an address is too much to just pass up.

I know there are risks. Can you help clarify them?

I'd be willing to bet that he's incorrectly expecting there to be collisions.

I'd be willing to bet that you're right.

Though in theory, the system is sound. In practice, things can happen. As we saw when they were using bad blocks data, the firstbits address given out may be wrong. You can never be sure that this won't happen again, right?

an address created a couple days ago, and used for the first time an hr ago is not showing up, it has 6 confirms on the transaction.

edit after 12 confirms it works now.  (i didn't check in the middle of 6 and 12)

Has anybody asked what happens if at some point you give out your 4-bit address to receive some BTC from a new friend and they give the BTC's to a complete stranger? It just doesn't sit well...  :-\

Can you think of ways to improve? It's not a complicated thing, maybe something open source could be written that would use your own copy of the chain?

If it ends up that you need to trust a party for look ups it is still better than other shorteners because anyone who can follow the simple rule can join and add redundancy. Obviously you can't just go trusting any one though. Hopefully some people with related business who already have trust will make conversions.

You mean if there is a mistake? The coins would be gone.

Sorry, we need to clarify the 6 confirmations thing.  It does require MORE than 6 confirmations, so seven would be the minimum before you see it show up in a search.  This ensures the system has sufficient time to verify that all addresses have been gathered and added to the database.

I'm assuming Bitman misgrokked the concept, as I and many others did before the moment of ah ha zen.

If the following were the ENTIRE block chain history, then the underlined prefix will have been and always will be their first bits:

1h8sjkl123456789 January
1h8sxx123456789 February
1h8abc123456789 March
1h7123123456789 April
1h8sww123456789 May
1z987asdf9isfhakls June

Well, let's post something here, so that it works :).

I have a transfer with 22 confirmations, involving an address that is still unknown to firstbits.com. It appears in the block explorer. What do I do?

I agree that something doesn't seem to be working anymore. My address first in block 136059 isn't in firstbits.com's database, and it's now block 136071. I'm guessing that a bitcoin client crashed or something.

Looks like a small change I made to the code caused it to get stuck in a loop, never moving beyond block 135948.  I'll fix it and let you know when the blocks have been filled between 135948 and whatever block we're currently at.

Fixed and blocks are updated through 136101, so addresses up through 136094 should be retrievable now.

Working now. Thanks!

First up, thanks to FreeMoney and SgtSpike.This is awesome.

Then I would like to make two suggestions. The first relates to the checksum discussion. It is important to note that simply extending the firstbits name beyond the minimum required characters is NOT the same as a traditional checksum. Where a standard 1 character checksum is sufficient to detect any single character typo, this does not hold for extended firstbits adressess. The 1 character extended 1kk5k address is 1kk5kf. If this is mistyped as 1kk5kg it may well point to another valid address. It doesn't today, but it could. In this case the typo was actually in the "checksum" meaning that you end up worse off than you would have been had you just quoted 1kk5k as your address.

A simple way to add a (still optional) checksum would be to use a separator followed by a traditional checksum i.e. 1kk5k-A or something similar. One simple implementation would be to ensure that the sum of the characters (when interpreted as digits in a base 36 system) adds to 0 modulo 36, But you could also have multi-character checksums that can detect more elaborate typos.

Once something like this is in place, I see no reason why this shouldn't be in the mainline client. It may initially refuse to accept firstbits adresses without checksums and later allow one to bypass this rule if you click through enough "are you SURE SURE SURE" dialogs.


I can hardly believe that this hasn't been discussed more. If the discussion is elsewhere please point me to it.

Vanity addresses and the firstbits algorithm make for a potent combination. If you think 1kk5k was easy to remember, try 1spike (or even 1spike-AX since you don't really have to "remember" spike the "additional" load of remembering the checksum suddenly seems even more trivial).

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 ;D. 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 am pretty sure that this can be added to the existing algorithm without any breaking changes (i.e. if 1linux or 1kk5k or whatever belonged to you before it is guaranteed to still belong to you unless you choose to dispose of it). One way of doing this would be to do the lookup as before, but once the address is found to check all subsequent transactions from that address for one that matches a to be determined arbitrary pattern. If such a match is found then the destination of that address becomes the new owner of the firstbits address in question. Rinse and repeat. This is slightly more computationally expensive than the existing algo, but no one is doing millons of firstbits lookups per second are they?

One example of a pattern that may signify a transfer of ownership is a payment from 1linuxdhfgf... to 1linuxtrsyudas.. of EXACTLY 123 satoshis. The amount should be very small and chosen in such a way that no such payments allready exists in the blockchain (so no-one has accidentally transferred ownership of their firstbits alias while trying to buy coffee  ;)).

This is just an example to clarify the concept and not suitable for actual use because it leaves open the possibility that someone may in future transfer a firstbits alias without intending to, either due to an incredible coincidence or because they were actively tricked. A better solution would be to use the pubsig script as an indicator. An otherwise nonsensical script can be used as an indicator that 1stbits ownership is being transferred. It has the downside that some BTC is being burnt (since it would be impossible to claim that output of the tx) but I don't think anyone is going to miss a few satoshis  ;). On the upside, one would need a special client to transfer alias ownership so no aliases would be transferred by accident.

If this was implemented we would suddenly have a market for firstbits aliases and hopefully I can sell 1Hannes to one of the many billionares out there with Hannes as a first name  ;). The only downsides that I can see is the slight increase in computational complexity of a lookup (as mentioned before) and the fact that if one does a firstbits lookup under the new standard one really needs to be online and up to date with the blockchain (allthough you would be able to get away with an offline lookup 99.9999% of the time).

In my original example I showed transfer of ownership of the 1linux alias from 1linuxdhfgf... to 1linuxtrsyudas.. but one could debate whether the second address needs to start with 1linux at all. If it didn't then we would have a marketplace even for firstbits aliases that have not yet been claimed. I would like 1HannesNaude but don't have access to the ridiculous amounts of hashpower I would need to generate it myself. But for anyone that is already running vanitygen the cost of adding it to their patterns list is close to zero. If it was in everyone's pattern lists because everyone knew that I would pay a million BTC for it ;), it would almost certainly be generated within a day.

Obviously anyone can introduce either of these suggestions, but I really believe it would be best if the firstbits originators did it. Then there would be no confusion or competing standards. Also this is much easier to do now while there is really only a single implementation to adapt than later when many clients and e-wallets have implemented firstbits and lots of code needs to be updated.

I had thought about this, but didn't want to post twice in a row :).

What I had in mind was that if I own 1linux123 and other person were more interested in "1linux", he/she could generate an address such as 1linux456 and pay me some money, 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. The blockchain is the database and it is by definition impossible to delete something that has been confirmed by enough blocks from the blockchain. So to transfer ownership one has to enter a "redirect" tx into the blockchain.

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

What do you mean 'extended firstbits addressess'?


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.

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.


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

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.

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.


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.


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


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.

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.

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

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.

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?

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.

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.  ;D

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/

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

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.

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.

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.

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.

Bug is fixed, thanks for reporting!

Glad to make this a better world :P.

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.

Right now I'm drunk as hell.  FirstBits helped me transfer 10 BTC  between my computers.  An admirable service, in my opinion.

First bits really ought to be the standard in the clients. It *might* even compress the local blockchain. The address is only a hash of the key. We don't really need the 32-char address except as.. well.. an address.



You have to be always drunk. That's all there is to it—it's the only way. So as not to feel the horrible burden of time that breaks your back and bends you to the earth, you have to be continually drunk.

But on what? Wine, poetry or virtue, as you wish. But be drunk.

And if sometimes, on the steps of a palace or the green grass of a ditch, in the mournful solitude of your room, you wake again, drunkenness already diminishing or gone, ask the wind, the wave, the star, the bird, the clock, everything that is flying, everything that is groaning, everything that is rolling, everything that is singing, everything that is speaking. . .ask what time it is and wind, wave, star, bird, clock will answer you: "It is time to be drunk! So as not to be the martyred slaves of time, be drunk, be continually drunk! On wine, on poetry or on virtue as you wish."

Wonderful. Very glad it's helpful and easy enough for a drunk to use. :-)

Well why use a website. Wouldnt it be best to code this into the client?

Do I hear a bounty? Seriously! Has this been proposed to the dev team? are they open to the idea?

(I might make a stab at the node.js project, but I can't make heads or tails of Satoshi's code).

It took a few tries >_>

(3 seconds later) OH GOD WHY AM I MISSING 10 BTC?!?!  hehe

I've added support for first bits at http://pi.uk.com/bitcoin (http://pi.uk.com/bitcoin) with some usage caveats (see https://bitcointalk.org/index.php?topic=40264.msg545396#msg545396 (https://bitcointalk.org/index.php?topic=40264.msg545396#msg545396))

Very cool!

I assume you are calculating them independently?

yes, they should be fully compatible with firstbits.com though.

Very cool, glad to have a separate implementation.

One little possible wrinkle though. We have been ordering two transactions that would otherwise have the same firstbits if they were not in the same block according to their appearance in the block data (first to appear being first). We are investigating switching to giving them both the longer firstbits. An example:

Block 1:
1asd1234567...

Block 2:
1asd2fkkkgrt...
1asd2sqp434...

Currently 1asd2fkkkgrt... would have FB of 1asd2 and 1asd2sqp434... would have FB of 1asd2s.

It seems like it might be better to not need the extra rule of tiebreaking with order of appearance and instead to give each the FB as if the similar address came before. In this case giving 1asd2fkkkgrt...  a FB of 1asd2f. It seems more elegant to use a rule of "String required to differentiate an address from all addresses in the SAME and previous blocks" and have nothing about order in the block.

Very sorry for not addressing this before or publishing our exact code. Would like your input on this issue.

+1 from the peanut gallery. I had been searching for exactly such a case (I have seen some strange vanity addresses in the same block which might qualify). Are you aware of any real world cases on this ambiguity?

Writing something that will find any/all.

I definitely prefer the same or previous rule, but is it worth changing if it changes many FB?

My totally non-repeatable grep|sed|uniq -c script couldn't find conflicts even with these four char vanity prefixes. The fact that all of these four char vanities all begin with capitals makes me suspect their creators had no firstbit aspirations. I would think it's early enough in the game that there's no pr... famous last words. I'm curious what you come up with.

I like this neat idea. Is there a chance that somebody write patch for official client?

+1 .. I think it's inevitable: multiple implementations, expanding user base, simple proven algorithm, it'll happen. I expect firstbits could help condense the local block chain. There need only be one instance of each (firstbits key, address) tuple and all other instances of the address can be reduced about 80%.

Hey FreeMoney and SgtSpike, have you chatted with Genjix about implementing firstbits in libbitcoin (https://bitcointalk.org/index.php?topic=30646)?

https://gitorious.org/libbitcoin/libbitcoin

http://firstbits.com/api/?a=19keo3

NO_MATCH

however looking it up on the front page returns an address.

why the difference?

I think the API is not showing recent (not sure how far back) addresses. Investigating.

Should be working now - thanks for the report!

Hi, I recently implemented firstbits for Abe.

What do you propose to do if/when a previously unseen address appears in a multisig (https://en.bitcoin.it/wiki/BIP_0011) output or (horrors) a script-hash (https://en.bitcoin.it/wiki/BIP_0016) input?

Neither Abe nor BlockExplorer recognizes multisig scripts, but bitcointools decodes them into addresses, which blockchain.info displays: example (https://blockchain.info/tx-index/2507817/60a20bd93aa49ab4b28d514ec10b06e1829ce6818ec06cd3aabd013ebcdc4bb1).  That site also displays firstbits of script-hash addresses: example (http://blockchain.info/fb/34).

The addresses I've looked at all appeared earlier in the chain in "normal" pubkey or single-address outputs, but nothing's to prevent someone from sending to a multiple-signature destination that includes a new address.  Would that allocate a new firstbits?

I'm tempted to say "no" out of laziness and because Firstbits are for published addresses, whereas multiple-signature transactions are more for self-transfers.

The "escrow" address (as labeled by blockchain.info) is not added as a firstbits address at this point in time.  All other addresses involved in a multisig transaction would be added as firstbits addresses.

Would you consider defining "appears" on http://firstbits.com/about.php to exclude appearances in OP_CHECKMULTISIG outputs?

I can't tell what is best, but we should all do it the same and be clear.

Want to see what Piuk thinks and then lock it in 'officially'?

Request sent. (https://bitcointalk.org/index.php?topic=40264.msg958945#msg958945)

I have excluded M-Of-N (Escrow) transactions from firstbits calculations.

P2SH addresses (http://blockchain.info/address/3N6RjoL4Z93c2VFpqpwJNCUsy5MFikzBWr) get a firstbits with the prefix 3 so as not to collide with old style addresses.

Anything you would like me to change?

I am happy with these rules.  I suggest something like the following to define "appearance" in the chain:

A couple of bug reports for firstbits.com:

1.

The email address listed on the site doesn't work:


2. (What I tried to email to you.)

When I enter the address from the genesis block (1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa), firstbits.com prints:

I would be happy to try your patch for Abe. Is it online?
Are you able to show something like http://blockchain.info/fb/3g2 already? (it has a 2of3 signature).
It doesn't work on firstbits as well as on "vanilla" Abe.

Sorry, I have not implemented this address type for Abe.  Everything I've done is checked in. :)  The rules I proposed above got no reply, and I lost interest.  Abe does not follow them exactly; for example, it ignores trailing OP_NOP when processing an output script.  I have not taken the time to find test cases to determine how firstbits.com and blockchain.info handle nonstandard and newer script types.  Here is the latest on Abe's implementation: https://bitcointalk.org/index.php?topic=22785.msg965329#msg965329

Just wanted to report that when I visit FirstBits.com now it gets stuck on the sealswithclubs.org advert and FF keeps trying to contact that web site. Even after 20 seconds or so I never get the entry address field.

Seems to hang the page indefinitely. Tried over and over, same result.

Whoa, sorry. Let me look into this.

Anyone else getting that?

It paused for about one second or less for me before displaying the blank which it has never done before.

And in the meantime if you don't know you can use blockchain.info to look up firstbits. Just put the address or firstbits in the search field there.

I think I fixed it, it seems to load instantly for me now.

It's odd because I hadn't changed a thing in months.

Please tell me if it works for you now Bkk.

Yup. Seems to be ok now. I'm deep in the rice fields of SE Asia so whatever caused it to be slow was exacerbated ten fold here.

Cool. Thanks a bunch for letting me know and following up.

Free, is firstbits.com discontinued or just temporarily down? Thanks.

It's discontinued by him, but I plan to continue it at firstbits.net (and .com if I can get a hold of the domain).  In the meantime, there's this website: http://bitcoinfirstbits.com/.  I forgot who runs it.  Lookups can also be done at blockchain.info.

That's right. I'm going to give the domain to Spike if I'm able.

Alright, I quickly put firstbits.net up, but right now it just reads from blockchain.info's API.  I need to rewrite the engine for calculating them, because the original one was simply too slow.

I may be interested in adding firstbits functionality to the Mycelium backend system. To do this I need to know exactly what the rules for name resolution are. It seems that blockchain.info does not do it the same way that Abe does. Without a firm rule-set the purpose of firstbits is defeated.

SgtSpike, can you share the precise definition of a firstbits address?

I wasn't even aware that Abe even performed firstbits resolution.  Is there a running example you can point me to?

The definition is mostly displayed in layman's terms here: http://firstbits.net/about.php
Also there's the basic SQL statement used here:  http://firstbits.net/logic.html

Whatever address appears first in the blockchain claims the Firstbits for every previously unused combination up to the full address.  For example, 1SgTspiKe5HHkjdSeD72q9WsiJhRiaxf9 doesn't have the firstbits 1s, 1sg, 1sgt, or 1sgts because other addresses used prior to this one already started with those combinations, but it DOES have the firstbits 1sgtsp, 1sgtspi, 1sgtspik, 1sgtspike, 1sgtspike5, etc, all the way up to 1SgTspiKe5HHkjdSeD72q9WsiJhRiaxf.

If two addresses with the same firstbits appear in the same block, then the addresses are given firstbits in the order they are seen in the raw block data (i.e., the first one would be given 1sgtspike, and the second would be given 1sgtspikeX, where X is the next character in the address).  Blockexplorer.com shows the raw block data, and lists the transactions in the same order as they are seen in the raw block data, so it is a reliable source for determining which address should come first in the event that the same new firstbits combination is shared by two addresses in the same block.

This is always how firstbits have been resolved.  If Abe resolves firstbits in a different manner than the above, then it should not be calling them firstbits.

Thanks.

Regarding Abe read here: https://bitcointalk.org/index.php?topic=16217.msg960077#msg960077
and here: https://bitcointalk.org/index.php?topic=16217.msg1044812#msg1044812
Just a few posts upstream :-)

Let me refresh your memory. :)  https://bitcointalk.org/index.php?topic=16217.msg957933#msg957933


Thank you, but this is not a precise specification.


IIRC, this contradicts information given earlier, that neither address would get 1sgtspike: both new firstbits would contain enough characters to distinguish them from each other, regardless of their ordering within the block.


True, but if so, it is not for lack of trying.  Rather than rename the function in Abe, why don't we finish the standard and bring ourselves into agreement.  Here is where we left off: https://bitcointalk.org/index.php?topic=16217.msg960077#msg960077

Hello again John!

Firstbits.com had always differentiated by order of appearance in the raw block data, and given the first appearance the shorter firstbits.  I'm not sure who stated otherwise, but for firstbits.com, that's always been the case.  I am not sure what standard blockchain.info follows on that front, but I assumed it followed the same.  We should find out.  Regardless, giving enough firstbits to distinguish both addresses in the same block is certainly cleaner.  I didn't want to change it for fear it could screw up someone relying on the original implementation.  The likelihood of someone using one of those addresses is slim, but the possibility still exists.  Now would be a good time to change it, if we are also nailing down other portions of the specification.

Yes, let's indeed finish the standard.  I suppose I dropped out of that original discussion because I am not familiar enough with the different OP functions of Bitcoin and what they mean/do.  Is there some reading I can do somewhere that explains more about these?

I suppose I would say that as long as a transaction is valid and included in the blockchain, there is no reason it shouldn't also be included in firstbits.  Will the average person know what a transaction with OP_NOP means, or how to know if a transaction has it or not?

For example, transaction 5492a05f1edfbd29c525a3dbf45f654d0fc45a805ccd620d0a4dff47de63f90b has an OP_NOP appended to one of the addresses.  Blockexplorer decodes the address correctly, but blockchain.info doesn't seem to have a handle on it:
http://blockexplorer.com/tx/5492a05f1edfbd29c525a3dbf45f654d0fc45a805ccd620d0a4dff47de63f90b
https://blockchain.info/tx/5492a05f1edfbd29c525a3dbf45f654d0fc45a805ccd620d0a4dff47de63f90b

So you are arguing that these OP_NOP transactions should be discluded, despite the fact that they are included in the blockchain?

I am not disagreeing with you, I just want to understand more about what the disclusions are and how easy it will be for the average person to understand why a particular address doesn't have firstbits.

Perhaps I read it here:



Cleaner, I suppose, although I, too, originally based it on order within the block.  If it is possible (is it?) for an earlier tx to spend the output of a later tx in the same block, we would have to be careful about whether the earlier one's input script triggers "appearance" of the address in case a competing address appears in a third transaction between those two.  The rule about "all addresses appearing in the same block" avoids that issue, while unfortunately making some address prefixes ineligible ever to become firstbits.


Thanks for the willingness to clean up.  I think in this case, the change would never result in a firstbits becoming the firstbits of another address.  Rather, some (rare) firstbits would become non-firstbits, ineligible due to appearing first in two or more addresses within a block.


The wiki describes the original two standard transactions: https://en.bitcoin.it/wiki/Script#Scripts.  P2SH is in BIP 16: https://en.bitcoin.it/wiki/BIP_0016.  The authoritative reference is the IsStandard (https://github.com/bitcoin/bitcoin/blob/acc775c5547a94fa5ad12ecb0bdaeefdc285d853/src/script.cpp#LC1332) and Solver (https://github.com/bitcoin/bitcoin/blob/acc775c5547a94fa5ad12ecb0bdaeefdc285d853/src/script.cpp#LC1124) functions in src/script.cpp.


Yes.  In fact, here is a case where Abe does the other thing, and the standard that I propose will require a change.

I assume that the reference client does not generate these OP_NOP transactions, nor does any client designed with interoperability in mind.  The last time I checked, there were only a handful of them.  I can only speculate why someone went to the trouble of making them.  I remember first seeing them in Abe, checking BlockExplorer, and adding a tiny change to make Abe handle them compatibly.  The problem is, if we allow OP_NOP at the end, where do we draw the line?  Do we allow multiple OP_NOPs or other operations?  I guess we could just as easily define the script types by how scripts start, and if firstbits.com has always done this, that might convince me.  I consider a full, exact match cleaner.  In practice, I think anything after the standard portion gets ignored, unless it would make the script or block too big.  I haven't checked whether IsStandard allows trailing junk, but I have the impression that developers mostly frown on it.

Thanks for your comments.

Touche on the about page.  :D  I know we specifically didn't mention it there because we didn't want to go into too much detail, but it sounds like we should have anyway.

Yes, you are correct about making that change for addresses in the same block - the distinction would only invalidate some firstbits, it wouldn't actually change any of them from pointing at one address to pointing at another.  I wouldn't have a problem with making this change then.

Regarding the OP_NOP transactions, I read that some people used them to donate transaction fees to a certain pool.  It's a bit beyond my level of comprehension as to how exactly that works, but essentially, only Eligus could take the fee for these transaction:  https://bitcointalk.org/index.php?topic=11481.0

I suppose I would still lean towards what the Bitcoin protocol accepts, not what various clients do and do not accept and can and cannot generate.  If the protocol allows it to be placed in the blockchain, then it should be given a firstbits.  OP_NOP transactions are not normal, and cannot be generated with the default client, but they are still valid Bitcoin transactions.  I don't see any reason to disclude any valid scripts that anyone wants to run from being included in firstbits calculations.

You certainly know a great deal more about the inner workings of Bitcoin than I do.  I'd just like to see why you don't want these non-normal transactions to be included.  You mentioned having to modify your code slightly to be able to handle these special transactions - are you concerned about having to continue to modify your code in order to deal with new combinations of operations?

That's okay, perhaps we'll get it done here now... :)


Thanks for digging that up.  It looks as if the transactions are indeed generated by end users (of a modified client) who do see the affected addresses.  I don't have a full database handy, but I am curious how many OP_NOPs are in the chain and whether they still occur.  If it's a tiny percentage and none recently, I'm less concerned.  But here, a firstbits assigned in an OP_NOP output would indeed be reassigned to another address, so I suggest we consider it carefully.


Yes, and I fear that "what the protocol accepts" and what future users will consider an "appearance of an address" may be computationally infeasible for an unvarying standard such as firstbits should be.  For example, each normal address (starting with 1) has a unique corresponding, standard 1-of-1 P2SH output script and address starting with 3.  If you know the 1-address, you can find the 3-address, but not vice versa, at least until the output is spent.  Does the spending of such an output constitute appearance of the 1-address?  Some might say yes, others no.  The firstbits standard must give an answer for every possible case like that that may appear in the future.

Firstbits must be derived only from the blockchain, obviously.  "Bitcoin addresses" never occur directly in the blockchain; rather, they are extracted by matching scripts against templates and associating script types with well-known "version bytes".  If your address were spelled out in the block whenever it sent or received coins, we could trivially define first appearance.  Since that is not the case, it is up to us to cope with the complexity.

It is still an open question to me, whether to ignore non-functional trailing script fragments such as Eligius's OP_NOP.  The whole class of them would have to be easily identified, or if a special case for the single OP_NOP would yield better backward compatibility, I would consider just that.  I do not have time right now to find out the answers, but if someone more interested than I comes up with the data, I will comment on it.  :)

Essentially what you are saying is, there are a potentially infinite number of ways that operations can be arranged and used, and each one could require special handling to resolve firstbits.  In order to eliminate inconsistencies between different firstbits implementations, we need to stick to commonly-used scripts and operation combinations, as one would find in widely-distributed Bitcoin clients.  Otherwise, all firstbits implementations must continually update to account for odd transactions, or risk providing different firstbits information than other implementations.  Implementations in this case would also have to agree to some set of handling rules for new odd transactions that appear, in cases where there might be ambiguity (such as the P2SH case you presented above).

This makes sense, and I now agree that we should stick to providing firstbits only for those transactions deemed "regular".  Said transaction types should be well-defined and listed, so that all implementations can easily follow the same rule set.

Jan, given SgtSpike's and my openness to change, would you care to work on a precise definition?

Yep, working on a first draft. A significant part was already done by you  ;)



Regarding this:

I am pretty sure that an earlier tx cannot spend outputs from a later output in the same block (the other way around happens all the time). I had the same worry when I did my block chain loader back in october last year and included some hefty logging in case it appeared. It never did. The specification and implementation will be cleaner without this corner case.

I'll have something for you to review later today

Firstbits Definition (Draft)

Firstbits Base Representation
All Bitcoin addresses that appear in the block chain using a well defined set of recognized transaction output formats have a unique firstbits base representation. The firstbits base representation of a bitcoin address is the shortest non-empty substring starting with the first character of the Bitcoin address and converted to lower-case, which does not collide with the firstbits base representation of another address appearing in a transaction output earlier in the block chain. Thus, a firstbits base representation is always in lower-case.

The order of appearance for addresses in transaction outputs in the same block follows the order of transaction outputs in the raw block data.

Firstbits Addresses
A Bitcoin address can several valid firstbits addresses. A firstbits address can be derived from a firstbits base representation by appending additional characters from the Bitcoin address up to and including the last character of the Bitcoin address. A firstbits address can have any combination of upper and lower case.

Example 1
Bitcoin address:               1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
Firstbits base representation: 1
Firstbits address examples:    1, 1a, 1A, 1a1z, 1A1z, 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa

Example 2
Bitcoin address:               1SgTspiKe5HHkjdSeD72q9WsiJhRiaxf9
Firstbits base representation: 1sgtsp
Firstbits address examples:    1sgtsp, 1SgTsp, 1SgTspiKe5HHkjdSeD72q9WsiJhRiaxf9

Recognized Transaction Output Formats
An address is said to appear in a block when it appears in one of the block's transactions' pubkey, pubkey hash, or script hash outputs.

Pubkey Output
A pubkey output is a transaction output with a script of the form: An address is said to appear in a pubkey output when its version byte is 0 and its key hash equals the 160-bit hash of the output script's push operand (pubKey).

Pubkey Hash Output
A pubkey hash output is a transaction output with a script of the form: An address is said to appear in a pubkey hash output when its version byte is 0 and its 160-bit key hash equals the output script's push operand (pubKeyHash).

Script Hash Output
A script hash output is a transaction output with a script of the form: An address is said to appear in a script hash output when its version byte is 5 and its 160-bit key hash equals the output script's push operand (scriptHash).

In particular, output scripts not matching the above three cases can not affect whether an address appears in a block, nor can input scripts.  For example, a script containing OP_DROP or OP_NOP can not match the cases, but the push operand in a pubkey output may have any length.

Looks pretty good Jan.  My only comment is that the line "The order of appearance..." is largely irrelevant.  We have agreed that order in a block doesn't matter - all addresses with matching firstbits in the same block will have characters added until they each have unique firstbits.

As I wrote just above:

This adds unnecessary complexity, potentially invalidates old firstbits addresses, and is incompatible with what other implementations do today.
I really think it is a bad idea.

It would be interesting to find an example of such a case to compare how it is resolved on any services that work with firstbits.  I have a feeling they are not all resolved in the same manner.  I disagree regarding complexity - I think it actually makes implementation much simpler, which is why I like the change.  Yes, it will invalidate a few specific firstbits - perhaps we should run some sort of script to find out exactly which firstbits would be invalidated.

It is actually more complex to regard all transactions in a block in a holistic way rather than just handling them one at a time.

However, here is the definition we got so far for transactions in the same block (which is actually used today):
If you make a less complex description that unambiguously describes your way of handling collisions I'll agree with you.

Thank you, and sorry for the delay!


I don't think this is true or needed.  Some addresses have no firstbits base representation, because an address differing only by case appeared earlier.


This is good but could be clearer.  How about:
(Appearance implies "in a transaction output" as specified below.)



I don't have a strong preference.  Abe does use enough characters to distinguish from addresses later in the block.  I think the code was simpler before I did this.  I don't think conceptually either way is more complex; you choose between defining "order of appearance" and "same or earlier block".  I strongly suggest finding an example and checking blockchain.info's treatment of same-block collisions, since that site obviously has a lot of work put into it and may be unwilling to change.  And let's try to include piuk.

I edited my last reply to ensure that "collision" includes collision with longer substrings.  For example, 1SgtspiQ... has a substring 1Sgtspi which collides not with 1SgTspiK's base representation, but with a firstbits address derived from it.  So the base representation of 1SgtspiQ... must include the Q.

The chance of two addresses only differing by case is something like 1 in 34^34 (or 34^27 if you're looking at the shortest possible Bitcoin address), is it not?  If so, I'd say we can safely assume no two addresses have been, or will ever have, the same address differing only by case.  Even 24^27 is such an impossibly high number as to conclude it will not happen within the life of the earth.

I agree.  Since all three of us seem to be willing to change, let's see what blockchain.info is doing and go from there.

EDIT:  As luck would have it, Firstbits doesn't appear to currently be working on blockchain.info at the moment.

Nevertheless, if I recall correctly, examples do exist, presumably where one address is not generated in the usual way (and coins sent to it are therefore dead).

Ok, that make sense.  If a person purposefully tried to copy an address, all they'd have to do is worry about the checksum matching, and that's just a matter of a script running through combinations of various capitalized/uncapitalized letters and numbers until they find a checksum that matches the checksum of the original address.  I can see how this would be possible.

Firstbits is still down on blockchain.info.  Is there a live example of ABE with firstbits lookup?

I don't know of any offhand.

This looks like it'll make it possible to actually memorize an address.  Cool! ;D

You have to be always drunk. That's all there is it's the only way. So as not to feel the horrible burden of time that breaks your back :P

It is very possible!  I have three of my addresses memorized so that I can easily send to any one of them any time.

Problem is, there's no way to look up firstbits right now, and piuk doesn't seem to care that it isn't working on blockchain.info.

Shortening a hash, especially a Bitcoin address is just asking for trouble

it's more like a 'shortcut'

just like we don't type c:\program files\bitcoin\bitcoin.exe -datadir=g:\data  every time we want to run bitcoin, we just use a shortcut that knows where to find it

dumb

Plagiarism.  Set to ignore faiza1990.

Please do tell why.

Faiza1990 is a known troll, don't feed him

I think this definitely has its uses, not dumb. It can of course cause trouble in some scenarios but I would still like to use it and have a simple address to tell someone.
But now the blockchain.info's API doesn't work and reading this thread I get is hasn't worked for a while. Is there a working firstbits lookup somewhere?

The blockchain.info one goes up and down often.  It seems there's some backend process that crashes/stops working.

And no, there are no other lookups available, so if blockchain.info's lookup isn't working, then there's no way to look up firstbits addresses.