Merge pull request #1268 from JeremyRubin/patch-1

Fix BIP-119 Typo + Clarify the reasons for 32 bit lengths

1 files changed, 11 insertions, 7 deletions

diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki
index 223e8dd..eecb709 100644
--- a/bip-0119.mediawiki
+++ b/bip-0119.mediawiki
@@ -356,13 +356,15 @@ spent. In general, using CHECKTEMPLATEVERIFY with more than one input is difficu
 and exposes subtle issues, so multiple inputs should not be used except in
 specific applications.
 
-In principal, committing to the Sequences Hash (below) implicitly commits to the number of inputs,
+In principle, committing to the Sequences Hash (below) implicitly commits to the number of inputs,
 making this field strictly redundant. However, separately committing to this number makes it easier
 to construct DefaultCheckTemplateVerifyHash from script.
 
-We treat the number of inputs as a `uint32_t` because signature checking code expects nIn to be an
-`unsigned int`, even though in principal a transaction can encode more than a `uint32_t`'s worth of
-inputs.
+We treat the number of inputs as a `uint32_t` because Bitcoin's consensus decoding logic limits vectors
+to `MAX_SIZE=33554432` and that is larger than `uint16_t` and smaller than `uint32_t`. 32 bits is also
+friendly for manipulation using Bitcoin's current math opcodes, should `OP_CAT` be added. Note that
+the max inputs in a block is further restricted by the block size to around 25,000, which would fit
+into a `uint16_t`, but that is an uneccessary abstraction leak.
 
 =====Committing to the Sequences Hash=====
 
@@ -378,12 +380,14 @@ script.
 
 =====Committing to the Number of Outputs=====
 
-In principal, committing to the Outputs Hash (below) implicitly commits to the number of outputs,
+In principle, committing to the Outputs Hash (below) implicitly commits to the number of outputs,
 making this field strictly redundant. However, separately committing to this number makes it easier
 to construct DefaultCheckTemplateVerifyHash from script.
 
-We treat the number of outputs as a `uint32_t` because a `COutpoint` index is a `uint32_t`, even
-though in principal a transaction could encode more outputs.
+We treat the number of outputs as a `uint32_t` because a `COutpoint` index is a `uint32_t`.
+Further, Bitcoin's consensus decoding logic limits vectors to `MAX_SIZE=33554432` and that is
+larger than `uint16_t` and smaller than `uint32_t`. 32 bits is also friendly for manipulation using
+Bitcoin's current math opcodes, should `OP_CAT` be added.
 
 =====Committing to the outputs hash=====