From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id A1DC6C013B for ; Tue, 8 Dec 2020 18:11:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 8B489873EB for ; Tue, 8 Dec 2020 18:11:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWRXMpyX5pPy for ; Tue, 8 Dec 2020 18:11:23 +0000 (UTC) X-Greylist: delayed 00:23:51 by SQLgrey-1.7.6 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by whitealder.osuosl.org (Postfix) with ESMTPS id 2F205873D5 for ; Tue, 8 Dec 2020 18:11:23 +0000 (UTC) Received: by mail-ej1-f49.google.com with SMTP id ga15so25938651ejb.4 for ; Tue, 08 Dec 2020 10:11:23 -0800 (PST) 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=/mLIvsF+2rOsoMwqziOH2BYgtSEbLwg/+bqE4aYYLUY=; b=VX3JxPasxIDKDRu1bCsv0kKphqD6wsiQMeaEctdMUfmdsUGX7KtDseiMOViHi2xqsy Qx8bUUVE7API2A8djJPe5g9jbYyP4XBamuRRJTZTardSUfy4pJqXM8c3I7TNi1EK65u4 OGAJhRaorV4TUT7d6fUTO5KxH0ZdAPjXSw8ru0iTKlF/thqkIx7KnJwMQ0rierqMQYtt 1/mJ8SC5MyOVdYuSLSPRJT2v8dTNlC/m/B3V7UDolg+9lRuoIGFiSr+s4G0A1XgspdiE 3Qm++4VUz15gNj7Hdnzyg9nr0BcUdxEHadtVGyHyDMVoI9air7+gtfYsHwAJrrgW2C3a k1LQ== X-Gm-Message-State: AOAM531wRWwTXghWJrEr8J7KHzOUaLO6bTuEJfBcTPaM7oGuf96ePNB6 2eN837A6SntTnQyfIrVPFqzPJccJfvlLsRAHXb2O+7A3LiaUP/dc X-Google-Smtp-Source: ABdhPJwAyPx41YdYzy2a/bGi1gk6fsV5ojL/W6NQk3P3Lf86Q8Rzn+GKEBwVoa+ZiMF4hoYCKVT/Jic4ZM09gIPpbpY= X-Received: by 2002:adf:e60e:: with SMTP id p14mr25605128wrm.188.1607449189584; Tue, 08 Dec 2020 09:39:49 -0800 (PST) MIME-Version: 1.0 References: <87imblmutl.fsf@rustcorp.com.au> <877drn2g6q.fsf@rustcorp.com.au> <878sc120f5.fsf@rustcorp.com.au> <20201020102952.4iwpugi5dxawufgo@ganymede> <5Zb8Vf0nq7_rg04OTJwVIY565lDZowEfBXX9IBVLIuG7lTa_sIe4BL3YbpBK2NUAZV7QasZTPHVo5J2uJoRgjj3TveBC12QEp9oTdnLis0k=@wuille.net> <20201206130453.tiu36iigva2jj5qn@ganymede> In-Reply-To: <20201206130453.tiu36iigva2jj5qn@ganymede> From: Ryan Grant Date: Tue, 8 Dec 2020 17:39:23 +0000 Message-ID: To: Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" 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: Tue, 08 Dec 2020 18:11:24 -0000 It looks like a good strategy for a bech32 library that is external to Bitcoin Core would be: - Default to the new M, under the same bech32 brand. - Provide an interface to explicitly use both M=1 and M=0x2bc830a3. - If decoding fails, throw an error; but in constructing that error inform whether the other M would have succeeded. - Provide an interface for a BIP173 implementation to peek at the witness version byte of the data part, which may also involve sanity-checking that byte for errors using a BIP173-specific understanding of the appropriate checksum. Return values for this special interface might currently be: "it's version zero, based on a clean decoding", "it's version one, based on a clean decoding", "it's version zero, based on an auto-corrected byte", "it's version one, based on an auto-corrected byte", "no result, due to a decoding error on this byte", and "too many errors to say anything more about decoding". Although the reasoning is clear for doing so, looking into the data that is supposed to be checksummed to determine which checksum to use is not very elegant. There are two trips into a bech32 library for a BIP173 decoding, and an indeterminate result on the version byte would require heuristics for deciding what to do with the rest of the data part to even advise the user on the error. Because of this, as a library writer I would be tempted to auto-correct the witness version byte (against the "SHOULD NOT" advice of BIP173's current version), if it were the only one corrupted, as per the example return values above. Please advise. Some of the libraries that will be contemplating these steps include: https://github.com/topics/bech32?o=desc&s=stars Here are three existing uses of bech32 that are external to Bitcoin Core: https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md https://github.com/btcontract/lnurl-rfc https://github.com/bitcoin/bips/blob/master/bip-0136.mediawiki Of the above, I think BIP136 can be unconditionally moved to M=0x2bc830a3 due to having little legacy burden.