bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-05-12 12:03:29 +00:00
Code Issues Releases Wiki Activity

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

Browse Source 
when drafting the BIP I attempted to triangulate what the width of the fields for number of inputs/outputs should be from various sources in the codebase, and made an error in looking at the signing and encoding logic, and not the _decoding_ logic which restricts vectors (vin, vout) to MAX_SIZE which is 33554432. This fully justifies not using a wider type (uint64_t).

Also clarified arguments for not using a narrower type (uint16_t) which would be possible just for the vIn based on block size, because it's a leaky abstraction (you can still encode and decode such a transaction,  just not mine it).


thanks to @roconnor-blockstream for pointing this out
This commit is contained in:
Jeremy Rubin 2022-01-04 16:11:30 -08:00 committed by GitHub
parent a3a397c823
commit b96b1712fc
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 11 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
bip-0119.mediawiki
View File

@ -326,13 +326,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 and exposes subtle issues, so multiple inputs should not be used except in
specific applications. 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 making this field strictly redundant. However, separately committing to this number makes it easier
to construct DefaultCheckTemplateVerifyHash from script. to construct DefaultCheckTemplateVerifyHash from script.
We treat the number of inputs as a `uint32_t` because signature checking code expects nIn to be an We treat the number of inputs as a `uint32_t` because Bitcoin's consensus decoding logic limits vectors
`unsigned int`, even though in principal a transaction can encode more than a `uint32_t`'s worth of to `MAX_SIZE=33554432` and that is larger than `uint16_t` and smaller than `uint32_t`. 32 bits is also
inputs. 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===== =====Committing to the Sequences Hash=====
@ -348,12 +350,14 @@ script.
=====Committing to the Number of Outputs===== =====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 making this field strictly redundant. However, separately committing to this number makes it easier
to construct DefaultCheckTemplateVerifyHash from script. to construct DefaultCheckTemplateVerifyHash from script.
We treat the number of outputs as a `uint32_t` because a `COutpoint` index is a `uint32_t`, even We treat the number of outputs as a `uint32_t` because a `COutpoint` index is a `uint32_t`.
though in principal a transaction could encode more outputs. 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===== =====Committing to the outputs hash=====