add standard outputs to transaction limits docs

Author: mr-zwets

website/docs/compiler/script-limits.md

@@ -22,6 +22,10 @@ To keep contracts within size limits, consider modular design. Splitting contrac
 
 NFT commitments can store up to 40 bytes of data as local state. If more data is needed, you can hash the full state and store only the hash in the commitment data. Later, when required, the full state must be provided and validated against the stored hash.
 
+:::caution
+The 40-bytes limit on commitment length is of great practical importance for contract authors. Workarounds are needed to keep more bytes of local state in smart contracts.
+:::
+
 ### Operation cost limit
 
 Bitcoin Cash enforces an operation cost limit (op-cost) per transaction input. This determines the computational budget available for operations in a contract. The op-cost is based on script length: longer input scripts allow for a higher compute budget.
@@ -70,6 +74,16 @@ function calculateDust(outputSize: number): number {
 Before CashTokens `546` bytes was often used as good default value, however with tokenData outputs have become larger in size.
 For ease of development, it is standard practice to use 1,000 satoshis as dust to outputs. Provably unspendable outputs (OP_RETURN outputs) are exempt from this rule.
 
+### Output Standardness
+
+Bitcoin Cash only allows a few types of `lockingbytecode` scripts for outputs in the normal network relay rules. These are called 'standard outputs', contrasted to 'non-standard outputs' which cause the transaction not to relay on the network.
+
+There's 4 types of standard output types: `P2PKH`, `P2SH` (which includes `P2SH20` & `P2SH32`), `P2MS` and `OP_RETURN` data-outputs. For more details see the [standard outputs documentation][standard-outputs-docs].
+
+:::caution
+The `lockingbytecode` standardness rules can be important for smart contract developers, and is why CashScript has helpers like `LockingBytecodeP2PKH`, `LockingBytecodeP2SH32` and `LockingBytecodeNullData`.
+:::
+
 ## Summary table
 
 | Limit type | Constraint |
@@ -81,7 +95,9 @@ For ease of development, it is standard practice to use 1,000 satoshis as dust t
 | Max transaction size | 100,000 bytes |
 | Max OP_RETURN data size | 220 bytes data payload |
 | Dust threshold | based on output size (commonly 1,000 sats is used as dust) |
+| Output Standardness | `P2PKH`, `P2SH` (incl. `P2SH20` & `P2SH32`), `P2MS` and `OP_RETURN` data-outputs|
 
 For further details on transaction validation and standardness rules, see the [documentation on BCH transaction validation](https://documentation.cash/protocol/blockchain/transaction-validation.html).
 
 [op-cost-table]: https://github.com/bitjson/bch-vm-limits/blob/master/operation-costs.md
+[standard-outputs-docs]: https://documentation.cash/protocol/blockchain/transaction/locking-script.html