Bitcoin.  Meni posted a whitepaper of confirmation security.  For most transaction values 6 confirms is an overkill.  Satoshi never indicated 6 confirms has some magical significance.  Merchants should set confirmation policies based on the likelihood of an attack and the potential value lost if an attack is successful. 

We only require three confirms.

There is no benefit to doing so.

Difficulty only adjusts every 2016 blocks and is based on the timespan between the most recent block and the block 2016 blocks ago.  The network targets a 10 minute average so this span should be 20,160 minutes (2016 * 10).  If the timespan is longer or shorter than 2016 difficulty will adjust to whatever difficulty would have resulted in a 20,160 minute span.  Difficulty adjustments are capped at 25% and 400% of prior difficulty.

So a group of miners "could" do this however they would lose 100% of revenue when not mining, and only decrease difficulty by the percentage of miners who decide not to mine.

As an example say 20% of miners decide not to mine the last 20 blocks.  Due to only 80% of the hashpower working on the last 20 blocks, those blocks on average would take 12.5 minutes each ( 10/0.8 ) or 250 minutes total which is 50 minutes more than normal.  Everything else being the same, the 2016 block period would take 50 minutes or 0.25% longer than expected. Difficulty for the next 2016 blocks would thus be 0.25% lower.  All miners (even those who didn't stop mining) would earn 0.25% BTC more in the next 2016 blocks, however the cost for the "abstaining miners" would have to forfeit 20/2016 = ~1.0% of their revenue. The "abstaining" miners would lose 0.75% of their gross revenue to ensure the continual miners earned 0.25% more.

Miners might as well trade $20 bills for $5 bills it would be just as effective.

Dwolla should show up in your account almost immediately.  Verify the correct dwolla ID is on your FC4B profile.  If funds haven't already been posted to your dwolla account send an email to info@tangiblecryptography.com with all the info you have in the post above.

Possibly but it will never happen.  At best a government would launch something "like" Bitcoin but with implicit user tracking, tax reporting, mining done only by central bank, unlimited coin minting, etc.  That crippled currency would be no better than existing fiat and that is why MintChip was a non-starter.

Governments are all about control.  Bitcoin is freedom.  I find it unlikely any government would ever give the power of money back to the people.  If they do then great we won.

That is not true.

0-confirm tx can be double spent by a mere race attack.
0-confirm tx can be double spent by a Finney attack.
A confirmed tx can be double spent by any significant % of global hashing power although as the number of confirmations rises the probability of success greatly declines.  At 6 confirms for example someone with 10% of global hashing power only has a roughly 1 in 10,000 chance of successfully building a longer chain than the rest of the network.

So let me get this right you honestly think that if I legitimately hack into your PayPal account I can send money to myself and there is nothing you, PayPal, or your credit card can do?  Really?  I mean does that even seem plausible to you?

So
1) you go on vacation
2) I hack into your PayPal account
3) I send a gift of $20,000 from your PayPal account to mine.  Your PayPal account doesn't have a $20,000 balance so PayPal charges $20,000 against your attached CC.
4) I use the "super-duper-hacker-auto-win-open-close" system (I = the person who hacked your account opens and closes a dispute against myself).
5) You come home and realize a $20,000 charge on your VISA card.

You honestly think that no dispute is possible?  PayPal will just say "sorry man the hacker used the super duper method we are incapable of reversing the transaction.  So you hang up and call VISA and they say "oh man PayPal you say.  Sorry you can't charge back PayPal funding even if it is fraudulent".  See is says right here in the Credit Card Reform and PayPal Control Act of 2011.  By federal law your credit card dispute rights are nulled if and only if a hacker does the "super-duper-auto-win-open-close" method.  It is actually the only loophole to your consumer protection rights. Had the hacker done anything else we could help you but sorry this fraudulent transaction is now valid.  Please make a payment on your credit card.  The min payment is $100 and 29.99% interest will accrue on the $20,000 balance until paid.

Really?  Have you thought about this for a second?  Forget Bitcoin, PayPal would be the best irreversible payment system for hackers all over the world.

Of course there is
a) use a stolen/hacked PayPal account
b) use your PayPal account and simply claim it is stolen/hacked.
c) bypass PayPal and chargeback using your funding credit card.  When PayPal loses the funds they will reverse it as well.

There is absolutely no method which is immune to fraud using PayPal.  None.  
Use PayPal if you trust the counterparty, otherwise don't.

Honestly I would have.  I respect Roman for shutting the exchange down when he knew his account was being closed but 24 hours of trading would have allowed those willing to take a risk on ACH withdraw to buy from those who wanted BTC at any cost.  A potential win-win.  I have no doubt bitfloor will payout the full USD balance so I would have gladly sold BTC .... for a 5% to 10% markup.

The last time difficulty adjusted downward was 8 adjustments (~16 weeks) ago .  The "stairstep" line in the graph above is the difficulty adjustment.

As indicated above difficulty only adjusts every 2016 blocks.  So if you are looking at the current hour and saying "the network is too slow" well you are just looking at variance not a change in hashing power.

At 10 minutes per block, 2016 blocks should take 20,160 minutes (or 15 days).  None of the 7 prior difficulty adjust periods took more than 20,160 minutes thus the average number of blocks per hour was >10 minutes thus difficulty rose.


Every 2016 blocks the network looks at the timespan between the last block and the block 2016 blocks prior.  The target is for that timespan to be 20,160 minutes.  The network then computes the difficulty that would have been necessary for the prior 2016 blocks to meet the target and adjusts the difficulty to that.  Say at the next adjustment the timestpan between the current block and the block 2016 blocks prior is 19,152 minutes and difficulty is 8974296.0148879 then the new difficulty is 5.26% higher ( 20,160 / 19,152 ) = 1.0526.  8974296.0148879 * 1.0526 = 9446627.38409252.

Yes.  However I would recommend against "playing around" with money given that my understanding could be incomplete.

In your example backup A had 100 keys in keypool, you then added 400 new ones, then used the oldest one.  The keypool is actually a key queue the keys are used in sequential order.
So even if the current copy was lost "backup A" cointains the "used" key plus 99 more. 

Still as CIYAM indicated anytime you make changes to the wallet I would strongly recommend making a new both before AND after the change.  I would also strongly recommend you backup system be automated AND not replace prior backups (i.e. have date of backup in filename).  A decent sized keypool combined with good backup procedures should make the risk of key loss negligible.  If you are still paranoid using pywallet you can dump the keys from the keypool and print them out as an alternate backup method (would allow recovery even if wallet became corrupt and backups corrupt as well).

6 confirmations.

you can check for your transaction here:
http://blockchain.info/

just put either the transaction id or the deposit address into the search box.

Most "defense" software (anti virus, anti malware) work on signatures.  It is a constant battle between hackers exploiting new vulnerabilities and anti-malware software adding those new malware to their detection libraries.  No defense software is 100% effective against 0-day threats.  Never had and never will be.  Now you should still use it but it should be the last line of defense not the first.

Regarding java.  Yes it is horribly horribly insecure.  If you run an untrusted java app the attacker can do just about anything he could do if logged in directly on your computer.  If you have java uninstall it completely now.

Agreed I have long since given up on Java.  I won't install it on any machine and won't use any site/app which requires it.  Until Oracle starts taking security seriously it is too much of a vulnerability.  Java + bitcoin = "please steal my coins".


The encryption method is AES with a 256 bit symetric key.  The key is derived from the password by hashing the password with SHA512 a dynamic number of times (~10,000 on average 2012 computer system) using the EVP_BytesToKey function from the OpenSSL library. The number of iterations varies because the wallet will do a quick benchmark first a pick a high number of rounds that can still be completed in <1 second.  The faster your computer the more rounds are used in the key derivative function.  Every time you change the password the wallet will run the benchmark again.  This ensure the algorithm will keep up with the effects of Moore's law.  If you get a new faster system for maximum security change your password.

Not necessarily.  The QT client only prompts for password when performing an action which requires access to the private keys (normally signing a message or sending bitcoins).  This is intentional to reduce scope where password can be grabbed.  Launching the client to check your balance for example doesn't require access to the private keys and thus the client won't prompt to decrypt the wallet.

There is no backdoor to the encryption.

So there are a couple of possibilities:
a) user's wallet was not encrypted or was unlocked (recent transaction) - unlikely but possible
b) user's wallet had a weak password
c) user's computer was infected with malware keylogger
d) user re-used password on another site (which was compromised)
e) user re-used password on another site and it was stored in a password utility like lastpass which itself wasn't encrypted

I am thinking c is the most likely but without specific details we may never know.

I do think it would be a good idea if the bitcoin program directory (not to be confused w/ datadir) had a file (say paths.conf) with two options:

This would allow someone for example to put the datadir (everything but wallet.dat) in one location and the wallet.dat in another location (like removable usb drive).  

These values should also be able to set from the GUI. 

A cautious user could physically remove the usb drive when not conducting transactions.  This would require some refactoring of the QT client such that it can "run" (connect to network, download blocks, relay transactions, etc) without access to the wallet.dat.  When access to wallet.dat is restored (user inserts usb drive) the client would need to be smart enough to recheck recent blocks in an intelligent manner.

Highly volatile long term asset appreciation.

Er that is 5 words.

Bitcoinity has various backgrounds/effects which are displayed based on triggers.  I haven't seen the Matrix one yet.  Something in the data (volume, price action, etc) must have triggered it.

There is no vulnerability or security flaw.  Maybe Bitcoinity should have a "? WTF Just happened" link when those special effects occur.

Asset goes up = bubble inflating.
Asset goes down = bubble bursting.
Obviously those are the only two states possible.

I wonder if they apply the same definitions to the stock market as well.

The later.  keypool sets the size of the keypool.  The wallet will create as many keys as necessary to achieve the keypool size.

If the wallet is encrypted the additional keys will not be created until the wallet is unlocked.