Topic: Blockchain.info - Bitcoin Block explorer & Currency Statistics - page 169. (Read 482649 times)
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
October 08, 2011, 04:28:47 PM
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?
October 08, 2011, 02:34:22 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!
October 08, 2011, 01:51:12 PM
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.
October 07, 2011, 01:53:16 PM
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.
October 07, 2011, 12:20:34 PM
This is how I imagine it, always showing the previous block before orphans.
However, in the case of multi-block orphans (potential attack) it might be easier to visualize if you also added the next node:
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?
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?
October 07, 2011, 11:45:45 AM
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).
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.
October 07, 2011, 11:17:19 AM
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).
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).
October 07, 2011, 10:24:22 AM
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.
http://pi.uk.com/bitcoin/orphaned-blocks
Now working on xc's idea.
October 03, 2011, 06:37:18 PM
Awesome! Looks great!
Thanks. Looks like Eligius's clock is wrong http://pi.uk.com/bitcoin/block-index/378832/00000000000008db9eb6d09370f17e3ef92624594849c79d77c26547a0705ea7
October 03, 2011, 03:27:26 PM
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
October 03, 2011, 12:21:47 PM
I've also added received received timestamps as per Maged's suggestion.
Awesome! Looks great! October 02, 2011, 05:43:40 PM
I think your percentages are off a little.
Fixed. I've also added received received timestamps as per Maged's suggestion.
October 02, 2011, 01:46:27 PM
no lo entiendo
Can you describe the use case/steps?
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
October 02, 2011, 10:23:48 AM
no lo entiendo
Can you describe the use case/steps?
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
October 01, 2011, 10:11:56 AM
no lo entiendo
Can you describe the use case/steps?
Can you describe the use case/steps?
October 01, 2011, 02:59:30 AM
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.
September 30, 2011, 07:52:15 PM
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.
September 30, 2011, 06:56:54 PM
Great new features. Perhaps RSS/Atom with params would be less taxing on your system?
http://pi.uk.com/rss?address=12345678798,1abcdefgh
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.
September 30, 2011, 06:50:23 PM
Great new features. Perhaps RSS/Atom with params would be less taxing on your system?
http://pi.uk.com/rss?address=12345678798,1abcdefgh
http://pi.uk.com/rss?address=12345678798,1abcdefgh
September 30, 2011, 06:41:46 PM
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
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
Jump to: