This is my bet for the weekend dip:

Whoever here has the IP
162.220.65.143
is infected with "morpheus fucking scanner" bot. Requests began appearing in my httpd access log immediately after I posted the 2 images yesterday.

R

Wer ist jetzt noch übrig?

Here is an obscenely bullish desktop wallpaper (for usage as pr0n substitute), concentrating at this multiple times a day for 2 minutes each time will release endorphins and convert every bear into a bull after long enough exposure. I have made it 1024*768 for old laptops, I can make higher resolutions too. 

this looks bearish to me.

I'm starting at the beginning because I'm trying to find the signal below the noise and not the noise itself, and the only signal I could identify so far that seems to be persistent over the entire past history of bitcoin price is something that looks strikingly similar to something that could be modeled as exponential growth.

In the spirit of Gordon E. Moore I might soon be able to postulate prof7bit's law: "Over the history of Bitcoin the number of USD needed to buy a single unit of bitcoin doubles approximately every 4 months"

That's how they are defined (and used everywhere), so that's also how they are plotted. If you shift the plots backwards in time its no longer what a trader would expect to see when he is told that this is a simple moving average (SMA) or exponential moving average (EMA), it would be an entirely different indicator. It would be possible but then it wouldn't be the good old well known SMA or EMA anymore.

Except that the mean is not zero but significantly positive. And thats why i'm just hodling (besides some automated risk rebalancing to convert the randomness into profit).

The github address linked in section 1.3 on sx.dyne.org: https://github.com/genjix/sx/ does not work for me (404)

Otherwise these sx tools seem to be a great project, exactly what I was looking for all the time, why didn't I see this earlier?

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.

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

Heißt das jetzt die Miner werden verkauft, mit oder ohne OK der Anteilseigner? Wozu dann noch die PM mit der Frage? Ich kann die PM nicht beantworten (Anteil verkaufen) wenn die einzige mögliche Antwort lautet: "Ich verkauf die Anteile, mach Du den Preis, ich akzeptiere alles", dann könnte ich sie genausogut verschenken.

Ich verkaufe meine Anteile (lieber auch eher früher als später) wenn ich ein konkretes Angebot höre und das gilt dann aber auch.

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.

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)

As I understand it the complete source of the Mycelium wallet app is on github, what keeps you from reading the portion of the code that is talking with their servers to understand what the server must do and replace the SSL certificate in the code with the one of your own server once you have managed to write one?

Yes, thats what I said. And also what you said in your first post (before you suddenly claimed the exact opposite: "No the API connects only to bitcoin nodes."). If it connects to Mycelium proprietary servers then I see two possible ways to fix it:

* write an open source version of these mycelium servers from scratch by inspecting / reverse engineering the API
* modify Mycelium code so that it can use Electrum servers API instead to query the information it needs

And actually even a third one:

* Mycelium.com releases the source code of the server as open source, so other people can set up servers too.

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.

Huh? you just said it connects to proprietary servers (which is also my understanding) and now you say it connects to bitcoind nodes.

Couldn't it be modified so that it works with electrum servers?