Topic: Blockchain.info - Bitcoin Block explorer & Currency Statistics - page 158. (Read 482699 times)

deleted (I wrote some bullshit but then I realized I'm too tired. So I'll think about it and write later).

I think this problem is my fault from speaking about 'the' firstbits of an address by which I mean the shortest, but maybe we need a different word of the longer ones.

Addresses not in the chain don't have a firstbits. You can ask what it would be if it was added now, but that's dangerous to start talking about and working with because you don't know what else is in the same block for example.

Thanks to the firstbits.com algorithm, such address don't have any firstbit shortcut :-).

So what the firstbits of 1Locus7CPi1wGYAnKuXAR2dWTP2BSdqvyJ (capital C) be?

piuk, actually firstbits is only the shortest address for one bitcoin address, but all longer shortened address will work, too. As an example all of following firstbits (or call them "prefixes") will lead to the 1Locus7cPi1wGYAnKuXAR2dWTP2BSdqvyJ: 1locus7, 1locus7c, 1locuscp, ...

It's because this Bitcoin address will everytime win the lookup in the blockchain for given prefix, SORTED by blocknum where it was firstly seen, no matter what address will be announced later. I see this as an advantage, because shortest possible address isn't necessary the fancier one. As an example I want to use 1locus even when the *real* firstbits is 1locu, because "Locus" is the name of the company bounded to the donation address. In this case, freemoney's algorithm do the work just fine.

A firstbits address returns the first appearance of itself, that's it. The best reason for doing it like that is that people using more length than necessary (for safety or vanity) won't get burned.

I don't understand why both 1locu and 1locus resolve to 1LocUS4PUJeRSbR5ekySXEM4qMBT3xemp7. How can an address have multiple firstbits? why is 1Locus7cPi1wGYAnKuXAR2dWTP2BSdqvyJ not 1locus?

We do seem to be using different alogorithms, I have renamed them on blockchain.info.

Awesome work.

I run a node (169.237.101.192) that is located in California.  For some reason it shows up as being in Cairo at http://blockchain.info/connected-nodes

It might be because this same node runs a tor hidden service, but I'm not sure.

The other node I run that is also accessible via tor hidden service does not show up in the list of active nodes.  Is there an IP that I can add to addnode in my conf that will make sure I connect to blockchain.info and show up on the globe?

Unless there is a re-org a firstbits address will never change.

When you enter a firstbits address we find the earliest address that starts with it. Lower block number is earlier and inside of a block it's whichever comes first in the raw data.

When you enter a bitcoin address we look at all addresses in the chain (which you could also call "all addresses appearing before yours") to see how long of a starting string from your address is required to differentiate it from all others. Later additions will not affect it.

I'm sorry for the confusion. How can I improve the explanation on firstbits.com/about.php?

fyi, firstbits.com already indexed 1locus7* address and 1locus still points to original 1locus4*...

No, firstbits.com will permanently resolve 1locus to 1locus4... exactly because it is ordering the results with blocknum.

The probability of the ambigous result is significant, as you see it happen to me now. 1locus7... is the real address I wanted to resolve and I found the error on the blockchain.info just by chance.

Please, do one of following:
a) show big red message about different algos using on your site and firstbits.com, which is obviously true
b) (temporary) hide firstbits.com and wait to Freemoney
c) Rename it to something other than firstbits

We use the same algorithm just different SQL queries. firstbits.com does something like this:

select * from firstbits where prefix like '?%'

blockchain.info does

select * from firstbits where prefix = '?'

any firstbits using a wildcard are not permanent. I guarantee that in a few hours time the firstbits of 1locus will change on firstbits.com. The chances of this affecting anybody are minuscule, I don't think it warrants removing them from the site.

Well, both you and firstbits solution is correct from some view, but both are different, becase you both use different algorithm. As firstbits.com is original author of firstbits idea and your algo is *slightly* different, you should NOT call it firstbits or follow official specification, even if you don't like it.

I understand your view, but please hide firstbits field on the site until this issue will be resolved with firstbits.com owners.

Edit: I wrote to Freemoney to give us official documentation, so it will be clear then.

It think it's incorrect of firstbits to resolve wildcard prefixes.

If you search for 1locus at firstbits.com it will resolve it to 1LocUS4PUJeRSbR5ekySXEM4qMBT3xemp7 which users might think this is a permanent firstbits but it's not and will change in just a few confirmations time (at block 161612). The correct firstbits for 1LocUS4PUJeRSbR5ekySXEM4qMBT3xemp7 is 1locu only.

Edit: Blockchain.info's firstbits will get recalculated after a re-org, I did post a warning explaining the need to give a transaction at least 24 hours confirmation time before using firstbits .

Afaik when there are two candidates for the same prefix, the older (deeper in the blockchain) should win. So for 1locus it should resolve to 1LocUS4PUJeRSbR5ekySXEM4qMBT3xemp7 forever, with or without existence of 1locus7.

Edit: It's exactly how firstbits.com's mechanism works. It loads all address with given prefix (select ... from ... where address like 'prefix%') and then pick the address with the lowest blocknum. This is the only way how to not confuse users with new addresses in the future blocks.

Edit2: firstbits.com are delayed by the purpose. firstbits resolution should be permanent, irreversible, so blockchain reorgs are dangerous. For this reason firstbits is resolving only addresses which are already deep enough in the blockchain. I think it's pretty good idea. Actually I'm writing PM to freemoney to let him write official specification of firstbits algorithm, to not confuse other developers. Anyway, lack of any documentation is pretty usual in bitcoin circles. I know all this only because I read firstbits.com source code...

1LocUS4PUJeRSbR5ekySXEM4qMBT3xemp7 came first in block 134334 and has the first bits "1locu" (Both blockchain.info and firstbits.com agree).


1Locus7cPi1wGYAnKuXAR2dWTP2BSdqvyJ came after in block 161612 which gives it the firstbits "1locus" (which blockchain.info correctly has). however http://firstbits.com/ reports that its not in the blockchain, which is wrong (Block explorer will back me up on this http://blockexplorer.com/address/1Locus7cPi1wGYAnKuXAR2dWTP2BSdqvyJ)

piuk, I just found that you've an error in firstbits, obviously.

http://blockchain.info/fb/1locus => 1Locus7cPi1wGYAnKuXAR2dWTP2BSdqvyJ

but

http://firstbits.com/1locus => 1LocUS4PUJeRSbR5ekySXEM4qMBT3xemp7

Please fix this asap, as it can lead to wrong transactions for users using firstbits AND it can also damage firstbits as a concept.

What is the use case for this why would you want to be notified by email for one address and google talk for another?

What I can add is notifications after x confirmations and multiple simultaneous notification types. Regarding the fees 80% of recent transactions have been essentially free (ignoring the mandatory miners fee which you would have to pay using the mainline client anyway).


APNS notifications are supported in the iPhone app, I think cost would be prohibitive for SMS notifications (btw if anyone wants to test the app PM me your iPhone device ID and i'll send you  development build when it's ready).



Good to have you on board.

1) Labels will defiantly be added at some point.
2) I'm not sure i like the idea of pasting it in the send to field, but i may be possible to have full bitcoin: uri support (https://developer.mozilla.org/en/Web-based_protocol_handlers).
3) Never heard of Google Authenticator, I'll look into it.
4) Can do
5) My Wallet, My transaction, My addresses it kind of meant to go together as a bit of brand identity (but I agree it's not working especially well).

There needs to be someway for the server to know a particular user is the owner of a wallet, this cannot be done traditionally because the password is not shared with the server. So instead a 36 character random shared key is generated and stored inside the wallet, once the json is decrypted client side then it is used as a server side password (when backing up the wallet, updating account details etc).

Live status is whether or not you are connected via Websocket. If you have a live connection then new transactions/confirmations will update without reloading the page.

The fees don't seem unfair to me; although possibly they will as bitcoin's value increases.  0.01BTC when it's $6 per coin is different from 0.01BTC when it's $60 per coin; but that is a problem for another day I think.

The implementation and site are, I think, all excellent.  I've just swapped BitcoinSpinner from my android desktop for a bookmark to blockchain.info.  A native android app will be very pleasant, but given how nice the mobile version of the site is, it's not a necessity (QR scanning is about the only thing that would add; and I can work around that with the clipboard and a barcode scanner).

Suggestions (but these are by no means deal breakers):

• Given that I can choose a source address for sending/fees; it would be very convenient if I could give wallet addresses a label.  Remembering what I've designated each address to be for when it's just a sequence of base58 digits is tough
• Allow 'bitcoin:' URLs in the "Send To" field.  In particular, strip off the "bitcoin:" and automatically grab the "?amount=" parameter.  I'm not sure how standardised the bitcoin URL schema is, but whatever there is would be nice to support (QR code scans sometimes include this)
• Support for Google Authenticator, as the second factor.  It's open source I believe, and I'd rather carry my phone than yet another authenticator (the bank have already forced one on me)
• A direct link to the FAQ on the wallet page (perhaps the word 'FAQ' could be the link in the "support" paragraph?   )
• Remove "my" from "my transactions".  (just a personal preference, "my" doesn't really identify anyone in particular more than "your transactions" would; and it's obvious whose transactions we're talking about)
• Distinguish between "Cleared" and "Uncleared" balances.  "Uncleared" including unconfirmed (but valid) transactions that have appeared from the network; and "cleared" being those with N confirmations on top (I'd be happy with N=1).

Can I also ask: in the FAQ you describe the "shared key".  Could you clarify what that's for?  Isn't the wallet decrypted in the browser?  What is that shared key decrypting?

Finally, what does "live status: disconnected" mean?