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.

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.

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.

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.

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.

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).

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.

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.