I've noticed Waveaddicts predictions are ultimately bang on, but it seems everytime he expects a small bump up after a fall, never happens.. I've saw it at least 4 times now, where it just never transpired, I would very very very minorly tweak your thinking along the lines of the heavy pressure downwards (selling) is oppressive and generally never lets it move back up. As well as the up trends never transpire very high either because of the weight of selling keep it down.. I love the analysis, but trading on short(ish) term with it is very very hard to do.. I've given up trying any moves on bitcoinica as it is a horrible money waster, and just concentrated on mid term.. mid term, your bang on.. Keep it up..  Agreed! Very well said |
|
|
|
Yeah, I'm staying out of this. My base price is so far under $1 now that I don't feel compelled to try to improve it at every little move, and I don't want to lose any of the bitcoins I've been able to snatch up from all these little freak outs. Let's bounce off $3.80 or $3.50 or $3.00 or even $1 for all I care. I'm going to try to take a break for a few weeks.
My base price is actually negative because all I have in Bitcoins is profits. And yeah. Bring it on. @Mushoz If short term is too much noise, I recommend simply not following it. And I agree, there are tons of false signals and you will probably lose money if you trade it all the time. The clearest signals are kind of always at the extremes = turning points for mid or long term. Yes, you're right. But at the moment, there's no way for me to know how "clear" signals are. I know the very basics of TA, but that's about it, so there's no way for me to judge the probability of different scenarios coming true. Perhaps this would be a good addition, maybe even keep it for premiums only if WaveAddict would prefer that. But maybe he could add his opinion on each prediction he makes, with how sure he is of that prediction? It doesn't even have to have (a lot of) arguments, because that might cause it to become too technical (although this would be something positive for me as I love learning new stuff!). Even a simple percentage would do. That way we can get a feel of the certainty surrounding each prediction. Also, I have another tip to improve this service. WaveAddict's current premium mails often contain price targets/directions, without any explanation as how he came to those targets/directions. I'm not saying he's just throwing numbers around, as when I asked about it, he gave me the explanation, but I think it would be better if you included the explanation in the premium mail. It will probably even save WaveAddict work as well, as he won't have to answer individuals about that. If it is important that the mail gets send ASAP, an explanation in a follow-up mail could be used. |
|
|
|
|
I feel like he focuses too much on Elliot Wave Theorem instead of the underlying technical indicators, at least in the short term pictures. The Bitcoin market is still relatively tiny, and a single person with deep enough pockets can create "waves" on charts. Elliot Wave Theorem is all about mass psychology in markets, but with bitcoin - at least on short term scales - a lot of moves are created by a single or a couple of people, rather than the mass. There's just tons of noise on the shorter time scales.
Does anyone else feel the same? By the way, please don't take this too negatively. WaveAddict's longer term predictions have been really accurate so far, and while his targets were off a bit sometimes (The 5.6 H&S target comes to mind, but this is understandable, as technical analysis is more of an art than science), the direction of the longer term moves have been accurate so far.
And comparing him with s3052, the two are even so far on the longer time scales. Both initially said we'd be visiting a new low below the 3.80 low we had a while ago, but both switched to a more bullish view from the low/mid 4.xx, although WaveAddict called it out sooner, and you would have profited a bit more if you would have followed him.
From the low 5.xx range s3052 was slightly better. Both initially said we'd be visiting higher prices, but both switched to a more bearish view from the low 5.xx, although s3052 called it out sooner, and you would have profited a bit more if you would have followed him.
|
|
|
|
It's whole line from left to right incl. spaces and special characters. It's logical that it cannot be title or description of topic because those can be dynamicaly changed / moved / remoevd.
The string can be found on the page more than once.I wonder how is it possible that people are complaining when someone offers them free money  Nice. That's using your noodle. I intend to play this game again. Next time it'll be for more money, and it'll be even harder. I actually found it before he posted that, was just wondering how to import the string Thank you very much again! I'm curious. Exactly what process/tools did you use? Deafboy, same to you. The private key redeemer on Mtgox apparently accepts plain text strings as well It generated the private key automatically! I figured it was worth a shot to try |
|
|
|
It's whole line from left to right incl. spaces and special characters. It's logical that it cannot be title or description of topic because those can be dynamicaly changed / moved / remoevd.
The string can be found on the page more than once.I wonder how is it possible that people are complaining when someone offers them free money Nice. That's using your noodle. I intend to play this game again. Next time it'll be for more money, and it'll be even harder. I actually found it before he posted that, was just wondering how to import the string Thank you very much again! |
|
|
|
Ah sorry It was: "Bitcoin Forum > Bitcoin > Bitcoin Discussion" |
|
|
|
Got it! Thanks |
|
|
|
|
I think I found it, I don't know how to generate a private key from the string though :p
|
|
|
|
Validating creates quite a bit of load on the CPU, so it will most likely be bottlenecked by the CPU. A fast connection should easily be able to download the entire blockchain within 30 minutes, as long as the client is well connected with a working uPnP setup. We'll have to wait and see I guess Does anyone know how I can check whether this Pull is included in 0.6RC1? I would like to give this a shot, but I'm not capable of compiling Bitcoin myself. Thanks It was only merged today. 0.6.0rc1 is 1.5 month old. 0.6.0rc4 is 6 days old. It will be included in 0.6.0rc5. You shouldn't run outdated release candidates by the way - there's a reason a newer rc was created: the old one had (too many) bugs. Ah, ok, thanks for the tip! Looking forward to RC5 then |
|
|
|
This is awesome news! A full blockchain download in 33 minutes on a laptop is excellent! Thank you all who made this possible, you've just majorly lowered the bar to entry Note that that is not including the downloading, only processing them - I imported it from a local file. I assume in normal circumstances it will still take an hour or two (and if you have bad luck, a lot more) to download. Validating creates quite a bit of load on the CPU, so it will most likely be bottlenecked by the CPU. A fast connection should easily be able to download the entire blockchain within 30 minutes, as long as the client is well connected with a working uPnP setup. We'll have to wait and see I guess Does anyone know how I can check whether this Pull is included in 0.6RC1? I would like to give this a shot, but I'm not capable of compiling Bitcoin myself. Thanks |
|
|
|
By tweaking some caching settings, a rather spectacular speed increase for loading a block chain was obtained. This will probably end up in 0.6 still.
I pulled #964 for 0.6 this morning. I had played with database settings several months ago and saw no speedup because there was another bug causing a bottleneck. That bug was fixed a while ago, but nobody thought to try tweaking the db settings again until a few days ago. Pieter and Greg did all the hard work of doing a lot of benchmarking to figure out which settings actually matter. PS: the database settings are run-time configurable for any version of bitcoin; berkeley db reads a file called 'DB_CONFIG' (if it exists) in the "database environment" directory (aka -datadir). This is awesome news! A full blockchain download in 33 minutes on a laptop is excellent! Thank you all who made this possible, you've just majorly lowered the bar to entry |
|
|
|
The 38.2% Fibonacci retracement off this sharp move from $5.26 to the first bottom of $4.84 was around $5. So the likely retrace to 5 after 4.84 was probably a wave 4 meaning that we are currently in a terminal 5 which will likely bottom us out in the 4.6 - 4.75 range before we head up in a meaningful correction.
Could have done with that in an email... I get an alert on my phone from emails; but I don't sit and monitor this forum constantly. I am now completely confused. How does the above fit in with your most recent email? I have no idea where I should be now and what I should be looking out for. the previous email still holds since that terminal 5th wave that I talked about above concludes with a big rally afterwards which over time should still get us close to the target area (I would subtract .10 though from the number I gave though) that I talked about in the email. Remember, I want you guys to sell on strength and not in weakness during a panic selling binge which we continued yesterday after the initial sell-off. But, yes I will send my thoughts in email form for now on. I am sorry about that. Subtract .10 from which number? The target given in the premium mail? |
|
|
|
|
I'm not sure if this is a bug, or intended, but the current loading bar for synchronizing isn't really informative. If I launch my client it starts at 99% as if it started with 0 blocks, and is almost done. If it is say 100 blocks behind, it should start at 0%, and increase by 1% for every 1 block downloaded in my opinion.
|
|
|
|
Very good post, and you're right! Back to the initial point then. Except for some very basic stuff, I'm no programmer. But how hard do you think it is to implement a caching feature? I was checking the Bitcoin-qt process, and it looks like most of it's I/O activity was happening to the blkindex.dat file, which could quite easily fit in most people's RAM. Do you think it's feasible to cache that entire file into RAM? Of course, a smarter caching algorithm would be much better, but would also be quite a bit harder to implement. And we have to make sure sudden loss of power won't result in corrupted blockchains. Btw, just for reference, I started writing Armory about 9 months ago when the blockchain was a few hundred MB. I asked the same question, and even built an experimental, speed-optimized blockchain scanner that holds the entire blockchain in memory. It has been remarkably successful for those that have enough RAM, but it's going to become unusable very soon. The blockchain has more than doubled in size since I started, and it's increasing in speed. I'm scrambling to get something in there so that systems with less than 4GB of RAM can use it... Instead, I'm switching to an mmap-based solution which seems to give the best of both worlds. It's treating disk space like memory, and a memory access retrieves the data from disk if it's not in the cache. The nice thing about this is, if you have a system with 8GB+ RAM, it will just cache the whole blockchain and you get the benefits of the original implementation. But if you have less RAM, it will cache as much as it can, and supposedly intelligently. The caching is OS-dependent, but fairly optimized, as it's something that's actually implemented at the kernel layer. The only consideration there is that if you are going to some kind of structured access pattern of the file, then you can "advise" the mmap'd memory about it and it will optimize itself for it (i.e. - if you are going to access the whole file sequentially, it will start caching sector i+1 as soon as you read sector i). The problem with "why not hold everything in RAM?" questions is that with Bitcoin, there is no limit on what "everything" will be. I don't know exactly what the blockindex holds, but there's no guarantee it won't get wildly out of hand -- maybe someone figures out how to spam the blockchain with certain types of bloat. Then, thousands of users who've been using the program for months, suddenly can't load the client anymore. Even with blockchain pruning, there's no guarantees. So, my lessons from Armory were that you should never count on anything being held entirely in RAM. And I like gmaxwell's solution of having a SPV-node until synchronization completes, then switching. I've been pondering this a lot recently, but haven't come up with a good, robust (and user-understandable) way to implement it yet. mmap appears to be the correct solution here (and possibly gmaxwell's solution as well) Any developers of the satoshi client looking at this? I'd be willing to try my hand at a patch if someone can point me in the right direction, but I'm not familiar with the bitcoin client code or libdb (which may need altered if it doesn't already provide mmapability for databases). That implementation sounds fantastic! Exactly what we need. Would be great if this could be implemented, I really think this is quite a high priority. Getting started with bitcoin should be as painless, fast and easy as possible for new users. Good luck with this Notme |
|
|
|
Dissappointing.....
Don't be disappointed. I think on the whole this is a good thing. We're going to solidify a floor and if you play your cards well and you could be sitting on a kick-ass long position in a few weeks.  Not when you already have a PISS poor position already... As usual.. Im tired of trying to make sense of the analysis and constantly getting fucked.. Showing patience only increases my losses Sounds like we need to meet at a bar and talk LOL. Im smoking a joint as we speak, going for a ride on my honda... everything is better on 2 wheels.. Driving/riding while under influence....... Just don't..... |
|
|
|
Dissappointing.....
Don't be disappointed. I think on the whole this is a good thing. We're going to solidify a floor and if you play your cards well and you could be sitting on a kick-ass long position in a few weeks. Not when you already have a PISS poor position already... As usual.. Im tired of trying to make sense of the analysis and constantly getting fucked.. Showing patience only increases my losses Are you a premium member? Should be much easier to trade with those direct trading tips, instead of just analysis. I signed up a few days ago, haven't received anything yet, but that's understandable because there haven't been any good trading positions afaik. Looking forward to those mails |
|
|
|
Are there going to be any premium email in the near future? I'm wondering what the best ways of trading this volatility are Thanks! |
|
|
|
ahahaha. S3052 idiot subscribers pwned
Ehhh? S3052 was right actually |
|
|
|
Very good post, and you're right! Back to the initial point then. Except for some very basic stuff, I'm no programmer. But how hard do you think it is to implement a caching feature? I was checking the Bitcoin-qt process, and it looks like most of it's I/O activity was happening to the blkindex.dat file, which could quite easily fit in most people's RAM. Do you think it's feasible to cache that entire file into RAM? Of course, a smarter caching algorithm would be much better, but would also be quite a bit harder to implement. And we have to make sure sudden loss of power won't result in corrupted blockchains. |
|
|
|
I've been running bitcoin smoothly for months, although now it seems that I can't connect to the bitcoin network and transactions that I've sent aren't going through. At the bottom of the client it says "0 active connections to the bitcoin network" although I do have an internet connection. Tried restarting the client, didn't work. So, what do I do?
Try checking your firewall settings. Maybe something is preventing your client from making connections? And did you install anything lately that might be conflicting? |
|
|
|
|
Show Posts
