The difficulty gets reevaluated and adjusted every 2016 blocks.

Gould: The fact that the problem is "hard" is almost a happy coincidence which the system takes full advantage of.  The reason the hashing algorithm is used is because it's answer incorporates the data of the system.  An NP problem would satisfy the "proof of work" aspect, but wouldn't provide any verification about the validity of the transactions, nor would it be unique to those transactions: You could work on an NP problem for 10 years, and then once you solved it, say "Oh hey, I solved this for the current batch that's here right now" when secretly you had started it for the batch from 10 years ago.  It wouldn't verify the accuracy and validity of any of the transactions, whereas the answer to the hashing problem is unique to the set of transactions for that time period, and can't be "faked", thus proving that those transactions are valid.

Ah, right, my calculation was off.  Nevermind then.

My "oldest" transaction is from 7/11 (roughly 6 days ago).  It has 2983 confirmations, which even at a "slow" estimate of every 10 minutes, that was 8 hours ago. :-S  And it doesn't increase when the number of blocks does.

I left out chain because that was the whole "previous hash" part of the block, forgot to explicitly state it.

Also, A coin, block, transaction etc are all concepts. =P When I say "trace", I mean that a coin is nothing more than it's history of transactions, found within blocks.

I'm going into the technical detail here because I want to make sure I have it right before I generalize or simplify things.  I'd also like to incorporate how it works at this core level, because a lot of the confusion I've seen new users have stems from the fact that they don't understand that, and figuring that out really helped me personally.

As for verifications, that's what I thought at first.  However, the "Confirmations" goes up at a very disproportionate rate to blocks generated.  If a verification/confirmation was simply someone burying it in the chain with future blocks, then it would get one confirmation every 10 minutes.  So, The only other explanation I can think of is that the verification/confirmations happen every time someone "checks" to make sure that the block the transaction is contained in is correct (by hashing it and comparing to the target value), which is done roughly once per user on the network (thus, a rapid increase when a transaction first occurs, as it propogates through the network, followed by the very slow incremental increase as new users "log on" and verify the blocks that happened in their absence.)

>.< Yea, I've read the wiki, as well as the PDF/Whitepaper.

*nods*  It's a good initiative, and ANY development in the interest of bitcoins right now is good development.

It's a good temporary solution, and the only drawback I can see is that it requires a different/separate install, as opposed to just being something server-side.  Granted, I can't come up with an alternative either, but it IS a bit of barrier-to-entry for some people.

I'm currently in the process of writing a very concise guide of how bitcoin works for those new to the system and without the benefit of the background in programming I had.  I just want to make sure I have it all correct, so here's my understanding of the core concepts:

Coin: A cryptographically secure "trace" of all transactions back to the generation of said coin.
Block: A cryptographically secure record of all transactions occurring in a (roughly) 10 minute time period.
Transaction:  A publicly announced transfer of ownership of a bitcoin.

The general process for creating a block:

Create a section of memory containing: Timestamp, the previous blocks hash, an integer we'll call "Nonce", and a set of transactions.
Add a transaction to said block which transfers 50 btc to you out of thin air.  Because this contains your bitcoin address, this makes the block of memory unique to you.

Until the solution is found:
 - Check to see if someone's already solved the block.  If so, keep the section of memory in tact, but look at their solution.
     - Check to see that all the transactions are in the block, the timestamp and previous hash are correct, and the hash of the whole thing produces something less than the target.  If so, tell everyone you've verified the block, and start listening to see if other people have verified it.  Once a certain number of people have verified it's accuracy, (120 to be exact), wipe the section of memory above clean and start over.
 - Check for new transactions.  If so, add it to the section of memory above.
 - Hash the section of memory, producing it's "DNA"/Signature (I've found that's the best way to explain hashes to someone unfamiliar with them)
 - Compare this hash to a "target" value.  This is some value that all of the clients agree upon.  If it's less, Shout bingo.
 - Otherwise, increase the value of Nonce and loop.

When reconnecting to the network, you have to download blocks that were solved since you last DC'd.  Each one you download, you verify it, and broadcast whether you found it was valid or not.  This is what increases the "confirmations" count in the UI.


Is the above information generally accurate?  If so, I'll go ahead and finish up my guide (written much more succinctly than this post, I should hope) and post it here for other people to digest.

The original post is, in my opinion, missing out on one subtlety.

The computation isn't "arbitrarily pointless."  The computation being performed is what keeps the system valid.  You're contributing your CPU to the task of making the system itself secure.  The only thing that's chosen arbitrarily is how hard to make that problem (and thus how "secure" and less fake-able to make the network), and that's done for supply limiting reasons.  You're performing a distributed computation, the intrinsic value of which is that it makes the economy more lucrative and viable as a REAL economy.

In order to bring in a little cash, and more importantly support the bitcoin economy, I'd like to offer my services up as a web developer and/or custom software developer (Mainly C#, but I can write in plenty of other languages), payable in bitcoins. =)

Here's my resume:  http://quantumplation-corner.appspot.com

Feel free to contact me here, or through email.  Prices are completely negotiable, and paying with bitcoins earns you quite a significant discount over my usual pricing (there's the "helping the bitcoin economy" aspect )