I have the Antec 1200W.

I listened to it...I think it's a very interesting question whether money needs to be a commodity (and have some intrinsic value beyond scarcity)...I tend to agree with the notion that "money has value because money has value" (even thought the speaker was suggesting that's nonsense)...interestingly, bitcoin does have intrinsic value beyond just its scarcity.  I'd argue that electronic, peer-2-peer, pseudo-anonymous, free transactions give it an intrinsic value above and beyond simple scarcity.  I tend to think something needs little more mild curiosity to be suitable for bootstrapping into money (and bitcoin has plenty of that).  For example, as a parent of two boys, I've witness the "silly band" economy...my living room has served as a spontaneous silly band trading floor for the neighborhood kids on several occasions.  I've also seen the silly band economy wither at the hands of inflation.

Don't get too frustrated...these aren't the people you need to convince anyway.

What emansipater describes is actually very close to how I look at it.  I initially thought this was a good idea, but TheKid has really good points.  If you promote mining, then people are going to be disappointed with the amount they are actually able to mine.  They'll fail to see the point and bitcoins won't stick.  However, sell bitcoins as a great cross gaming platform mechanism to exchange various in-game currencies and I think you might have a hook for gamers (in fact, I wonder if someone might be able to do well building an exchange explicitly targeted at that).  Not having to deal with paypal fees, etc would be a great selling point I would think (I'm not a gamer, so I'm not totally sure).

You do have good arguments about the need to more widely distribute bitcoins (to trade in bitcoins (other than currency exchange), a critical mass of people are needed that actually have bitcoins and are willing to use them.  I'm promoting it via my facebook circles...in just a couple of days I've gotten three people to give it a try.  They all are excited by the potential.

Also, I think bitcoins may already be reaching a critical mass...the rate of adoption, the appreciation of value, etc all point to an already bootstrapped currency...things may take off from here without anyone needing to do anything extraordinary to promote it.  The value of bitcoin is pretty self evident to substantial portion of people that look at it.  Still, more promotion can only help.

I've enjoyed the profitable vs non-profitable threads (especially the non-profitable one).  Here's my take...mining is marginally profitable.  Based on my calculations, without spending a lot of time doing research to get the absolute maximum value for your penny spent on hardware, if you are assuming difficulty doesn't rise dramatically and the price of bitcoins remains about where it is, you're probably looking at 4-6 months to recover your hardware costs.  But, difficult *is* going to rise...and bitcoins *could* fall in value.  Where I live, I can recover my incremental monthly electricity costs in a little over 1 day, but I live in an area lucky to have relatively cheap electricity rates.  So, you are taking a bit of risk that these variables don't materially change during the time you're trying to recover your hardware costs.  And, you can expect to spend quite a bit of time doing the research, getting setup, and learning all you need to learn to get a high performing mining rig.

Personally, I've enjoyed getting into mining, however now that the novelty has worn off, I wonder if it would have been better to simply buy the dips in bitcoin prices to accumulate...and have spent that time working on offering some kind of service to earn bitcoins or spend the time working on bitcoin related software.

I do in fact have an Antec 1200W power supply...here's the model:
http://www.antec.com/Believe_it/product.php?id=MTc1Nw==

Based on the following thread, it seems I'm not the only one experiencing trouble with this mobo:
http://vip.asus.com/forum/view.aspx?id=20110211072855742&board_id=1&model=M4A89GTD+PRO%2FUSB3&SLanguage=en-us&page=1

I have opened an issue with ASUS.  But the question remains...I'd like to hear from people with a dual 5970 setup with a socket am3 mobo, which specific model are they using?

I was all excited to plug in a second 5970 into my system, only to find that there is apparently a bug of some sort that keeps it from booting (can't even get to the bios screen and no video signal when both are plugged in).  This is an ASUS M4A89GTD/Pro USB3.  Don't not get this mobo if you plan on running dual 5970's.

So, now that I have to get another mobo (and desiring not to be a beta tester for the mobo manufacturers), I'd like to find one that is *confirmed* (by someone actually running dual 5970s) to work.  I need an AMD socket am3 mobo.

It's not a power supply issue...I'm having the same problem with the same mobo and I have a 1200W PSU.  I've seen others on the asus forums with the same issue too.

My thoughts exactly...the value of a transaction has no bearing on the cost to process it...so valuein has should have no bearing on priority.  I think the winning formula is to base priority on a combination of age, fee, size, and time since the last transaction involving one of the accounts in the transaction (to deal with the spam issue).  That last one should be carefully tweaked to better deal with the recent delay issues experienced with slush's pool.  This priority would govern the forwarding behavior of the clients.  In addition, clients should factor this priority calculation into the decision on whether or not to accept blocks.  Blocks that seem to be grossly out of alignment with these priority assessments should be treated with great suspicion.

Holding bitcoin actually is an investment in production, and that's where I believe your thinking betrays you...you view it simply as an unproductive medium, but that is grossly discounts the value that the platform is creating...you are investing in a community (rather than a company)...you are providing that community with liquidity to expand and improve the platform.  It is an interesting question...in a sense you are gaining as society as a whole is gaining...you are investing in something that better unlocks the potential of a community.

Was ot just me or did other people tune out when the original post degenerated into terrible, nationalistic generalizations and stereotypes?

After IRC discussion, I became aware of transaction rate limiting as a means of mitigating the spam problem...I hadn't realized that before, but I think it's a pretty simple solution to the spam problem (much simpler that the proof of work suggestion I made earlier).

I don't agree with eliminating free transactions...in fact, I believe the likely trajectory of things is that transactions will be remain free (I mean just look at all the unprofitable mining that's happening now).  Merchants, exchanges and many others have an interest in facilitating transactions and will always step in to ensure they get processed, even the free ones.  In fact, everyone using bitcoins has an interest in free transactions.  It's a good selling point and a way to attract new users (and without new users, this experiment will fail).  I know this doesn't come as good news to those of you hoping to strike it rich through mining (though maybe there is a future for you in collecting fees from those merchants willing to subsidize the cost of mining).

Other than that, I agree with molecular's other proposals.  I will add that clients need to become smarter about prioritizing the transactions they forward to ensure the p2p traffic remains manageable and clients need to have a strong role in deciding which blocks are accepted and which are rejected (it would be bad if an attacker with a very large budget could buy the resources necessary to dominate block creation and prevent almost everyone's transactions from getting through).

What would stop a well funded, bad actor from using a super computer to create blocks with only a few of it's own transactions in it?  Someone that wanted to undermine bitcoin?  I think it's a very bad idea for the network to not set some criteria regarding transaction inclusion into blocks.

Also, regarding another question (from twobitcoins) about whether there should be free transactions at all: first, I'd say that regardless of fee or no fee, dropped transactions are bad...it opens up a possibility of fraud and it will undermine confidence in the system (see the various postings of people wondering and worrying about what happened to their bitcoins if you doubt that).  It is correct that block generation is not free, but people will pay to get transactions into block sooner rather than later and these paying transactions will subsidize the free transactions and free transactions increase the overall value of the bitcoin network.

As for spam transactions, well, there is already a good solution that was proposed years ago to solve the spam dilemma...proof-of-work.  If you want to issue a free transaction, the network could require a small proof of work for such transactions.  The proof of work required for free transactions could even be linked to the current mining difficulty...the higher the difficulty for mining, the higher the difficulty require for free transactions.  There could even be a correlation between the transaction fee and the required difficulty (such that paying a small amount wouldn't eliminate the proof of work, but might let you buy down the difficulty).  And, you could even link that required fee to the average number of transactions in recent blocks such that a block containing only proof-of-work free transactions would amount to some total (say 50 btc)...so, for example, if the average number of transactions in recent blocks is 100, the transaction fee required to completely eliminate the proof of work requirement on any individual transaction would be 0.50 btc.  If the average number of transactions was only 10, then the fee would be 5 btc/transaction.  Clients wouldn't even forward transactions that didn't have the required fee or proof of work.  People could even offer services to compute the proof-of-work on behalf of users on less powerful clients (for a fee of course...or it could be a part of some larger account or hosting service that a user purchases).

Oh...one other thing...I would think it should be fairly trivial in the client to come up with suggested fees for desired verification speeds based on the recent block statistics...I could imagine a selection list in the GUI like:

   Transaction fee (expected confirmation speed):
       0.00 btc (>4 hrs)
       0.01 btc (~1.5 hrs)
       0.05 btc (~30 min)
       1.00 btc (<15 min)

I think this is a bad idea, possibly very bad...the network has to set the rules regarding what are acceptable blocks and what are not...and with that, what transactions those blocks must include.  If it's easy to create transactions that the issuer can be confident the network will drop, it opens the whole system up to rampant abuse and fraud.  If this were possible someone could easily craft bitcoin transactions designed to be abandoned and use those for payment...a person could obtain some good or service long before the unsuspecting victim realizes what has happened.  This is not a recipe that will engender confidence in the system.

Furthermore, this would put too much power in the hands of miners...it's the responsibility of the network to validate blocks and transactions and to decide what is acceptable and what is not.  Not the miners.  I cannot stress this point enough.  The miners will still have an equal role in setting the market rate for transactions (which is what I think you're after here).  Setting aside the current 50btc payout for blocks, if the predominate fee that people are offering is low enough, there will be little incentive to mine (based solely on the transaction fees)...so, mining activity will plummet as will the difficulty.  I think what you'd find is that it would get low enough that some merchant would realize they need their transactions verified and would press some old spare PC into service to do the mining (with the difficulty being low, it would be a very cheap thing to do).  They would be generating blocks for their own transactions and because of the rules enforced by the network, everyone else's as well.  He would prioritize his own transactions (but would have to remain within the guidelines of the network)...other merchants, needing the same service would either run a miner themselves, or start attaching a fee to their transactions.  And, soon, anyone wanting to see their transactions clear a little sooner than 4 hours (again, arbitrary number I picked) would start attaching a small transaction fee.  Conversely, if everyone is competing to have their transactions verified quickly and bidding up the fee for that, then more people will enter the mining business to capture a piece of those profits.

I don't think it will be a good idea to allow any announced transaction to fail to get processed by the network...the announcement of the transaction on the network should be the act of transacting...inclusion in a block just makes it confirmed and permanent.  I initially thought that some policy of expiring unprocessed transactions would be good, however that would open up the possibility of clients deliberating crafting transactions to fail (in order to get something for nothing).

So, what if both the age and the transaction fee are considered in the priority calculation?  Any transaction over 4 hours (just making something up) old should have priority over any younger, fee bearing transaction, no matter the fee involved.  In other words, transactions under 4 hours old would be processed based on fee first, age second, while transactions older than 4 hours would be processed based purely on age (fees breaking ties I guess...and obviously all the nodes on the network would have to enforce this such that a miner couldn't just ignore those rules).  Under this scheme (after the end of block awards), fee bearing transactions would entirely subsidize the cost of free transactions (otherwise there would be no incentive for block creation).

I don't know what implications this might have on block size limits...I haven't learned enough about the system to understand the importance of transaction or block size limits...if there is a high enough sustained transaction volume, I imagine the block chain would start to fall further and further behind.  Lifting those limits might open the network to DOS attacks but having those limits would seem to create an upper bound on transaction volume and the system would have no choice but to abandon really old transactions that have yet to be processed.

If abandoned transactions were unavoidably a part of the system, I don't think reclaiming those coins is really an issue...at least not at the protocol or network level.  Clients could simply reverse those transactions in their tallies if a certain amount of time has passed without confirmation (such that the network would have flushed it).  The goal of the network would be to never flush any transaction, but if it started to happen (even on a small scale), maybe the block and/or transaction size could be increased...all clients don't necessarily need to retain the transactions inside blocks...they could keep running tallies of bitcoins in various accounts and validate/digest each block as it comes through (maybe with a small tail to handle the case where blocks occur close in time to each other).  You would still want to have a number of super nodes keeping the full history (and making all transactions available to peers as needed), but you would eliminate a lot of storage requirements on a lot of nodes without losing their important block validation role.

But, you are completely ignoring the question of how much it is expected to increase.  With bitcoin, once all coins are mined (which won't be for a long while) and once it has reached a point of saturation (note: that may not mean everyone uses it or even a very large percentage of people use it), it is expected that it will experience deflation due to coin loss and/or continued adoption.  I'd argue that the returns you could expect from such deflation would fall far short of other investment opportunities that would be available to you.  Holding it would be viewed more as a savings activity than an investment activity (much like gold and silver holdings are savings, not investments).

"keeping all your wealth in currency" ...well, that would be a really, really dumb idea.  Keeping all of your wealth in any one thing is a never a good thing.  Any financial planner preaches diversification.  What you describe is no different than keeping some of your wealth in land, gold, silver or just about anything else of value with intrinsic scarcity (something almost everyone does).

If bitcoin was widely used, then the wealth that you did store in bitcoin is effectively an investment in the overall economy.  It's a bit like investing in the S&P 500 (though it would be an even better proxy for the overall economy).  However, it's unlikely bitcoin will reach that great of a penetration any time soon (nor is that necessary for bitcoin to become very successful), in which case holding btc is like investing in the bitcoin oriented subset of the overall economy.  To the extent that the bitcoin economy is growing, such an investment would do well...to the extent it isn't growing, it would not do well.  Eventually, the bitcoin economy would stop growing as it reached a certain level of penetration, at which time bitcoin value would stabilize and not be a very attractive investment relative to other investment opportunities.  One shouldn't confuse the use of a commodity as a store of value with its utility as a medium of exchange.

I personally would never use such a service if I knew that anyone else had an ability to decrypt my wallet.  I think people should be required to take the steps necessary to remember (or store in a safe somewhere) their wallet password, it's the safest practice and protects them and the services that hold very valuable data.  The UI could make this very clear to the user (if they lose or forget their password, their wallet is gone forever).  Note, I did think about schemes for splitting up an encrypted form of their password and storing it on three separate services...or using the public key of three different such backup services to encrypt the key so as to require the services to coordinate with each other if recovery is necessary.  I think something along those lines might still be possible, but could be added later if really needed, but I would absolutely design it to be optional and come with disclaimers and warnings that you are giving people a means of accessing the contents of their wallet by sharing such information.



Prompting on every send wouldn't be necessary (though for extra security one could set an option to require it).  Password entry would occur only on startup and a hash of the password stored in memory (rather than the user's raw password).  This password hash could then be used for everything...deriving one hash for encryption of the local file and through coordination with the backup service to get a different salt and hash for encryption of the backup copies when necessary.  The user would not need to enter the password again as long as the client remained running (and when the wallet eventually is properly separated from the client and UI processes, one could shut down the wallet when not in use (or it could time out) yet keep the client connected to the network and validating transactions, etc).

Btw, I meant to mention I can help with the coding (my IRC handle is gasteve) if you want help.  I do think getting this right is essential and would make it easier for lay people to have confidence in storing substantial sums of bitcoin in their wallets.

P.S. The client should also verify backups after uploading by re-downloading, decrypting and validating the contents.  And the ability to backup to two or more services should enabled in the client (for extra redundancy) and perhaps even the default.

I'm very interested in this feature...if you upload the RSA key pair and the encrypted AES key, wouldn't the server then have everything necessary to decrypt the wallet?  That wouldn't be good.  Here's what I think I would do:

First, I think support in the official client for a wallet backup is an absolute must have.  From a user perspective, they would fire up the client, enter info once for a wallet backup service provider, all the encryption would be done in the official client (only strongly encrypted wallets are ever sent to the backup service provider).  The user should only have to enter a domain name for the backup service of their choosing (I'll leave the design for billing out of this post for now...mainly because I would hope this service would be offered for free initially while bitcoin is gaining in popularity...but also because I haven't given it any thought).  Once the user enters the domain name for the service of their choice, it'll contact the service and get some unique id for the backup (this id would be used for recovery and the user should be instructed to keep that id in safe location in case they ever need to access the backup for recovery purposes).  I suggest just using an id so that the service doesn't have to implement any account creation and such and the user doesn't have to go through that process (however, another alternative would be to use a users email address and doing email confirmation...that would minimize the risk of a user forgetting an assigned backup id).

Now for wallet encryption.  I would ask the user for a password and enforce some basic minimum entropy and password strength.  You then take the password and apply a crypto hash with a salt (i.e. sha256) to yield a derived password of say 24 bytes in length.  This is the key that will be used to encrypt the wallet with AES-256.  The encrypted wallet is transmitted to the server using SSL (which uses public key crypto).  The server could encrypt once more for storage on disk (in case someone gains access to the files on the server).

The client would automatically backup to the server every time a new bitcoin address is created (prompting for the user's password if they haven't already entered it, but remembering the server and id/email details).  The user's password would never be stored on disk.

Recovery would require the server assigned wallet id (or email address) to retrieve the backup wallet and the user would need to support their password (which would be hashed to get the AES-256 key for decryption).

Note: I do realize that hashing their password with a salt doesn't really add much additional protection against a brute force password attack if the attacker knows the salt and the hash algorithm (note, for a bit of extra security, the salt could be obtained from the server and be different for each account...an attacker would need to know what salt generation method the server was using).  If the attacker doesn't know the hash algorithm or salt, then the hash ensures a longer, and hence more secure, encryption key.

For even more security, the user's password could also be hashed on the client a second time (different salt) and that hash used for authenticating the user with the service such that someone else couldn't obtain download access to a user's encrypted wallet (keeping an encrypted wallet out of untrusted hands being one additional protection against a brute force attack).

One possibility I thought about, but discarded was to use GPG auth for authentication with the service and for securely storing a long, generated AES key on the client machine.  However, this has the disadvantage of relying on the local storage to keep the keys necessary for authentication and decryption (and then you would need a backup solution for this file as well!!!).

Note, the locally stored wallet should also be AES-256 encrypted on disk...the same password (with hashing and salting) could be used for the encryption key.  This would enable the user to enter one password on startup to decrypt the local wallet...and hash into a key for encrypting the backup.  The user's password would only be in memory temporarily for generating these hashes (thus reducing the risk of stealing this password out of memory...though the hash used for backup encryption would still be in memory).