In the real financial world, matching and settlement occur asynchronously from each other, on different systems. Matching is "X tried to buy Y at Z, Q tried to sell Y at Z, their orders match." Settlement is physically delivering Y to X while physically debiting Z from Q.
Bitcoin developers haven't quite cottoned onto the wisdom of separating these functions architecturally. (One of many advantages is "If your matching system is compromised, you shut it down and investigate, but no money actually leaves. The settlement system is in your back office and much more protected than the matching system, because the settlement system doesn't have to talk to customers directly.")
Bitcoin developers instead have developed a security pattern called hot wallet/cold wallet, where BTC which are available to the system are "hot" and BTC which are not available to the system are "cold." The idea is that, in any given day, you might only require 2% or so of your company's total reserves to go in or out. You keep the private keys to, say, 5% of it on the live system. That's your hot wallet. You keep the private keys to the remaining 95% somewhere else. That's your cold wallet. Even if your live system is rooted, you should not (the thinking goes) lose the private keys to the cold wallet.
The Bitcoin community widely believes that this pattern is sufficient to prevent events like the recent Mt. Gox debacle, where the system was compromised and both the hot wallet and cold wallet were drained.
Bitcoin developers haven't quite cottoned onto the wisdom of separating these functions architecturally.
I'm not sure this is true. Any off blockchain transaction is basically an unsettled (and therefore reversible) bitcoin transaction. So for example, trades on bitcoin exchanges and payments between web wallets will have separate and distinct settlement phases. Generally bitcoin enthusiasts gloss over this though, because they don't like the idea of reversible transactions.
The current maximum transaction rate for the bitcoin networks is something like seven transactions per second. So either they'll have to figure out how to increase that or move to a more conventional clearing and settlement system if bitcoin-as-a-payment-network ever takes off in real size.
> The current maximum transaction rate for the bitcoin networks is something like seven transactions per second
What? I'm not entirely sure that I understand this correctly: Do you say that the whole bitcoin network, with all that computing power, can't compute more than 7 transactions per second?
The limit here is one of design: each block is currently limited to X MB, each transaction takes Y bytes, and each block is designed to happen every Z minutes; for Bitcoin's current values of 1MB (expected to be raised at some point if the size becomes a limit), something like 1k, and 10 minutes, that works out to 7 transactions per second.
Altcoins which have chosen blocktimes of say 1 minute will be able to do more transactions per second, and ones which lift the 1MB cap likewise.
They can compute more than 7 transactions per second, but it is at present a hardcoded artificial limit (one of many) because if the network tried to sustain e.g. 100 TPS like an actual bank, the block chain would balloon in size to terabytes very quickly, and since every Bitcoin client needs every transaction in history, that would force most people to abandon it.
> Today the Bitcoin network is restricted to a sustained rate of 7 tps by some artificial limits. These were put in place to stop people from ballooning the size of the block chain before the network and community was ready for it. Once those limits are lifted, the maximum transaction rate will go up significantly.
I don't know the details, but I think this arises from the rate at which blocks are discovered and the amount of space each transaction takes within a block. 7 tps is actually pretty high. All of paypal only does about 100 tps.
Execution (match engines are just a part of that) and settlement aren't just different parts of an exchange architecture; they are often different business units, or even different companies.
@patio11 - I dont understand. From what you wrote about matching-settlement vs hot-cold it seems there are still two systems at play there. I don't understand why there is a difference in security unless there is a time element in play (settlement at EOD).
Doesn't that violate the real time nature of bitcoin then? I have built e-commerce settlement systems in the past and I thought that the big challenge with bitcoin was always the instantaneous element.
You're correct, injecting extra time delay between transactions and settlement is one of the reasons why that architecture is more secure. That's a feature of it, not a bug. That is not the only difference: at almost all Bitcoin exchanges, your hot wallet is on your web tier and exposed to the adversary (so successful adversaries have authority to disburse 5% of your deposits), with the matching/settlement separation, a successful adversary still has no authority to disburse any percentage of your deposits. The hot/cold system also doesn't require e.g. intelligent accounting and reconciliation of those accounts, which is a major reason why the financial system actually works.
BTW: Bitcoin isn't a real-time system. The community widely believes it is, but people who actually understand what is happening would say "cough Yeah by 'real-time' we mean 'an hour later' cough."
Are you saying that Bitcoin-based financial systems cannot introduce a more secure settlement system without fundamental architectural changes to the Bitcoin protocol?
Or are you simply saying that nobody has apparently done so?
If the former, I would like to challenge that assumption. If the latter - what are you really trying to get at?
Bitcoin developers haven't quite cottoned onto the wisdom of separating these functions architecturally. (One of many advantages is "If your matching system is compromised, you shut it down and investigate, but no money actually leaves. The settlement system is in your back office and much more protected than the matching system, because the settlement system doesn't have to talk to customers directly.")
Bitcoin developers instead have developed a security pattern called hot wallet/cold wallet, where BTC which are available to the system are "hot" and BTC which are not available to the system are "cold." The idea is that, in any given day, you might only require 2% or so of your company's total reserves to go in or out. You keep the private keys to, say, 5% of it on the live system. That's your hot wallet. You keep the private keys to the remaining 95% somewhere else. That's your cold wallet. Even if your live system is rooted, you should not (the thinking goes) lose the private keys to the cold wallet.
The Bitcoin community widely believes that this pattern is sufficient to prevent events like the recent Mt. Gox debacle, where the system was compromised and both the hot wallet and cold wallet were drained.