The site has been up and down for the past few days which messes up the stats. It is advantageous for mining pools to be feel connect so even if they don't accept incoming connections eventually they will connect to me. It doesn't matter if they are balancers or not if deepbit's mining nodes are still behind them, which ip do you think is incorrect?

Oh, if this means that deepbit connect to you from those IPs, then it's everything perfect. I though you just guessed IPs from pinging his site :-).

Quote

How can you be sure the pool is reporting the correct has rate?

Don't get hashrate from website (because very pool calculates in a slightly different way), but pick blockheaders or blocknums from their stats page. Then you can calculate rough hashrate by yourself.

If pool is hiding some blocks on stats page, then it's completely different story. But I don't think it's an issue at least for biggest one.

The website routes through cloudflare so which I don't think will work with telnet. I'm keeping the ip's of my nodes hidden. Node 1 has a static ip which you can probably find fairly easily, Node 2,3,4 change ip every few hours.

I love the different graphs you have available on your site. However, sometimes I feel like I'd like to see more history than just a year. Could you add an option to see the data for the whole lifetime of the network? Especially for the number of transactions graph but other would be nice too. Also, an option for logarithmic scale to accompany that would be great

I love the different graphs you have available on your site. However, sometimes I feel like I'd like to see more history than just a year. Could you add an option to see the data for the whole lifetime of the network? Especially for the number of transactions graph but other would be nice too. Also, an option for logarithmic scale to accompany that would be great

I'va added options to view all data and log scale. Log scale is a beta feature of high charts so its not perfect, sometime the graph won't render or the y axis scale is a little messed up.

I'va added options to view all data and log scale. Log scale is a beta feature of high charts so its not perfect, sometime the graph won't render or the y axis scale is a little messed up.

Thank you! There's still one little bug left but I'm happy with just being able to see the graphs for all time in logarthmic It would be great if you can fix the date scale that's shown on the bottom as well as the magnitudes shown on the left.

Also, would be great to have another graph. The number of addresses with unspent outputs.

I'm not sure exactly what this would illustrate. As more coins are coming into production the figure will almost certainly increase regardless of wether there is an increased number of holders.

On a different note, as the site seems to be running well, I've removed the connection limits on the bitcoin nodes. Currently connect to over 4000 unique nodes (approx 10,000 connections due to overlap) is this a record?

Also, would be great to have another graph. The number of addresses with unspent outputs.

I'm not sure exactly what this would illustrate. As more coins are coming into production the figure will almost certainly increase regardless of wether there is an increased number of holders.

On a different note, as the site seems to be running well, I've removed the connection limits on the bitcoin nodes. Currently connect to over 4000 unique nodes (approx 10,000 connections due to overlap) is this a record?

It's another way of getting an idea of how much bitcoin is getting real world use. In addition to the daily transaction counts.

Looks like Eligius has their clock set 1 hour 10 minutes into the future, and you are using the block time instead of the received time for the age...That block is also completely missing from http://blockchain.info/blocks/1320972380607.

Looks like Eligius has their clock set 1 hour 10 minutes into the future, and you are using the block time instead of the received time for the age...That block is also completely missing from http://blockchain.info/blocks/1320972380607.

I'm going to leave as the block time as there could be a delay between that and the received time. The block you mention is an interesting anomoly as the extra hour pushed it to the next day http://blockchain.info/blocks/1321058780607.

as it does on blockexplorer.com, but it actually does something completely different. Searching by address prefix is useful for checking physical bitcoins.

I will probably open source the backend at some point. I have forked the mainline bitcoin client to allow several machines to operate as if they were running a single bitcoin node e.g. they share the same blockchain and load balance transaction and block validation. I don't have any plans to open source the front end.

This is not implement, it should say not found not sure why it takes you to an unrelated address. How would collisions between addresses with the same prefix be handled?

Interesting graph, you are trying to show their is a direct relationship between market price and number of transactions? I personally don't believe this to be true. correlation != causation.

No, I'm trying to show that a) they're heavily correlated b) There seems to be a direct relationship between the price bottom and transactions per day c) This graph can be used to estimate how much air (that is, speculation) there is in the exchange rate.

I'm curious what you're using to determine which pools found blocks...considering you've posted multiple blocks as found by BTC Guild that were not, and multiple blocks not found by BTC Guild as ones we have .

No, I'm trying to show that a) they're heavily correlated b) There seems to be a direct relationship between the price bottom and transactions per day c) This graph can be used to estimate how much air (that is, speculation) there is in the exchange rate.

I'm curious what you're using to determine which pools found blocks...considering you've posted multiple blocks as found by BTC Guild that were not, and multiple blocks not found by BTC Guild as ones we have .

I'm a method similar to Dam Kaminsky's proposal, recording the first node to relay a transaction as the transaction's origin. As it says on the pools stats page this isn't always 100% accurate.

Block 000000000000003b1aa4d6d6171b6a6973471139a7cfaa6897b7501104c089c0 only propagated to 1% of the nodes while block 00000000000007c2b8380f991b3b36e8152c79e16434fcb6b7f0b498fa359f14 propogated to over 100%. From that data if your node had received the lesser propagated block then there was a high chance of it becoming orphaned.

That's fantastic! May I suggest you change the map_canvas dimensions? You've got the United States, S. America, Africa, and Australia squarely in there (by default), but you cut off half of Europe, Canada, Russia, and heaven forbid all of Greenland. Think of the polar bears!