Fix typos

dao/overview.adoc

@@ -203,7 +203,7 @@ The risk of forking provides a strong incentive not to act contrary to the inter
 
 It is possible for the main stakeholders to abuse their power in detriment to the interests of minority stakeholders (a.k.a. a majority attack). For example, a majority could vote to add new rules for confiscating or invalidating the tokens of the minority stakeholders. Such decisions constitute a hard fork, i.e. a change to the system that is not backward compatible.
 
-The established network will not accept transactions on the hard fork. This means that a malicious fork would have the difficult task of starting a network of traders from scratch, in particular since they have to compete against the old network. Second, the token value on the new fork would be essentially zero, and the attackers would presumably lose a lot of wealth.The attackers need to get their token value back and this would take decades, given a token yield of a few percent.
+The established network will not accept transactions on the hard fork. This means that a malicious fork would have the difficult task of starting a network of traders from scratch, in particular since they have to compete against the old network. Second, the token value on the new fork would be essentially zero, and the attackers would presumably lose a lot of wealth. The attackers need to get their token value back and this would take decades, given a token yield of a few percent.
 
 In short, we see no economic incentive for a majority attack on the Bisq DAO.
 

dao/phase-zero.adoc

@@ -364,7 +364,7 @@ With that said, it's a good idea to consult with stakeholders via the Bisq forum
 
  . something that the relevant maintainer(s) would be likely to merge;
  . something that stakeholders would likely vote to approve as a compensation request;
- . subjected to as as much feedback as possible while still an idea and thus cheap to change or abort.
+ . subjected to as much feedback as possible while still an idea and thus cheap to change or abort.
 
 Remember: _every contributor_ is free to work on what they want, including maintainers who may or may not want to review and merge your pull request if they don't have any prior context for it, or reason to believe it's worth spending their time on.
 
@@ -439,7 +439,7 @@ An _operator_ is a bonded contributor responsible for running ("operating") soft
 
 === Administrator
 
-An _administrator_ is a bonded contributor responsible for managing ("adminstering") applications and services that support the Bisq project. Examples include GitHub admin, DNS admin, Slack admin, IRC admin and Discourse (forum) admin.
+An _administrator_ is a bonded contributor responsible for managing ("administering") applications and services that support the Bisq project. Examples include GitHub admin, DNS admin, Slack admin, IRC admin and Discourse (forum) admin.
 
 === Other roles not listed here
 

exchange/howto/add-alternative-base-currency.adoc

@@ -77,6 +77,6 @@ If the PR gets merged the seed node operators and arbitrators will be assigned a
  - At each new release we will check if already supported base currencies have been traded in the past 4 months. If this requirement is not met the base currency will be removed. The Bisq trade statistics are taken as reference. Removal of a not-traded base currency will not be announced beside in the release notes of the new release.
  - Adding the base currency again requires a statement about the changed circumstances (e.g. link to discussions where demand for the base currency is documented,...).
 
-=== Getting an new base currency into production might take a bit
+=== Getting a new base currency into production might take a bit
 
 Adding a new base currency will be part of the normal release cycle.

exchange/howto/run-price-relay-node.adoc

@@ -15,7 +15,7 @@ The mining fee estimation is delivered by:
 
 . link:https://bitcoinfees.21.co/[21.co]
 
-_Please note that the fee estimation function might get separated in future into it's own node._
+_Please note that the fee estimation function might get separated in the future into its own node._
 
 
 === Background:
@@ -28,20 +28,20 @@ There are several reasons why the Bisq application does not connect directly to
 
 For those 2 reasons we changed in earlier updates to the model of operating a price relay node running as Tor hidden service which connects to the service providers in clear net mode and contains the API key for Bitcoin Average.
 
-The price relay carry an important security aspect: +
+The price relay carries an important security aspect: +
 If the trader is using a percentage based price in the offer the actual trade price will be calculated using the current market price taken from the market price providers. If a node would deliver wrong data it could lead to a wrong trade price. Both traders check the calculated price by themselves but if both are connected to the same malicious provider it would result in a wrong trade price. Connection is made randomly to one of the providers in the list. We have as well a check for the age of the price and if the price is older than 30 min. the market price will be ignored. If no price is available percentage based offers cannot be taken. A monitor service checking all price relay nodes and comparing their values for outliers is an important feature we need to add soon.
 
 The price relay is a simple http server and has to be set up to be accessible as Tor hidden service. Additionally if the operator wants he can open it to clear net (at least one clear net node is useful for supporting the regtest-without-tor dev setup for receiving market prices). We don't recommend to advertise the node address to not get traffic from non-Bisq users. There is no authentication scheme for Bisq users which make the service vulnerable for abuse of DDoS attacks. An authentication scheme for a P2P/open source environment is a challenge on its own but considered important to get explored further.
 
 
 The user connects to one of the nodes randomly and if a node fails it tries the next in random node in the list.
 If the first node is not available it decreases usability for the user because price display at startup takes longer.
-But more critical is that if both nodes are offline percentage based offers cannot be used. Similar if a price node has connection issues with the providers the prices are outdated and likely invalid for other peers when the user engage in a trade.
+But more critical is that if both nodes are offline percentage based offers cannot be used. Similar if a price node has connection issues with the providers the prices are outdated and likely invalid for other peers when the user engages in a trade.
 
 
 == Price relay node operators
 
-The price relay node addresses (onion address) are hard coded in the application but can be overruled if the user adds a price relay node address as program argument. Any user can run therefor their own price relay node and connect to it. Though they require an API key for Bitcoin Average (cost are 12.- or 35.- USD/month depending on plan).
+The price relay node addresses (onion address) are hard coded in the application but can be overruled if the user adds a price relay node address as program argument. Any user can run therefor their own price relay node and connect to it. Though they require an API key for Bitcoin Average (cost is 12.- or 35.- USD/month depending on plan).
 
 Some contributors of Bisq are running the default price relay nodes which are hard coded in the application. It requires a to set up a bond in BSQ to get the privilege to run a default price relay node and it requires that a certain quality of service is met. The operator also need to acquire an API key for Bitcoin Average. Currently we trust that all operators do their best to provide a reliable service without defining exactly the metrics for the quality of service.
 

exchange/howto/run-seednode.adoc

@@ -32,7 +32,7 @@ _Side note: The seed nodes on Linux get a out of memory error after running a fe
 === Duties of the seed node operator
 
 The operator of a seed node need to be responsive in case of seed node software updates as well to OS updates. If there are connectivity issues he need to investigate and if required upgrade his server (RAM, CPU). We recommend 2-4 GB of RAM for one seed node to allow 30 connections. He should check the error logs and the node log file (in the data directory) occasionally. He has to have a professional level of operational security to operate the node.
-Operators need to subscribe to the  Bisq Slack channel 'seednode' and act if their node reports errors.
+Operators need to subscribe to the Bisq Slack channel 'seednode' and act if their node reports errors.
 
 
 == System requirements for hosting machine
@@ -101,7 +101,7 @@ Seed nodes are monitored in the Bisq Slack channel 'monitoring' and errors are s
 
 == Bond
 
-We define a Bond of 2000 BSQ for the privilege to run a seed node. In case of severe failures of service (malicious or carelessness)  the bond would be confiscated (burned).
+We define a Bond of 2000 BSQ for the privilege to run a seed node. In case of severe failures of service (malicious or carelessness) the bond would be confiscated (burned).
 
 
 == Payment

exchange/whitepaper.adoc

@@ -200,7 +200,7 @@ Bisq does not use a reputation system, as such systems can easily be manipulated
 
 === Standard exchange process
 
- 1. Trader selects the arbitrators he want to accept in case of disputes or stick with the default selection of all matching arbitrators.
+ 1. Trader selects the arbitrators he wants to accept in case of disputes or stick with the default selection of all matching arbitrators.
  2. Trader sets up a payment method account.
  3. Buyer deposits bitcoins from external wallet (for security deposit, create-offer fee and mining fee)
  4. Buyer publishes the offer. Create-offer-fee gets paid to one of his selected arbitrators. The security deposit will be locked in his local Bisq trading wallet in case someone takes the offer.
@@ -214,7 +214,7 @@ Bisq does not use a reputation system, as such systems can easily be manipulated
 === Resolving a dispute
 
  1. The traders started a trade but for whatever reason it got stalled.
- 2. After the max. allowed trade period (depends on the payment method: e.g. OKPay: 1 day, SEPA: 8 days) the software displays an "Open dispute" button, which is otherwise not visible. Any trader can requests arbitration by pressing that button.
+ 2. After the max. allowed trade period (depends on the payment method: e.g. OKPay: 1 day, SEPA: 8 days) the software displays an "Open dispute" button, which is otherwise not visible. Any trader can request arbitration by pressing that button.
  3. Bisq provides a chat like communication system for disputes (and support tickets in case of software bugs) only between the trader and the arbitrator. The initiating trader will see his first (system) message he has sent to the arbitrator requesting a dispute.
  4. The arbitrator receives the dispute request and the software send a dispute message to the other trader, informing him that his peer has started a dispute. The two traders cannot communicate directly with each other and cannot see the communication of the other trader with the arbitrator.
  5. Traders and arbitrator communicate in real time, end-to-end encrypted.

manual-dispute-payout.adoc

@@ -10,7 +10,7 @@ In rare cases, it can become necessary for an arbitrator to work with a trader t
 
 The instructions that follow assume that a trade dispute has already been opened, arbitrated and closed, but that for some reason the payout transaction has not occurred as expected.
 
-One reason that a payout transaction may not go through is because the "winner" of the dispute (i.e. the trader who is being awarded the trading amount) has not come online since the ticket has been closed. It is necessary for the winner's Bisq client to come online in order to actually sign their part of of the 2-of-3 multi-sig transaction. If you believe this is the problem, you should *not* jump straight to a manual payout. You should first:
+One reason that a payout transaction may not go through is because the "winner" of the dispute (i.e. the trader who is being awarded the trading amount) has not come online since the ticket has been closed. It is necessary for the winner's Bisq client to come online in order to actually sign their part of the 2-of-3 multi-sig transaction. If you believe this is the problem, you should *not* jump straight to a manual payout. You should first:
 
  1. Re-open both buyer and seller tickets for this trade using `cmd-U`
  2. Re-close the ticket of the "losing" (i.e. the trader who is *not* receiving the trade amount, this time checking the "Use loser as publisher" checkbox.
@@ -44,7 +44,7 @@ P2SHMultiSigOutputScript:
 
 === Step 1. Review dispute details
 
-In `Support > Aribtrator's support tickets`, find the trade dispute in question, select it, and *review the closing chat message to determine who was the "winner" of the dispute*, i.e. who was supposed to have recieved the trading amount payout. For example, the closing comments on the dispute below make it clear that it was the seller who won the dispute:
+In `Support > Aribtrator's support tickets`, find the trade dispute in question, select it, and *review the closing chat message to determine who was the "winner" of the dispute*, i.e. who was supposed to have received the trading amount payout. For example, the closing comments on the dispute below make it clear that it was the seller who won the dispute:
 
 image:images/determine-winner.png[determining who was the winner]
 
@@ -66,7 +66,7 @@ Also *take note of the `txFee` value in the contract JSON*, e.g.:
 
    "txFee": 36000,
 
-This is the value of the bitcoin transaction fee denominated in Satoshis. Later, *you will need the same transaction fee value denominated in BTC*, which can be found by dividing the Satoshi value by 100,000,000, e.g.:
+This is the value of the Bitcoin transaction fee denominated in satoshis. Later, *you will need the same transaction fee value denominated in BTC*, which can be found by dividing the satoshi value by 100,000,000, e.g.:
 
     36000/100000000 = 0.00036000 BTC
 
@@ -112,7 +112,7 @@ When you have the trader's private key, move on to the next step.
 [[issue-payout]]
 === Step 4. Issue the manual dispute payout
 
-Now that you have all the necessary information, you can *open the Emergency multi-sig payout tool* by clicking `alt-g` in the dispute view:
+Now that you have all the necessary information, you can *open the Emergency multisig payout tool* by clicking `alt-g` in the dispute view:
 
 image:images/multisig-payout-tool.png[Emergency multi-sig payout tool]
 
@@ -124,7 +124,7 @@ sellerPayoutAmount:: The amount in BTC the seller should be paid out, e.g. `0.06
 
 arbitratorPayoutAmount:: This value should always be `0`, as we no longer issue payouts to arbitrators
 
-Tx fee:: The value of the `txFee` taken from the JSON contract details above, after converting from Satoshis to BTC, e.g. `36000` Satoshis => `0.00036` BTC
+Tx fee:: The value of the `txFee` taken from the JSON contract details above, after converting from satoshis to BTC, e.g. `36000` satoshis => `0.00036` BTC
 
 buyerAddressString:: The buyer's bitcoin address
 

payment-account-age-witness.adoc

@@ -5,7 +5,7 @@ Manfred Karrer <[email protected]>
 2017-09-14
 
 [abstract]
-This proposal describes a protection mechanism against a fraud scheme in which a criminal has obtained illegal access of a bank account and tries to buy bitcoin with the stolen funds. The victim of the stolen bank account will likely contact his bank once he discovers the fraud and initiate a bank chargeback. The bitcoin seller would in such a case be at risk to lose the received payment in Fiat currency. We *assume* that the criminal who has access to the bank account intends to take out the funds of that account as quickly as possible as well as that he intends to do that in a few large transactions because with each transaction the risk increases that the fraud gets discovered and the account gets frozen. With the *trade amount limits* in Bisq we have already a protection against that fraud scheme but we would like to increase the security by adding a verification scheme for the *age of the bank account*. To protect users privacy we use a hashing scheme and only the other trading peer - who will receive anyway the payment details during the trade process - is able to verify that the provided hash in the offer matches the real account data.
+This proposal describes a protection mechanism against a fraud scheme in which a criminal has obtained illegal access of a bank account and tries to buy bitcoin with the stolen funds. The victim of the stolen bank account will likely contact his bank once he discovers the fraud and initiate a bank chargeback. The bitcoin seller would in such a case be at risk to lose the received payment in Fiat currency. We *assume* that the criminal who has access to the bank account intends to take out the funds of that account as quickly as possible as well as that he intends to do that in a few large transactions because with each transaction the risk increases that the fraud gets discovered and the account gets frozen. With the *trade amount limits* in Bisq we have already a protection against that fraud scheme but we would like to increase the security by adding a verification scheme for the *age of the bank account*. To protect user privacy we use a hashing scheme and only the other trading peer - who will receive anyway the payment details during the trade process - is able to verify that the provided hash in the offer matches the real account data.
 
 NOTE: This proposal was implemented in Bisq v0.6.0
 
@@ -136,7 +136,7 @@ We need to be sure that the date of the trade in the AccountAgeWitness object ca
 
 A more advanced fraud approach would be an attempt of hijacking someone else's AccountAgeWitness and payment account to gain the benefit of an already aged account.
 
-A malicious trader could make a trade with someone who has already an old account and takes the account data of that trader to use it for an own account. That fake account can only be used for buying BTC because for selling he would not receive the Fiat money but the user from where he has "stolen" the data. Because he has traded with the peer he has received all the relevant data for the verification like the salt and the pubKey. To protect against such an hijacking attempt we use the peers signature to verify ownership of the AccountAgeWitness data. Without the private key the fraudster cannot create a correct signature matching the pubKey and input data. The public key is used for the hash in the AccountAgeWitness so he cannot alter that. The signed data is defined by the other peer and different for each trade so he has no chance to use data where he knows already the signature.
+A malicious trader could make a trade with someone who has already an old account and takes the account data of that trader to use it for an own account. That fake account can only be used for buying BTC because for selling he would not receive the Fiat money but the user from where he has "stolen" the data. Because he has traded with the peer he has received all the relevant data for the verification like the salt and the pubKey. To protect against such a hijacking attempt we use the peers signature to verify ownership of the AccountAgeWitness data. Without the private key the fraudster cannot create a correct signature matching the pubKey and input data. The public key is used for the hash in the AccountAgeWitness so he cannot alter that. The signed data is defined by the other peer and different for each trade so he has no chance to use data where he knows already the signature.
 
 
 === Changing a foreign AccountAgeWitness