That is an incorrect assumption.

Price is always dependent on volume.  There are enough buyers and enough sellers that any trade which isn't an outlier to current daily volume can be absorbed without any significant change in price.

That doesn't mean the market is willing to absorb an unlimited volume without more slippage.  Try dropping $1M USD or 250K coins on to the market and I guarantee you the market will move.  Not only will it move directly (you simply sucking up the supply or demand) others will jump in and attempt to capitalize on that momentum. 

The "calm" is simply a metric of depth vs volume.  Depth has grown faster than volume (likely as many chased "free profits"). Today it takes "more" to move the price compared to a year ago.  Volume while it has grown, it hasn't grown by a comparable amount.  If volume quadruple and depth didn't increase you would see volatility take off again.

A few dollars in electricity in hardware would only be worth millions if the person decided not to cash out.  So pretending they only risked a few dollars is intellectually dishonest.  You simply say it because it reinforces your point of view.

Say someone mined 100K coins and it only cost them $300 (hardware, time, electricity).  When Bitcoin was worth $0.01 ea that investment suddenly was worth $1K.  As soon as they had the potential to sell some or all of their coins at the market price that became what they risked by not selling.  By not accepting $1K and holding they were no longer risking $300 they were risking $1K.  The same thing applied as the price rose from $0.01 to $0.10 to $1.00 and all the way up to $30.00 and then back down to $2.00 and back up to $5.00.

At each point the holder was risking the current value (in fiat) against the potential of future appreciation (which isn't guaranteed).  The only way someone ends up a Bitcoin millionaire is not by merely "risking a few dollars" but also being willing to continually risk the current value and not "cash out".

You claim the Bitcoin early adopters are unfairly enriched for their minimal risk.  However that enrichment only happens unless they either have already sold out (like getting a Pizza for 10K coins) or Bitcoin continues to expand.   If Bitcoin fails which you continue to claim it will then the early adopters won't be enriched millions. 

It seems you want to have your cake and eat it to.  Bitcoin early adopters will be unfairly rich by holding coins,  the very same coins which have no value if Bitcoin fails.  So which is it?  The early adopters are unfairly enriched to the tune of millions or Bitcoin will fail?

My understanding is they take like 30% or so from what they pay developers.  Unlikely they would even support a "game developer" who sells Bitcoins but even if they did we are talking a prohibitive markup.

Unlikely that would assume the custom ASIC is pin for pin compatible with the current FPGA and happens to run at the same voltage.  Even if it did powering (for example) a @10W chip on a 80W DC PSU is going to be horribly inefficient.   Then you consider the heat sink, fan, and other supporting infrastructure is sub optimal it doesn't make much sense.

You take the traded in boards and ship them in bulk to a assembly shop who will remove the FPGA and reball them.  They can also remove any components on the board with significant resell value, scrap the boards, and sell off the components w/ resale value.

FPGA can then be resold in the second hand market (as already being done with such chips)
[/quote]

http://en.wikipedia.org/wiki/Fungibility

It would be the death of Bitcoin (or any currency).

No thanks.


So what is the difference between 1 phone + 1 phone being used as a dedicated bitcoin device  vs 1 phone + dedicated bitcoin device.

My point is the hardware already exists.  It is called a smartphone.  It has everything you need including connectivity and software.

For most casual users a single device is fine for the paranoid just carry two.  

Nice list.  I would add use a hardware security module to enforce
a) business rules (i.e. limits on # of tx per hour, size of tx, volume, etc)
b) delays on larger tx (i.e. tx < 100 BTC processed instantly, 100 BTC to 250 BTC delayed 1 hour, 250 BTC to 1000 BTC delayed 4 hours, 1000 BTC to hot wallet max delayed 12 hours)
c) delays on  high tx velocity (i.e. once cumulative tx in last hour exceed 3x avg hourly volume delay all tx 1 hour,  once cumulative tx in last hour exceed 5x hourly volume delay all tx 4 hours).
d) periodic status messages signing for delivery off the server (since signing key is inside HSM attacker couldn't spoof good status messages.  Attacker could block delivery of bad messages but that in itself should trigger a warning to off site monitoring).

Full disclosure I am working on a HSM for protecting Bitcoin Hot Wallets (Bitcoin Security Module).

Care to clarify on #4?

If it is just signed w/ hash of password well attacker can simply use the stored hash to sign any withdrawal as any user.
If it is signed by actual user password there is no way for the server to validate this as they don't have the actual password.

On edit:
I guess it would be possible to create a public/private key pair with the private key being based on a hash of the password (but not same hash used for login authentication) and store the public key in user's record.  When user makes a withdrawal he is prompted for password which is validated and then private key constructed to sign the withdrawal message.

ThiagoCMC wins auction for 159.19 BTC + shipping.
Per his request I will have the Single delivered to me and then shipped to him.

While that would be better (anything would be better) it wouldn't provide much protection from an informed theif. I do agree it would prevent the smash & grab type robberies but nothing more sophisticated.  If the attack has root/admin access to the server then any software level protections would be rendered inert.

For example no "alert emails" would go out because a good thief would stop all outbound communication.  If an application on the server can unlock the wallet so can a good attacker.   Also when the wallet is decrypted for legit transactions it is loaded into memory.  An attacker with root access can recover can recovery the decrypted wallet from memory even if he never gets the encryption key.

Likewise any code which relies on the host (under the control of the attacker) to validate tx is doomed.  The attacker has control of the system clock and can use that to bypass any protections.

Essentially one must assume that one that attacker has control over the host that any and all protection systems of that host are disabled.  The goal then it to have protection systems which don't rely on the compromised host, which operate from a security perspective that the host may be at any time compromised.

Essentially trust still comes down to the assumption that the thief won't gain root/admin access to the server.  I guess it all depends on what you are protecting.  I would imagine if the Bitcoinica team could have gone back in time before the first robbery and installed a HSM/BSM they would have gladly done so.

sebastian,

That still requires HSM to be able to parse &validate blocks, find tx, match them against user database, validate tx, determined deposited amounts, and update user's profile.  I think you may be overestimating the computational power of these devices (well at least the ones which don't cost $80K).   My goal would be to get the cost <$500 installed that requires making the BSM logic as simple as possible.

Still I encourage you to start coding and experimenting. 

The Yubico HSM is a classic example of how I said Bitcoin presents some unique challenges.  In most HSM applications you are simply protecting the private key.  The Yubico can protect a private key, it can even sign a tx but it has no concept of "what" it is signing.

So to take Bitcoinica as an example the attacker would be unable to steal the private key but it could ask the Yubico to sign this tx transfering 18K from Bitcoinica hot wallet to the attacker's address and the Yubico would happily do it.

The largest issue becomes sliding ratio between scammers and legit buyers.

Lets just say hypothetically if you could sell coins using reversible payment system @ MtGox rate, the % of scammers would be 15% of sales.  15% isn't bad right?  Well if you sold @ MtGox rate you would have no profit.  So you go 15% scammers + goal of having 10% profit.  So just mark the coins up 25%.   Well the problem is that @ +25% they become much less attractive to legit buyers so the "concentration of scammers goes up.  Instead of say 15% scammers it is now maybe 25% scammers.  So you need to mark it up to 35%.  Of course we need to consider ebay/PP costs of 10% so it is more like 45% markup. 

However once again at 45% markup it is even less attractive to legit buyers.... etc.

How are you going to do a Bitcoin tx when neither party has access to the internet?

No reason for a smartphone to have internet when you don't want it to.  "Airplane mode" disables all radios at the device level.  Kinda hard to be online when you have no signal.

sebastian you say the HSM can "know" when a user deposits but the only way it can natively "know" is if there is an entire blockchain and bitcoind and connectivity with multiple legit nodes all inside the the HSM.

If the bitcoind, blockchain, and bitcoin network connectivity is on the host you have to assume all of that is now under the control of the attacker and the HSM is simply being fed data which the attacker wants to see.

I encourage multiple different approaches but trying to put the entire tx server inside the hsm isn't really a hsm any more.  It is just a server and bitcoinica thought they had the server well secured.

Down to 166?  I might need to buy it at this price (just kidding).

If you have the funds in Bitcoins there is no issue.  I will ship it anywhere you want.

There are a couple of ways to do this and I am still thinking about how it is best handled.  

One method would be to have all deposited funds go directly to cold storage and then generate when you initialize the device it generates a hot address and the operator sends some of the funds to the hot wallet.  Once the rules are set there is no bypass or override.  

Another option would be to have a cold storage address loaded as part of the initialization parameters and unlimited funds can be transfered to the cold storage but any other address must follow "the rules".

A third oprtion which is more flexible but potentially less secure is to allow an override password (more likely a 128bit or 256 bit key) that would allow the operator to disable/modify the tx rules.  Even this is still more secure than a plaintext wallet as in normal operation the "override key" wouldn't be stored on the tx server.

Personally I think the second option is optimal but right now I am just trying to get the basics working.  The bad news is even send many is complex (possibly requiring swapping data in and out of the device) given the constraints on memory and storage.


Either.   The interface will be transparent to the loading of the assembly and communicating with the device.

sebastian,

I am glad to get a conversation going and there is no one solution.

Hardware devices tend to have limited resources.  The hardware device I am using has very limited memory and storage (under 200KB combined).  It simply wouldn't be possible to store user data inside the module.  Currently it only works with a single private key.  Working with multiple keys may require storing it outside the database in encrypted format.

Also trying to limit tx based on user's balances has limited utility.  If we assume the attacker has complete control of the host they could simply record a fake deposit and then request a withdrawal.  I am glad you are thinking about it though.  We need lots of people thinking about it.

I am taking the approach that if the attacker doesn't have access to the private key he needs to play by the "rules" and those rules can be constructed to limit the amount of the loss (potentially to nothing if the attacker triggers a lockdown or generates tx which have a required waiting period before decryption).