Improve content on integrated addresses

docs/public-address/integrated-address.md

@@ -1,17 +1,14 @@
 # Integrated address
 
-Monero integrated address embeds a compact payment ID.
+Integrated addresses are ideal for accepting Monero in an automated fashion - like in online stores and exchanges.
 
-Use integrated address to learn for what you are being paid. It is ideal for accepting Monero in an automated fashion,
-like online stores and exchanges.    
+Monero integrated address embeds a payment ID. This allows you to learn for what you are being paid.
 
-You should allow Monero software to generate integrated addresses for you (instead of forcing your own payment IDs).
 Please note these are Monero technical payment IDs and must not be confused with business identifiers like order number or invoice number.
 
 The transaction to integrated address will not reveal the payment ID publicly.
 Payment ID in a transaction will be encrypted with a shared secret (one-time random key known only to sender and recipient).
 Only the recipient will be able to match the transaction against payment ID.
-TODO: explain how exactly payment IDs are encoded in transactions.
 
 Monero integrated address obsoletes the former practice of using full 32-bytes payment ID in a transaction extra field (where it was not encrypted).
 
@@ -29,9 +26,31 @@ It totals to 77 bytes. The bytes are then encoded ([src](https://github.com/mone
 
 `4LL9oSLmtpccfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45DJ852K5Jv2bYXZKKQePHES9khPK`
 
+## Integrated addresses vs subaddresses
+
+Both types allow you to learn for what you are being paid.
+
+**Individuals** should prefer **subaddresses** to receive payments. This is to improve privacy in certain scenarios. See article on [subaddresses](/public-address/subaddress) for details.
+
+**Businesses** accepting payments in an automated way should prefer **integrated addresses**. The rationale is as follows:
+
+* Scenario where subaddresses improve privacy is not applicable for businesses b/c businesses have the same identity over time. Consequently, subaddresses provide no benefits over integrated addresses.
+
+* No private key is necessary to generate integrated address. This provides a strong security advantage because services that generate integrated addresses need no access to wallet. In contrast, to generate a subaddress, one needs a private view key.
+
+* No shared counter is necessary to generate integrated address. This allows individual services to independently generate integrated addresses w/o synchronizing on a common sequence. In contrast, subaddresses are generated sequentially, and so the sequence (the counter or index) is a coupling point between the wallet and all services that need to generate the address. Back to integrated addresses, note that embedded payment IDs are 64-bit. This means the space is large enough that one can simply generate them randomly and reliably assume uniqueness.
+
+* In very specific scenarios, preparation effort to monitor a very huge number of subaddresses, could became an issue. See [this reddit thread](https://www.reddit.com/r/Monero/comments/9aevri/is_it_fair_to_say_integrated_addresses_are/e4vf47p) for details.
+
+
 ## Caveats
 
-Single transaction cannot pay to multiple integrated addresses.
+There are some caveates:
+
+* Single transaction cannot pay to multiple integrated addresses.
+
+* As individual running a wallet you should generally prefer subaddresses. However, if you happen to use integrated addresses, you should allow Monero software to generate integrated addresses for you (instead of forcing your own payment IDs).
+
 
 ## Reference
 

docs/public-address/main-address.md

@@ -8,11 +8,11 @@ Publishing your Monero address does __not__ endanger your privacy. That's becaus
 
 There are a few **types of public addresses** in Monero:
 
-* Standard address - basic type of an address, also refered to as raw address
+* Main address - basic type of an address, also refered to as raw address
 * Subaddress - what you should be using by default
 * Integrated address - relevant for exchanges, merchants, and other businesses accepting Monero in a fully automated way
 
-## Standard address
+## Main address
 
 Historicaly, raw address was the only available option. For that reason it is the most widely adopted and supported address type.
 
@@ -42,13 +42,15 @@ Index       | Size in bytes    | Description
 33          | 32               | public view key
 65          | 4                | checksum ([Keccak-f[1600] hash](https://github.com/monero-project/monero/blob/8f1f43163a221153403a46902d026e3b72f1b3e3/src/common/base58.cpp#L261) of the previous 65 bytes, trimmed to first [4](https://github.com/monero-project/monero/blob/8f1f43163a221153403a46902d026e3b72f1b3e3/src/common/base58.cpp#L53) bytes)
 
-It totals to 69 bytes. The bytes are then encoded ([src](https://github.com/monero-project/monero/blob/8f1f43163a221153403a46902d026e3b72f1b3e3/src/common/base58.cpp#L240)) in [Monero specific Base58](/cryptography/base58) format, resulting in a 95 chars long string. Example standard address:
+It totals to 69 bytes. The bytes are then encoded ([src](https://github.com/monero-project/monero/blob/8f1f43163a221153403a46902d026e3b72f1b3e3/src/common/base58.cpp#L240)) in [Monero specific Base58](/cryptography/base58) format, resulting in a 95 chars long string. Example main address:
 
 `4AdUndXHHZ6cfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45DJ852K5Jv2684Rge`
 
 ## Generating
 
-Standard address is derived from the root private key. TODO: describe.
+Main address is derived from the root private key.
+
+TODO: describe.
 
 ## Reference
 

docs/public-address/subaddress.md

@@ -48,9 +48,9 @@ Index       | Size in bytes    | Description
 ------------|------------------|-------------------------------------------------------------
 0           | 1                | identifies the network and address type; [42](https://github.com/monero-project/monero/blob/784f7b07f05a645d43f62ed3a9cefda4b0c57825/src/cryptonote_config.h#L153) - main chain; [63](https://github.com/monero-project/monero/blob/784f7b07f05a645d43f62ed3a9cefda4b0c57825/src/cryptonote_config.h#L167) - test chain
 
-Otherwise the data structure is the same as for [standard address](/public-address/standard-address/).
+Otherwise the data structure is the same as for [main address](/public-address/main-address/).
 
-Each subaddress conceptually has an index (with 0 being the base standard address).
+Each subaddress conceptually has an index (with 0 being the main address).
 The index is not directly included in subaddress structure but is used as input to create the private view key.
 
 ## Generating
@@ -71,7 +71,7 @@ TODO: describe rest of the procedure.
 
 ## Caveates
 
-* Subaddress **cannot** be used to receive transactions having multiple destinations (e.g. pool payouts). Only the standard address (the one with index == 0) can receive such transactions.
+* Subaddress **cannot** be used to receive transactions having multiple destinations (e.g. pool payouts). Only the main address (the one with index == 0) can receive such transactions.
 * It is not recommended to sweep all the balances of subaddress to main address in a single transaction. That links the subaddresses together on the blockchain. However, this only concerns privacy against specific sender and the situation will never get worse than not using subaddresses in the first place. If you need to join funds while preserving maximum privacy do it with individual transactions (one per subaddress).
 * Convenience labels are not preserved when recreating from seed.
 

mkdocs.yml

@@ -21,7 +21,7 @@ nav:
 #    - CryptoNight PoW: 'cryptography/cryptonight.md'
     - Base58: 'cryptography/base58.md'
 - Address:
-    - Standard: 'public-address/standard-address.md'
+    - Main: 'public-address/main-address.md'
     - Subaddress: 'public-address/subaddress.md'
     - Integrated: 'public-address/integrated-address.md'
 - Multisignature: 'multisignature.md'