From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4B53DC0733 for ; Wed, 15 Jul 2020 21:05:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 29C9E22264 for ; Wed, 15 Jul 2020 21:05:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FakWz7YoScB for ; Wed, 15 Jul 2020 21:05:35 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) by silver.osuosl.org (Postfix) with ESMTPS id 511672201C for ; Wed, 15 Jul 2020 21:05:35 +0000 (UTC) Received: by mail-wr1-f51.google.com with SMTP id a6so4387029wrm.4 for ; Wed, 15 Jul 2020 14:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uOvXHKvK2e7atAvjmx66cskkx2Islae6HVEDCW+YCTc=; b=TxMD+Q4C883dsmTCly1HuR+kWLLB0CpozX2xUc+OLTIsESPzAk1zF2jTXS9/g9XhyX 0SqsWtm1RIaFi135y40bt9EFt8He8bWcJU/4CVOcd+m93VYTOMnSy6cJdV7G59S1B/6B Ex2LJwd1yf3FF+YSMMowOCZSSNA0QYkbTT0dBClEaX3/dCD+EZVUEdAiTEsqGogyJZ/y oDFQ4YWB8xNvkpIJLc4X2c/DFBGCSkQa0bJfeFtwcoOx03c5xSdfPK5jTMdggvZxLoHP H9Hm/VIszqBnKSVbzYW27HRZ15vknba3dAiQ5adeWls4wZmzOBqDb03NWbpk55tH8FxO h27g== 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:cc; bh=uOvXHKvK2e7atAvjmx66cskkx2Islae6HVEDCW+YCTc=; b=Jp4l8QiemC11qYOSTlzT8l8b0BPzYiH51dB0pgNk65JLREiKvZs5Swis9NFthlaEjw Xuw0UOizrH7TaP99N5RTiPYD4/Fgwjiqaw9nXYUFdtn+OIocs3u+F4z5FbQGO7XxxdJQ W75M37xMrSygiisOV/HTk25aMDCF9lSdjUmeljdEhk1bCxepbENBIz8Axl6qDa3V9R/b PDtd18dccGx4/F1NTiHBUEImFvUk4apH/zi7rfK+mcFQPBWLxITE+/OFM1Mu4EJ1BJeb JnnzIwDu1L6av0kuavU77TnH8ofLfIWDkbP117T4Xn0g3rRNazWoQfPmmdHd7/87+Cit SbdQ== X-Gm-Message-State: AOAM533fm98ru1hnA7rznXlcqww0cA5V0QM42j1diVFn3CF7XfpGMmM8 NI9DzWYbR58m/UyFlSqYqhbIdo2Y6IvXz4+CRq4= X-Google-Smtp-Source: ABdhPJy2wqEzyGoNxUg38fhksmNPOeWm9bodSausJFHtij2aimRGq8TbTUPwyV9s+PxzZEQeQ1FOEkUeRoAAvXKSof0= X-Received: by 2002:adf:e4d0:: with SMTP id v16mr1384146wrm.193.1594847133641; Wed, 15 Jul 2020 14:05:33 -0700 (PDT) MIME-Version: 1.0 References: <20191108021541.n3jk54vucplryrbl@ganymede> <611b4e5b-e7cf-adc7-31e1-b5ff24b6574b@mattcorallo.com> <2sU6YozN9nn30cofkAMhffgjDLZwjG3mvF0nBgOsVQQEY9ROmP72GuHWjnBlF_qa8eeQPU8bxleZqcvRGJgS-uJ2xWYmAm9HjrFWWx_9o8k=@protonmail.com> In-Reply-To: From: Greg Sanders Date: Wed, 15 Jul 2020 17:05:22 -0400 Message-ID: To: "Russell O'Connor" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000df2fdc05aa81484f" Cc: Pieter Wuille Subject: Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 21:05:37 -0000 --000000000000df2fdc05aa81484f Content-Type: text/plain; charset="UTF-8" Can you make it clear what the bold vs not-bold numbers mean? On Wed, Jul 15, 2020 at 4:56 PM Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> That brings me to Matt's point: there is no need to do this right now. We >> can simply amend BIP173 to only permit length 20 and length 32 (and only >> length 20 for v0, if you like; but they're so far apart that permitting >> both shouldn't hurt), for now. Introducing the "new" address format (the >> one using an improved checksum algorithm) only needs to be there in time >> for when a non-32-byte-witness-program would come in sight. >> > > As a prerequisite to taproot activation, I was looking into amending > BIP173 as stated above. However after reviewing > https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb#detection-of-insertion-errors > it seems that insertions of 5 characters or more is "safe" in the sense > that there is low probability of creating a valid checksum by doing so > randomly. > > This means we could safely allow witness programs of lengths *20*, 23, > 26, 29, *32*, 36, and 40 (or 39). These correspond to Bech32 addresses > of length *42*, 47, 52, 57, *62*, 68, and 74 (or 73). We could also > support a set of shorter addresses, but given the lack of entropy in such > short addresses, it is hard to believe that such witness programs could be > used to secure anything. I'm not sure what the motivation for allowing > such short witness programs was, but I'm somewhat inclined to exclude them > from the segwit address format. > > Given that we would only be able to support one of 39 or 40 byte witness > programs, it is sensible to choose to allow 40 byte witness programs to be > addressable. This is the maximum witness program size allowed by BIP 141. > > So my proposal would be to amend BIP173 in such a way to restrict "bc" and > "tb" segwit address formats to require witness programs be of size *20*, > 23, 26, 29, *32*, 36, or 40. Witness programs of other sizes (between 2 > and 40) would, of course, still be legal in accordance with BIP 141; > however they would be unaddressable by using this "bc" and "tb" prefix. > Another address format would be needed to support other witness sizes, > should the need ever arise. > > -- > Russell O'Connor > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000df2fdc05aa81484f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can you make it clear what the bold vs not-bold numbers me= an?

On Wed, Jul 15, 2020 at 4:56 PM Russell O'Connor via bitcoin-dev <= ;bitcoin-dev@lists= .linuxfoundation.org> wrote:
On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille vi= a bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
<= /div>
That brings me to Matt's point: there is no need to= do this right now. We can simply amend BIP173 to only permit length 20 and= length 32 (and only length 20 for v0, if you like; but they're so far = apart that permitting both shouldn't hurt), for now. Introducing the &q= uot;new" address format (the one using an improved checksum algorithm)= only needs to be there in time for when a non-32-byte-witness-program woul= d come in sight.

As a prerequis= ite to taproot activation, I was looking into amending BIP173 as stated abo= ve.=C2=A0 However after reviewing https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb#detecti= on-of-insertion-errors it seems that insertions of 5 characters or more= is "safe" in the sense that there is low probability of creating= a valid checksum by doing so randomly.

This means= we could safely allow witness programs of lengths 20, 23, 26, 29, <= b>32, 36, and 40 (or 39).=C2=A0 These correspond to Bech32 addresses of= length 42, 47, 52, 57, 62, 68, and 74 (or 73).=C2=A0 We coul= d also support a set of shorter addresses, but given the lack of entropy in= such short addresses, it is hard to believe that such witness programs cou= ld be used to secure anything.=C2=A0 I'm not sure what the motivation f= or allowing such short witness programs was, but I'm somewhat inclined = to exclude them from the segwit address format.

Given that we would only be able to support one of 39 or 40 byte witness = programs, it is sensible to choose to allow 40 byte witness programs to be = addressable.=C2=A0 This is the maximum witness program size allowed by BIP = 141.

So my proposal would be to amend BIP173 in su= ch a way to restrict "bc" and "tb" segwit address forma= ts to require witness programs be of size 20, 23, 26, 29, 32,= 36, or 40.=C2=A0 Witness programs of other sizes (between 2 and 40) would,= of course, still be legal in accordance with BIP 141; however they would b= e unaddressable by using this "bc" and "tb" prefix.=C2= =A0 Another address format would be needed to support other witness sizes, = should the need ever arise.

--
= Russell O'Connor
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000df2fdc05aa81484f--