From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id E3211C013B for ; Sun, 6 Dec 2020 20:44:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id C2B7E87322 for ; Sun, 6 Dec 2020 20:44:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfVoURIR8Oue for ; Sun, 6 Dec 2020 20:44:03 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) by hemlock.osuosl.org (Postfix) with ESMTPS id C79A387315 for ; Sun, 6 Dec 2020 20:44:02 +0000 (UTC) Date: Sun, 06 Dec 2020 20:43:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net; s=protonmail2; t=1607287439; bh=pa5XpcmXre6YdNiIlWlq9gHEl7M7a+IHBGX2pPURM2E=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=LD7ASrCQsg8gsS6AjQ4PjvT+IYYl0jlVeNzZEtUX1eVdAmlagJFZh9f+tPBXTGLqG Hcf/bjbi4rFj65j85H5X4uUX4O3SeHMVCmNjdaPRERyRzdYzdNQgNdFWVto7/AKLAr 1vQCJdg9sYHnPPw+Pdm3jfcYjxboJ98GwqcOiWHluRqtGCg1qBz12Hl2nUjPIMNehW DcGLsAWWln+vnweCdiaPqLmDvwzY3+qc5BjXywLhEyji5LnzL5W4gVpjErEtXAeOxo XwUNJoevFuXhRIVMpFLk6NcAO6WZCA6itpui29V4ZmExZE09Ci1oeJlASyOZsDDwXg AFJdwfd9UhmuA== To: "David A. Harding" From: Pieter Wuille Reply-To: Pieter Wuille Message-ID: In-Reply-To: <20201206130453.tiu36iigva2jj5qn@ganymede> References: <87imblmutl.fsf@rustcorp.com.au> <878sc120f5.fsf@rustcorp.com.au> <20201020102952.4iwpugi5dxawufgo@ganymede> <5Zb8Vf0nq7_rg04OTJwVIY565lDZowEfBXX9IBVLIuG7lTa_sIe4BL3YbpBK2NUAZV7QasZTPHVo5J2uJoRgjj3TveBC12QEp9oTdnLis0k=@wuille.net> <20201206130453.tiu36iigva2jj5qn@ganymede> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 06 Dec 2020 20:49:25 +0000 Cc: Bitcoin Protocol Discussion 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: Sun, 06 Dec 2020 20:44:05 -0000 =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Sunday, December 6, 2020 5:04 AM, David A. Harding wrote= : > On Sat, Dec 05, 2020 at 11:10:51PM +0000, Pieter Wuille via bitcoin-dev w= rote: > > > I think these results really show there is no reason to try to > > maintain the old-software-can-send-to-future-segwit-versions property, > > given that more than one not just didn't support it, but actually sent > > coins into a black hole. > > I don't think this is a good criteria to use for making a decision. We > shouldn't deny users of working implementations the benefit of a feature > because some other developers didn't implement it correctly. > > > Thus, I agree with Rusty that we should change the checksum for v1+ > > unconditionally. > > I disagreed with Rusty previously and he proposed we check to see how > disruptive an address format change would be by seeing how many wallets > already provide forward compatibility and how many would need to be > updated for taproot no matter what address format is used. I think that > instead is a good criteria for making a decision. > > I understand the results of that survey to be that only two wallets > correctly handled v1+ BIP173 addresses. One of those wallets is Bitcoin > Core, which I personally believe will unhesitatingly update to a new > address format that's technically sound and which has widespread support > (doubly so if it's just a tweak to an already-implemented checksum > algorithm). Hi Dave, You're right to point out there is nuance I skipped over. Let's look at the behavior of different classes of software/services that e= xist today when trying to send to v1+ addresses: (A) Supports sending to v1+ today * Old proposal: works, but subject to bech32 insertion issue * New proposal: fails (B) Fails to send to v1+ today * Old proposal: fails * New proposal: fails (C) Incorrectly sends to v1+ today * Old proposal: lost funds * New proposal: fails So the question is how the support for sending to v1+ in (a) software weigh= s up against protecting both (a) from the insertion issue, and (c) from los= t funds. I do think (c) matters in this equation - people may choose to avo= id adopting v1+ witnesses if it were to be known that some senders out ther= e would misdirect funds. But the fact that (a) is small also means there is= very little to gain from the old proposal. So perhaps I should have formulated it as: the small number of v1+ compatib= le senders today (regardless of the reasons for that) shows how futile the = attempt to have one address type for all witness versions was, and the fact= that there are even some who misdirect(ed) funds is the final nail in the = coffin. Changing the checksum unconditionally gives us a new attempt at tha= t. > Given that, I also now agree with changing the checksum for v1+. Great. Cheers, -- Pieter