From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 00D83146B for ; Fri, 8 Nov 2019 13:42:27 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-il1-f178.google.com (mail-il1-f178.google.com [209.85.166.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E91B5712 for ; Fri, 8 Nov 2019 13:42:25 +0000 (UTC) Received: by mail-il1-f178.google.com with SMTP id n18so5142902ilt.9 for ; Fri, 08 Nov 2019 05:42:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meedamian.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=xQdx6QlIyljE3uNw6/ghqa+KQ0Ws6mdbws5UB8UwTnc=; b=KkC1Mm81qeTHHXzqH9AAoQLImu7eifas7gccZzMorvPumYeXr8CrT0xQ7vEqLKDIXe /4OgmMsXegIDm9TlA3bA+FIznHzs8XfBxKcMdDquvcyBjJFDbvd08PoNM9N//S6M5goa PPT2M381MzHNZHTLgb28Rs5c2niB2HTliCAxo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=xQdx6QlIyljE3uNw6/ghqa+KQ0Ws6mdbws5UB8UwTnc=; b=e6kXqVkp+TP6Bg/Tr8NaFur/dAQ8SGHrvnm4iKEeIcEjRhn3asu304S1agQFdpigSm kgmeLNCfpvnj92t/h38PezEpbYm8kcJNwjOUtfZ7euwmqwEEIOWWJaHUcY746cLfbfjq FyvKIehB8QpcnrAc9RTV//kzTOXUwboGUj//brAlvho3YZ5sYk6FhS6gGKsEC7PyI0c9 pfYZPmHFLAY3XI1sl6f90gRrsksjbXhNeFBJbVqVjRBKC/SELG+920B63iPFcJiKgTT4 r7RUuL72s5YY2XW9FcetLPYK90psK1bj5tNSLiZ91q1q5hJut4cFljKukbMlWbzklNPw UTmg== X-Gm-Message-State: APjAAAV3anmkrKRnumzWhtHMhldhjHmiqa21c5t2V46DKYKwNL5ZVKZh RBq7iqw9udy49HmlraF+tscvOzZGmZmsfkv3PyEQv2v4IU7+odqP X-Google-Smtp-Source: APXvYqynoCVKUOcMLr7OYCZGwP+Mle7YdJn4WxbE4SDjulk1YpIOTE4a+9WJgH6de0rOfaU2xMSnnbsmZSSjKWBAHHY= X-Received: by 2002:a92:9cce:: with SMTP id x75mr12680246ill.31.1573220545073; Fri, 08 Nov 2019 05:42:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Damian Mee Date: Fri, 8 Nov 2019 14:42:13 +0100 Message-ID: To: "Russell O'Connor" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000be2f110596d5f37c" X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED, DOS_RCVD_IP_TWICE_B, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 08 Nov 2019 14:24:32 +0000 Subject: Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 13:42:27 -0000 --000000000000be2f110596d5f37c Content-Type: text/plain; charset="UTF-8" > a new human-readable-prefix for length prefixed bitcoin witness programs. "btc1" anyone? Yes, please! On Fri, Nov 8, 2019 at 2:04 PM Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I do like the idea of length prefixing the witness program. I will note > that the 1 byte witness version is really more like a 1 character witness > version. There are 17 different segwit versions and there are 32 > characters in the bech32 alphabet. That leaves 15 unused characters that > we can use for assigning new meanings too. > > That said, it is probably most sensible to define a new > human-readable-prefix for length prefixed bitcoin witness programs. "btc1" > anyone? > > On Fri, Nov 8, 2019 at 12:12 AM ZmnSCPxj via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> 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 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000be2f110596d5f37c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> a new human-readable-prefix for length prefixed bitco= in witness programs.=C2=A0 "btc1" anyone?

Yes,= please!

On Fri, Nov 8, 2019 at 2:04 PM Russell O'Connor via bit= coin-dev <bitco= in-dev@lists.linuxfoundation.org> wrote:
I do like the idea o= f length prefixing the witness program.=C2=A0 I will note that the 1 byte w= itness version is really more like a 1 character witness version.=C2=A0 The= re are 17 different segwit versions and there are 32 characters in the bech= 32 alphabet.=C2=A0 That leaves 15 unused characters that we can use for ass= igning new meanings too.

That said, it is probably= most sensible to define a new human-readable-prefix for length prefixed bi= tcoin witness programs.=C2=A0 "btc1" anyone?

On Fri, Nov 8, 20= 19 at 12:12 AM ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundati= on.org> wrote:
Good morning Pieter, and all,

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

=C2=A0 =C2=A0 =C2=A0 * The data-part values:
=C2=A0 =C2=A0 =C2=A0 ** 1 byte: the witness version
=C2=A0 =C2=A0 + ** If the witness version is non-zero, 1 byte: the length o= f the witness program.
=C2=A0 =C2=A0 =C2=A0 ** A conversion of the 2-to-40-byte witness program (a= s defined by [https://github.com/bitco= in/bips/blob/master/bip-0141.mediawiki BIP141]) to base32:
=C2=A0 =C2=A0 =C2=A0 *** Start with the bits of the witness program, most s= ignificant bit per byte first.
=C2=A0 =C2=A0 =C2=A0 *** Re-arrange those bits into groups of 5, and pad wi= th zeroes at the end if needed.
=C2=A0 =C2=A0 =C2=A0 *** 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 witn= ess programs would have a data-part value encoded as below:

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

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

=C2=A0 =C2=A0 =C2=A0 1 // actual witness version
=C2=A0 =C2=A0 + 1 // padding length
=C2=A0 =C2=A0 + 1 // witness length
=C2=A0 =C2=A0 + 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
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000be2f110596d5f37c--