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 EAA46C0051 for ; Thu, 8 Oct 2020 00:21:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id C98ED203D2 for ; Thu, 8 Oct 2020 00:21:22 +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 fMlTE4IeZ-9I for ; Thu, 8 Oct 2020 00:21:21 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from ozlabs.org (ozlabs.org [203.11.71.1]) by silver.osuosl.org (Postfix) with ESMTPS id DF575203AA for ; Thu, 8 Oct 2020 00:21:20 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 4C6BhG0TRSz9sTR; Thu, 8 Oct 2020 11:21:17 +1100 (AEDT) From: Rusty Russell To: Bitcoin Protocol Discussion Date: Thu, 08 Oct 2020 10:51:10 +1030 Message-ID: <87imblmutl.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain Subject: [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 00:21:23 -0000 Hi all, 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. Here's a summary of each proposal: 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). 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] 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. (Note non-v0 segwit didn't relay before v0.19.0 anyway, so many places may already be restricting to v0 segwit). The sooner a decision is reached on this, the sooner we can begin upgrading software for a taproot world. Thanks, Rusty. PS. Lightning uses bech32 over longer lengths, but the checksum is less critical; we'd prefer to follow whatever bitcoin chooses. [1] Technically less for non-v0: you have a 1 in 8 chance of a typo in the second letter changing the checksum algorithm, so it's 1 in 8 billion.