bip-0054: mention Luke's extranonce concern in rationale

bip-0054.md

@@ -118,7 +118,13 @@ early [bip-0034][BIP34] violations also allows applications to recover the block
 having to parse Script. Leveraging the existing timelock mechanism makes the check self-contained:
 the same coinbase transaction cannot have been valid in a previous block[^11]. This simplifies both
 reasoning and client implementation, since the [bip-0030][BIP30] check can be skipped entirely past
-Consensus Cleanup activation, regardless of the [bip-0034][BIP34] activation status[^12].
+Consensus Cleanup activation, regardless of the [bip-0034][BIP34] activation status[^12]. One person
+[raised the concern][miningdev nLockTime] that the `nLockTime` field would be an ideal extranonce
+for ASIC controllers if such controllers ever became a bottleneck in mining operations. Others
+[replied][miningdev nLockTime] that the same benefits could be achieved by using a dummy output
+instead, should that ever become necessary. The authors [believe][ML remaining concerns] the
+benefits of using `nLockTime` to differentiate coinbase transactions outweigh the theoretical
+cost of making it unavailable for extranonce rolling by ASIC controllers.
 
 ## Backward compatibility
 
@@ -251,3 +257,5 @@ MERKLEBLOCK] for a full description.
 [inquisition-implem]: https://github.com/darosior/bitcoin/tree/2509_inquisition_consensus_cleanup
 [Core 30.0]: https://bitcoincore.org/en/releases/30.0
 [Core validation.cpp BIP34]: https://github.com/bitcoin/bitcoin/blob/390e7d61bd531505bb3d13f38316c282b85ed1dd/src/validation.cpp#L2401-L2459
+[miningdev nLockTime]: https://groups.google.com/g/bitcoinminingdev/c/jlqlNHHNSNk
+[ML remaining concerns]: https://gnusha.org/pi/bitcoindev/UsKuvCXXhSAnNVx5a0K2UfP3srAr3slW9mcOjtYk9LnolaOXfWrW9jpqbxsQQPkyQuZogkhz2Hbfwii2VsTm79vRDpgKduxk35hpBu_t7Do=@protonmail.com/