Yes.  Both you and Cryptopirates rock.  

It compiled file after I installed miniupnpc.

I'm actually feeling pretty happy - I haven't compiled anything from source in... a really really long time.  Thank you both for your insights and help and sorry to waste your time with a question that was covered in the /doc directory (and probably a google search... I didn't try Google because I thought "it just launched tonight, no one will likely have the answer yet" but now that I see that's it's basically the bitcoin wallet with some changes, I could have googled it.

That fixed it.  It was libboost.  So, yeah, it was a dumb question.  

And then I hit a miniupnpc error, discovered that there's a /doc directory with all of the dependencies and kicked myself for not looking harder for the answer before posting here.  Thank you.

Yeah, I did that.

pm:~/StabilityShares/src$ mkdir obj
mkdir: cannot create directory `obj': File exists
pm:~/StabilityShares/src$ make -f makefile.unix
g++ -c -O2 -pthread -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -g -DBOOST_SPIRIT_THREADSAFE -D_FILE_OFFSET_BITS=64 -I/home/pm/StabilityShares/src -I/home/pm/StabilityShares/src/obj -DUSE_UPNP=0 -DUSE_IPV6=1 -I/home/pm/StabilityShares/src/leveldb/include -I/home/pm/StabilityShares/src/leveldb/helpers -DHAVE_BUILD_INFO -fno-stack-protector -fstack-protector-all -Wstack-protector -D_FORTIFY_SOURCE=2  -MMD -MF obj/alert.d -o obj/alert.o alert.cpp
alert.cpp:6:53: fatal error: boost/algorithm/string/classification.hpp: No such file or directory
compilation terminated.
make: *** [obj/alert.o] Error 1


Oh, and incidently, Crytopirates, I'm mining on your pool.  It's going well so far.  As of right now, I'm hashing about 4% of the total pool capacity - which is neat.   Good pool.  I've been watching the stats. 

I'm a pretty new Linux user so go easy on me please if I did something dumb, but I did a git clone from the link above and then ran the 3 commands at the bottom and it ran for a while and came back with this:

m@pm:~/StabilityShares/src$ make -f makefile.unix
g++ -c -O2 -pthread -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -g -DBOOST_SPIRIT_THREADSAFE -D_FILE_OFFSET_BITS=64 -I/home/pm/StabilityShares/src -I/home/pm/StabilityShares/src/obj -DUSE_UPNP=0 -DUSE_IPV6=1 -I/home/pm/StabilityShares/src/leveldb/include -I/home/pm/StabilityShares/src/leveldb/helpers -DHAVE_BUILD_INFO -fno-stack-protector -fstack-protector-all -Wstack-protector -D_FORTIFY_SOURCE=2  -MMD -MF obj/alert.d -o obj/alert.o alert.cpp
alert.cpp:6:53: fatal error: boost/algorithm/string/classification.hpp: No such file or directory
compilation terminated.
make: *** [obj/alert.o] Error 1

This is on Ubuntu 12.04 LTS.

Thanks in advance for any help or advice.

Thanks for the replies.  I think I get it.

Now I hope I understand it well enough to explain it to about 120 engineers tomorrow at noon.

Thanks again

I'm giving a presentation on bitcoins tomorrow and I gave a dry run this morning and I got stuck on one particular question.   I have read the Wikipedia entry, I have read the https://en.bitcoin.it/wiki/Mining entry and I don't see exactly the issue that I'm asking.

If new transactions are arriving all the time, and the longest block is one that is accepted, then it seems like there's an endless treadmill of new transactions arriving while the hash is being calculated - what cuts off how many transactions are in a block?  It seems like you could have so many transactions arriving that no one can ever calculate a hash?

Like I read this entry from this article http://codinginmysleep.com/bitcoin-mining-in-plain-english/


What prevents an endless flood of transactions from preventing the calculation of a block?

Thanks in advance for your patience in answering a somewhat-technical but still very basic newbie question.

rPJBWdhYq1woDZPLsBz8tXoVSaBLSN69Qp

I'll be interested to see it.  I've been looking into creating an FPGA-based miner and I'm not coming remotely close to the $/kh/s rates of ATI video cards.  The salsa 20 core routine wants a lot of high-speed memory, and I just don't see how to get that with an FPGA.  If you rely on the gate-array itself, you can get the raw speed you need but you don't have enough concurrent hashes and if you try to do something like use the FPGA DDR routines to go to a DDR, it's orders of magnitude too slow from a memory throughput perspective.  It's the same fundamental issue that I think all of the FPGA investigations run into.  

I will be extremely interested to see your approach because right now, with a ~$300 FPGA, I'm still ~1/3 of the dollar-to-hash rate that I'd need to be to compete with a GPU... although power looks better.

Do you have any links to jasinlee's project?  I've worked on FPGA's before and I'm curious about his approach.

I ordered one fairly early and I have no regrets.  We'll see how it goes.

An LTC-based FPGA would be tricky and expensive and for equivalent hashing rates, it would be more expensive than a video card.

That's an interesting observation, dhenson.  I definitely had the feeling that the crash today was orchestrated and manipulated, and since it appears to have been successful, once can only expect that there will be more of them.

What I would prefer to see happen is to have the tier 1 internet providers push down rules to requiring the adoption of source IP address verification and disabling of recursive DNS from non-trusted addresses to solve the largest DDoS attacks from happening.  It's long been known how to stop DDoS amplication attacks from happening, so it would be helpful to have the loopholes closed down through the hierarchy of service providers - especially in the US where the most open recursive DNS servers are located.  Markets will always be manipulated, and bots are allowed on stock and fiat currency exchanges so it would be odd - and particularly ironic given the roots of Bitcoins - to disallow their (ie. "pull the plug") on their use in bitcoin exchanges.

Also, it would be really helpful for Bitcoins on the whole that there would be more competition in the exchanges. Or we need our one major exchange to do a better job. I read in the MtGox blog that people don't understand how hard what they are doing is... and that's probably true, but they need to step up their game, and if that costs too much then they need to raise fees to raise money to step up their game. A queue of 19000 people for verification and trade latencies of over an hour isn't going to cut it. So much hinges on MtGox either being a highly effective exchange, or else MtGox having lots of competition. If we keep on course where there is one major exchange that is overwhelmed, then the momentum that BTC has as an alternative international currency will decrease.

We also need exchanges that can reduce volatility by allowing short-selling - people who short currencies (or stocks) have a bad reputation, but they do help substantially with volatility by creating sales during run-ups. Pretty much everyone who has been around currencies (and commodities and stocks) for a while can spot a bubble, and people shorting (or borrowing a currency in order to sell it) counter-act price increases with increasing price sales. Short selling doesn't solve the problem of bubbles, but it definitely helps with decreasing volatility. Until there are some tools for allowing shorting, we will continue to see dramatic BTC <-> fiat currency volatility

I registered so that I could reply to MtRed closing thread in the Pools forum to tell RedditRex that I loved MtRed as a pool, thought he did a great job, and to wish him the best.   I'm a bit bummed about this 4-hour waiting period though.