Topic: Blockchain.info - Bitcoin Block explorer & Currency Statistics - page 168. (Read 482646 times)
November 10, 2011, 01:39:08 PM
Btw what's dns for your node? telnet blockchain.info 8333 does not work...
November 10, 2011, 01:37:17 PM
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.
November 10, 2011, 01:30:58 PM
Nice job!
One question: why older transactions have no date/time ?
One question: why older transactions have no date/time ?
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.
It's just my feeling or Bitcoin pools stats are completely wrong? Afaik you're detecting pools by IP, which won't work. Many pools don't have opened port 8333, for example. And your observed IPs (e.g. deepbit) are also wrong - those IPs are balancers, not mining backends and they're also subject of changes during attacks etc.
Probably only parsing website stats is a feasible way how to get sane pie chart of hashrate distribution.
Probably only parsing website stats is a feasible way how to get sane pie chart of hashrate distribution.
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?
Quote
Probably only parsing website stats is a feasible way how to get sane pie chart of hashrate distribution.
How can you be sure the pool is reporting the correct has rate?
November 08, 2011, 08:28:16 PM
It's just my feeling or Bitcoin pools stats are completely wrong? Afaik you're detecting pools by IP, which won't work. Many pools don't have opened port 8333, for example. And your observed IPs (e.g. deepbit) are also wrong - those IPs are balancers, not mining backends and they're also subject of changes during attacks etc.
Probably only parsing website stats is a feasible way how to get sane pie chart of hashrate distribution.
Probably only parsing website stats is a feasible way how to get sane pie chart of hashrate distribution.
November 07, 2011, 11:12:05 AM
http://blockchain.info/block-index is 404 Not Found
November 04, 2011, 03:56:48 AM
Nice job!
One question: why older transactions have no date/time ?
One question: why older transactions have no date/time ?
November 04, 2011, 03:48:00 AM
Site will be down 9:00 - 11:00 AM - Moving to new server.
October 21, 2011, 08:22:53 PM
The site is giving an error from the web provider, Cloudflare.
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.
October 21, 2011, 11:26:39 AM
The site is giving an error from the web provider, Cloudflare.
October 16, 2011, 06:09:08 AM
By the way, I got the impression that your service could track relayed transactions even when not locked into a block (0/unconfirmed). I removed transaction fees from main.h and sent a tiny (0.005 BTC) transaction. The fact that I can't see it means what? 1. you won't display the transaction until it's in a block, 2. no other nodes have relayed the transaction, 3. nodes have actively rejected it (somehow), 4. or....?
It should accept it but other nodes won't relay it so you'll have to push it directly to one me (or to eligius https://en.bitcoin.it/wiki/Free_transaction_relay_policy who should in turn relay it to me)
October 15, 2011, 09:17:22 PM
http://www.blockchain.info is perfect!
By the way, I got the impression that your service could track relayed transactions even when not locked into a block (0/unconfirmed). I removed transaction fees from main.h and sent a tiny (0.005 BTC) transaction. The fact that I can't see it means what? 1. you won't display the transaction until it's in a block, 2. no other nodes have relayed the transaction, 3. nodes have actively rejected it (somehow), 4. or....?
By the way, I got the impression that your service could track relayed transactions even when not locked into a block (0/unconfirmed). I removed transaction fees from main.h and sent a tiny (0.005 BTC) transaction. The fact that I can't see it means what? 1. you won't display the transaction until it's in a block, 2. no other nodes have relayed the transaction, 3. nodes have actively rejected it (somehow), 4. or....?
October 15, 2011, 06:39:05 PM
谢谢
您的欢迎
Don't really like bitebi. I've moved it to http://www.blockchain.info Simple & to the point, still open to new suggestions though.
October 15, 2011, 12:24:03 AM
EDIT: Oh wait, I assumed incorrectly, you're using European, 9 October. Please use YYYY-MM-DD HH:mm:ss Zulu. The Chinese will thank you. 
Personally dates seem most natural to me as hh:mm:ss dd/mm/yy but i've changed them to ISO 8601 anyway.I'm also thinking of moving the site to it's own domain anyone got any good name ideas?
bitebi.com (bitcoin in pinyin) seems up for sale. October 14, 2011, 08:39:54 PM
Nice, I see you now redirect to the block if there are no orphans.
The base http://pi.uk.com/bitcoin/ returns a 404.
Timestamps such as "13:56:51 09/10/2011" are both dyslexic and ambiguous. One can only guess from your -.com TLD that it's 10 September.
EDIT: Oh wait, I assumed incorrectly, you're using European, 9 October. Please use YYYY-MM-DD HH:mm:ss Zulu. The Chinese will thank you.
EDIT2: No, I assumed that I assumed incorrectly. But I was incorrect. You ARE using American notation: 20:10:39 29/09/2011 can only mean 29 September. ISO 8601 and UTC are our friends.
The base http://pi.uk.com/bitcoin/ returns a 404.
Timestamps such as "13:56:51 09/10/2011" are both dyslexic and ambiguous. One can only guess from your -.com TLD that it's 10 September.
EDIT: Oh wait, I assumed incorrectly, you're using European, 9 October. Please use YYYY-MM-DD HH:mm:ss Zulu. The Chinese will thank you.
EDIT2: No, I assumed that I assumed incorrectly. But I was incorrect. You ARE using American notation: 20:10:39 29/09/2011 can only mean 29 September. ISO 8601 and UTC are our friends.
Thanks for the heads up on the 404. Personally dates seem most natural to me as hh:mm:ss dd/mm/yy but i've changed them to ISO 8601 anyway.
I've added a WebGL globe showing online nodes @ http://pi.uk.com/bitcoin/nodes-globe . You need chrome or to enable WebGL in safari or firefox. Use your show wheel to zoom.
If you want more accurate data countries and hostnames can be seem on http://pi.uk.com/bitcoin/connected-nodes
I'm also thinking of moving the site to it's own domain anyone got any good name ideas?
October 11, 2011, 07:45:12 PM
Nice, I see you now redirect to the block if there are no orphans.
The base http://pi.uk.com/bitcoin/ returns a 404.
Timestamps such as "13:56:51 09/10/2011" are both dyslexic and ambiguous. One can only guess from your -.com TLD that it's 10 September.
EDIT: Oh wait, I assumed incorrectly, you're using European, 9 October. Please use YYYY-MM-DD HH:mm:ss Zulu. The Chinese will thank you.
EDIT2: No, I assumed that I assumed incorrectly. But I was incorrect. You ARE using American notation: 20:10:39 29/09/2011 can only mean 29 September. ISO 8601 and UTC are our friends.
The base http://pi.uk.com/bitcoin/ returns a 404.
Timestamps such as "13:56:51 09/10/2011" are both dyslexic and ambiguous. One can only guess from your -.com TLD that it's 10 September.
EDIT: Oh wait, I assumed incorrectly, you're using European, 9 October. Please use YYYY-MM-DD HH:mm:ss Zulu. The Chinese will thank you.
EDIT2: No, I assumed that I assumed incorrectly. But I was incorrect. You ARE using American notation: 20:10:39 29/09/2011 can only mean 29 September. ISO 8601 and UTC are our friends.
October 11, 2011, 07:21:04 PM
When I look at the latest block, I see no transactions. Is there a delay? http://pi.uk.com/bitcoin/block-height/148961
Your on the block height page, click on the hash.
Bit confusing i know.
October 11, 2011, 07:17:24 PM
When I look at the latest block, I see no transactions. Is there a delay? http://pi.uk.com/bitcoin/block-height/148961
October 11, 2011, 06:50:24 PM
New features!
You can see how well a transaction or block has propagated through the network (or at least the nodes i am connected to). Known/Trusted nodes are listed in the order they were relayed not including the originating ip.
e.g.
For a transaction:
http://pi.uk.com/bitcoin/tx-index/11109374/5b04ffeb046f89a1d8739f8ff799b1c46c3345e0c4cc7a2e67d408f39879624a
For a block:
http://pi.uk.com/bitcoin/block-index/388174/000000000000047c8bcceeade127a3628ee8076454714dedf290fc52e1041072
Also you can see a list of nodes connected at
http://pi.uk.com/bitcoin/connected-nodes
You can see how well a transaction or block has propagated through the network (or at least the nodes i am connected to). Known/Trusted nodes are listed in the order they were relayed not including the originating ip.
e.g.
For a transaction:
http://pi.uk.com/bitcoin/tx-index/11109374/5b04ffeb046f89a1d8739f8ff799b1c46c3345e0c4cc7a2e67d408f39879624a
For a block:
http://pi.uk.com/bitcoin/block-index/388174/000000000000047c8bcceeade127a3628ee8076454714dedf290fc52e1041072
Also you can see a list of nodes connected at
http://pi.uk.com/bitcoin/connected-nodes
October 08, 2011, 07:40:22 PM
I downloaded a copy of the block chain from http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/ and am getting some good data from it (still importing).
One chain fork does like it's been purposely crafted (maliciously or for testing?)
One chain fork does like it's been purposely crafted (maliciously or for testing?)
October 08, 2011, 05:00:33 PM
Yeah, that's excellent. What would it look like if an orphan chain continued for a few blocks? Perhaps you can mention (in the Next block(s)) that it is "likely orphaned" http://pi.uk.com/bitcoin/block-index/383776/00000000000001df2ba97a1537c5a5ed26ce070be48501c6944fc7414d8de194 but now I'm just getting picky. It's already very clear and hugely useful!
It should look something like your diagram showing the next block when the chains finally converge. Needs testing though as I don't know what would happen if an already orphan chain split again. Another good idea, will add it soon.
piuk, your link to Deepbit is wrong. The link leads to deepbit.org which is wrong and the correct one is deepbit.net, and it sounds suspicious...you didnt try to phish me did you?
You caught me. This has all been an elaborate scam to phish deepbit passwords
deepbit.com .net and .org all point to the same ip hosted by Hetzner Online. Jump to: