Diablo reported that running multiple opencl threads improves utilization substantially, his miner runs three per gpu.  Though this may be due to the excessive usage of blocking IO in the fast path (wtf‽).

I'm looking forward to the phatk kernel.  Getting a miner with a control plane which isn't crap is a dream that I haven't had the free time to realize.

Thanks for working on this!

I recommend microsd and http://www.spy-coins.com/producthtm/micronickle.htm in the future.

Backing (as well as intrinsic value) is a liability for money, not an asset.  It artificially pins the value of the money-units to something other than what the market would reach absent the backing, or it artificially influences the value of the backing asset. E.g. in the case of gold— gold is orders of magnitude more expensive than other substances which are more rare, more difficult to obtain, and more industrially useful— thus leading to an inefficient under-utilization of gold.

The parallel with name backing is pretty obvious: If you fuse naming and bitcoin either names will be wildly under/overpriced due to demand for bitcoin, or bitcoin will be wildly under/overpriced due to demand for names, or both.

This article changed how I thought about money by arguing about why gold is not great money. Perhaps you'll find it interesting: http://www.libertariannews.org/2011/06/21/against-the-gold-standard/

I would instead argue that when people think of backing as a problem what they are really concerned with is guaranteed liquidity. Unfortunately, even if we made it so you could always buy names with bitcoin (perhaps with an automatic variable exchange rate to avoid the backing problems I suggested above) it wouldn't really solve the liquidity problem because you might want something _other_ than names, like food. And if you were having problems getting people to accept bitcoin for food then you're going to have pretty much the same problem with bitcoin-connected names for food.

I don't buy the bitcoin-backed-by-proven-transactions.  I thought I might need certify a document creation time at some point in the future the other day so I dropped a SHA-512 randomly into #bitcoin where is was logged by hundreds of disinterested parties. Should I actually need to prove it I could just subpoena a few of them. I can cheaply put a hash in a newspaper classified, etc.  Timestamping is so cheap that its almost valueless on its own, and the cases where you'd need machine verifiable timestamps that bitcoin provides over and above the cheap options I just gave are few and far between.

I think this is an excellent point which I missed previously because of all the distraction related to restoring the lost coin and the common misconception that the loss of coin itself is a problem.  I think you undermined your argument in the first post by arguing for more than was strictly necessary to achieve these ends.

To remove the uncertainty you simply need to take the coins out of circulation forever, it's not required that they be remined.  Otherwise you end up with another kind of uncertainty: e.g. say bitcoin manages to deflate to the point where 1 BTC = $1m in todays relative value... and a ton of lost coins miss their long hearbeat and show up mining. So no matter what algorithm you choose for dishing out the expired coin it could end up making mining ludicrously and socially destructively valuable compared to any other occupation. Even if there is a long delay from the point where the coin expires to when it shows up again that just moves around the point at which everything blows up.

In some ways your proposal as stated only removes uncertainty in that it makes sure the pessimal case _always_ happens: that after the currency deflates due to high usage, lost money appears out of the abyss and screws everyone up.

However, I don't think that "heartbeat it" _or lose it forever_  violates any of the system invariants in the way that "keep printing" as proposed explicitly by SgtSpike,  and jon_smark. Nor does it create the possibility of a crazy gold rush appearing randomly in the future. (Heartbeating, incidentally would simply mean forming a new transaction, not an explicit heartbeat event.)

The obvious time to implement this would be at the same time as doing a cryptosystem upgrade, as the first expiration could be timed to adequately prevent a bunch of actually lost coins returning from the grave as ecc keys are cracked.  It would be easily argued for then because people will easily see that the failure to implement it will allow the lost coins to return and blow the economy up.

I would expect the only debate at that point would be over if it should be a one time cutoff or a rolling one.

Could be, should be, but isn't right now. The actual blockchain file is a dumb blob of bytes. The BDB file store offsets into that file. Pruning it would require atomic operations which cover both, or building a separate file and switching.... or putting it all in the database, which I assume is not done for performance/space reasons.


Not quite solely: You need to know something to tell if its the right key— otherwise you'd just accept any signature!  Fortunately, the transaction already provides the address, and we're already using the address to determine if the public key is the right one.

Page 48 of http://www.secg.org/download/aid-780/sec1-v2.pdf describes how to do key recovery, see step 1.6.1.  Note that there can be two possible public keys, but I don't think this creates a security issue because if someone can find a case where both candidates hash to the same address then they can already cause trouble with our current system.
Edit: I was corrected that it's up to four possible matching public keys

Right, their concern is theft, so a voluntary delay is pointless— otherwise I would point out that you can already form post-dated transaction in the bitcoin protocol by using the nLocktime field.  (Can't be mined until a particular block number or network time).

I think its a mostly a nonsense concern, and actually insoluble the way they suggest. People already suggest that the confirmation time in bitcoin will cause the system to fail, so adding a mandatory additional time to confirmation would _not_ help.

As far as it being nonsense— no cashlike system has this feature and they work fine. As you suggest the solution to theft in the context of cash is better security.  Transferring your savings into a offline wallet (a piece of paper or usb key) is analogous to locking your cash/gold bars in a safe and is the reasonable and prudent thing to do.

If bitcoin continues to grow in success I expect we'll also see secure hardware wallets— special devices that hold your keys securely and which you plug in via USB to send and receive from.

There are, however, technical things we can do to improve the security beyond just the basic "secure your computer/wallet".

For example, the user could transfer the funds into in-blockchain-escrow by forming a transaction that two signatures (the user's and a third parties) that are required for release of the funds.  Offering the service of being a third party signer for such transactions (perhaps requiring additional authentication or a time delay for release) may eventually be a reasonably profitable bitcoin business.

Another thing we could do is write code for miners that allows you to _bump_ a pending transaction out of their queue prior to it being mined if a conflicting transaction comes in that has a sufficient fee (Perhaps 1 BTC + 3% of the value).  A mode could be offered in the bitcoin client where if it sees someone else spending its coin it generates a fresh and safe keypair then produces a conflicting txn with the appropriate fees which locks the funds under a new key plus a preselected escrow service key, and this transaction hopefully gets mined first. This couldn't be a default because people using the same wallet from multiple places would shoot themselves in the head with it.

This would increase the risk of accepting unconfirmed transactions, because it provides a ready reversal mechanism for unconfirmed transactions to everyone. So as a community we ought to think long and hard about it before allowing it, but it's a possible option which doesn't require any kind of grand redesign or slow down transactions further in the common case.

Of course, there will be other ways to work with bitcoins in the future — e.g. bitcoin backed debit cards that provide centralized confirmation for very fast and low value transactions. But I don't think that additional currencies (be they distributed or centralized) are at all appropriate for addressing the security concerns.

Yea, thats unfairly negative.

"Mining gold takes energy, apart from increasing the supply of gold, most of which will simply be locked away in vaults, the energy is wasted"

"Validating and transporting cash takes energy, apart from discouraging counterfeiting and moving the cash from place to place, the energy is wasted"

People complaining about bitcoin's energy usage are ignoring the externalized (and thus hidden) energy costs in the alternatives.  Perhaps bitcoin is worse right now given the low amount of economic activity, but its nowhere near as bad as a simplistic analysis would make it sound.

Ob pedantry:  The 21M limit comes not from the quantization limit at 1e-8, it arises as the limit of the geometric series.  If the bitcoin precision is increased the total number of bitcoins will not go past that limit.

You're also overstating the current blockchain size.  The client keeps orphan forks that it heard about plus a number of excessively bloated indexes. The blocks themselves are in blk0001.dat.  On client I bootstrapped a few weeks ago (so it has some amount of dead forks in it already) is 285MBytes.

The blockchain can also be significantly compressed because almost all txn use the same script and because public keys in signed transactions can be reliably derived from the signature. (It's not clear that Satoshi knew this, but even so— it takes a bit more computation to validate without the public key.) Just running a simple compression on it that doesn't take advantage of the ability to recover public keys shrinks the file to 190MBytes.

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.