Should be a little better now. Polar bears are still out in the cold.


Changed

Here's list of some of the addresses involved . Maybe you can get something useful out of it

Another potential use for this data: Today two blocks were generated at height 153715.

http://blockchain.info/inv/00000000000007c2b8380f991b3b36e8152c79e16434fcb6b7f0b498fa359f14
&
http://blockchain.info/inv/000000000000003b1aa4d6d6171b6a6973471139a7cfaa6897b7501104c089c0

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.

Tested and have found no problems.

However, if i may make a suggestion, I came across a possible usage caveat today. I was withdrawing some coins from bitcoinica, so I opened the client and clicked on "Address book" then copied the address i had labeled "Bitcoinica" to the clipboard. However that address is actually the address for depositing coins into bitcoinica not a receiving address. On the "address book" tab i think it should be clearly labeled they are addresses for sending coins. Or combine the "Receive coins" tab and "Address book" tab with sending and receiving address tables on top of each other.

Nothing that complicated, i look through a list of the ip's that relayed the most blocks. Then use a) server hostname b) whois c) google d) location e) look at mining pools stats pages and see if any correspond.

Ok try and add it to the site when i get chance.


Had a problem with tomcat segfaulting, seems to be fixed now.


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.

I have added live network propagation maps @ http://blockchain.info/inv/${hash} . You can use this tool to help determine the origin or a transaction as well as to measure how well it has propagated through the network. If "First Relayed" and "Most relayed" match that ip is almost certainly the owner of a transaction e.g. http://blockchain.info/inv/9b35b2956bb9a98dd573d1154c84b68518d47fff57c09c061106440754224b37.

If they are not the same but geographically very close together e.g. http://blockchain.info/inv/f631f8d4153797fdb5b0b78514af9e126fa6607d106d56e9d2a584a494186a1d then the originator is probably the "most relayed" node.

to determine the owner of a block look at the mining pools list look at which pools relayed first. For example BTC guild is almost certainly the owner of this block http://blockchain.info/inv/0000000000000a39d6754b7aa1fa78d6a67481d16531ceb34b0df890a28fe0f2

It works best in Safari & Chrome, which have web sockets enabled (not tested on i.e.). Relay data is removed after 24 hrs.

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.


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.


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?

But you don't need miners to forward the transaction, they only need to go from the users to the miners. If miners want to withhold their own transactions that is up to them.


Its not.

I can't answer your question but i doubt this will ever being an issue. It is true that mining pools have an incentive to withhold transactions but these nodes only make up a tiny proportion of the network. I have 120 mining pool nodes in my database out of +26,000 nodes in past 24 hours. Normal nodes have an incentive because they need to network to function properly in order to process their own transactions + bandwidth costs are tiny.

If this really became a problem a much easier solution would be for pools to offer a rewards to nodes that relay them a transaction they haven't seen before. Pools could offer 10% of the transaction fee back to the node that relayed them the transaction. This could be implement with minimal change to the core protocol and would create more efficient paths for network propogation.

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?

You would need to exclude coinbase transactions.

net.cpp


Bitcoin defines a limit for the maximum number of outbound connections the client will attempt to make. Once this limit is reached the client will stop trying to make new connections, but will still accept new incoming connections.

You can recompile and increase this number.

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.

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.


Yeah it has been very flaky the last week. It was running on my home ADSL connection but has now been moved to a new datacenter so it should be better from now on.

Transactions only have a received time if my node was online at the time it was made. Otherwise the timestamp from the for block it was included first in the best way to estimate the time.


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? 


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

Should be back up now. Stats will be screwed up for a while as it's been down for a few days. Bandwidth is about ~35GB Month.

Site will be down 9:00 - 11:00 AM - Moving to new server.

I don't just have miners in the database, the categories are: "Miner", "Merchant", "Exchange", "Misc" - Gavin is in Misc (where i put all the fallback nodes).

Gavin, your ip was listed on https://en.bitcoin.it/wiki/Fallback_Nodes so I added it to my known nodes list. Anomalies usually occur when i'm not connected to the node that finds a block then it will be almost random whoever relays it to me next. Let me know if you want your ip removed.

Apologies for the down time, back for now but might be down again for a few hours tomorrow. Should be much more reliable after that.