|
i think he is talking about gpu hardware production not bitcoin production.
|
|
|
|
try formatting the cell, custom format.  |
|
|
|
it's time, price, amount the time is unix (epoch) time (not sure if there is a difference or just different names for the same thing) 1282038389 = Tue, 17 Aug 2010 09:46:29 GMT see http://www.epochconverter.com/or use the formula I gave above in a spreadsheet. |
|
|
|
|
in your browser there should be something like save page as. save it as a .csv or .txt and then import it into Excel or whatever you want to use
|
|
|
|
|
i think the time is unix time. [edit: originally said UTC but meant to say unix time]
you can convert it into a more human readable form if you use a formula like this in Excel (where A2 is the UTC cell)
=DATE(1970,1,1+(A2/(60*60*24)))+TIME(MOD(INT(A2/3600),24),MOD(INT(A2/60),60),MOD(A2,60))
that'll give you day/month/year hour:min
you can use just
=DATE(1970,1,1+(A2/(60*60*24)))
to get day/month/year
hope that helps
|
|
|
|
|
no it means 1 old bitcoin will = 1 million new BTC or 1000 kBTC
1 new BTC would = 1 current uBTC
|
|
|
|
|
this can make an interesting example of how bitcoin transfers may not be 100% anonymous all of the time.
|
|
|
|
|
other explanation videos could be things like:
backing up a wallet
how to move your BTC when you change your computer
|
|
|
|
|
sorry Akiron,
just realized that your graph takes into account the 1440 minutes in a day factor that you mentioned in a post above.
the % of cumulative days destroyed/total BTC days at >20% seems quite high to me. does the calculation for days destroyed need to be corrected for the 1440 minutes in a day too?
|
|
|
|
|
hi Akiron,
is the y-axis scale correct. looks like it's out by a factor of 100 if jerfelix's previous calculations were right.
|
|
|
|
|
great charts ThomasV.
If I'm looking at it right for recent blocks tx fees/day are ~20 BTC. Very rough estimate say ~200 blocks/day (I know it should be 144 blocks if we assume 10 minutes between blocks, but block creation has been faster than that recently) - that gives a very rough ballpark number of 0.1 BTC in fees/block. Not far off smell's 0.075 BTC/block average (difference probably from actual block creation has been >200 blocks/day recently).
good to see the trend is increasing in the Bitcoin Report charts.
I actually downloaded Python yesterday and was thinking of teaching my self how to write a script to create a csv file with the block # and total tx fee in that block # as suggested by PLATO. Never used Python before and haven't coded anything since some C++ classes I did in college over 10 years ago but have been thinking for a while to learn some new skills and this seemed like an interesting project.
|
|
|
|
it's a start but not exactly the same as mechanical turk. imagine if amazon allowed payment of mechanical turk tasks in bitcoins - tasks could also easily be priced at sub US $0.01 in bitcoin. |
|
|
|
you're right maybe I should have just given the power number in W rather than MWh/day , so ~3.39 MW. People are used to the unit of energy in kWh from their electricity bill, so units of power in kWh/day make some sort of intuitive sense. There is a book I like called "Sustainable energy without the hot air" which has a good explanation of units of energy and power and the author explains his reasoning for using different units to explain things. http://www.inference.phy.cam.ac.uk/withouthotair/c2/page_24.shtml. The whole book is available for free by the way. |
|
|
|
I've seen some numbers in other threads before estimating this. This site has a lot of data on the different hardware including J/MHash etc. https://en.bitcoin.it/wiki/Mining_hardware_comparisonThe 5850 card you mention seems be ~1.85 Mhash/J or ~1.85 Mhash/s per W. I think I've seen other people use a very rough number like 1 Mhash/s per W - probably not a bad estimate when you consider all the different types of hardware, AC/cooling costs etc. Using 1 Mhash/s per W, we get 0.024 kWh/day per Mhash 3.390 Thash/s = 3.390*10^6 Mhash/s = (3.390*10^6 Mhash/s *0.024 kWh/day per Mhash) = 81360 kWh/day = 81.36 MWh/day |
|
|
|
|
sounds like mechanical turk for bitcoin would be a good idea.
hopefully someone will build something like that
|
|
|
|
This BitcoinDays Destroyed number still doesn't provide a perfect picture, it is just a much better measure than looking at raw spending totals. Here's an example: 1. Someone who mined 50 bitcoins exactly one year ago spends them.
Consider a slight variation on that ... example 5: 5. Someone who mined 50 bitcoins exactly one year ago spends 1 BTC. In Case 5 only 1 BTC was spent and 49 BTC was returned as change. There would still be 18,250 Bitcoin-days destroyed, even though the coins representing all but 365 of those Bitcoin-days remained in the same wallet. I understood the first 4 examples, but not that example 5 you just explained. Why are all 18250 BTC days destroyed? Why not just 365? Is it because some part of the 50 that was originally minted is finally spent, regardless of how many? If so, why? if I understand it correctly when you receive bitcoins it's like having a "bitcoin note" of the denomination of the amount that you received them. so if you mine 50 BTC you get a 50 "BTC note" say. For simplicity, say you only have that 50 BTC in your wallet. You spend 1 BTC, so that "note" has to be broken - so it's like all 50 are spent, 1 BTC goes to the address you sent it to and the change of 49 BTC is returned to an address you own. So now you have 49 BTC in your wallet that are fresh (i.e. zero days old). For the BTC days destroyed calculation it's like all 50 BTC have been spent (so days destroyed = 50 x # of days you've held them) even though in reality you've sent 1 BTC and still own the other 49. hope that's right. someone can correct me if I'm wrong. |
|
|
|
maybe I'm missing something but are there some errors in these numbers for BTC days destroyed? Some blocks have negative values for days destroyed. For example see block 65711 has -151.03 BTC days destroyed. There are 48 other blocks in this csv file with negative numbers for days destroyed. Very interesting data and analysis by the way. thanks to all concerned. Well, looking at the Block Explorer for block 65711, it seems that the previous block 65710, which holds the redeemed output, actually has a timestamp that is later than block 65711. So, apparently the calculation is "correct", but I honestly don't know why the dates are backwards... good spot on the time stamp inconsistencies. I was looking at the block explorer to try and make sense of the numbers but didn't notice that. Maybe someone else can explain why the time stamps are out of sync with the block numbers |
|
|
|
maybe I'm missing something but are there some errors in these numbers for BTC days destroyed? Some blocks have negative values for days destroyed. For example see block 65711 has -151.03 BTC days destroyed. There are 48 other blocks in this csv file with negative numbers for days destroyed. Very interesting data and analysis by the way. thanks to all concerned. |
|
|
|
Seems like it's going up anyway.  But, consider this: There's someone, or a group of people with a considerable part of the network's computing power, in the order of the Thash/s. They only allocate some of that power right before difficulty increases and turn it off right after difficulty increases, taking advantage of the screwiness for the first blocks, in hopes others miners will leave and the difficulty increase forecast actually gets skewed, and as the change approaches and some people leave, they gradually put their power in, ensuring a steady profit. Maybe I'm just nuts, and yes, this is one pretty tinfoil hat. i'm pretty sure it doesn't work like this. how can these mystery miners take advantage of the "screwiness for the first blocks" after the difficulty change as you call it. It's only a screwiness in the calculated hash rate stats that happens after the difficulty change. The difficulty is set for a 2016 block period, it doesn't change. So for a certain hash rate you should get the same return on average for a particular difficulty regardless if it's just right after that difficulty has been set or if it's just before the difficulty is going to be readjusted |
|
|
|
|
Show Posts
