always use dots in "e.g."

coding-conventions.md

@@ -32,7 +32,7 @@ We like them as long as they add detail that is missing from the code. Comments
 
 * Explain **what** the code is doing at a higher level than is obtainable from just examining the statement and surrounding code.
 * Explain **why** certain choices were made and the tradeoffs considered.
-* Don't be afraid of **redundancy**, many people will start reading your code in the middle with little or no idea of what it's about, eg, due to a bug or a need to introduce a new feature. It's OK to repeat basic facts or descriptions in different places if that increases the chance developers will see something important.
+* Don't be afraid of **redundancy**, many people will start reading your code in the middle with little or no idea of what it's about, e.g. due to a bug or a need to introduce a new feature. It's OK to repeat basic facts or descriptions in different places if that increases the chance developers will see something important.
 * Explain **how things can go wrong**, which is a detail often not easily seen just by reading the code.
 * Use good grammar with capital letters and full stops. This gets us in the right frame of mind for writing real explanations of things.
 

getting-started-java.md

@@ -14,7 +14,7 @@ title: "Getting started in Java"
 
 ## Initial setup
 
-**bitcoinj** has logging and assertions built in. Assertions are always checked by default regardless of whether the `-ea` flag is specified. Logging is handled by the [SLF4J](http://www.slf4j.org) library. It lets you choose which logging system you'd prefer to use, eg, JDK logging, Android logging, etc. By default we use the simple logger which prints most stuff of interest to stderr. You can pick a new logger by switching out the jar file in the lib directory.
+**bitcoinj** has logging and assertions built in. Assertions are always checked by default regardless of whether the `-ea` flag is specified. Logging is handled by the [SLF4J](http://www.slf4j.org) library. It lets you choose which logging system you'd prefer to use, e.g. JDK logging, Android logging, etc. By default we use the simple logger which prints most stuff of interest to stderr. You can pick a new logger by switching out the jar file in the lib directory.
 
 **bitcoinj** uses Gradle as its build system and is distributed via git. There are source code/jar downloads you can use, but it's more secure to get it directly from the source repository.
 

release-notes.md

@@ -914,7 +914,7 @@ Known issues:
 
 * Transaction confidence listeners are still run with the wallet lock held, which means it's possible to trigger unexpected lock inversions by doing certain things inside them. Also, confidence listeners sometimes run in places where the wallet code is not fully re-entrant, meaning that modifying the wallet whilst inside a confidence listener may cause problems. A simple fix is to run your listener code in a separate thread. A future release will fix this by ensuring that listeners only ever run at the end of wallet mutating operations and with the wallet unlocked. Core objects will also switch to using non-reentrant locks so unexpected reentrancy deadlocks early and reliably.
 * If multiple peers disconnect simultaneously it's possible for the system to deadlock due to Netty allowing uncontrolled reentrancy when sending outbound messages (issue 381).
-* The Wallet expects that it can store all transactions in memory (including spent transactions), eg, for rendering in lists and availability during re-orgs. On highly constrained devices like old Android phones it is possible to run out of RAM if a wallet gets very large.
+* The Wallet expects that it can store all transactions in memory (including spent transactions), e.g. for rendering in lists and availability during re-orgs. On highly constrained devices like old Android phones it is possible to run out of RAM if a wallet gets very large.
 * There are some bugs that can cause the wallet to get into an inconsistent state in various rare situations. The wallets can be fixed by replaying them. These bugs will be addressed as the next highest priority.
 
 

security-model.md

@@ -20,7 +20,7 @@ _Learn about the difference between full vs simplified modes, and how a bitcoinj
 
 bitcoinj supports two different modes for your application: full verification and simplified verification. The mode you choose controls the resource usage of your application and how much trust you need in other participants in the Bitcoin system. As a developer, it's important you understand the differences and in which situations your app can or cannot be trusted.
 
-Firstly, let's recap how a regular full node works. The fundamental problem Bitcoin solves is achieving consensus on who owns what. Every node maintains a database of unspent outputs, and transactions that attempt to spend outputs that don't exist or were already spent are ignored. Blocks are solved by miners and broadcast to ensure everyone agrees on the ordering of transactions, and so nodes that don't see a broadcast transaction for some reason (eg, they were offline at the time) can catch up.
+Firstly, let's recap how a regular full node works. The fundamental problem Bitcoin solves is achieving consensus on who owns what. Every node maintains a database of unspent outputs, and transactions that attempt to spend outputs that don't exist or were already spent are ignored. Blocks are solved by miners and broadcast to ensure everyone agrees on the ordering of transactions, and so nodes that don't see a broadcast transaction for some reason (e.g. they were offline at the time) can catch up.
 
 The act of checking, storing and updating the database for every single transaction is quite intensive. Catching up to the current state of the database from scratch is also very slow. For this reason, not every computer can run a full node.
 
@@ -62,7 +62,7 @@ If somebody executes a Finney attack against your app, the `TransactionConfidenc
 
 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.
+**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, e.g. 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.
 
 Just because a transaction appears in a block does not mean it is valid. Again, bitcoinj apps do not check transaction validity. Instead the assumption is that it's difficult to build a block chain containing an invalid block because you would have to be able to outrun the rest of the miners combined. There is one exploit against this assumption that is not yet fixed: **if an attacker can control your connections to the Bitcoin network, they can prevent you from seeing newly found legitimate blocks and mine their own invalid block containing a bad transaction**. This attack is detectable because unless the attacker can outrun the network (a 51% attack), the speed with which new blocks arrive will drop significantly. In future bitcoinj may offer a "red alert" mode in which things that seem odd are flagged, it would indicate to your app that it's time to stop trading.
 

working-with-the-wallet.md

@@ -149,7 +149,7 @@ Note that between `completeTx` and `commitTx` no lock is being held. So it's pos
 
 To _commit_ a transaction means to update the spent flags of the wallets transactions so they won't be re-used. It's important to commit a transaction at the right time and there are different strategies for doing so. 
 
-The default sendCoins() behaviour is to commit and then broadcast, which is a good choice most of the time. It means there's no chance of accidentally creating a double spend if there's a network problem or if there are multiple threads trying to create and broadcast transactions simultaneously. On the other hand, it means that if the network doesn't accept your transaction for some reason (eg, insufficient fees/non-standard form) the wallet thinks the money is spent when it wasn't and you'll have to fix things yourself.
+The default sendCoins() behaviour is to commit and then broadcast, which is a good choice most of the time. It means there's no chance of accidentally creating a double spend if there's a network problem or if there are multiple threads trying to create and broadcast transactions simultaneously. On the other hand, it means that if the network doesn't accept your transaction for some reason (e.g. insufficient fees/non-standard form) the wallet thinks the money is spent when it wasn't and you'll have to fix things yourself.
 
 You can also just not call `wallet.commitTx` and use `peerGroup.broadcastTransaction` instead. Once a transaction has been seen by a bunch of peers it will be given to the wallet which will then commit it for you. The main reason you may want to commit after successful broadcast is if you're experimenting with new code and are creating transactions that won't necessarily be accepted. It's annoying to have to constantly roll back your wallet in this case. Once you know the network will always accept your transactions you can create the send request, complete it and commit the resulting transaction all under a single lock so multiple threads won't create double spends by mistake.
 
@@ -206,7 +206,7 @@ The wallet provides the `WalletEventListener` interface for learning about chang
 
 By default the Wallet is just an in-memory object, it won't save by itself. You can use `saveToFile()` or `saveToOutputStream()` when you want to persist the wallet. It's best to use `saveToFile()` if possible because this will write to a temporary file and then atomically rename it, giving you assurance that the wallet won't be half-written or corrupted if something goes wrong half way through the saving process.
 
-It can be difficult to know exactly when to save the wallet, and if you do it too aggressively you can negatively affect the performance of your app. To help solve this, the wallet can auto-save itself to a named file. Use the `autoSaveToFile()` method to set this up. You can optionally provide a delay period, eg, of a few hundred milliseconds. This will create a background thread that saves the wallet every N milliseconds if it needs saving. Note that some important operations, like adding a key, always trigger an immediate auto-save. Delaying writes of the wallet can help improve performance in some cases, eg, if you're catching up a wallet that is very busy (has lots of transactions moving in and out). You can register an auto-save listener to learn when the wallet saved itself.
+It can be difficult to know exactly when to save the wallet, and if you do it too aggressively you can negatively affect the performance of your app. To help solve this, the wallet can auto-save itself to a named file. Use the `autoSaveToFile()` method to set this up. You can optionally provide a delay period, e.g. of a few hundred milliseconds. This will create a background thread that saves the wallet every N milliseconds if it needs saving. Note that some important operations, like adding a key, always trigger an immediate auto-save. Delaying writes of the wallet can help improve performance in some cases, e.g. if you're catching up a wallet that is very busy (has lots of transactions moving in and out). You can register an auto-save listener to learn when the wallet saved itself.
 
 ## Wallet maintenance and key rotation
 

working-with-transactions.md

@@ -64,7 +64,7 @@ A confidence object has one of several states:
 
 * If **BUILDING**, then the transaction is included in the best chain and your confidence in it is increasing.
 * If **PENDING**, then the transaction is unconfirmed and should be included shortly as long as it is being broadcast from time to time and is considered valid by the network. A pending transaction will be announced if the containing wallet has been attached to a live `PeerGroup` using `PeerGroup.addWallet()`. You can estimate how likely the transaction is to be included by measuring how many nodes announce it after sending it to one peer, using `TransactionConfidence.numBroadcastPeers()`. Or if you saw it from a trusted peer, you can assume it's valid and will get mined sooner or later as well. 
-* If **DEAD**, then it means the transaction won't confirm unless there is another re-org, because some other transaction is spending one of its inputs. Such transactions should be alerted to the user so they can take action, eg, suspending shipment of goods if they are a merchant.
+* If **DEAD**, then it means the transaction won't confirm unless there is another re-org, because some other transaction is spending one of its inputs. Such transactions should be alerted to the user so they can take action, e.g. suspending shipment of goods if they are a merchant.
 * **UNKNOWN** is used if we have no information about the confidence of this transaction, because for example it has been deserialized from a Bitcoin structure but not broadcast or seen in the chain yet. UNKNOWN is the default state.
 
 The confidence type, available via `TransactionConfidence.getConfidenceType()`, is a general statement of the transactions state. You can get a more precise view using getters on the object. For example, in the `BUILDING` state, `getDepthInBlocks()` should tell you how deeply buried the transaction is, in terms of blocks. The deeper it is buried in the chain, the less chance you have of the transaction being reversed.
@@ -94,7 +94,7 @@ It's possible to send someone money by directly giving them a transaction, which
 
 ### Participation in contracts
 
-[Contracts](https://en.bitcoin.it/wiki/Contracts) allow for a variety of low trust trades to take place, mediated by the Bitcoin network. By carefully constructing transactions with particular scripts, signatures and structures you can have low-trust dispute mediation, coins locked to arbitrary conditions (eg, futures contracts), assurance contracts, [smart property](https://en.bitcoin.it/wiki/Smart_Property) and many other possibilities.
+[Contracts](https://en.bitcoin.it/wiki/Contracts) allow for a variety of low trust trades to take place, mediated by the Bitcoin network. By carefully constructing transactions with particular scripts, signatures and structures you can have low-trust dispute mediation, coins locked to arbitrary conditions (e.g. futures contracts), assurance contracts, [smart property](https://en.bitcoin.it/wiki/Smart_Property) and many other possibilities.
 
 You can learn more about this topic in the article [WorkingWithContracts](working-with-contracts).