BitcoinWisdom.com - Live Bitcoin/LiteCoin Charts

[BitcoinWisdom]

It's system limit. server only can return UTC data. and display in local time.

Hm, would you consider using UTC for display too?

Bitcoin price events and discussions are global in scope, not particularly related to the reader's locale.  It may be easier for everybody if everybody uses the same clock.

It should be no problem.

[MusX]

Hi, can we have a BTCLTC kraken on your site? there are already BTCEUR and LTCEUR from kraken. And BTCLTC volume is already as high as LTCEUR.

any news about that? from technical point of view it should be a piece of cake as you already have two currency pairs from kraken.
besides BTCLTC would be the first such pair on your platform

[BitcoinWisdom]

Hi, can we have a BTCLTC kraken on your site? there are already BTCEUR and LTCEUR from kraken. And BTCLTC volume is already as high as LTCEUR.

any news about that? from technical point of view it should be a piece of cake as you already have two currency pairs from kraken.
besides BTCLTC would be the first such pair on your platform

The BTCLTC is different from other exchange LTCBTC and the volume is not high enough, only 34.72 in last 24 hours. so it will not be added currently.

[JorgeStolfi]

I noticed that your chart squeezes out "empty" intervals, which seem to be common in some sites. For example, this is an excerpt of the 1-minute data for BTC-China provided by bitcoincharts.com:


2014-01-14 18:29:00   5009.61   5009.61   5009.61   5009.61   0.43   2154.13   5009.61
2014-01-14 18:30:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:31:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:32:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:33:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:34:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:35:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:36:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:37:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:38:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:39:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:40:00   5009.61   5009.61   5009.6   5009.6   0.41   2043.92   5009.6


(those are UTC times)

On your chart the 18:29 datum is immediately followed by the 18:40 datum.  That makes the horizontal scale non-linear.

While one can get used to it, wouldn't it be clearer and simpler to leave blank spaces for empty intervals (i.e make the horizontal axis linear, with the abscissa computed from the time rather than from the datum's index)?

For stock and commodity prices, it makes sense to omit the intervals when there is no trade, such as weekends and nights.  That's because the market actually disappears during those intervals -- so that Friday 4:00 pm coincides with Monday 9:30 am in "Wall Street time".  For Bitcoin prices, however, the global network effectively keeps the market running continuousy, even when one exchange is down or has no transactions. 

By the way, in a market that is continuously active, the "opening price" and "closing price" become rather arbitrary data points.  Thus the color of each candle should perhaps be defined by comparing its closing price with the previous closing, rather than with its opening price.  Or perhaps one should redefine the opening and closing prices by linear interpolation between adjacent transactions.  But presumably that would be too messy to implement, and too confusing to people who are used to the current scheme.

I should add that I find your charts wonderful, and that is why I am complaining so much. 

[BitcoinWisdom]

I noticed that your chart squeezes out "empty" intervals, which seem to be common in some sites. For example, this is an excerpt of the 1-minute data for BTC-China provided by bitcoincharts.com:


2014-01-14 18:29:00   5009.61   5009.61   5009.61   5009.61   0.43   2154.13   5009.61
2014-01-14 18:30:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:31:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:32:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:33:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:34:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:35:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:36:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:37:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:38:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:39:00   1.7e+308   1.7e+308   1.7e+308   1.7e+308   Infinity   Infinity   Infinity
2014-01-14 18:40:00   5009.61   5009.61   5009.6   5009.6   0.41   2043.92   5009.6


(those are UTC times)

On your chart the 18:29 datum is immediately followed by the 18:40 datum.  That makes the horizontal scale non-linear.

While one can get used to it, wouldn't it be clearer and simpler to leave blank spaces for empty intervals (i.e make the horizontal axis linear, with the abscissa computed from the time rather than from the datum's index)?

For stock and commodity prices, it makes sense to omit the intervals when there is no trade, such as weekends and nights.  That's because the market actually disappears during those intervals -- so that Friday 4:00 pm coincides with Monday 9:30 am in "Wall Street time".  For Bitcoin prices, however, the global network effectively keeps the market running continuousy, even when one exchange is down or has no transactions.  

By the way, in a market that is continuously active, the "opening price" and "closing price" become rather arbitrary data points.  Thus the color of each candle should perhaps be defined by comparing its closing price with the previous closing, rather than with its opening price.  Or perhaps one should redefine the opening and closing prices by linear interpolation between adjacent transactions.  But presumably that would be too messy to implement, and too confusing to people who are used to the current scheme.

I should add that I find your charts wonderful, and that is why I am complaining so much.  

BTC exchange is 7x24 hours work. so it is different from traditional stock or forex.

Here is at least 2 advantage for omit blank data
1. Omit blank data could returns more data, for some exchange, if won't omit blank, in 1 minute candlestick, you will only see more than 80% blank data.
2. Keep chart fast, as I tested local, fill data will slow down chart a lot, at least decrease 300% performance on intialize.

You could use CandleStickHLC instead of CandleStick if want shows continuously.

[JorgeStolfi]

You could use CandleStickHLC instead of CandleStick if want shows continuously.

Oops, thanks!

[prof7bit]

4850 means the sum amount of 4850 to 4899.999999

This is quite counterintuitive, this would also have been my next feature request. It should be displayed in a more symmetrical manner: asks between (and including) 4850.00001 and 4900.00000 should be summarized under 4900.

if on the bid side it reads

4800  142

then this means 142 BTC must be sold to break 4800

so consequently if on the ask side it reads

4900 132

it should also mean the same: 132 must be bought to break 4900
and not 132 must be bought to break 4949.9999 (which is a very odd number)

Currently its quite cumbersome to read the ask side, one has to add 50 (or 5) to the number and even then it includes only the orders that are lying in front of this level and omits the ones that are at exactly this level. I would be very thankful if this could be changed, this is the last and only remaining tiny little annoyance that separates this otherwise brilliant website from true and universal perfection. I will have no more reason to complain from the moment on this becomes implemented.

[MusX]

Hi, can we have a BTCLTC kraken on your site? there are already BTCEUR and LTCEUR from kraken. And BTCLTC volume is already as high as LTCEUR.

any news about that? from technical point of view it should be a piece of cake as you already have two currency pairs from kraken.
besides BTCLTC would be the first such pair on your platform

The BTCLTC is different from other exchange LTCBTC and the volume is not high enough, only 34.72 in last 24 hours. so it will not be added currently.

In terms of volume BTCLTC is now 50% of the LTCEUR volume, as mentioned before it was the same volume a little bit time ago.
Also that BTCLTC is different from LTCBTC I see more as an advantage than disadvantage.
Anyway, lets just wait for more volume, kraken is the highest quality market at the moment so it is just a matter of time
Regards

[CoolStoryBro]

Currently its quite cumbersome to read the ask side, one has to add 50 (or 5) to the number and even then it includes only the orders that are lying in front of this level and omits the ones that are at exactly this level. I would be very thankful if this could be changed, this is the last and only remaining tiny little annoyance that separates this otherwise brilliant website from true and universal perfection. I will have no more reason to complain from the moment on this becomes implemented.

nice find!

[BitcoinWisdom]

4850 means the sum amount of 4850 to 4899.999999

This is quite counterintuitive, this would also have been my next feature request. It should be displayed in a more symmetrical manner: asks between (and including) 4850.00001 and 4900.00000 should be summarized under 4900.

if on the bid side it reads

4800  142

then this means 142 BTC must be sold to break 4800

so consequently if on the ask side it reads

4900 132

it should also mean the same: 132 must be bought to break 4900
and not 132 must be bought to break 4949.9999 (which is a very odd number)

Currently its quite cumbersome to read the ask side, one has to add 50 (or 5) to the number and even then it includes only the orders that are lying in front of this level and omits the ones that are at exactly this level. I would be very thankful if this could be changed, this is the last and only remaining tiny little annoyance that separates this otherwise brilliant website from true and universal perfection. I will have no more reason to complain from the moment on this becomes implemented.

It was talked several months ago, I still prefer the consistency to consider it is break or not.
The graphic looks like
---- 4900
|  164 [4850,4900)
---- 4850
|  132 [4800,4850)
| <- Current price 4823
---- 4800
| 78 [4750,4800)
---- 4750
| 122 [4700,4750)
---- 4700
So it won't be changed, maybe would be an option.

[il--ya]

are there any plans to add ablility to save lines/fib levels/fans for registered/pro users?

[JorgeStolfi]

It was talked several months ago, I still prefer the consistency to consider it is break or not.
The graphic looks like[...]
So it won't be changed, maybe would be an option.
[/quote]
Why not shift the price column down by half a line? Then it would look sort of like this


           4900 -
                  653
           4850 -
                  233
           4800 -
                  25
4778.22
                  12
           4750 -
                  63
           4700 -
                  423
           4650 -
                  1024

except that it would be squeezed vertically so that both columns are single-spaced.

[prof7bit]

I still prefer the consistency

But as it is now it is inconsistent, the ask is treated different than the bid. Bid shows correctly the amount laying at the level and in front of it, ask is showing the amount laying behind the level. Traders are normally interested in the size of a "wall" at a certain level and that is the volume at this level including the orders in front of it. "Top of the book" on the ask side is the smallest ask while top of the book on the bid side is the highest bid, the sort order is inverted (relative to the top of the book) and then naturally "in front of a level" means the usage of floor() on the bid side and ceil() on the ask side. This is the only way to achieve symmetry and consistency. Please reconsider your decision, it would be a great usability improvement for us traders if the ask side were grouped the same way as the bid side.

So it won't be changed, maybe would be an option.

Yes, please consider that option and maybe also consider making it the default option (and then eventually you might also consider removing the old option as it makes no sense anyways)

[BitcoinWisdom]

It was talked several months ago, I still prefer the consistency to consider it is break or not.
The graphic looks like[...]
So it won't be changed, maybe would be an option.

Why not shift the price column down by half a line? Then it would look sort of like this


           4900 -
                  653
           4850 -
                  233
           4800 -
                  25
4778.22
                  12
           4750 -
                  63
           4700 -
                  423
           4650 -
                  1024

except that it would be squeezed vertically so that both columns are single-spaced.
[/quote]
The mode you wanted is
---- 4900
|  164 (4850,4900]
---- 4850
|  132 (4800,4850]
---- 4800
| <- Current price 4823
---- 4800
| 78 [4750,4800)
---- 4750
| 122 [4700,4750)
---- 4700
or
---- 4900
|  164 (4850,4900]
---- 4850
|  132 (4800,4850]
| <- Current price 4823
| 78 [4750,4800)
---- 4750
| 122 [4700,4750)
---- 4700
depends on 4850 or 4800 used.
The second mode looks no problem. just the brain need think in other way. the number beside 4850 means the sum of volume less and equal 4850 instead of think it's always the amount greater or equal. or think it is break price instead of axis price.

[BitcoinWisdom]

I still prefer the consistency

But as it is now it is inconsistent, the ask is treated different than the bid. Bid shows correctly the amount laying at the level and in front of it, ask is showing the amount laying behind the level. Traders are normally interested in the size of a "wall" at a certain level and that is the volume at this level including the orders in front of it. "Top of the book" on the ask side is the smallest ask while top of the book on the bid side is the highest bid, the sort order is inverted (relative to the top of the book) and then naturally "in front of a level" means the usage of floor() on the bid side and ceil() on the ask side. This is the only way to achieve symmetry and consistency. Please reconsider your decision, it would be a great usability improvement for us traders if the ask side were grouped the same way as the bid side.

So it won't be changed, maybe would be an option.

Yes, please consider that option and maybe also consider making it the default option (and then eventually you might also consider removing the old option as it makes no sense anyways)

Add option is much more complex. now I've changed it to break price.

[btc6000]

Why is the current price shown actually the last trade that was executed? The current price on a chart would usually be the mid point between best bid and best ask on the order book, and so a 0.0001 trade $10 away from best wouldn't influence the price displayed on the chart.

Cheers,

[prof7bit]

Add option is much more complex. now I've changed it to break price.

Great! This was fast! Get this man another drink!
(sent)

[JorgeStolfi]

now I've changed it to break price.

Thanks! My "vertically shift" suggestion was to format it as follows

except with smaller dots (or dashes) between the two columns...

As for which end of the interval is open or closed: it will be confusing to readers either way, so it is indifferent.

The Salomonic solution is to split orders that are eactly equal to the break price (say 4850) and count half their volume on each side of it (half above and half below 4850).  But this solution may be even more confusing to readers...

However, the criterion should be symmetric around the spread, since one usually reads the asks upwards and the bids downwards. 

Thanks again, and all the best.

[prof7bit]

and count half their volume on each side of it (half above and half below 4850).  But this solution may be even more confusing to readers...

Yes, this would be really confusing. Now if I see

"850 46" I can go ahead and buy 46@850 and eat this wall precisely and completely without anything left.

[BitcoinWisdom]

Why is the current price shown actually the last trade that was executed? The current price on a chart would usually be the mid point between best bid and best ask on the order book, and so a 0.0001 trade $10 away from best wouldn't influence the price displayed on the chart.

Cheers,

I'm afraid not. Also the price will be display on tab title. I think the closing price is better. especially for panic sell/buy.