Return-Path: <hello@meedamian.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 00D83146B for <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; Fri, 8 Nov 2019 13:42:25 +0000 (UTC) Received: by mail-il1-f178.google.com with SMTP id n18so5142902ilt.9 for <bitcoin-dev@lists.linuxfoundation.org>; 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: <CAPg+sBjC-D2iWYywj_X-evQoWx56nb0YnASLVwCSCzWT6Guu3A@mail.gmail.com> <sZtrFEIbPoH5v6IpNboec9kgSui-E8QLHllL3u3TgB42iRU3zkzi6cJuGTqUp1-9MMp0kURGuMRCmBv9AC6e9RPmMZpGVSAr0-HSRfyfhzM=@protonmail.com> <CAMZUoK=QFPAzZzxFOA6ZYez_dwCTi_OxYup19w32suDvBdXJoQ@mail.gmail.com> In-Reply-To: <CAMZUoK=QFPAzZzxFOA6ZYez_dwCTi_OxYup19w32suDvBdXJoQ@mail.gmail.com> From: Damian Mee <btc@meedamian.com> Date: Fri, 8 Nov 2019 14:42:13 +0100 Message-ID: <CANeGfAeOK3bC+NkAtYaT-6XVmi8_200rU_=Jv7OszEGdkXN85g@mail.gmail.com> To: "Russell O'Connor" <roconnor@blockstream.io>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> 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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <div dir=3D"ltr">> a new human-readable-prefix for length prefixed bitco= in witness programs.=C2=A0 "btc1" anyone?<div><br></div><div>Yes,= please!</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class= =3D"gmail_attr">On Fri, Nov 8, 2019 at 2:04 PM Russell O'Connor via bit= coin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco= in-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>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.</div><div><br></div><div>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?<br></div><br><div cl= ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Nov 8, 20= 19 at 12:12 AM ZmnSCPxj via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@l= ists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundati= on.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m= argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left= :1ex">Good morning Pieter, and all,<br> <br> Can we modify Bech32 SegWit address format for version 1 and above as below= ?<br> <br> =C2=A0 =C2=A0 =C2=A0 * The data-part values:<br> =C2=A0 =C2=A0 =C2=A0 ** 1 byte: the witness version<br> =C2=A0 =C2=A0 + ** If the witness version is non-zero, 1 byte: the length o= f the witness program.<br> =C2=A0 =C2=A0 =C2=A0 ** A conversion of the 2-to-40-byte witness program (a= s defined by [<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-01= 41.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitco= in/bips/blob/master/bip-0141.mediawiki</a> BIP141]) to base32:<br> =C2=A0 =C2=A0 =C2=A0 *** Start with the bits of the witness program, most s= ignificant bit per byte first.<br> =C2=A0 =C2=A0 =C2=A0 *** Re-arrange those bits into groups of 5, and pad wi= th zeroes at the end if needed.<br> =C2=A0 =C2=A0 =C2=A0 *** Translate those bits to characters using the table= above.<br> <br> 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.<br> <br> Older software being given the modified v1 address format would mis-send it= to the wrong witness program, however.<br> <br> Alternately we could just keep using version 0 in the address format foreve= r.<br> 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:<br> <br> =C2=A0 =C2=A0 * The data-part values:<br> =C2=A0 =C2=A0 ** 1 byte: legacy witness version, which must always be 0.<br= > =C2=A0 =C2=A0 ** 1 byte: actual witness version, which must be non-zero.<br= > =C2=A0 =C2=A0 ** 1 byte: padding length: 0 or 1.<br> =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.<br> =C2=A0 =C2=A0 ** variable: witness program.<br> <br> A writer for a v1 or later address would initially set an empty padding, th= en compute:<br> <br> =C2=A0 =C2=A0 =C2=A0 1 // actual witness version<br> =C2=A0 =C2=A0 + 1 // padding length<br> =C2=A0 =C2=A0 + 1 // witness length<br> =C2=A0 =C2=A0 + witness_length<br> <br> 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.<br> <br> To a reader that understands only bech32 v0, such an encoding would look li= ke a SegWit v0 invalid-program-length, and be rejected.<br> 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.<br> <br> 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.<br> <br> Regards,<br> ZmnSCPxj<br> _______________________________________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundation.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev</a><br> </blockquote></div></div> _______________________________________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundation.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev</a><br> </blockquote></div> --000000000000be2f110596d5f37c--