Bitcoin Forum
May 27, 2015, 03:39:48 PM *
News: Change your password!
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 [4] 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 ... 162 »
  Print  
Author Topic: Blockchain.info - Bitcoin Block explorer & Currency Statistics  (Read 318641 times)
piuk
Hero Member
*****
Offline Offline

Activity: 910



View Profile WWW

Ignore
September 27, 2011, 12:12:05 PM
 #61

Looking Great!

I'd also like to see sequential transaction numbers (and ISO 8601 dates), then confirmation status is just subtraction.

however you should be extremely careful using these as they may change if the chain is reorganised.

Have we ever had a reorg longer than 2 blocks? http://blockexplorer.com/q/reorglog

I've done a little testing and it seems to work well. Just a thought, maybe you could provide a short url/redirect for firstbits. Something like: http://pi.uk.com/f/12345

I'll see what i can do about the dates and tx numbers.

No i don't think we have, but it *could* happen. So if your going to get business cards printed with your firstbits address on then it would be a good idea to wait until the address is at least 24 hrs old.

You can search for first bits e.g http://pi.uk.com/bitcoin/search/1a the only problem is if you have a firstbits like "1234" then if will think your looking for a block height.

This isn't an either/or situation. It's merely adding more precision to the timestamps which will allow us to have much better data to work with in the future. You show unconfirmed transactions already, so I suspect that adding a timestamp will be trivial.

Yes I am recording the timestamp when the client first receives the inventory hash, so yes i just need to copy this to the blocks / transactions table.

1432741188
Hero Member
*
Offline Offline

Posts: 1432741188

View Profile Personal Message (Offline)

Ignore
1432741188
Reply with quote  #2

1432741188
Report to moderator

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1432741188
Hero Member
*
Offline Offline

Posts: 1432741188

View Profile Personal Message (Offline)

Ignore
1432741188
Reply with quote  #2

1432741188
Report to moderator
1432741188
Hero Member
*
Offline Offline

Posts: 1432741188

View Profile Personal Message (Offline)

Ignore
1432741188
Reply with quote  #2

1432741188
Report to moderator
1432741188
Hero Member
*
Offline Offline

Posts: 1432741188

View Profile Personal Message (Offline)

Ignore
1432741188
Reply with quote  #2

1432741188
Report to moderator
1432741188
Hero Member
*
Offline Offline

Posts: 1432741188

View Profile Personal Message (Offline)

Ignore
1432741188
Reply with quote  #2

1432741188
Report to moderator
piuk
Hero Member
*****
Offline Offline

Activity: 910



View Profile WWW

Ignore
September 27, 2011, 03:13:11 PM
 #62

I've added a "Found by" column to the homepage which shows the ip the block was first relayed by (similar to pident). This won't be 100% accurate due to network latency, my client crashing etc.

The list of known ip's I have are as follows:

Quote
82.146.47.200   pool.itzod.ru   http://pool.itzod.ru/
173.193.21.69   Mt.Red   http://www.mtred.com
81.29.3.30   Mainframe Mining   http://mining.mainframe.nl/
78.47.187.255   Eligius   http://eligius.st
46.4.121.119   Deepbit   http://deepbit.org/
46.4.121.118   Deepbit   http://deepbit.org/
46.4.121.100   Deepbit   http://deepbit.org/
46.4.121.99     Deepbit   http://deepbit.org/
46.4.121.120   Deepbit   http://deepbit.org/
78.46.186.29   BTC Guild   https://www.btcguild.com/
78.46.186.53   BTC Guild   https://www.btcguild.com/
78.46.186.52   BTC Guild   https://www.btcguild.com/
46.4.116.147   BTC Guild   https://www.btcguild.com/
78.46.186.27   BTC Guild   https://www.btcguild.com/
78.46.186.28   BTC Guild   https://www.btcguild.com/
78.46.186.51   BTC Guild   https://www.btcguild.com/
78.46.186.54   BTC Guild   https://www.btcguild.com/
188.40.93.82   BTC Guild   https://www.btcguild.com/
78.46.186.50   BTC Guild   https://www.btcguild.com/
78.46.186.30   BTC Guild   https://www.btcguild.com/
76.74.166.121   BitcoinRulez (tor)   http://metrics.torproject.org/descriptor.html?desc
209.15.238.254   BitcoinNow (tor)   http://metrics.torproject.org/descriptor.html?desc
204.45.253.21   Bitclockers   http://bitclockers.com
50.19.225.254   Ars bitcoin   https://arsbitcoin.com/

Does anyone know Slush's push pool ip?


piuk
Hero Member
*****
Offline Offline

Activity: 910



View Profile WWW

Ignore
September 30, 2011, 11:41:46 PM
 #63

I've added a free email notifications system for bitcoin transactions @ http://pi.uk.com/bitcoin/payment-notifications.  You can subscribe to a particular address and will receive notifications when a payment is sent or received. Notifications will be sent ~20 seconds after a the transaction is received, it does not wait for any block confirmations.

I'm also considering the possibility of allowing JSON to be posted to a callback url depending if people think they would use it. This is a best effort service, don't subscribe to every address, if i feel it is being abused i will disable it.

PiUK

netrin
Sr. Member
****
Offline Offline

Activity: 322


FirstBits: 168Bc


View Profile

Ignore
September 30, 2011, 11:50:23 PM
 #64

Great new features. Perhaps RSS/Atom with params would be less taxing on your system?
http://pi.uk.com/rss?address=12345678798,1abcdefgh

Greenlandic tupilak. Hand carved, traditional cursed bone figures. Sorry, polar bear, walrus and human remains not available for export.
piuk
Hero Member
*****
Offline Offline

Activity: 910



View Profile WWW

Ignore
September 30, 2011, 11:56:54 PM
 #65

Great new features. Perhaps RSS/Atom with params would be less taxing on your system?
http://pi.uk.com/rss?address=12345678798,1abcdefgh

Good idea netrin, yes that would probably scale better than email. I'll add it to my todo list.

netrin
Sr. Member
****
Offline Offline

Activity: 322


FirstBits: 168Bc


View Profile

Ignore
October 01, 2011, 12:52:15 AM
 #66

Good idea netrin, yes that would probably scale better than email. I'll add it to my todo list.

Don't get me wrong. The email would be very cool. If it doesn't already, I'd suggest an unsubscribe link in the email. I don't expect people to just randomly pay me money. But I would realistically give an address to a customer/friend and wait minutes, hours, days for a transaction email (rather than polling the block chain periodically) and then forget about the address after I've received payment.

Greenlandic tupilak. Hand carved, traditional cursed bone figures. Sorry, polar bear, walrus and human remains not available for export.
piuk
Hero Member
*****
Offline Offline

Activity: 910



View Profile WWW

Ignore
October 01, 2011, 07:59:30 AM
 #67

Don't get me wrong. The email would be very cool. If it doesn't already, I'd suggest an unsubscribe link in the email. I don't expect people to just randomly pay me money. But I would realistically give an address to a customer/friend and wait minutes, hours, days for a transaction email (rather than polling the block chain periodically) and then forget about the address after I've received payment.

An unsubscribe link is included on the bottom of every confirmation email. I thought it might be useful for people who have coins in cold storage and they can be alerted if they are moved unexpectedly.

If i expanded the system to http POST data to a particular url would people use it? It could be used as a rudimentary way to accept payments on a website without any signups.

netrin
Sr. Member
****
Offline Offline

Activity: 322


FirstBits: 168Bc


View Profile

Ignore
October 01, 2011, 03:11:56 PM
 #68

no lo entiendo

Can you describe the use case/steps?

Greenlandic tupilak. Hand carved, traditional cursed bone figures. Sorry, polar bear, walrus and human remains not available for export.
piuk
Hero Member
*****
Offline Offline

Activity: 910



View Profile WWW

Ignore
October 02, 2011, 03:23:48 PM
 #69

no lo entiendo

Can you describe the use case/steps?

Never mind just found out that https://bitcoinnotify.com/ are already providing the http POST service. Looks like their doing a good job, so there is no point in me duplicating their service.

I've added a pie chart showing market share of the top pools @ http://pi.uk.com/bitcoin/pools


NothinG
Hero Member
*****
Offline Offline

Activity: 560



View Profile

Ignore
October 02, 2011, 06:46:27 PM
 #70

no lo entiendo

Can you describe the use case/steps?

Never mind just found out that https://bitcoinnotify.com/ are already providing the http POST service. Looks like their doing a good job, so there is no point in me duplicating their service.

I've added a pie chart showing market share of the top pools @ http://pi.uk.com/bitcoin/pools


I think your percentages are off a little.

piuk
Hero Member
*****
Offline Offline

Activity: 910



View Profile WWW

Ignore
October 02, 2011, 10:43:40 PM
 #71

I think your percentages are off a little.

Fixed. I've also added received received timestamps as per Maged's suggestion.

Maged
Global Moderator
Legendary
*
Offline Offline

Activity: 1246


View Profile

Ignore
October 03, 2011, 05:21:47 PM
 #72

I've also added received received timestamps as per Maged's suggestion.
Awesome! Looks great!

piuk
Hero Member
*****
Offline Offline

Activity: 910



View Profile WWW

Ignore
October 03, 2011, 08:27:26 PM
 #73

Awesome! Looks great!

Thanks. Looks like Eligius's clock is wrong http://pi.uk.com/bitcoin/block-index/378832/00000000000008db9eb6d09370f17e3ef92624594849c79d77c26547a0705ea7

P.S. Whatever pool owns ip 85.17.51.144 (Host leaseweb) stand up and be counted. It annoying me i can't categorise it Tongue


Maged
Global Moderator
Legendary
*
Offline Offline

Activity: 1246


View Profile

Ignore
October 03, 2011, 11:37:18 PM
 #74

That's entirely intentional. It allows them to re-use the merkle tree instead of rebuilding it for every miner who requests work. This is the main reason why I wanted you to have the received times available for blocks.

piuk
Hero Member
*****
Offline Offline

Activity: 910



View Profile WWW

Ignore
October 07, 2011, 03:24:22 PM
 #75

I've redone the orphaned blocks page to make it easier to visualise chain splits:

http://pi.uk.com/bitcoin/orphaned-blocks

Now working on xc's idea.

netrin
Sr. Member
****
Offline Offline

Activity: 322


FirstBits: 168Bc


View Profile

Ignore
October 07, 2011, 04:17:19 PM
 #76

Very cool. Though is wasn't immediately obvious what you are trying to show. It wasn't until I consulted the previous block and selected "next block(s)" (and there are two of them, EXCELLENT). Perhaps if you showed the previous block (and perhaps the next successful block) your orphaned block page would be immediately obvious.



I don't think you need all the visual hell that I've introduced, but a link to Previous and Next would be helpful. On the other hand, if we did experience a multi-block orphan (attack), then I think you'd need the extra graph nodes to make sense of the attack. Also, an issue I have with your current implementation is that the previous orphaned block with arrow up seems to suggest that it links directly into the next orphaned block which is (in most cases) not true (I suppose that's what you mean to demonstrate with a dotted arrow, which would be more apparent in a context with solid/direct and dotted/indirect linked nodes).

Greenlandic tupilak. Hand carved, traditional cursed bone figures. Sorry, polar bear, walrus and human remains not available for export.
piuk
Hero Member
*****
Offline Offline

Activity: 910



View Profile WWW

Ignore
October 07, 2011, 04:45:45 PM
 #77

Very cool. Though is wasn't immediately obvious what you are trying to show. It wasn't until I consulted the previous block and selected "next block(s)" (and there are two of them, EXCELLENT). Perhaps if you showed the previous block (and perhaps the next successful block) your orphaned block page would be immediately obvious.



I don't think you need all the visual hell that I've introduced, but a link to Previous and Next would be helpful. On the other hand, if we did experience a multi-block orphan (attack), then I think you'd need the extra graph nodes to make sense of the attack. Also, an issue I have with your current implementation is that the previous orphaned block with arrow up seems to suggest that it links directly into the next orphaned block which is (in most cases) not true (I suppose that's what you mean to demonstrate with a dotted arrow, which would be more apparent in a context with solid/direct and dotted/indirect linked nodes).

Yeah the dotted line is mean to represent a continuation of the chain but some block heights have been skipped for compactness. I see what you mean, so show the previous block with a solid lines to the descendants. Perhaps the previous block could be centralised then the dotted arrow below it wouldn't line up to show it's not the next block in the chain. Thanks for the feedback, i'll experiment with it.

netrin
Sr. Member
****
Offline Offline

Activity: 322


FirstBits: 168Bc


View Profile

Ignore
October 07, 2011, 05:20:34 PM
 #78

This is how I imagine it, always showing the previous block before orphans.
Code:
149000 [19:00:00]

          ^
          :
          :           x
148334 [18:47:17] [18:47:27]

          ^
          |
          |
148333 [18:30:00]

          ^
          :
          :           x
148284 [09:00:59] [09:01:09]

          ^
          |
          |
148283 [08:50:00]

However, in the case of multi-block orphans (potential attack) it might be easier to visualize if you also added the next node:
Code:
149000 [23:00:00]

           ^
           :
           :
148336 [20:17:17]

           ^
           |
           |          x
148335 [19:57:17] [19:57:27]

           ^          ^
           |          |
           |          |
148334 [18:47:17] [18:47:27]

           ^
           |
           |
148333 [18:30:00]

           ^
           :
           :
148285 [09:20:59]

           ^
           |
           |          x
148284 [09:00:59] [09:01:09]

           ^
           |
           |
148283 [08:50:00]

By the way, do you know the longest orphan chain we've experienced? Is there any record or does that just get lost after reorg?

Greenlandic tupilak. Hand carved, traditional cursed bone figures. Sorry, polar bear, walrus and human remains not available for export.
piuk
Hero Member
*****
Offline Offline

Activity: 910



View Profile WWW

Ignore
October 07, 2011, 06:53:16 PM
 #79

By the way, do you know the longest orphan chain we've experienced? Is there any record or does that just get lost after reorg?

Don't know as i haven't been running the site that long. Orphaned blocks are still kept in the database after a reorg so someone who has been running a client for a long time will have the data. If Mt.gox, deepbit etc want to upload me a copy of their block chain i'll gladly import the data.

piuk
Hero Member
*****
Offline Offline

Activity: 910



View Profile WWW

Ignore
October 08, 2011, 06:51:12 PM
 #80

This is how I imagine it, always showing the previous block before orphans

I think it's a bit clearer now http://pi.uk.com/bitcoin/orphaned-blocks.

Pages: « 1 2 3 [4] 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 ... 162 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!