Blockchain.info - Bitcoin Block explorer & Currency Statistics

[FreeMoney]

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.

[1714931675]

1714931675

[1714931675]

1714931675

[slush]

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

[BkkCoins]

I've always treated the First in FirstBits as meaning both first digits in address AND also first use in the blockchain. You really can't depend on a address shortening of any kind unless it's recorded in the chain. Given how fast VanityGen can spit out duplicate matching addresses the First being address only isn't dependable at all. Anyone could see a FirstBits address, plug it into VanityGen and soon have another match. It has to be dependent on First Seen as well.

BTW I think the new fixed fee is very reasonable and I hope it encourages people to use the wallet.

[piuk]

ok i'm a little slow but I think i get it now. I have modified the blockchain.info firstbits algorithm so that it should produce the same results as firstbits.com. It's recalculating now, approx two hours until completion.

The old algorithm was:

for every block
  for every transaction
   for every output address
    for ii = 0; ii < address.length; ++ii
      prefix = address.lowercase().substring(0, ii);
      if (!firstbitsExists(prefix)
        addFirstBits(prefix, address);
    end
  end
 end
end

The new algorithm is:

for every block
  for every transaction
   for every output address
    for ii = 0; ii < address.length; ++ii
      prefix = address.lowercase().substring(0, ii);
      if (!firstbitsExists(prefix, &lastExistingAddress)
        addFirstBits(longestDistinguishablePrefix(address, lastExistingAddress), address);
    end
  end
 end
end

I do prefer the old algorithm though as with the new one won't all the short prefixes be used much quicker? Anyway Slush thanks for reporting the bug.

[piuk]

btw if anyone here is the owner of blockchain.com or knows who is the owner is please could you PM me.

[Maged]

I do prefer the old algorithm though as with the new one won't all the short prefixes be used much quicker?

Yes, but that doesn't matter. What matters is the depletion of meaningful prefixes. For example, if someone makes 1Locu..., the probability of it also taking the much more meaningful 1Locus by chance (assuming that they really did want just 1Locu) is quite low. That's the beauty of the firstbits working all the way through the entire address. It allows people to generate a longer prefix than needed and have that longer, intended, prefix work forever. In a way, it makes it possible for the algorithm to determine what a person was really aiming for, without ever having to ask them.

[realnowhereman]

Just a head's up: on the mobile version of the wallet, there are no buttons on the import/export page.  e.g. You can enter an address, but have nothing to click to send it for processing and be added to your wallet.

The non-mobile version is fine.

[piuk]

Yes, but that doesn't matter. What matters is the depletion of meaningful prefixes.

True I hadn't really consider the vanity aspect of firstbits.

The incompatibility should now be resolved.

http://www.blockchain.info/fb/1Locu
http://www.blockchain.info/fb/1Locus
http://www.blockchain.info/fb/1Locus7

Block explorer compatiable query api up

http://www.blockchain.info/q

Just a head's up: on the mobile version of the wallet, there are no buttons on the import/export page.  e.g. You can enter an address, but have nothing to click to send it for processing and be added to your wallet.

Now on my bug list, thanks.

[slush]

The incompatibility should now be resolved.

Excellent! Thank you for your hard work :-).

[piuk]

Hello, I believe you are designating certain blocks as found by P2Pool which weren't actually found by P2Pool. Yet, some of the block labeled as P2Pool are correct.

Edit: 162009, for example, was not found by P2Pool.

Nothing much I can do about this. Because I'm using the "first relayed" ip it's not always accurate. Once slush restarts his node it should help with things a bit.

[doublec]

Block 162209 is shown as P2Pool but it was the bitparking mmpool. You can confirm this with the IP you have being that of the mmpool server. There's a few others with that IP shown as P2Pool as well.

[rjk]

Block 162209 is shown as P2Pool but it was the bitparking mmpool. You can confirm this with the IP you have being that of the mmpool server. There's a few others with that IP shown as P2Pool as well.

ALL THE BLOCKS ARE BELONG TO P2POOL

[piuk]

Block 162209 is shown as P2Pool but it was the bitparking mmpool. You can confirm this with the IP you have being that of the mmpool server. There's a few others with that IP shown as P2Pool as well.

I have changed that IP back to bitparking. The problem might be an ip can automatically be assigned to P2Pool by the scraper, but it can never be unassigned. So it is more of a representation of all ip's that ever once joined the network, rather than ones actually mining currently.

[ataranlen]

So I'm seeing 176.31.159.150 on the website, and thought I would mention that this IP is owned by YaS Webservices, http://yas-online.net/

Ladies and Gentlemen,

I was just curious, I noticed your IP address, 176.31.159.150, on the site Blockchain.info
I was curious as to your involvement with bitcoins.

~Nathan Stoltenberg
ataranlen@gmail.com

Hello,

I have forwarded your request to the person in charge of the bitcoin pool. Please be patient and await a reply with 24 hours.

Your Contact:
********
YaS-Online Management
****@*****

This information, once I receive it, would allow us to classify them as a pool on Blockchain.info.

[piuk]

So I'm seeing 176.31.159.150 on the website, and thought I would mention that this IP is owned by YaS Webservices, http://yas-online.net/

I suspect the reason why this IP is showing such a high number of relayed blocks stems from the fact that I am having trouble connecting to Slush's node. Because I can't connect to slush any blocks found by the pool will get designated to another ip.

Because 176.31.159.150 happens to be hosted by the same ISP as Slush (Ovh Systems) it is likely they share a very low latency latency connection and the reason why 176.31.159.150 is relaying Slush's blocks so fast. The equipment may even be in the same datacenter.

[Jine]

Bitlc.net is now using these ip-addreses:

46.253.203.98
46.253.203.99
46.253.195.50
46.253.195.51
46.253.195.52
46.253.195.53
46.253.195.54


With the two ones in bold being the main pool and main website (also running bitcoind)

[piuk]

46.253.203.98

Thanks, I've added them.

[beckspace]

This is a hell of a wallet! Congratulations, Piuk!

May I ask: how the user's public addresses are handled? Do you collect information about them associated with IP address? If I have a "watch only" wallet, how the server's logs allow to connect the addresses?

Thanks.

[ataranlen]

I suspect the reason why this IP is showing such a high number of relayed blocks stems from the fact that I am having trouble connecting to Slush's node. Because I can't connect to slush any blocks found by the pool will get designated to another ip.

Because 176.31.159.150 happens to be hosted by the same ISP as Slush (Ovh Systems) it is likely they share a very low latency latency connection and the reason why 176.31.159.150 is relaying Slush's blocks so fast. The equipment may even be in the same datacenter.

I got a response from the aforementioned company this morning:

Hello, I've received a forward of you stating that one of our Server's
IP is appearing on your(?) website.
I was quite surprised to see that as everything the server is currently
running is the "bitcoind" client without doing any transactions and
whatsoever.

And since RPC and that stuff is protected by password and IP
restrictions do I wonder now how this was possible, maybe you could
explain that?

Regards,

[piuk]

This is a hell of a wallet! Congratulations, Piuk!

May I ask: how the user's public addresses are handled? Do you collect information about them associated with IP address? If I have a "watch only" wallet, how the server's logs allow to connect the addresses?

Thanks.

The server logs the IP the wallet was created with and the IP of the last wallet backup. A wallet can operate in two modes.

Payload only mode - If you have alerts disabled (default) then the server does not keep any information about your public keys and the only thing it stores is an encrypted JSON payload.

Public key mode - If you have alerts enabled your public keys are inserted in a separate table along with your email or skype username etc. This could then be used to connect public keys to a wallet identifier.

We do not log any data regarding /multiaddr lookups (the api call needed to lookup your balance) and your wallet identifier is not included in this lookup.

I got a response from the aforementioned company this morning:

Seems they are not running a pool so I've allocated that IP to Slush instead. Thanks for looking into it.



It seems about 80% of the hashing power is allocated for. The IP's that I would most like to label are:

1) 88.6.208.35 - Spanish IP, Largest share of unknown blocks - no other pools seems to be hosted in spain.

2) 62.220.146.204 = Tor node

3) 107.20.185.227 = either ABCPool.co or Arsbitcoin.com

4) BTCMine seems to be overly represented. I have allocated them 88.214.194.226 (Which is definitely them) and 88.214.193.104 (Which I allocated because its the same ISP and block). It's possible that 88.214.193.104 belongs to a different pool.