|
...
and $429,496,729,600 by July 2020!
Sweet. I can't wait.
|
|
|
|
too late we already hit i wonder if we'll see it rise to $35, and then everyone instinctively sells off, dropping it again.
That is why my foolproof plan is to sell @ $33.29 (don't tell anyone). |
|
|
|
Here is a short version of a text-to-key algorithm, resulting from a discussion with gmaxwell and etotheipi. I'm currently working on other things, but I hope it can already provide some inspiration. The idea is to have both a variable number of iterations, and a checksum (by not allowing every possible input text). To go from text T to key: - Calculate SHA512(SHA512(...(SHA512(T))), with 256 iterations
- If the 256th iteration results in a hash that starts with 8 zero bits, output the 255th iteration result as key
- If not, do more iterations, until the 512th
- If the 512th iteration results in a hash that starts with 9 zero bits, output the 511th iteration result as key
- If not, do more iterations, until the 1024th
- If the 1024th iteration results in a hash that starts with 10 zero bits, output the 1023th iteration result as key
- and do on ...
So you sacrifice some bits in checksums, but compensate those exactly by more iterations. This way, the seed text itself encodes the number of iterations, and an attacker cannot know the right number in advance, preventing a short way out. A more complex version, with some mathematical guarantees is derived here, but there is little explanation. I like it. Still 256 is probably too small. Modifying the algorithm so the min passphrase is say 2,000 iterations and the average passphrase is closer to 10,000 iterations would be better. Also I think we should move away from SHA-256. With all the OpenCL, FPGA, and soon ASIC hitting the market for massively acceleration SHA-256 hashing using a chained function of an algorithm already massively accelerated seems like steps forward, one step back. Even SHA-512 would be better. Something like bcrypt would be even better. |
|
|
|
It's excellent but: It's presuming e.g. bruteforcing a website where the site effectively rate limits the attempt. His impossible to crack passwork at 1000 attempts per second is only a few hours work on a GPU cracker that does a billion attempts per second in an offline attack. So people should be careful not to carelessly generalize the conclusions there. It isn't presuming a websiting is rate limiting. What website puts the number of login attempts at 1,000 per second and doesn't lock the account after the first billion wrong passwords?  It is presuming that person protecting the passwords actually cares about security. bcrypt or pbkdf2 That is the whole point SHA-256 is TOO FRIGGIN fast to provide any brute force resistance (unless the passphrase is extremely long). bcrypt w/ workload of 10 will slow a GPU down to 10,000 or so password attempts per second. At workload 20 it is more like 10 (no thats no a typo) password attempts per second. Now rethink that carton if a high end GPU is only able to attempt 10 to 10,000 passwords per second? |
|
|
|
|
Hard to believe that someone who registered two days ago and has a token number of posts might take irreversible funds in a no risk scam.
The scammer tag won't do much good. 8 posts? Je will throw away the account, create a new one, and try to scam another quick coin.
Reputation or escrow.
Reputation or escrow.
Reputation or escrow.
|
|
|
|
So a warning to potential victims this has to be a scam (and setting a new low for effectiveness).The OP wanted to SELL BTC and receive Moneybookers, the OP was willing to get only $7 per BTC Someone points out he can get $9 using our site. Hmm $9 is better than $7. OP doesn't use our site and instead is now "sold out". So hee intentionally opted to sell for $7 vs $9? Now despite him saying he needed MoneyBookers to pay a bill he is buying coins and paying with MoneyBookers  So he went BTC -> MB (at >$2 loss per coin) -> BTC? For what purpose? To rapidly lose money?
|
|
|
|
Works now! Thanks
The prior answer was incorrect. It looks like our bitcoind went unresponsive for a couple hours last night. The server kept retrying to connect to bitcoind to get a deposit address. Since bitcoind was up but unresponsive it just seemed "nothing happened when clicking create order". I will add a time out to the order page with a plain English error message to the TODO: list. T The puzzling thing is we have a watchdog which will auto-restart bitcoind if it crashes. Last night it didn't crash until much later. It was simply unresponsive. When it finally did crash (~3 hours later) it auto-restarted and began taking orders again. I think the simplest fix is to have the watchdog check for responsiveness and restart bitcoind when it is unresponsive. Maybe also have it send the staff a text message. Thanks for your feedback. |
|
|
|
Why are people so obsessed with dictionary attacks. It's so easy add something into the passphrase which is not in a dictionary. Just missspell a word. If you speak a local dialect, use some words from that. I doubt it is easy to run a dictionary attack on a passphrase containing bits of Bavarian, Southern Thai or Islay Gaelic.
I think you misunderstand. When we talk about dictionary attack we aren't talking about Webster's English dictionary. We are talking about lists of passwords which have been collected over the years via a variety of methods (stolen password list, old brute forced password hash tables, major hacks, social engineering, keyloggers, phishing sites, etc). I would provide some links but not sure if the mods would approve. A password cracker will use a database of 2 to 14 million passwords which includes misspellings, brands/names, slang, common substitutions (p@ssword), prefixes/suffixes (password123). |
|
|
|
(You'll get a lot better deal than $7 too! ) Um this just in our buy price has been lowered to $7.01. j/k Are you trying to buy or sell bitcoins? |
|
|
|
The forum does have ads. The fair way to choose ads is by selling ad space. |
|
|
|
If u spend the Amazon code before it becomes fraud... do they still neg your acct ?
Yes and they will expect payment to bring it back to zero. Yes Amazon has a collections department. Yes Amazon sells delinquent debt to collection agencies. Yes they will put it on your credit report for even $10 owed. |
|
|
|
you can still wear an indestructable pair of jeans for many years before they fall apart
but the fashion industry works hard to make people think they need be stylish and new stylish clothes
are released every season every year ,and famous people wear them so everyone else wants to wear the latest
very clever ......
Ain't that the truth. We did some spring cleaning and my wife donated almost 20 pairs of shoes which had never be used to Goodwill. Indestructible or not there would still be demand for women's shoes. Now an industructable (and remained forever comfortable) men's dress shoe. Oh forget about it. They likely would be passed down as heirlooms. |
|
|
|
|
Just theorizing but I think most password requirements are worthless and are checking the wrong thing.
Personally if I had a site I would
a) use bcrypt which ensures passwords of 8 characters or more can't be brute forced
b) require passwords to be 8 characters
c) lookup user's attempted password against db of known/weak/leaked passwords and reject it if found.
No need for "Th!s is my @nnoyingly l0ng password333".
"happy clown jumper" all lower case can't be brute forced if protected by bcrypt and isn't on any password list used by hackers.
|
|
|
|
|
Ah. No wonder why I couldn't figure it out. I first assumed it was 0 but then I noticed a delay so I figured it was 1 but that wasn't always consistent. I didn't think of the possibility that "from self" would be handled differently.
So that leads me to my followup question. It isn't possible to "spend" 0-confirm tx with bitcoind? The protocol allows it.
If bitcoind doesn't increment until 1 confirmation it will error out (insufficient funds) until 1-confirm is detected and it it increments.
Thus bitcoind is more conservative than the protocol? I guess this behavior can't be overriden without modifying the source.
|
|
|
|
I would consider a salt to be a "quasi-secret" that doesn't need to be treated with extreme care, but should probably not be posted in public or something. If the attacker knows the salt, he can start building tables before he attacks you, even though it's unlikely that he could get very far with that anyways.
Sometimes salt is used a quasi-secret but that is generally bad practice. A good crypto system is one where you can assume the attacker knows the alogorithm, the salt, the ciphertext/hash, and other details (like number of rounds) and still never be able to crack the secret. If the attacker knows the salt, he can start building tables before he attacks you The purpose of the salt isn't to prevent an attack. It is to prevent the attacker from building a general solution. For example SHA-256 of password is: 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8 however the SHA-256 of "password|192386633" is dc8b776a57bff42900f4c4e345731d4c2addeae4df957c45b06a6c8450cd612a The 192386633 isn't intended to make the passphrase stronger. That is the purpose of the passphrase. The 192386633 is intended to make the hashing of passphrases useless for any other purpose than a specific attack. Even known the salt serves this purpose. Someone who feels that the salt needs to be non-public is either: a) uninformed b) feels their passphrase may be weak and is trying to compensate by adding more entropy via the salt It is possible to produce secrets which can't be brute forced even when the salt is known if the following are true: a) an algorithm which slows the throughput of attacker is used (single round SHA-256 is not secure for protecting passphrases) b) a random salt of sufficient length is used (at least 64 bit but 128 bit is better) c) a strong passphrase is used |
|
|
|
Probably a stupid question but how much space would be needed for a db of every hash and value?
Well "every value" is simply an infinite number. However to store say every passphrase using printable symbol on a standard keyboard (95) up to a length of 20 would be 95^20 = 3.58 x 10^39 records If we assume no overhead and an average of 10.5 bytes for the input and 32 bytes for the hash that would be: 1.52 x 10^41 bytes ~152,356,517,023,630,000,000,000,000,000 1 TB hard drives. The earth has about 1.3x10^50 atoms so even storing 1 bit per atom it would take up roughly a planet sized body. Of course if the user had salt their hash wouldn't exist in your database. To account for every 32 bit salt would require ~4 billion earth sized planets. |
|
|
|
Salt would be a good countermeasure against this type of search and so would a key derivitive function (as opposed to a simple SHA-256) to massively increase the computational requirements.
What is the advantage of using a salt+password over simply using a fully random private key generated by the satoshi client? The salt needs to be stored somewhere, and if you lose the salt you lose the coins, right? Salt isn't a secret. While correct if you lose the salt you will be unable to reconstruct the key since salt isn't a secret it can be sent plain text, given to other people, stored in multiple locations (dropbox, google docs, computer, thumbdrive, printed in safe, etc). Seems more sensible to me to store an aes256-encrypted wallet or private key than a salt.
In many instances it is however then it isn't a brain wallet. Salt is simply a mechanism to add non-secret entropy. It prevents the attacker (like OP example) from attacking in parallel against all potential users (and if Bitcoin becomes popular enough there may be billions) simultaneously. It also prevents a scenario where you passphrase no matter how clever or strong may be chosen randomly by another user and your access to coins compromised. |
|
|
|
|
the site isn't that new but they haven't always been collecting that data. due to the "looseness" of timestamps in bitcoin protocol to get accurate data a node needs to record this in realtime.
|
|
|
|
What would happen if two lucky blocks in a row were found by honest nodes in less than the 10 minute average? At that point, wouldn't the honest network be working on a new block 5 while the attacker is still trying to build a block 4 to attach to his alternate block 3? Wouldn't then the chain split favor the honest network and put mr 51% on his ass for a round, forcing him to reset and restart his attack with honest block 5?
No. It would go like this: 1 Attack-block 2 Attack-block which builds off of 1 3 lucky-guy publishes one here which builds off of 2 4 lucky-guy #2 builds off #3 5 attack-block ignores 3 & 4 and builds off #2 6 attack-block ignores 3 & 4 and builds off #5 7 attack-block ignores 3 & 4 and builds off #6 attack chain is the longest & attacker broadcasts all blocks to the network. compliant nodes re-org to longest chain (attack #7) double spend occurs. The side with 51% of hashing power has a mathematical certainty to end up with the longest chain ... eventually. Given enough time if an attacker has more than 50% of hashing power the probability he will have the longest chain approaches 100%. |
|
|
|
|
On what planet is a Bluray less expensive than a HDD?
|
|
|
|
|
Show Posts
