Yay!  

Is it time for the gifs of bulls and rockets yet?

From an investment point of view, there are 3 types of investors in mining industry:

1. Investors who bought ASIC devices using bitcoin
These investors are pure bitcoin only, they will never cash out to fiat since they believe the bitcoin is the way to go, they will not affect the market price

2. Investors who pre-ordered ASIC devices last year using fiat money
For them, they might want to get the invested fiat money back, since currently the ASIC devices are very efficient, they only need to sale small amount of coin to break even, and then they can keep it running risk free

3. Investors who pre-ordered ASIC devices recently using fiat money
They will get delivery in autumn, by that time, to return on investment is not that easy, they might need to continuously sell the coins until they reach break even, they will put a pressure on the price

We might see much more sell presure on the market when difficulty went enough high this autumn

On spaghetti code, I would venture some advice that has worked for me over the decades. Upon "inheriting" some "old code", that "just has to work", I work on a "parallel" version, keeping the original for "current production" and the new for "eventual replacement".

The "parallel" version is not a "refactoring" or rearranging of the code in any fashion, at least not initially. I worked in C and before that assembler, but I see a lot of C in the bitcoind code!

First one must have all the code "in view" and as much in one's head as possible. And using the best IDE and tools one has, begin to first name things properly. This means everything, from class definitions to instance names, methods, member variables. And very important, no magic numbers, like method_name( argument_variable, 0 ). What is the 0? What does it represent?

For example, I am looking at db.h, ~line 117 in the CDB.Read template area. And there is a magic  ssKey.reserve(1000);
OK what does the 1000 represent? Is it important? Does it matter? Shouldn't it be a
const intergal_type Meaningfully_named_Value = 1000;

I know how it is when one is "in the zone", and coding. Documentation is superfluous and slows one down! And in the 1970s, especially, less so in the 1980s, and basically no more in the 1990s and on, variable names were no longer restricted to 8 or 16 characters, or 32 characters (of significance), etc. And [floppy] disc storage didn't force a lot of "vertical" compression (read K&R style here). Nor horizontal compression (read no spaces between operators and operands here). I see a lot of that "residue" in the code.

Just renaming things doesn't change the executable, AFAIK, in a release build. So I would globally, with a careful global search and replace, acknowledging each replacement, names that are obviously too terse, obscure or no longer even representative of what they are, with more meaningful names.

I have done this with some God awful C chess code, to good effect some time ago. One finds dead code, duplicate globals, etc. etc.

It is tedious but neccessary, and the result will be the same .exe file but the code will start to look readable.

I have had many an argument with "upper management" about spending the time to make a code base readable and where the names truly reflected what they are. Otherwise I am constantly translating with a symbol table in my head, what everything means. I hate that, and I hate having to remember things that I know I shouldn't have to!  Example, what is the instance bitdb, see line 29 in db.cpp rally a class of? Then what is the Class CDBEnv{} really? Is it a BerkeleyDB or a LevelDB, or a ? Of what? Wallet, block chain info? I keep digging, hoping to find a comment or some "action" that might nail it down to something definite. Then I can rename it from bitdb to something more meaningful.

I propose that style of renaming, rearranging, etc. that leaves the executable, byte for byte identical. Maybe then we can see the beauty of the forest thorough the ugly arrangement of the trees. I think the .h files especially need a lot of "work". I see hodge podge lines of extern this or that sprinkled in .h and .cpp files!

I would propose this sort of "one to one transformation" of the code to start with, and then it may become easy to: find the bugs that are there, add new "stuff", enhance old "stuff", etc. etc.

BTW, I am doing it myself, off to the side anyway, since I hate K&R style, and all the stuff mentioned above, and more (LOL)

Ron

What if there is no 33% drop ever again? 

Mmmm.... The market appears to be distilling quite well.

Could this be the bottom? It's looking good, not many would expect the bounce here, but it does appear that people is regaining trust.

You've got a point. It's just crazy watching someone with a lot of bankroll manipulating the market... but I guess that's why I also shy away from high stakes poker tables

Screw the fancy economy talk, where the heck we're going now? 

Other than moving speculation out of the blockchain, and maybe some press, there's not much value added.
I hope they make some $$ but since they are adding zero BTC merchants, what does it add to the BTC economy.  It isn't even the first Bitcoin ETP/ETF

yes this.  you saw how fast that fake $80 wall got pulled

95, IF we break 90 again. right now it doesn't seem like it, especially considering the walls.

never seen chartbuddy talk, but im also a noob

You know where milk comes from, right? You know what those animals are fed, right? You know how much oil is used to support the growth of those crops, right? Then you know how all that stuff is moved around, right?

I predict your first year of mining will bring you 0.45 BTC for each stick you have.
Lets necro this thread in a year and run a regression against the actual difficulty rises.