public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses
Date: Fri, 08 Nov 2019 05:11:53 +0000	[thread overview]
Message-ID: <sZtrFEIbPoH5v6IpNboec9kgSui-E8QLHllL3u3TgB42iRU3zkzi6cJuGTqUp1-9MMp0kURGuMRCmBv9AC6e9RPmMZpGVSAr0-HSRfyfhzM=@protonmail.com> (raw)
In-Reply-To: <CAPg+sBjC-D2iWYywj_X-evQoWx56nb0YnASLVwCSCzWT6Guu3A@mail.gmail.com>

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 witness program.
      ** A conversion of the 2-to-40-byte witness program (as defined by [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) to base32:
      *** 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 the 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 length and allows future version 1 addresses with lengths other than 32, while 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 forever.
The requirement would be to ensure that SegWit vN (N >= 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, then 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 and 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 like 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 first, and consider it as SegWit v1 or higher if it was parsed correctly as above.

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

Regards,
ZmnSCPxj


  parent reply	other threads:[~2019-11-08  5:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-07 22:35 [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses Pieter Wuille
2019-11-07 22:45 ` Greg Sanders
2019-11-08  0:41   ` Matt Corallo
2019-11-08  2:15 ` David A. Harding
2019-11-08  3:15   ` Eric Voskuil
2019-11-10 21:51   ` Pieter Wuille
2019-11-11  1:02     ` Matt Corallo
2019-11-13  2:56       ` Clark Moody
2019-11-13  5:32         ` ZmnSCPxj
2019-11-13  6:30           ` Pieter Wuille
2020-07-15 20:56             ` Russell O'Connor
2020-07-15 21:05               ` Greg Sanders
2020-07-15 21:11                 ` Russell O'Connor
2019-11-08  5:11 ` ZmnSCPxj [this message]
2019-11-08 13:03   ` Russell O'Connor
2019-11-08 13:42     ` Damian Mee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='sZtrFEIbPoH5v6IpNboec9kgSui-E8QLHllL3u3TgB42iRU3zkzi6cJuGTqUp1-9MMp0kURGuMRCmBv9AC6e9RPmMZpGVSAr0-HSRfyfhzM=@protonmail.com' \
    --to=zmnscpxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=pieter.wuille@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox