Date: Fri, 08 Nov 2019 05:11:53 +0000
To: Pieter Wuille <pieter.wuille@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <sZtrFEIbPoH5v6IpNboec9kgSui-E8QLHllL3u3TgB42iRU3zkzi6cJuGTqUp1-9MMp0kURGuMRCmBv9AC6e9RPmMZpGVSAr0-HSRfyfhzM=@protonmail.com>
In-Reply-To: <CAPg+sBjC-D2iWYywj_X-evQoWx56nb0YnASLVwCSCzWT6Guu3A@mail.gmail.com>
References: <CAPg+sBjC-D2iWYywj_X-evQoWx56nb0YnASLVwCSCzWT6Guu3A@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot
	addresses
Precedence: list

Good morning Pieter, and all,

Can we modify Bech32 SegWit address format for version 1 and above as below=
?

      * The data-part values:
      ** 1 byte: the witness version
    + ** If the witness version is non-zero, 1 byte: the length of the witn=
ess program.
      ** A conversion of the 2-to-40-byte witness program (as defined by [h=
ttps://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) to b=
ase32:
      *** Start with the bits of the witness program, most significant bit =
per byte first.
      *** Re-arrange those bits into groups of 5, and pad with zeroes at th=
e end if needed.
      *** Translate those bits to characters using the table above.

This retains the ability of a bech32 address to specify any valid witness l=
ength and allows future version 1 addresses with lengths other than 32, whi=
le closing this malleation.

Older software being given the modified v1 address format would mis-send it=
 to the wrong witness program, however.

Alternately we could just keep using version 0 in the address format foreve=
r.
The requirement would be to ensure that SegWit vN (N >=3D 1) output witness=
 programs would have a data-part value encoded as below:

    * The data-part values:
    ** 1 byte: legacy witness version, which must always be 0.
    ** 1 byte: actual witness version, which must be non-zero.
    ** 1 byte: padding length: 0 or 1.
    ** If padding length is 1, 1 byte: padding, which must be 0.
    ** 1 byte: witness program length.
    ** variable: witness program.

A writer for a v1 or later address would initially set an empty padding, th=
en compute:

      1 // actual witness version
    + 1 // padding length
    + 1 // witness length
    + witness_length

If the above sum is 20 or 32, then the writer selects a non-zero padding an=
d inserts the padding byte so that the above sum is now 21 or 33.

To a reader that understands only bech32 v0, such an encoding would look li=
ke a SegWit v0 invalid-program-length, and be rejected.
A reader which understands the above protocol would, instead of rejecting a=
 SegWit v0 invalid-program-length, instead attempt to parse it as above fir=
st, and consider it as SegWit v1 or higher if it was parsed correctly as ab=
ove.

The above proposal is of course ridiculous and I am now currently running d=
iagnostics on my processing units to see if further glitches occur in test =
reasoning skills.

Regards,
ZmnSCPxj