security-model.md: fix typo

Author: schildbach

security-model.md

@@ -60,7 +60,7 @@ If somebody executes a Finney attack against your app, the `TransactionConfidenc
 
 ## Confidence of confirmed transactions
 
-Many types of application don't deliver a service immediately, and there it's OK to wait for confirmation of transactions via inclusion in the block chain. When a transaction is included into the chain, the `TransactionConfidence` type changes to BUILDING and you can then access the transactions _depth_ (how many blocks have been built on top of this transaction), and _work done_, which is another view of the same thing. For example, immediately after a transaction has appeared in a block its depth is 1 and the work done depends on current [network speeds](http://bitcoin.sipa.be/). After an hour, on average there should be 6 blocks though the actual amount many vary considerably. The transaction confidence listeners run every time a new block is received, so you can register a listener and use that to trigger the act of delivering your goods or services when a confidence level is reached.
+Many types of application don't deliver a service immediately, and there it's OK to wait for confirmation of transactions via inclusion in the block chain. When a transaction is included into the chain, the `TransactionConfidence` type changes to BUILDING and you can then access the transactions _depth_ (how many blocks have been built on top of this transaction), and _work done_, which is another view of the same thing. For example, immediately after a transaction has appeared in a block its depth is 1 and the work done depends on current [network speeds](http://bitcoin.sipa.be/). After an hour, on average there should be 6 blocks – though the actual amount may vary considerably. The transaction confidence listeners run every time a new block is received, so you can register a listener and use that to trigger the act of delivering your goods or services when a confidence level is reached.
 
 **Recall that confidence can go down as well as up**. A "reorganize" is what happens when the chain you are on is replaced by a new best chain that ran parallel to yours. A re-organize can change your wallet arbitrarily, eg, by making transactions that were previously confirmed unconfirmed or (in the case of a double spend) dead. Re-orgs that make a transaction go dead are discussed in Satoshis paper, and are slightly different to the Finney attack case where there is no re-org, just a new best block. It's very rare for re-orgs to change the confidence of transactions that are buried deep in the chain.