diff --git a/chapters/authorization-authentication.adoc b/chapters/authorization-authentication.adoc
index 4534b2b3..5b7f10a7 100644
--- a/chapters/authorization-authentication.adoc
+++ b/chapters/authorization-authentication.adoc
@@ -896,13 +896,26 @@ the transaction invalid if (source: BIP65):
 1. the top stack item is greater than the transaction's +nLockTime+ field; or
 1. the +nSequence+ field of the input is 0xffffffff.
 
-[NOTE]
+[[timelock_conflicts]]
+.Timelock conflicts
+[WARNING]
 ====
 +OP_CLTV+ and +nLockTime+ use the same format to describe timelocks, either
 a block height or the time elapsed in seconds since Unix epoch.
 Critically, when used together, the format of +nLockTime+ must match
 that of +OP_CLTV+ in the outputs--they must both reference either
 block height or time in seconds.
+
+The above implies that a script can never be valid if it must execute
+two different calls to +OP_CLTV+, one which uses a height and one which
+uses a time.  It can be easy to make this mistake when writing advanced
+scripts, so be sure to thoroughly test your scripts on a test network or
+use a tool designed to prevent this issue, like a Miniscript compiler.
+
+An additional implication is that only one variety of +OP_CLTV+ can be
+used in any of the scripts of a transaction.  If the script for one
+input uses the height variety and a different script for a different
+input uses the time variety, there is no way to construct a valid transaction.
 ====
 
 After execution, if +OP_CLTV+ is satisfied, the parameter that
@@ -981,6 +994,15 @@ blocks, then so must +nSequence+. If +OP_CSV+ is specified in terms of
 seconds, then so must +nSequence+.
 
 Relative timelocks with +CSV+ are especially useful when several
+[[WARNING]]
+====
+A script executing multiple +OP_CSV+ opcodes must only use the same
+variety, either time-based or height-based.  Mixing varieties will
+produce an invalid script that can never be spent, the same problem we
+saw with +OP_CLTV+ in <<timelock_conflicts>>.  However, +OP_CSV+ allows
+any two valid inputs to be included in the same transaction, so the problem
+of interaction across inputs that occurs with +OP_CLTV+ doesn't affect +OP_CSV+.
+====
 (chained) transactions are created and signed, but not propagated, when
 they're kept "off-chain." A child transaction cannot be used until the
 parent transaction has been propagated, mined, and aged by the time