|
piuk (OP)
|
 |
September 27, 2011, 12:12:05 PM |
|
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/reorglogI'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/12345I'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. |
|
|
|
|
piuk (OP)
|
|
September 27, 2011, 03:13:11 PM
Last edit: September 27, 2011, 03:28:51 PM by piuk |
|
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: Does anyone know Slush's push pool ip? |
|
|
|
|
piuk (OP)
|
|
September 30, 2011, 11: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 |
|
|
|
|
|
|
piuk (OP)
|
|
September 30, 2011, 11:56:54 PM |
|
Good idea netrin, yes that would probably scale better than email. I'll add it to my todo list. |
|
|
|
netrin
Sr. Member
 Offline
Activity: 322
Merit: 251
FirstBits: 168Bc
|
|
October 01, 2011, 12:52:15 AM |
|
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. |
|
|
|
|
piuk (OP)
|
|
October 01, 2011, 07: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. |
|
|
|
netrin
Sr. Member
Offline
Activity: 322
Merit: 251
FirstBits: 168Bc
|
|
October 01, 2011, 03:11:56 PM |
|
no lo entiendo
Can you describe the use case/steps?
|
|
|
|
|
piuk (OP)
|
|
October 02, 2011, 03:23:48 PM |
|
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
|
|
October 02, 2011, 06:46:27 PM |
|
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/poolsI think your percentages are off a little. |
|
|
|
|
piuk (OP)
|
|
October 02, 2011, 10:43:40 PM |
|
I think your percentages are off a little.
Fixed. I've also added received received timestamps as per Maged's suggestion. |
|
|
|
Maged
Legendary
Offline
Activity: 1204
Merit: 1015
|
|
October 03, 2011, 05:21:47 PM |
|
I've also added received received timestamps as per Maged's suggestion.
Awesome! Looks great! |
|
|
|
|
|
Maged
Legendary
Offline
Activity: 1204
Merit: 1015
|
|
October 03, 2011, 11:37:18 PM |
|
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. |
|
|
|
|
|
netrin
Sr. Member
Offline
Activity: 322
Merit: 251
FirstBits: 168Bc
|
|
October 07, 2011, 04:17:19 PM
Last edit: October 07, 2011, 04:28:16 PM by netrin |
|
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). |
|
|
|
|
piuk (OP)
|
|
October 07, 2011, 04:45:45 PM |
|
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
Activity: 322
Merit: 251
FirstBits: 168Bc
|
|
October 07, 2011, 05:20:34 PM |
|
This is how I imagine it, always showing the previous block before orphans. 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: 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? |
|
|
|
|
piuk (OP)
|
|
October 07, 2011, 06: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. |
|
|
|
|
|
|
