Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning all,

It seems to me that adding the length for checksumming purposes need not require the length to be *actually* added in the address format.

So, currently, below is my understanding of bech32 validation:

* Run BCH checksum on witness program.
* Compare checksum to checksum in address.
  * If the checksum matches:
    * If version is 0, validate that the witness program is length 20 or 32.
    * Else accept.
  * If the checksum does not match:
    * Reject

Let me propose then:

* Run BCH checksum on witness program.
* Compare checksum to checksum in address.
  * If the checksum matches:
    * If version is 0, validate that the witness program is length 20 or 32.
    * Else validate that the witness program is length 32.
  * If the checksum does not match:
    * Get the length of the witness program.
    * Prepend the length to the witness program.
    * Run BCH checksum on concatenated length | witness program.
    * Compare checksum to checksum in address.
      * If the checksum matches:
        * Accept.
      * Else reject.

A writer of bech32 addresses would then:

* If the witness program is length 32, or witness version is 0 and witness program length is 20, use a non-length-prefixed checksum.
* Otherwise, use a length-prefixed checksum (but not include the length in the address, just change the BCH checksum).

This has the following properties:

* The bech32 address format is retained, and no explicit length is added.
* There are now two checksum formats: one with just the witness program, the other which validates with the witness program length.
  * Readers that do not understand the new checksum format will simply reject them without mis-sending to the wrong witness program.

Is the above acceptable?

Regards,
ZmnSCPxj