From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6A225C0051 for ; Thu, 8 Oct 2020 15:00:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 628DB86CA0 for ; Thu, 8 Oct 2020 15:00:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D265980-5iqM for ; Thu, 8 Oct 2020 15:00:34 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 9702786C45 for ; Thu, 8 Oct 2020 15:00:34 +0000 (UTC) Received: from harding by newmail.dtrt.org with local (Exim 4.92) (envelope-from ) id 1kQXPD-000896-55; Thu, 08 Oct 2020 11:00:31 -0400 Date: Thu, 8 Oct 2020 10:59:38 -0400 From: "David A. Harding" To: Rusty Russell , Bitcoin Protocol Discussion Message-ID: <20201008145938.vrmm33f6sugdc7qm@ganymede> References: <87imblmutl.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oq7mu4itommfwckz" Content-Disposition: inline In-Reply-To: <87imblmutl.fsf@rustcorp.com.au> User-Agent: NeoMutt/20180716 Subject: Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173) 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: Thu, 08 Oct 2020 15:00:35 -0000 --oq7mu4itommfwckz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 08, 2020 at 10:51:10AM +1030, Rusty Russell via bitcoin-dev wro= te: > Hi all, >=20 > I propose an alternative to length restrictions suggested by > Russell in https://github.com/bitcoin/bips/pull/945 : use the > https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb variant, > unless the first byte is 0. >=20 > Here's a summary of each proposal: >=20 > Length restrictions (future segwits must be 10, 13, 16, 20, 23, 26, 29, > 32, 36, or 40 bytes) > 1. Backwards compatible for v1 etc; old code it still works. > 2. Restricts future segwit versions, may require new encoding if we > want a diff length (or waste chainspace if we need to have a padded > version for compat). > =20 > Checksum change based on first byte: > 1. Backwards incompatible for v1 etc; only succeeds 1 in a billion. > 2. Weakens guarantees against typos in first two data-part letters to > 1 in a billion.[1] Excellent summary! > I prefer the second because it forces upgrades, since it breaks so > clearly. And unfortunately we do need to upgrade, because the length > extension bug means it's unwise to accept non-v0 addresses. I don't think the second option forces upgrades. It just creates another opt-in address format that means we'll spend another several years with every wallet having two address buttons, one for a "segwit address" (v0) and one for a "taproot address" (v1). Or maybe three buttons, with the third being a "taproot-in-a-segwit-address" (v1 witness program using the original bech32 encoding). It took a lot of community effort to get widespread support for bech32 addresses. Rather than go through that again, I'd prefer we use the backwards compatible proposal from BIPs PR#945 and, if we want to maximize safety, consensus restrict v1 witness program size, e.g. reject transactions with scriptPubKeys paying v1 witness programs that aren't exactly 32 bytes. Hopefully by the time we want to use segwit v2, most software will have implemented length limits and so we won't need any additional consensus restrictions from then on forward. -Dave --oq7mu4itommfwckz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl9/KVoACgkQ2dtBqWwi adNf5g//epa7QB+fhv7BoSX5HHXIaEhRUKdmCtIz4lkgKsgF+aNdL7EOw2Mcc87x a2PDZzNBUFZh9JXl3Atke3xksTuuylcPqIuqBwOEB7Ebz3A+I8fd2A9JxpONi5yL 9VjEU7NhoyawPca+3vnXHqVXUofLP0zkNJ6O+nIdWVbPohn3HSdOBW3ZqidVorvJ 7UHS1oqQskXl6AkR9+a7zoBbAAtDyZn/NepArBQJzHVs2iKApWrprIOme0AYkOy4 XZ2eRzDeG0dzkEpclC96XitpcAddZV7dcCo8xvBX6DmuXzV6OQSbrZV39B6r83wI /x+e+x7wn6sPTcpsMaB+J6bkzWzgz7mNULmAmDVGt27vg0lIdow5PUPySCvUkliI a0Jn8MCloAHIi3lkFALuvun157ZiQemwAtuNXar5FRAwPqI86bCDyPTRGch/uHy/ dJsT1iW23dR93Zh3RfC5ASsj+UrK5IFZhCtEr1M1ueLXwLn3kSIwm+5S3VmXPnCo BqVGRbG727j58r4nSxXCTMxcTykYVS2bMYcDV/anCEObXt75a4TPEuU89InBKTQE Hquh7rorFUrqu6RE1ysXuYCq5AzTP1WkY4qoePOS6g+kD2cQCozz3J8jnyAguajk PXB+FH4S4mA8NItSrA6g7PybNv/KaW6RZ0mmpgUY+Bli/NKyIio= =lAhw -----END PGP SIGNATURE----- --oq7mu4itommfwckz--