Fix typos

Author: rex4539

dao/specification.adoc

@@ -160,7 +160,7 @@ Periods are defined in block height. Each period is separated with a break of 10
 
  - Publishing compensation requests (3630 blocks, about 25 days)
  - Voting: Approve/decline compensation requests (450 blocks, about 3 days)
- - Voting commitment: The voters publish the decryption key and vot on their vote data consensus (300 blocks, about 2 days)
+ - Voting commitment: The voters publish the decryption key and vote on their vote data consensus (300 blocks, about 2 days)
  - Issuance of new BSQ (happens directly and automatically after the vote commitment is completed)
 
 The full cycle will last 4380 blocks which is about an average month if one block takes in average 10 min. The interval of 1 month has been used in the phase zero and can be considered as practical.
@@ -200,12 +200,12 @@ The range for allowed amounts for a compensation request payout will be 50 BSQ t
 
  * There have to be one OP_RETURN output as last output
  * The amount at the OP_RETURN output has to be 0
- * The first byte in the OP_RETURN data need to be the type byte: 0x01
- * The second byte in the OP_RETURN data need to match the nodes version byte: 0x01 (requests made with older versions are invalid)
+ * The first byte in the OP_RETURN data needs to be the type byte: 0x01
+ * The second byte in the OP_RETURN data needs to match the nodes version byte: 0x01 (requests made with older versions are invalid)
  * Size of OP_RETURN data is 22 bytes
  * There has to be a BSQ input for the fee payment
  * BSQ used for fee need to be mature
- * The fee need to match the fee defined for that cycle (can be changed by voting at each new cycle)
+ * The fee needs to match the fee defined for that cycle (can be changed by voting at each new cycle)
  * The block height must be in the correct period
  * It needs to have at least one output to the address defined in the compensation request data
 
@@ -221,8 +221,8 @@ Contributors need to have the latest version installed when doing a request to b
  * Output 4 (last): OP_RETURN data as defined above
  * Mining fee: 0.00050000 (0.00049900 BTC from input 2 + 0.00000100 BTC or 1 BSQ from input 1)
 
-The input 1 need to be larger than the fee so we enforce a BSQ change output (output 1). All outputs must not be smaller than the dust limit (2730 Satoshi). We require that the BSQ change is at input 0 and mandatory to have a clearly defined output index for the issuance output. The BSQ change output cannot be after the issuance output as that is interpreted as BTC as long it got not successfully voted.
- The BTC input at input 2 need to be at least the sum of the requested BSQ and the miner fee, in our case 0.00500000 BTC (requested BSQ) + 0.00049900 BTC miner fee.
+The input 1 needs to be larger than the fee so we enforce a BSQ change output (output 1). All outputs must not be smaller than the dust limit (2730 Satoshi). We require that the BSQ change is at input 0 and mandatory to have a clearly defined output index for the issuance output. The BSQ change output cannot be after the issuance output as that is interpreted as BTC as long it got not successfully voted.
+ The BTC input at input 2 needs to be at least the sum of the requested BSQ and the miner fee, in our case 0.00500000 BTC (requested BSQ) + 0.00049900 BTC miner fee.
  Please note that the output 2 is at request time interpreted as BTC. Only after the request got accepted by voting the output will get interpreted as BSQ and thus the requester has issued himself BSQ.
 
 ==== Voting
@@ -268,13 +268,13 @@ To avoid an attack scenario where the malicious voter could try to disrupt the c
 
  * There have to be one OP_RETURN output as last output
  * The amount at the OP_RETURN output has to be 0
- * The first byte in the OP_RETURN data need to be the: 0x02 (type)
- * The second byte in the OP_RETURN data need to match the nodes version byte: 0x01 (votes made with older versions are invalid)
+ * The first byte in the OP_RETURN data needs to be the: 0x02 (type)
+ * The second byte in the OP_RETURN data needs to match the nodes version byte: 0x01 (votes made with older versions are invalid)
  * Size of OP_RETURN data needs to be 22 bytes
  * There have to be a BSQ input for the fee payment
  * BSQ used for fee need to be mature
  * There have to be exactly 1 BSQ output for the voting weight
- * The fee need to match the fee defined for that cycle (can be changed by voting at each new cycle)
+ * The fee needs to match the fee defined for that cycle (can be changed by voting at each new cycle)
  * The block height must be in the correct period
 
 Contributors need to have the latest version installed when participating in voting to be sure to have the same version as the verification nodes.
@@ -324,9 +324,9 @@ After the vote reveal period and the following break has ended all the compensat
 - Verification rules for the issuance transaction
 
  * The BSQ output is equal to that what has been defined in the compensation request
- * The issuance amount need to be in the range of the min. and max. allowed amount
+ * The issuance amount needs to be in the range of the min. and max. allowed amount
  * The block height must have been in the correct compensation request period
- * The compensation request need to be accepted in the voting process
+ * The compensation request needs to be accepted in the voting process
 
 ===== Scenarios for gaming the voting process
 
@@ -351,11 +351,11 @@ Both need to fulfill basic requirements (availability, quality of work,...). If
 
 ==== Lockup process
 
-To register as mediator or arbitrator one need to send the required amount of BSQ to an own BSQ address. This special transaction contains OP_RETURN data which are marking that transaction as lockup transaction (OP_RETURN type 0x04). Any spend transaction from this address would render the BSQ invalid as the only valid process to unlock those funds is to use the unlock transaction.
+To register as mediator or arbitrator one needs to send the required amount of BSQ to an own BSQ address. This special transaction contains OP_RETURN data which are marking that transaction as lockup transaction (OP_RETURN type 0x04). Any spend transaction from this address would render the BSQ invalid as the only valid process to unlock those funds is to use the unlock transaction.
 
 ==== Unlock process
 
-To unlock the funds he makes another transaction to himself with other OP_RETURN data (OP_RETURN type 0x05) which marks that transaction as an unlock request and will become available for spending after the lock time is over. The unlocking period is about 2 months (9000 blocks). The delay for unlocking is required to give the community enough time to act in case of abuse to prepare the steps for a possible confiscation. Therefore the lock period need to be rather long.
+To unlock the funds he makes another transaction to himself with other OP_RETURN data (OP_RETURN type 0x05) which marks that transaction as an unlock request and will become available for spending after the lock time is over. The unlocking period is about 2 months (9000 blocks). The delay for unlocking is required to give the community enough time to act in case of abuse to prepare the steps for a possible confiscation. Therefore the lock period needs to be rather long.
 
 ==== Confiscation
 

exchange/howto/run-seednode.adoc

@@ -19,7 +19,7 @@ But more critical is that if a node has bad connectivity it might miss messages
 
 The seed node addresses (onion address) are hard coded in the application but can be overruled if the user adds a seed node address as program argument. Any user can run therefor their own seed node and connect to it.
 
-Some contributors of Bisq are running the default seed 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 seed node and it requires that a certain quality of service is met. The node need to support at least 30 connections.
+Some contributors of Bisq are running the default seed 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 seed node and it requires that a certain quality of service is met. The node needs to support at least 30 connections.
 
 Contributors running a seed node will file a compensation request each month and get paid a fixed amount of BSQ for it if node availability was as expected.
 
@@ -30,7 +30,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.
+The operator of a seed node needs to be responsive in case of seed node software updates as well to OS updates. If there are connectivity issues he needs 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.
 
 

manual-dispute-payout.adoc

@@ -42,7 +42,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 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:
+In `Support > Arbitrator'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]
 

payment-account-age-witness.adoc

@@ -109,15 +109,15 @@ The offer maker will add the hash used in the AccountAgeWitness object to his of
 
 === Verification
 
-When a trader takes an offer both users are exchanging in the trade process the signature of data defined by the other peer (for taker we use the offer ID, for maker we use the takers preparedDepositTx - we use that data like a nonce for the signature), the pubKey, the salt and the peers local date. With that data the other peer can verify that the other trader is the owner of the AccountAgeWitness data (as the pugKey is part of the hash and the signature gets verified with pubKey and predefined input data) and that the hash is matching the account data used for the trade. As the date of both users will differ at least sightly we exchange the peers local date and use that for calculating the age and trade limit. The date need to be inside a 1 day tolerance otherwise the trade fails. That way we avoid problems with corner cases when the age just enters the next level for one peer but the verifying peer might get another result because of time differences. Any violation of those rules would lead to a failed trade.
+When a trader takes an offer both users are exchanging in the trade process the signature of data defined by the other peer (for taker we use the offer ID, for maker we use the takers preparedDepositTx - we use that data like a nonce for the signature), the pubKey, the salt and the peer's local date. With that data the other peer can verify that the other trader is the owner of the AccountAgeWitness data (as the pugKey is part of the hash and the signature gets verified with pubKey and predefined input data) and that the hash is matching the account data used for the trade. As the date of both users will differ at least slightly we exchange the peer's local date and use that for calculating the age and trade limit. The date needs to be inside a 1 day tolerance otherwise the trade fails. That way we avoid problems with corner cases when the age just enters the next level for one peer but the verifying peer might get another result because of time differences. Any violation of those rules would lead to a failed trade.
 
 
 ==== Verification steps
 1. Check if witness date is after release date for that feature (v. 0.6)
-2. Check if peers date is inside 1 day tolerance window
+2. Check if peer's date is inside 1 day tolerance window
 3. Verify if witness hash matches hash created from the data delivered by peer (ageWitnessInputData, salt, pubKey)
-4. Check if peers trade limit calculated with its account age is not lower than the trade amount.
-5. Verify if signature of the predefined input data (offer ID or preparedDepositTx) is correct using the peers pubKey.
+4. Check if peer's trade limit calculated with its account age is not lower than the trade amount.
+5. Verify if signature of the predefined input data (offer ID or preparedDepositTx) is correct using the peer's pubKey.
 
 
 NOTE: By using offer ID and preparedDepositTx for the nonce we avoid the need for a challenge protocol. We have chosen data which are defined by the other peer so they cannot be manipulated.
@@ -134,7 +134,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 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.
+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 peer's 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