I think you are missing what Foxpup is saying.  Your deposit box being destroyed is no guarantee that you lost access to the funds.  It is impossible to prove that you have no backup of the private key and that anything of material value was lost.  No insurance company (none anywhere, ever) is going to write insurance for an event (that the insured was actually lost/destroyed) that they can't prove actually happened.


You lose.  Of course the odds that a personal safe, safety deposit box, and encrypted archive in the cloud all were destroyed simultaneously is so small that if it happened you likely have bigger problems.

Filing out a SAR or Form 8300 doesn't take 14-21 days.  Sorry.  It is utter BS that is your excuse.  

Six month ago wires were completed in 2 days and now it takes 21 days.  Did you forget how to fill out KYC AML paperwork?  

Furthermore the whole "it is a AML/KYC requirement" has titanic sized holes in it

A) In every delay customer support has been happy to cancel my withdrawal and let me take funds via another method (to include nearly untraceable bicoins).  If the funds were ACTUALLY held for AML investigation, assisting a customer with method to bypass the hold is CRIMINAL.  Period.   As in good way to spend next 10-20 years in a federal prison.  Once might be a mistake, but no way your staff is so utterly clueless on AML procedures to continually make the "mistake" of assisting your customers with methods to bypass an AML hold.

B) In every delay nobody ever contacts the customers.  There are no phone calls, no verification, no questions on the source of the funds.  Nothing.  Just complete silence and a long delay and then the funds go through.  The info you had on day 21 when funds are sent is the same info you had on day 1. 

C) The delay never goes away.  EVER large wire is delayed.  Even if somehow you were doing some investigating (which A&B make a insultingly stupid excuse) one would think that after 3, 4, 5, 10 wires eventually that customer could have funds deposited without delay.  Note I said without DELAY not without reporting.  Yes financial institutions have to file a SAR and 8300.  It takes all of 10 minutes to do.  Hell FinCEN makes it easy now, you can "efile" online.  The need to FILE can't explain why repeat withdraws are always DELAYED.

FILING =/= 21 day DELAY
REPORTING =/= 21 day DELAY
AML/KYC =/= 21 day DELAY
Following the law =/= 21 day DELAY

The process is always:
1) Make request
2) Wait 14-21 days (status "confirmed" = we haven't done shit because we don't have the money)
3) Day x (varies from 15 to 22 days) wire goes through.  No request for info, no verification, nothing.  Just a delay and then funds go though.

Yes multi-sig would work for this and it is supported by the protocol (although incomplete at this point).  However more likely companies would employ similar technology that they do now to protect PKI private keys.  The use of hardware security modules could allow business rules to be enforced at an enterprise level while not allowing any employee to ever have access to the actual private key.  This would decouple access from the actual private key.  Removing employee access could done via normal PKI processes (for example sending access revocation command to the HSM).

I hate to break it to you but miners != bitcoin.  miner != bitcoin user.  miner != only hold of bitcoins.

I hate the term market cap because it is completely wrong.

Notional Amount is accurate but intuitive.  I prefer the term money supply.   The Bitcoin money supply is currently ~9.3M BTC or ~$63M USD.

That wouldn't be in the last year.

I have.  Send an email to support and they can provide you the ABA (routing #).  Not sure why it isn't listed on the website.

Anyways my wire in was easy.  I ended up sending it late (~3PM EST).  Got notification within the hour from the site that it was pending and the funds were in my account the next morning.

Too easy... except he should post the ABA.  My bank allows using SWIFT code but doing so makes it an "international wire" price even though it isn't leaving the US.

There is but you can have it raised if verified.  I think it is 4,000 BTC for lvl2 and 40,000 BTC for lvl3.

It depends on your bank, account type, options, etc.

Some places allow you to do a wire online some reuqire it in person.

You should be aware that for $100 a wire is likely the worst possible way to get Bitcoins.

Your bank is going to charge $20 to $50 for the wire (and "free" personal checking tends to be the worse) and then IIRC MtGox charges a fee (but maybe that is just outgoing wires). 

We probably did lose some potential Dwolla orders due to not having enough available funds.  One thing I would clarify is that while PayPal is the most popular in number of sales ranked by total funds paid it is second to last (only bank wire had less funds paid out).  We paid out over twice as much by Dwolla than PayPal.

PayPal payouts tended to be smaller possibly being used for a specific purpose.  That is one reason why the lowered the limit.

Miners* aren't the most precious "values" (sic I assume you mean assets).   The first mover status has created a whole host of services and products using Bitcoin; that is what creates the value.  That is why nobody wants or need LTC.  That is why LTC will never go anywhere.  Switching to ASICs won't cause blockchain.info or the major exchanges, or bitmit.net or the dozens of wallets, android apps, and other products and services to disappear.


*Before some miner gets "but hurt" as a miner myself the value miners bring is the security of the network.  They allow consensus to be reached and attempted to spoof that consensus costly and futile.  So the network does need miners but that being said 10TH/s is likely MORE miners that Bitcoin needs RIGHT NOW.  I am not saying stop mining but honestly if network dropped to 5TH/s it would have essentially the same level of security. There is no eonomic value in attacking a 5TH/s network that isn't there in a 10TH/s network.  Anyone with the ability to destroy a 5TH/s network can likewise destroy a 10TH/s network.  Currently the level of security significantly outstrips the amount of economic activity that needs protecting.

Alright this i just getting annoying. 

Your personal dick measuring contest with paraipan doesn't belong at the top of the fraking General Discussion forum.
What exactly does your post have to do with Bitcoin?

Even if your right, your NOW wrong.  This is something for meta or the mods.  Nobody else gives a damn.  Please move, lock, or delete.

If you buy 1BTC for 5 USD someone else is selling 1 BTC for 5 USD.

Nothing has changed to the balance.

Before trade
You: 0 USD & 1 BTC
Counterparty: 5 USD & 0 BTC
MtGox total:  5 USD & 1 BTC

After trade:
You: 5 USD & 0 BTC
Counterparty: 0 USD & 1 BTC
MtGox total:  5 USD & 1 BTC

There were days in the last year where 0trades occurred on MtGox?  I find that hard to believe.

Where did I say anything about "should".  Facebook was superior to myspace and displaced it.  If facebook sole claim to success was that it started with an f and not a m it wouldn't have.

Cryptocurrencies can certainly co-exist with Bitcoin and it is entirely possible some SUPERIOR crypto-currency will displace Bitcoin.

You wanting to support another currency has no relevancy on WHY a merchant might choose LTC over BTC.  The reality is there is absolutely no reason to choose LTC which means an rational merchant won't.  LTC will continue to be a pump and dump altcoin scam until it ends up sub millicents per coin like all the other ones.  Why?  It simply has no purpose.

To use your myspace analogy it would be like a smaller, inferior, less popular myspace came along.  Yup myspace would still be on top.





Which is irrelivent to the post you responded to (adoption by merchants).  This isn't a football teams.  There is no reason to cheer for the home team.  LTC has no purpose, it won't ever be adopted by merchants and users in significant enough numbers to achieve a critical mass.  Its sole purpose is to mine it and sell it to suckers before the price collapses.

If any value in the rainbow table produces the same hash as your passphrase for any one of the thousands of hashing rounds that is a collision.  Once a collision occurs any subsequent rounds will always produce identical hashes.  The more rounds in the chained hashing system the higher the potential for a collision.  If the rainbow table has a value which produces the same hash as your passphrase on any round (not just the first round) then the attacker can generate the same private key.  The attacker may never know what you passphrase is.  It doesn't matter.  Same private key is same private key no matter how it is generated.  This is defeated by including a deterministic salt on each round of the hashing function to ensure that hash for one round can't be compared to any other round.   Of course that warning wasn't intended to be exhaustive.  There are dozens of potential design flaws waiting to render a system cryptographically weak.

Simple version:
Don't try to do it yourself because the odds are you will make some flawed decision based on incomplete knowledge.   Anyone other than a cryptographer is best served by using an existing cryptographically strong peer review system (and yes that include me).  I take my own advice.  FastCash4Bitcoins stores all passwords as bcrypt hashes.  

Correct however it is important to use existing systems.  A common mistake is for someone to try and "roll their own".  There are a lot of mistakes one can make which reduce the security and without enough knowledge it is tough to even know you have compromised the security.  For example failing to add salt after each iteration will allow an attacker to construct rainbow tables to reduce the workload.  The attacker doesn't have to match the output of the final round he can match the output of any round because once two inputs collide they will always have the same output on each round after that.



PBKDF2 is a good option because it has been extensively reviewed.  

It essentially does this:

That was only 4 iterations.  PBKDF2 normally does 10,000 or more iterations.  Essentially you are increasing the amount of computational power required to attempt one passphrase and thus for a given amount of computing power reducing the number of pass-phrases that can be checked.  SHA256 (and other hashing functions) are fast ... too fast.  You want to increase the computing time to the max that is viable for your scenario.  For example if you are manually generating a new key once a day who cares if it takes 10 seconds.  Make the # of rounds 100,000.  If your CPU can only has 1/10th of a password per second then a GPU likely can't do more than a 100 pps (passwords per second).  The largest farm/pool/botnet is probably <1 million pps.  Now if you are using this as part of some webservice maybe you can't handle an avg execution time of 10s but you probably can handle 0.01s.  You don't want it to be 0.0000000000000001s that is just making it painfully easy for an attacker.  

Tough day at the ole scamming mill boss?  Crack open a cold one and rant on about the suckers not being suckers and making it easy for ya!


In case anyone is wondering.  Mr "Whats wrong with this place" is upset that nobody was willing to hand over 1,000 BTC to an anonymous person with no skills, no rep, no collateral based on a one line proposal to "join in on the ASICS revolution".

Um I never did get an MBA but I am pretty sure that is how anyone profits in any enterprise.

You already answer it is above (2^256)/(2^160)  Of course that large number is of only academic interest.  160bit or 256 bit neither can be bruted forced.  Not with a single computer, not with a planetary sized super computer (and yes including the effect of Moore's law for the next century).

IF addresses are ever vulnerable in the future it is because one of the cryptographic primitives has become compromised not because of some brute force attack.  In such a compromise storing coins at an address where the public key is unknown to the public (and thus some future generation attack) "could" prevent an attack.  It would depend on exactly which cryptographic primitive is compromised, how it is compromised and how severe that compromise is.


Baring a cryptographic flaw in ECDSA?  Secure.  Unless there was a flaw in selecting the private key (cryptographically weak random number generator) your only option would be brute force.  A far more useful layer of protection for the ultra paranoid would be a hardware RNG where the output is simply not repeatable.