Be more explicit about ext_flag values in BIP118 #1335

1. 
   instagibbs commented at 3:07 pm on June 22, 2022: member

   I find it difficult to reason about as-written, even if implicitly it may be correct.

   cc @ajtowns

2. Be more explicit about ext_flag values in BIP118

   I find it difficult to reason about as-written, even if implicitly it may be correct.

   89a363f54c
3. in bip-0118.mediawiki:85 in 89a363f54c

   81@@ -82,7 +82,7 @@ We define the following constants using bits 6 and 7 of <code>hash_type</code>:
   82 * <code>SIGHASH_ANYPREVOUT = 0x40</code>
   83 * <code>SIGHASH_ANYPREVOUTANYSCRIPT = 0xc0</code>
   84 
   85-As per [[bip-0341.mediawiki|BIP 341]], the parameter ''ext_flag'' is an integer in the range 0-127, used for indicating that extensions are added at the end of the message. The parameter ''key_version'' is an 8-bit unsigned value (an integer in the range 0-255) used for committing to the public key version.
   86+As per [[bip-0341.mediawiki|BIP 341]], the parameter ''ext_flag'' is an integer in the range 0-127, used for indicating that extensions are added at the end of the message, with the value of ''0'' indicating no extension, and ''1'' indicating the presence of ''SigExt118(hash_type,key_version)''. The parameter ''key_version'' is an 8-bit unsigned value (an integer in the range 0-255) used for committing to the public key version.
   

   ---

   ---

   

   ajtowns commented at 5:47 am on June 24, 2022:

   What it’s intending to describe is:

   • BIP 341’s SigMsg behaviour is covered by SigMsg(h,0) = SigMsg118((h & ~0x40), 0)
   • BIP 342’s is covered by SigMsg(h, 1) = SigMsg118((h & ~0x40), 1) and ext = SigExt118(h, 0)
   • BIP 118 introduces new behaviour for SigMsg118((h | 0x40), 1) and SigExt118(h, 1)

   But maybe it would be better to change it entirely, and describe it more like:

   • If sig is not 64 or 65 bytes, fail.
   • If sig is 64 bytes:
     • hash_type = 0
     • sig_data = sig
   • If sig is 65 bytes:
     • hash_type = sig[64]. If hash_type == 0, fail.
     • sig_data = sig[0:64]
   • Return Verify(p, hash<sub>TapSigHash</sub>(0x00 || msg_and_ext, sig_data) where Verify is as defined in BIP 340, and where msg_and_ext is defined as:
     • If hash_type & 0x40 = 0, msg = SigMsg(hash_type, 1) per BIP341.
     • If hash_type & 0x40 != 0, msg = SigMsg118(hash_type) as “above”.
     • msg_and_ext = msg || Ext118(hash_type) as “above”.

   Then the definition of SigMsg118 only needs to deal with ANYPREVOUT signatures, and Ext118 can hard code key version 0x01.

   ---

   

   ajtowns commented at 8:18 pm on September 19, 2022:

   See #1367

   ---

   

   instagibbs commented at 8:19 pm on September 19, 2022:

   will review
4. Mertz22 approved
5. luke-jr added the label Proposed BIP modification on Jul 25, 2022
6. 
   ajtowns commented at 8:39 am on October 7, 2022: contributor

   #1367 was merged, so I guess this can be closed?
7. 
   instagibbs commented at 11:04 am on October 7, 2022: member

   Yes

   On Fri, Oct 7, 2022, 4:39 AM Anthony Towns @.***> wrote:

   #1367 https://github.com/bitcoin/bips/pull/1367 was merged, so I guess this can be closed?

   — Reply to this email directly, view it on GitHub https://github.com/bitcoin/bips/pull/1335#issuecomment-1271296927, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMAFUYOFHNOJZTF5L6E2ETWB7OVTANCNFSM5ZQS3W5A . You are receiving this because you authored the thread.Message ID: @.***>

8. fanquake closed this on Oct 10, 2022

   ---

Contributors
instagibbs ajtowns Mertz22

Labels
Proposed BIP modification