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

Why Bitcoin values will rounded now?

I use the blockchain.info for different things and I need all numbers after the comma to identify payments.
Is it possible to make a choice between a rounded and not rounded view?

You can now choose your local currency from the select box in the page footer. To quickly switch between BTC and your local currency click on one of the green buttons below a transaction (people were confused as to why they didn't do anything, I think this is a good use for them).

Also fixed a bug where two factor authentication emails were sometimes not being sent out.

iPhone app is done, I'm submitting it tomorrow.

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.


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.

I got a response from the aforementioned company this morning:

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.

Thanks, I've added them.

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)

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.

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/


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

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.

ALL THE BLOCKS ARE BELONG TO P2POOL

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.

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.

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

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

Now on my bug list, thanks.

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.

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.

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

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.

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.