Doesn't work for me unfortunately, I see no textures and a lot of errors like this:
WebGL: INVALID_VALUE: texImage2D: width or height out of range
[.WebGLRenderingContext]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering or is not 'texture complete'
This is on a retina MacBook Pro. I guess there's some hw incompatibility there.
On firefox I ran into the out_of_range error with the clear image used in WebKit browser. So on Gecko browsers I load a smaller image (which is a bit darker).
Other feedback: I suspect there aren't really tons of transactions being relayed out of costa rica - is this possibly the origin point on your globe model or something? Are you filtering out transactions with no geocodable IP?
I am currently unable to host a big node myself so I am relying on Bitcoincharts and the relay IP they detect. All transactions coming from Bitcoincharts itself (the wallet service) have the localhost IP (127.0.0.1). After being unable to find out where the company is based I've choosen to translate that IP to their main website IP (which is hosted in Costa Rica).
If anybody knows where Blockchain.info is based please let me know and I'll fix those transaction locations.
Great stuff. Where do you get the data? I'm working on a geolocation-centric visualization in webgl that would be a good fit for this kind of realtime(ish) data.
All transaction and block data is from Blockchain.info (https://blockchain.info/api/api_websocket) (you can also get that from the Bitcoin network itself pretty easily) and all geo location data (ip to geo) is from freegeoip.net. All data is proxied through my own server, so I'm not hammering those services.
Orange or gold will complement against the blue/green background, especially when you are popping/zooming out. They get lost in the background when the view pulls out.
I've now turned them orange, which improves the visibility a ton. Though I want to fix the lighting and color them based on variables instead of making them so plain as they are now.
I developed the same code base to do the same thing a month ago. It also front paged on Hackernews (http://www.earthbit.net ).
I guess the main difference is you're using your own proxy for the queries, which is sturdier than a third party. A worthwhile improvement as mine crashed under the load last time = )
Ah I knew I could not be the first one to come up with this idea. Nice to see an alternative as well! I love the sounds you added.
I like the fact that I provide all data for the website myself, though I'm not in a position to buy a lot of servers. So let's hope this one will hold :)
Right, so these are basically the ip addresses of the bitcoind nodes that are the entry point into the bitcoin network. They are not the addresses of the end users who are transacting in BTC. Correct?
You are partly correct. The IP is the node who first told Blockchain.info (assuming that's what this is using) about the transaction. The "entry point" to the network would be when the person sending first transmits it.
There is no way to be sure where a transaction came from, but if you have data about how long it took to reach parts of the network, you can make an educated guess (which becomes more accurate if you have more connections/nodes).
Some people specifically add Blockchain.info to their peer list, but that is bad for anonymity since all your transactions will then list your real IP in the "relayed by" field.
This is awesome, but just a small comment about "Next block expected in 7 minutes". The next expected block is always due in 10 minutes, no matter when the previous block was generated. Mining is a memoryless process.
What do you mean? If blocks are 10min apart (actually less as the network hashrate grows before the difficulty adjustment) and the last block was found 3 minutes ago, a new block is expected to be found after 7 more minutes.
The 10 minutes is only an average time at which the network can solve the problem with random tries. You won't see a lot of blocks 10 minutes apart because only when measured over longer timeframes it averages to 10 minutes.
Just like when you flip 10 coins they likely won't result in: head - tail - head - tail - (...). Though on average you end up with 5 tails and 5 heads.
> You won't see a lot of blocks 10 minutes apart because only when measured over longer timeframes it averages to 10 minutes.
That's why it says expected! To be 100% correct you could plot the cumulative density function as time progresses, but I think just printing the expected time is fine.
Each hash is essentially an observation of a uniformly distributed variable (hopefully). When you flip a coin, it's heads with probability 1/2 and tails with probability 1/2. The fact that you flipped heads on the first go doesn't change the probabilities. In the same way, the fact that your hash didn't match the difficult on the first go, doesn't change the probability it will match the difficulty on future hashes. So each hash is independent of the attempts you've already made, so there's the same probability of a match at any time step.
That's technically right (yep, I know gambler's fallacy too), but it doesn't address my comment.
Testing a block header is just a binary (yes/no) test with a given probability (target/max_target). Finding a block is repeating this test again and again, i.e. a binomial distribution, right?
Finding a block averages 10 minutes, which means that, after 10 minutes trying hashes randomly, the expectation of finding a block is high, i.e. the CDF of the binomial distribution approaches 1.
The result will deviate from the expected result? Of course! After all, it's a distribution... but this doesn't contradict the fact that as you try again a again, the probability of AT LEAST ONE hitting the target gets higher.
So, yes, it doesn't change the individual probability of each outcome, but it sure does mean that more hashes have been tried, i.e. there's a greater probability of a hash being found simply because we've tried more guesses as time passes, i.e. we're measuring the CDF with a high N.
To put it another way: the more coins you flip, the higher the expectation of AT LEAST ONE yielding tails (even if the previous attempts don't change the outcome probability).
Think about it: even if each coin outcome is always 1/2, we're not assessing whether it's going to be tails or not in flip N, but whether after N flips we'll see at least one flipping tails, whose probability is (1 - (1/2)^N).
Flipping a coin 7 times yields a 99% probability of flipping tails (or heads) at least once, regardless of previous outcomes.
And I'll stop here, I think I'm repeating myself :P
I'm sorry, but this isn't correct. Firstly, you need to understand what Binomial is describing. It is not describing the time between outcomes. It is describing the number of times you will observe a positive result amongst n independent Bernoulli trials (Yes/No trials). By the "CDF approaches 1", what you are saying is that P(X <= n) = 1. But, we know that to be true by assumption -- we can't possibly observe more than n positive results from n trials. The continuous-time analogue would be the Poisson process -- this counts the number of valid blocks that have been generated up to a time t. The inter-arrival time -- the time between valid blocks -- is a random variable with an Exponential distribution. This is the distribution we are really looking at. And Exponential is memoryless (see Wikipedia for a proof).
Don't be sorry, I love learning and correcting my mistakes! But I'm going to fight :P
Of course it does not describe time. It describes attempts (which grow with time because you're doing N attempts per second, i.e. the network hashrate). My point still stands.
I see your point, but I think we're unknowingly discussing a semantic issue: the expected time is not the time when you're expected to find a block, it is the time where the probability of at least one block being found is high (including the previous attempts). It's only gambler's fallacy if you're discarding the previous attempts and only measuring the probability of hitting a block in a single attempt, which of course is constant throughout all attempts.
> The inter-arrival time -- the time between valid blocks -- is a random variable with an Exponential distribution.
Sure, but if you pick 10 minutes, you'll be right more often than not (not counting hashrate changes, of course) because it averages 10 minutes...
One block is found in 1 minute and the next in 19? No problem. That's why it says "expected" and not "sure".
----
How many times do you have to flip a coin to have a 99% confidence of flipping tails at least once? Seven. You might need less than seven (the first attempt is already 50%) or more than seven (because 99% != 100% and we never reach 100%) but 99 out of 100 times you flip 7 coins you'll hit tails at least once.
I think that's what the "expected" means. You expect to flip tails within 7 flips (because I've arbitrarily set the bar at 99%) so we might be arguing what "expected" means.
Suppose you flip a coin and get 4 heads in a row. How many additional times do you have to flip the coin to have a 99% confidence of flipping tails at least once?
If you flip it only 3 additional times you get only a 7/8=88% probability of getting at least one tail.
You need to flip it 7 additional times you get 127/128=99.2% probability of getting at least one tail.
The coin doesn’t remember that the last 4 times it landed head.
You are right of course, a dice won't be estimated to roll on a 6 after it failed to do so 5 previous times.
I think the best solution is to remove the expected next block time counter altogether. One of the reasons UX wise I went for such an expected point in the future was that after reading it you are aware a new block will come again (just like when you first load the project) and that might keep you waiting for it.
I think you've been misled and this is not a case of gambler's fallacy (I might be wrong). You should check my comment[1]. And please correct me if I'm wrong!
> The next expected block is always due in 10 minutes
Not if the current network speed is higher than the difficulty level due to more mining power having come online since the last difficulty change.
You could estimate this by examining the block times over the last 120 (or some N) blocks, estimating the difficulty for that solve rate, and using the ratio of current network difficulty over the the estimated difficulty times 10 minutes.
I'm watching a real time 3D visualisation of the generation of a distributed unregulated worldwide crypto-currency using the largest network of computers the world has ever seen.
Screw it I'm off to the Black Sun for a drink and a sword fight.
39 comments
[ 2.6 ms ] story [ 100 ms ] threadWebGL: INVALID_VALUE: texImage2D: width or height out of range
[.WebGLRenderingContext]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering or is not 'texture complete'
This is on a retina MacBook Pro. I guess there's some hw incompatibility there.
In firefox the textures are noticeably darker for some reason.
Really cool visualisation anyway. Like it!
If anybody knows where Blockchain.info is based please let me know and I'll fix those transaction locations.
All transaction and block data is from Blockchain.info (https://blockchain.info/api/api_websocket) (you can also get that from the Bitcoin network itself pretty easily) and all geo location data (ip to geo) is from freegeoip.net. All data is proxied through my own server, so I'm not hammering those services.
In the next version I want to color them on transaction volume (combined with square sizes).
I developed the same code base to do the same thing a month ago. It also front paged on Hackernews (http://www.earthbit.net ).
I guess the main difference is you're using your own proxy for the queries, which is sturdier than a third party. A worthwhile improvement as mine crashed under the load last time = )
I like the fact that I provide all data for the website myself, though I'm not in a position to buy a lot of servers. So let's hope this one will hold :)
FYI: Your normal globe wasn't loading for me, I am seeing the same error that bothered my version as well. That is until @mrdoob pointed me to the error: https://twitter.com/mrdoob/status/429292386611511296
There is no way to be sure where a transaction came from, but if you have data about how long it took to reach parts of the network, you can make an educated guess (which becomes more accurate if you have more connections/nodes).
Some people specifically add Blockchain.info to their peer list, but that is bad for anonymity since all your transactions will then list your real IP in the "relayed by" field.
Just like when you flip 10 coins they likely won't result in: head - tail - head - tail - (...). Though on average you end up with 5 tails and 5 heads.
That's why it says expected! To be 100% correct you could plot the cumulative density function as time progresses, but I think just printing the expected time is fine.
Testing a block header is just a binary (yes/no) test with a given probability (target/max_target). Finding a block is repeating this test again and again, i.e. a binomial distribution, right?
Finding a block averages 10 minutes, which means that, after 10 minutes trying hashes randomly, the expectation of finding a block is high, i.e. the CDF of the binomial distribution approaches 1.
The result will deviate from the expected result? Of course! After all, it's a distribution... but this doesn't contradict the fact that as you try again a again, the probability of AT LEAST ONE hitting the target gets higher.
So, yes, it doesn't change the individual probability of each outcome, but it sure does mean that more hashes have been tried, i.e. there's a greater probability of a hash being found simply because we've tried more guesses as time passes, i.e. we're measuring the CDF with a high N.
To put it another way: the more coins you flip, the higher the expectation of AT LEAST ONE yielding tails (even if the previous attempts don't change the outcome probability).
Think about it: even if each coin outcome is always 1/2, we're not assessing whether it's going to be tails or not in flip N, but whether after N flips we'll see at least one flipping tails, whose probability is (1 - (1/2)^N).
Flipping a coin 7 times yields a 99% probability of flipping tails (or heads) at least once, regardless of previous outcomes.
And I'll stop here, I think I'm repeating myself :P
Of course it does not describe time. It describes attempts (which grow with time because you're doing N attempts per second, i.e. the network hashrate). My point still stands.
I see your point, but I think we're unknowingly discussing a semantic issue: the expected time is not the time when you're expected to find a block, it is the time where the probability of at least one block being found is high (including the previous attempts). It's only gambler's fallacy if you're discarding the previous attempts and only measuring the probability of hitting a block in a single attempt, which of course is constant throughout all attempts.
> The inter-arrival time -- the time between valid blocks -- is a random variable with an Exponential distribution.
Sure, but if you pick 10 minutes, you'll be right more often than not (not counting hashrate changes, of course) because it averages 10 minutes...
One block is found in 1 minute and the next in 19? No problem. That's why it says "expected" and not "sure".
----
How many times do you have to flip a coin to have a 99% confidence of flipping tails at least once? Seven. You might need less than seven (the first attempt is already 50%) or more than seven (because 99% != 100% and we never reach 100%) but 99 out of 100 times you flip 7 coins you'll hit tails at least once.
I think that's what the "expected" means. You expect to flip tails within 7 flips (because I've arbitrarily set the bar at 99%) so we might be arguing what "expected" means.
If you flip it only 3 additional times you get only a 7/8=88% probability of getting at least one tail.
You need to flip it 7 additional times you get 127/128=99.2% probability of getting at least one tail.
The coin doesn’t remember that the last 4 times it landed head.
I think the best solution is to remove the expected next block time counter altogether. One of the reasons UX wise I went for such an expected point in the future was that after reading it you are aware a new block will come again (just like when you first load the project) and that might keep you waiting for it.
[1] https://news.ycombinator.com/item?id=7159663
Not if the current network speed is higher than the difficulty level due to more mining power having come online since the last difficulty change.
You could estimate this by examining the block times over the last 120 (or some N) blocks, estimating the difficulty for that solve rate, and using the ratio of current network difficulty over the the estimated difficulty times 10 minutes.
Screw it I'm off to the Black Sun for a drink and a sword fight.