WiP

docs/index.md

@@ -1,9 +1,11 @@
-# Unofficial Monero Documentation
+# Unofficial Monero Documentation (1% done)
 
 Monerodocs attempts to organize basic technical knowledge on Monero in one place.
 
 The goal is to educate and onboard power users faster.
 
-While technical explanations are out there, the information is scattered through reddit posts, git comments, stack exchange answers, chat logs and the source code. This makes it hard to find complete and up-to-date explanations on advanced topics.
+While technical explanations are out there, the information is scattered through reddit posts, git comments, stack exchange answers, chat logs and the source code.
+
+This makes it hard to find complete and up-to-date explanations on advanced topics.
 
 If you spot errors or issues please kindly drop me an email at [qertoip@gmail.com](mailto:qertoip@gmail.com?subject=monerodocs) or submit a github pull request.

docs/public-address/Integrated-Address.md

@@ -29,6 +29,10 @@ It totals to 78 bytes. The bytes are then encoded ([src](https://github.com/mone
 
 `4LL9oSLmtpccfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45DJ852K5Jv2bYXZKKQePHES9khPK`
 
+## Caveats
+
+Single transaction cannot pay to multiple integrated addresses.
+
 ## Reference
 
 * question on [StackExchenge](https://monero.stackexchange.com/questions/3179/what-is-an-integrated-address) 

docs/public-address/Subaddress.md

@@ -1,41 +1,55 @@
 # Subaddress
 
-Subaddresses serve two purposes.
+**!! This is unreleased feature !!**
+
+Subaddresses serve two purposes described below.
 
 ## Prevent payer from linking your payouts together
 
-To prevent the payer from linking your payouts together simply generate a new subaddress for each payout. This way services like [Shapeshift](https://shapeshift.io) wouldn't know it is you again receving Monero.
+To prevent the payer from linking your payouts together simply generate a new subaddress for each payout.
+This way services like [Shapeshift](https://shapeshift.io) wouldn't know it is you again receving Monero.
+
+Note it won't help if you have an account with the service. Then your payouts are already linked in the service database, regardless of Monero.
 
 ## Group incoming payments
 
 Think income streams.
 
-Subaddresses allow you to group your incoming transactions within a single wallet.
+Subaddresses allow to group incoming transactions within a single wallet.
 
-You may want to organize your incoming funds into a streams like "donations", "work", "pool payouts", etc.
+User interface allows to assign convenience labels to subaddresses.
 
-At first glance this is similar to subaccounts in your bank account. There is a very important difference though.
+You may want to organize your incoming funds into a streams like "donations", "work", etc.
 
-In Monero funds don't really sit on public addresses. Public addresses are conceptually a gateway or a routing mechanism. Funds sit on the unspent outputs. Thus, a single transaction can aggregate and spent outputs from multiple addresses. This means you can spend more than any individual address balance.
+This is similar to subaccounts in your bank account. There is a very important difference though.
+
+In Monero funds don't really sit on public addresses. Public addresses are conceptually a gateway or a routing mechanism. Funds sit on the unspent outputs. Thus, a single transaction can aggregate and spent outputs from multiple addresses.
 
 ## Why not multiple wallets?
 
-The advantage over creating multiple wallets is that you only have a single seed to manage. All subaddresses can be derived from the wallet seed.
+The advantage over creating multiple wallets is that you only have a **single seed** to manage.
+All subaddresses can be derived from the wallet seed.
 
-## Caveates
+Additionally, you conveniently manage your subaddresses within a single user interface.
 
-* 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.
+## Data structure
-* 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).
 
-## Implementation
+Subaddress has a dedicated "network byte":
-
-Each subaddress has an index (with 0 being the base standard address). User interface allows to assign convenience labels to subaddresses. However, labels are not preserved when recreating from seed.
 
 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
 
-TODO: finish
+Otherwise the data structure is the same as for [standard address](public-address/standard-address).
+
+Each subaddress conceptually has an index (with 0 being the base standard address).
+The index is not directly included in subaddress structure but is used as input to create the private spend key.
+
+## 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.
+* 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.
 
 ## Reference