I specifically choose the most extreme version to contrast as dramatically as possible with the other option. The question of how much of the speculative bubble "has burst" versus how much "is bursting" is largely the same question as how much of the present value of bitcoins is due to investment value and how much is due to the inherent usefulness of bitcoins as a medium of exchange. My own opinion is that currently most of the value of bitcoins (80%?) is as an investment/speculation vehicle but that this value is at least indirectly grounded in the reasonable belief that bitcoins have a chance of acquiring significant future value as a medium of exchange.

You only need to do it once. But yeah, trillions is going to be awfully tough.

I'm stating the two theories as the extremes. The truth is likely in between those extremes.

TA is not intended to predict unique, low probability events. It's intended to predict what's likely to happen based on predictable interactions. Whether that makes TA valuable or worthless is another question.

First, let me just say that I fully agree that the properties of the bitcoin system create a floor value that typical private currencies wouldn't have. However, I do think that there are really only two possible explanations for the crash:

1) A short-term speculative bubble has burst. The price has dropped to one based almost entirely on the current usefulness of bitcoins as a medium of exchange and long-term investment vehicle. The price will shoot back up if there's another speculative bubble. Otherwise, it will gradually rise or fall as the value and usefulness of the bitcoin system changes due to adoption, competitors, and so on.

2) Unique events (early adopters selling, stolen bitcoins being dumped, etcetera) have pushed the price way down. If not for these, the previous increases (whether due to speculation, the usefulness of the bitcoin system, or whatever) would have continued, and as soon as this stops, the price of bitcoin will begin sharply increasing until the next such unique events.

Most likely, the truth is between these two.

Or, in summary, once this unique event ends, the price of bitcoins will go up, go down, or stay about the same.

That's the biggest problem. I think it's an excellent idea, but it may turn out to be so hard to get it right that it's just not practical.

Full traceability is their trick. They know everyone's identity and have the ability and willingness to sue people for fraud if needed. That may be part of your solution, but that won't do it completely for you.

I think your biggest problem will be avoiding the rate/risk spiral and keeping the rates low enough that honest people with low-risk transactions are willing to use it. The more the rates go up, the higher the risk that will be needed to justify buying the insirance, which will lead to the rates going up again as all the insured transactions are high risk.

You need to find a way to force diligence on the part of at least one party.

That would require the miner to later gather all those outputs into one transaction in a separate step to spend them, bloating that transaction. Consider if each of 12 transactions has a .005 fee, do you want to spend them as one 50.06 bitcoin transaction input or as a 50 btc input and 12 .005 btc inputs? It's much more elegant to do it in the mined block already.

I don't see how. All you do is create a fresh wallet, send the stolen coins to the fresh wallet, then send them to your wallet, and then to the exchange. How can anyone tell that this is any different from you receiving the coins legitimately?

If you start hounding people because they received bitcoins that were stolen a few transactions back, you reduce the usefulness of bitcoins to near zero. Consider:

1) You place an ad to sell some widgets for bitcoins.

2) Someone accepts your offer and sends you 10 bitcoins for the widgets.

3) You see that most of those bitcoins were stolen 10 transactions back 10 weeks ago. But you have no idea if the person who sent you the bitcoins did all 10 of those transactions between his own addresses and just waited 10 weeks or if the bitcoins have been in circulation for 10 weeks.

4) If you accept the bitcoins, and so does everyone else, then anyone can easily launder stolen bitcoins through you. If you do not, and everyone else doesn't either, the bitcoins become useless -- two weeks after you accept some bitcoins and send the widgets, you may find your bitcoins become unspendable. So you can't safely hold bitcoins and we all play hot potato with them. Yuck.

And, worse, whether you keep them or send them back, if you're not careful, you can easily contaminate your own bitcoin stash with the tainted coins.

While I certainly agree that forensic tracking of the stolen coins in the hope of identifying the thief is a great idea, trying to stop the spread of the coins will never harm the thief anywhere near as much as it harms legitimate users of bitcoins and the bitcoin system in general.

Yep. Shortcuts are a bad idea. The security properties of the bitcoin scheme work because every client fully validates every block, using precisely the same tests, before it accepts it. This is part of what is necessary to determine that a block is in fact part of the public hash chain.

I don't follow your reasoning. The second a new block comes out, everyone needs it. The client can hardly do anything without a current block chain.

Also, you need to see unconfirmed transactions to know if coins are heading your way. Otherwise, there will be a minimum 10 minute delay before you know a transaction has been initiated. How would you do a vending machine with a random delay around ten minutes?

The default client will refuse to relay some no-fee transactions. If my memory serves me correctly, it will actually rate-limit free transactions based (sort of) on total size of all free transactions seen in a 10 minute window. This should ensure any such attack would have to run for a very long time to do real damage, giving us plenty of time to react.

I believe the current scheme is adequate but not great.

For what it's worth, I didn't think you were a scammer (and I apologize if I sounded like I was accusing you of that or implying that). I think you meant well but didn't really have a good idea of what you were getting yourself into. We actually badly need an e-wallet service run by someone truly trustworthy. The problem is, trustworthy people understand what a complex job it is to really do that right, and unless you intend to scam people, it's not likely to be all that profitable and you may have to defend your reputation against false accusation after false accusation. So that drives away the honest people and attracts the scammer.

Imagine if you did your bit dollars plan, and I started claiming that I bought 10 BTC from you and then when I went to claim it, you said it had already been claimed. Say you were honest, sold me the 10 BTC, and all you know is that someone claimed them. You don't know whether I'm scamming you and I claimed them or someone somehow got the code and you can't prove the 10 BTC you sent was to someone who knew a code that only you and I should know. (Maybe they peeked at my bit dollar, maybe not, you don't know.) What do you do? Do you pay me back the 10 BTC to preserve your repuation? Out of what? It's not like this is a high-profit service.

And what if you get hit by a car while holding lots of other people's money?

Oh, well then the one that automatically places your buy at the daily low or your sell at the daily high should definitely go first.

The bid/ask spreads on TradeHill this weekend have been insane. But this hasn't been a typical weekend for bitcoins either.

That's not the way they would do the attack. They would build a rainbow table of a few trillion passphrases and the corresponding bitcoin addresses. Everytime a new bitcoin address appeared in the hash chain, they would check that address against the rainbow table. If they found a match, they would derive the private key again and claim the funds immediately.

There is an algorithm very similar to ECDSA that performs encryption, ECIES. The algorithm is explained here:
http://en.wikipedia.org/wiki/Integrated_Encryption_Scheme
I'm 95% sure ECIES can work with keys generated for ECDSA.

(This is, by the way, a somewhat surprising thing. It is definitely not true that because the keys can be used for signing they can obviously be used for secure encryption. It is not like RSA where signing and encrypting are almost the same operation. It just so happens that someone found a clever way to make it work.)

Only if two people use the same passphrase. Obviously, if someone you can't trust knows or can guess your passphrase, you are doomed.

I believe this is intentional. USE_UPNP=0 means that UPNP is not used by default but can be enabled. It's a three-way switch.

Really? That's kind of a nutty error. Are you sure you aren't using non-standard warning flags? GCC will issue crazy warnings if you enable all possible warnings, even "unsigned char j[10], k[10]; j[ i ]^=k[ i ];" will trigger an int->char warning.

The inflation wouldn't be added to the nominal interest. There is usually no way the lender can pass off the cost of inflation to the borrower. Inflation is like a "storage fee" on money. Since the lender is providing the money, he would have to pay the fee if he doesn't loan the money out. So how can he pass it on to the borrower?

For example, suppose I want to borrow your car for a month. And suppose we decide that $200 is a fair price for the wear and tear I'll place on your car and any liability you might have in case I damage the car, injure someone, get tickets, or the like. Now imagine we add something to the mix -- if you don't let me borrow your car for a month, you'll have to pay a $50 storage fee. Well logically now I should be able to negotiate a lower price. You can't pass on the $50 storage fee to me. This lower price I can now negotiate because you avoid the cost of holding the money perfectly balances the reduced value of the money I pay you back -- again, making the loan currency neutral.

The lender compares loaning the money to anything else he might do with the money. If sprocket futures are going up and reliably expected to continue to go up, he'll buy sprockets instead of loaning the money unless the borrower can pay more. A borrower must compete with everything a lender can do with his money -- the entire economy.

It's not whether the currency itself is inflationary or deflationary because the borrower or the lender could easily just change the money to a more favorable currency if that was the case. If some currency properties favored the lender, he'd just convert his money into that currency before lending it. And if some currency properties favored the borrower, he'd just seek loans denominated in those currencies.

Wherever they are held, if that disappears, every bitdollar becomes worthless. That's a pretty high risk considering how bitcoin-related business have a habit of disappearing.

There are a few ways to work around that:

1) Have a really good reputation, have people know your real identity, and operate completely in the open.

2) Hire independent auditors to provide independent configuration that how you say you run your business is the same as how you really run it.

3) Design your business in such a way that it's not easy for you to cheat people and get away with it. For example, document the amount of outstanding obligations you have and prove you have the reserve you claim you have.

But honestly, your system as proposed doesn't seem very useful. Pretty much the same thing can be done in ways that don't have the risks your method has.

Also, this could be a language barrier issue or just me being hypersensitive, but you seem a bit slow to understand the things people are telling you. I'm not suggesting you are stupid, just that you're not deeply familiar with the issues with running a business like this and the threats you will face. They're not obvious, and you can't magically know them just be being a smart guy. It seems like you might lack the experience necessary to run a business where you may be safeguarding hundreds of thousands of dollars of other people's money.

People asked the most obvious questions, the ones you should already have the answers for because you know people are going to ask them, and it seemed like you didn't understand the questions. In fairness, they weren't very detailed. But because you should already have thought through all the threats and how you will address them, it should have been sufficient to just point out the type of threat to hear your plan to address that threat. And it wasn't.

Say you have 50,000 BTC in bitdollars "out there". And say you typically redeem 1,000 BTC per day. You might "invest" 30,000 BTC in the market to try to make some extra money. But if you lose those BTC, eventually some customer will want to redeem a bitdollar and you won't be able to cover it.

To assure us that you are not "borrowing" your customers' money, you should do three things:

1) Publish the list of account(s) that are holding customer's funds.
2) Regularly publish the serial number and denomination of every outstanding bitdollar (but not the claim code).
3) Any time a new account is added to list 1, you should prove that it is your account. (There are various ways you can do this.)

That way, if I have a bitdollar, I can 100% confirm that it is valid and I can 100% confirm that you actually have the bitcoins to back all outstanding bitdollar. You cannot easily cheat this system because if one bitodollar isn't on the list, the owner of that bitdollar at least will know it. And if you don't have enough bitcoins to cover the total of all bitdollars, we can see that from the accounts.

You can still cheat people by refusing to honor bitdollars either one by one or just disappearing one day. But at least this will ensure that as soon as you start cheating, people will know to stop trusting you. (If they ever start.) It will also ensure you can't secretly "borrow" customer funds.