I find the screen width far too wide for my notebook display. I'm constantly scrolling back and forth.
Is it maybe possible to have an alternate style option (css chg maybe) that would suit a narrow layout? I'm sure there must be quite a few notebook users who can't handle non-wrapping wide layouts.
Otherwise, great! I like the visual style.
It should be a little better now at smaller resolutions. |
|
|
|
Yeah I thought I'd test my MySQL cluster by deleting data on one of the nodes. Turns out it couldn't recover. I can't remember why it seemed like a good idea at the time  , but it should be all reimported now. As for the csv data, I'll be adding an api sometime soon. |
|
|
|
Great... I'm out of bitcoins  what is your paypal? Thanks, No Need If you could link to the site from anywhere that would be great. The year graph is interesting. By far the largest peak of activity if right at the peak market price, looks like one of the early adopters stopped the rise by cashing out. Days destroyed:  Market price:  |
|
|
|
Finally got round to adding bitcoin days destroyed: http://pi.uk.com/bitcoin/charts/bitcoin-days-destroyed-cumulative?timespan=180days&showDataPoints=false&daysAverageString=1Please could someone double check my formula: days destroyed for one block =
for every transaction
get the timestamp of the owning block in seconds (t1)
for each input
get the value of the previous output (v1)
get the timestamp of the previous output's block (t2)
daysDestroyed += v1 * ((t1 - t2) / 60 / 60 / 24)
I don't know if Abe is calculating it in a similar fashion, but for me it is very slow (takes roughly 10 mins for per 24hour period) |
|
|
|
About 75% sure his ip is 128.253.153.95. It's from cornell.edu so possibly you could ring the university, but i'm not sure they could/would do much. |
|
|
|
I've added the a list of large recent transactions at http://pi.uk.com/bitcoin/largest-recent-transactionsAlso i've rewritten a lot of the bitcoin networking code so my client can now connect to around 2000 nodes. I'm running two clients so have a pretty good chance at intercepting double spends. |
|
|
|
This is pure Javascript and HTML.
Why does this have to depend on chrome? |
|
|
|
 lol brilliant! |
|
|
|
|
211k in the past 24hrs. The highest i have recorded is 234,122 between 11th-12th Jun 2011
|
|
|
|
Very well done!
Can you add timestamps to the transaction history of addresses?
I've added timestamps to the transaction themselves. Unfortunately due to the way my mysql tables are partitioned it's quite slow to lookup a block from a transaction so I probably won't be able to add timestamps to the transaction history. I've also added the ip of the node who first relayed a transaction. |
|
|
|
Just to confirm my own code changes...Are you logging the ip from the 'inv' or the 'tx' message? I originally logged the 'tx', but realized that the 'inv' message comes first. --E Logging from "tx", i think your right it might be better to log from inv (although when the client asks for an inv item the response will come from the same node). |
|
|
|
I've started recording ip's on my block tracker site. Currently connected to 600 nodes but don't want to increase the limit any further as bitcoind cpu usages gets too high. http://pi.uk.com/bitcoin/unconfirmed-transactions It will be interesting to to see whether any of these ip's are actually the transaction sender. A lot of them link to personal home pages and stuff. When i collect enough data i'll use the frequencies of ip's associated with a given address to try and guess the owner. |
|
|
|
+1 to notion of adding the Bitcoin DD (days destroyed) stat.
One other comment: where do you get $1000 / 2 years for 1 GHash? Is that approximately 50% depreciation per year on a rig which costs $1/MHash/s? Don't disagree with the number so much as interested in how you derived it.
The average upgrade cycle for gamers is somewhere between 18-24 months (can't find the link where i read it now). After two years old cards won't be worth running compared to the newer competition, there probably is some resale value which isn't calculated in. What is the logic used to estimate the transaction volume? Heres the method. Basically common transactions "1 in ->2 out" it takes the smallest value, ">2 in -> 2 out" it takes the largest, otherwise total all. public long getActualBTCSent() {
if (blockIsMined()) {
return 0;
//If a transaction transaction has more than two inputs and two outputs we take the largest output
} else if (nInputs >= 2 && nOutputs == 2) {
return Math.max(getOut().get(0).getValue(), getOut().get(1).getValue());
//If a transaction has one input and two outputs we take the smallest output
} else if (nInputs == 1 && nOutputs == 2) {
total = Math.min(getOut().get(0).getValue(), getOut().get(1).getValue());
//None simple transaction total all outputs
} else {
long total = 0;
for (Output output : getOut()) {
total += output.getValue();
}
return total;
}
} |
|
|
|
Feature request: Show date/time on transactions.
The problem with this is transactions don't have a time associated with them when sent. So there are two options: - Record the time my client receives the transaction (which would mean no times for old transactions) - Use the timestamp from the block the transaction was included in (no times for unconfirmed transactions) Which do you think would be best? |
|
|
|
The money doesn't have to come directly from new investment now. If the volume of transactions processed increases the value of bitcoin as a product increases, which can be used to settle the deficit in future. The is not happening though |
|
|
|
|
Show Posts
