Each bitcoin is currently divisible to 100,000,000 parts with the current software. If divisional granularity every became an issue the extra bit could be used to signal extended range.  This would be a simple, technical, and economically neutral change if it were ever required.

People who have invested resources and money into bitcoin did so with certain understanding and expectations of the dynamics of the system.  Your proposal would rob them of the expected return that was rationally factored into their decision.  Even if you'd benefit this time what reason would you have to expected that the _next_ change wouldn't rob you?   

There are some invariants in this system. Mess with them and you will completely and justifiably destroy all confidence in it. Other decisions are justifiable and are worth exploring but they should be explored in alternative systems (like beertokens) rather than by destroying this one and salting the earth for all similar systems.

Er. More than one.  You end up with a byzantine generals problem in determining that a situation exists which requires the higher difficulty.  Normally we solve the byzantine generals problem  by using the blockchain, but in this case we'd need to secure the blockchain a blockchain and we'd have infinite recursion.

Indeed, I missed the strlen()*  bit.  So 401 rounds for 8,8... Which is actually somewhat slower than crypt_md5 is for me. Hurray.   Sorry for being a bit quick to criticize on that point.

But yea, random salt is important.  It would be more accurate to call your "secret_salt" a "password key" or something like that, calling it salt promotes the misunderstanding of what salt is that results in people not using random salt.

At 25 rounds of your function you are less secure, computationally wise, than the FreeBSD crypt_md5 used by MTGOX for most of the passwords (which uses 1000 rounds).  Yours is only so terribly slow because your implementation is slow— passing through the interpreted language for every round.

Using the not super well optimized SHA-512 code in OpenSSL gives me 1,595,914 iterations of the whole algorithm per second on a single core of some 2.6 GHz i7.
(On 64bit systems SHA-512 is faster than SHA-256, and our miners that do most of 2x SHA-256 get 1MH/Core/GHz, so this sounds perfectly reasonable)

You're also failing to use per-user random salt, which means that an attacker with multiple versions of the user's password field (e.g. captured over time) will get an N-fold speedup from being able to hash once and compare multiple times.

So, in short, you've screwed up. Your failure to use standard functions left your security worse off than it would be using the decade old crypt_md5.

Unless you're a cryptographer you shouldn't be writing your own cryptographic functions.

Nope.

TXN 1 pays 200 BTC fee plus 1000 to TXN 2 and the rest back to owner, TXN 2 pays 200 BTC fee 700 to TXN 3...
and so on, enough to pay for the race and then some.

The TXN use nLocktime to spread them out and pay for the complete fork all on their own.

No, it doesn't have anything to do with the _number_ of transactions.  The effort required to secure the network comes from how beneficial reverse&respend and transaction denial of service of service attacks are.

So this is related to the market cap of bitcoin and how easily someone can make irreversible transactions using bitcoin.

Unfortunately since we have single parties bumping 40% hashpower at times (and pairs of parties >50%) we're not actually doing very well on the security front right now.  It would be hard for an outsider to attack the network, but by compromising someone in control of a lot of hashpower attacks could be accomplished easily within the system.

Not mentioned here is that fact that dozens of MTGOX hashed passwords were quietly disclosed on a hash cracking forum on Fri Jun 17, 2011 5:21 am
(http://forum.insidepro.com/viewtopic.php?t=9124&postdays=0&postorder=asc&start=75&sid=1a9e31567fe815c0eea63c40c39fb707 post by "georgeclooney")

Since the overwhelming majority but not all of the hashes match the mtgox database that was posted on this forum (now deleted) and elsewhere I suspect that this post may have been generated from an earlier dump than was disclosed on the forums and everywhere else after the big event.

This appears to be significantly ahead of the prior claimed breach, and is consistent with the great many other mtgox users claiming that their accounts were robbed prior to the big event on Sunday, which I believe would have been too early to be results of the mtgox database leak according to the official timeline re: auditor compromise.

Today the bitcoin client can work over Tor, but it can't connect to nodes which exist exclusively in the Tor cloud except manually. When using tor your node will just connect to regular internet nodes via tor.

This means, e.g. that while running bitcoin over tor can protect your privacy it doesn't help secure bitcoin against ddos and internet filtering attacks, because tor hidden nodes can't play much of a role.

To fix this bitcoin would need to know how to connect to onion addresses and how to share them with other nodes.

Fortunately this can be done without changing the bitcoin p2p protocol.  Bitcoin already shares addresses in IPv6 form. Fortunately the onion address space is already 80 bits and there is already a widely used mapping of onion to IPv6 called onioncat: http://www.cypherpunk.at/onioncat/wiki/OnionCat

To support this bitcoin would need to know to pack and unpack onion hostnames to onioncat IPv6 addresses, and would need to know to only attempt to connect to them via the tor-socks-proxy.  It would also be useful for it to know how to have a tor-proxy used only for onion while the rest of the connections use the public internet.

Is there any reason that this wouldn't be a good way of handling this?

Will it?  If they don't create more coin than exists— they actually have the assets they are loaning out— then there is no fraction-reserve.

IIRC intentionally selling a stock you can't deliver on is unlawful in the US (because it can be used to glut the market and crash the price of things pretty much at will).

They could also make their input addresses automatically public by using the type-2 deterministic wallets I described in another thread, but I don't think thats enough. We'd need to know that the sum of internal account balances is not greater than the sum of real coins held. I think that can only be solved with auditing.

The concern we should all have is that undisclosed fractional reserve practices on the part of major exchanges have an inflationary effect on the whole bitcoin economy.  If you use bitcoin and a major exchange engages in this practice you are harmed even if you never use the exchange personally.   You might not be the victim of a bankrun, but you will be harmed by the decreased value of bitcoin when you use it.

Since we know that more was removed from Mtgox than they were previously claiming (http://blockexplorer.com/address/1Q9ET7WzGaxkGnxMhffJnUGb1BT4m9KqVe see Kevin's post) and it's clear that mtgox's daily float requirements were far smaller than their balance (e.g. the >400k wallet) is there now a risk that mtgox will go back into operation with effectively fractional reserve, thus artificially inflating the supply of bitcoin?

They can only do so within their exchange, but thats by far the most economically significant place to create inflation.

How can the bitcoin community be confident that exchanges aren't doing this?



 

I reviewed your code and noticed that you were using an effectively unsalted scheme which would have been a security embarrassment to the project had it been deployed.  I read this entire thread before commenting. I apologize for not having the chance to read other forum threads which were not linked in the original post. I think its unfortunate that you believe I added nothing to the discussion.

I do see now that you made the incorrect claim that using the address as the IV prevents bruteforce attacks on the pull request— I missed it before because I only looked at the line by line comments.   Sadly using the address as the IV does almost nothing to prevent dictionary attacks.  I can still precompute the 1000x SHA-256, so what is the point of making this computationally hard when it can be trivially precomputed and shared between multiple stolen wallets? Each precomputed password requires only a single decryption to validate.

Here I mean precomputing the result of the 1000x SHA256 so that the marginal work is zero to try it on a new wallet.  As the software is currently implemented I can precompute the SHA256x1000 of the top hundred thousand most likely passwords then reuse it over and over again on many wallets. I could also construct disk-space compact tables of _all_ sufficiently simple passwords as exist for other unsalted schemes.

The current system is unsalted for all intents and purposes (there is something passed in as "salt", but it's a constant, so it doesn't do anything useful except make the hash different from other 1000x SHA256 EVP_BytesToKey users). This is pretty bad, in all cases it gives the attacker a speedup proportional to the number of wallets they can steal on top of the speedup they get from using a GPU farm.

If you're not going to change schemes, at least encode the iteration count in the file and turn it up so that it takes, say, 100ms when the password is set. Or failing that, at least pick something that takes 100ms on your own machine. CPUs are doing roughly 4 million SHA-256 per core per second with optimized code.  This could easily be made 100x harder without making it unacceptably slow even if nothing was done to address specialized hardware speedup.

Yes, of course the "top 1000" passwords are toast regardless. But hopefully giving good password advice, as Gavin suggests, prevents any of the top 1000 from being used. I'm more concerned about the "top 100000", which can be harder to eliminate with good password advice, and slowing down the attack by a factor of 100+ would make a material improvement to the effectiveness of these attacks.

Also, part of the purpose of wallet encryption is herd immunity:  Causing people to not bother writing and distributing wallet scarfing worms because they don't expect it to pay off.  So even weaker passwords get some increased protection from a scheme that makes harder passwords unreachably hard.

Encrypting only the high entropy part of the keying material sounds like a good idea idea to me. It sounds like a free boost to the complexity of checking a candidate password.

In light of the extreme crappyness of the mtgox passwords I think the hardening in the encrypted wallet branch is woefully insufficient. EVP_BytesToKey's 1000 rounds of sha256 is similar in computational complexity to the freebsd MD5 used for mtgox when run without special code on cpus and such tools slice through the mtgox password file like butter.

We already know that GPUs can do hundreds of millions of 2xSHA256 per second.... Having to do 1000 SHA256 to test a password is no big deal.

The salt also appears to be _constant_ unless I'm misreading the patch. Instead it should be per-user and saved in the wallet. Otherwise someone can simply pre-compute a ton of possible wallet keys for use against thousands of stolen wallets.  They could even make a nice wallet rainbow table using the same gpu cluster they originally bought for mining.  I think this is a CERT announcement level weakness and must be urgently fixed regardless of the other points I'm raising here.


I'd suggest instead that it be changed to use

A = scrypt(salt||password, 4 seconds)
key = scrypt(A||password, 10ms)

and simply save A in mlocked memory so that the high delay only happens the first send during a bitcoin session. (the second step could just as easily be BytesToKey if you want... it's just there to make searching memory of long running daemons unprofitable)

(see http://www.tarsnap.com/scrypt/scrypt.pdf and the implementation at http://www.tarsnap.com/scrypt.html)

Considering the mtgox passwords if this isn't done then it will still be _highly_ profitable to write wallet stealing worms unless the strengthening is made very strong.

ECC != RSA. You only need as much data is in a private key to create one.

I've discussed this enough on IRC that I thought I ought to put it someplace more lasting.

Bitcoin really ought to offer and default to using deterministic wallets.   The additional security of the current pre-generated ones is fairly small considering how most people use bitcoin and the liability of harm due to insufficient backups and increased pressure to keep a single wallet online is enormous.

What is a deterministic wallet?  It's a wallet which you can backup once and it stays backed up forever because all future addresses are determined in advance. It can also be stripped down to a very small size which could be easily backed up on paper (e.g. with a QR code). This is in contrast to the current non-determinstic wallets where the keys are random but are precomputed ahead so that you're safe only if you backup at least every 100 get addresses or sends, and which grow large and harder to backup on paper over time.

I've found the backup behavior of the current wallets fairly difficulty to get even moderately technical people to understand. The current system provides enough safety to encourage complacency but not enough to make complacency acceptable.  The positive side of a non-determistic wallet is that it becomes "unstolen" over time but people are frequently reusing addresses and attackers will not act slowly regardless.

There are two types of deterministic wallet I'd like to discuss. I'll call them type-1 and type-2.

Type-1 is the most obvious kind:

The wallet stores a large random seed  S (which can be encrypted if the user uses wallet encryption)

Privatekey(type,n) is then simply set to H(n|S|type)  where H is an acceptable secure hash function and type can be set to different values for change addresses vs displayed addresses (so this distinction is preserved even if new wallet metadata is lost).

The system would generate some (maybe 1000 of each type) addresses ahead of the furthest it has observed on the network but only bother to store the addresses. The keys can be regenerated as needed.



Type-2 is a bit less obvious and understanding it requires you to know about a property of ECC keys, roughly:

A_public_key = A_private_key*point

Which means you can do:

B_public_key = A_public_key+B_secret*point
and have a new key which has a private key:
B_private_key = A_private_key+B_secret

So a type2 wallet stores:
Master_private_key
A large Random_seed S.

and keys are given by

Privatekey(type,n) = Master_private_key + H(n|S|type)

which works just like a type-1, the advantage of the type-2 is that you can separately secure the Master_private_key, but still generate new addresses with
Publickey(type,n) = Master_public_key + H(n|S|type)*point

This means that a e-commerce site could have the front end webserver with access to the public key and S, and someone who hacked the server could violate the confidentiality of the addresses in use (because he could enumerate all past and future addresses based on an infrequently changed public key) but couldn't actually steal any of they money sent to the addresses because he would have no access to the private keys.

This could also be used to allow getaddress to work in the client without having to provide a key (access to the TXN data in the wallet means that access to the wallet, even with private key encryption, screws your confidentiality)  which would avoid the problem of backups being endangered due to address depletion from hitting getaddress a lot between entering in the key.

Look at the inputs to that transaction. The blocks are quite old. No megafarm was required.

The order book isn't a list of individual orders. It's a list of all coins available at a given price. If you and I put orders at the same price we'll be summed. Notice that there are no duplicate prices in the orderbook?

Nah, you're mistaking something completely boring for something interesting.

Someone put in a buy for 81.42NMC, You had a sell of 64.   All of yours, plus 17.42 of someone elses order were sold in order to satisfy the buyer.

This is how a normal market works.  If you buy X at Y price they it will buy all available up to amount X and price Y starting at the cheapest available.

 

The client can now run without irc.  -noirc -dnsseed as options, FWIW.  Crashing is surprising and unexpected though. Is it possible that mcaffee was crashing it because it tripped some mcaffee rule?