Date: Sun, 06 Dec 2020 20:43:49 +0000
To: "David A. Harding" <dave@dtrt.org>
From: Pieter Wuille <bitcoin-dev@wuille.net>
Reply-To: Pieter Wuille <bitcoin-dev@wuille.net>
Message-ID: <vLjiyu9VKGMXcCP2wNvFG1OuYl0IBHm5DQd1WncpKgaxJFZrwdD5JKvRfT5m9Cyrf4YPvmTPbHdREZmS-msdTBlf2RMwlr2mEgZ9TFYaVRg=@wuille.net>
In-Reply-To: <20201206130453.tiu36iigva2jj5qn@ganymede>
References: <87imblmutl.fsf@rustcorp.com.au>
 <S6FCoLsmwaQUhrtSURemcTcG8tUWTXYkBf-0Q0hxCpObfJQ0TXNcmJrQhoqy7ttWwtGnvyS-bJ5RSXJoPizAgjuMognzVnu3SM3wMujKy88=@wuille.net>
 <878sc120f5.fsf@rustcorp.com.au> <20201020102952.4iwpugi5dxawufgo@ganymede>
 <Kw_jwhASjriebJpsuUyi0u9EQmIVR1pQ3Jocqd9VeVDlmoH9s36bFAwr3PXu_pJd-Xly-hKun_yenLwbJvVIYWmlAiF5lMxuquLO2pTmlLo=@wuille.net>
 <CAMeZzJeG00q9DPQacidto5H16Ryb6ou6tnMDK1jnAuncnVXnsA@mail.gmail.com>
 <CAMeZzJdQuS1-0qPvY+0-yqRfVXgZV_2hmHB5hZwykm5WxjUkgg@mail.gmail.com>
 <5Zb8Vf0nq7_rg04OTJwVIY565lDZowEfBXX9IBVLIuG7lTa_sIe4BL3YbpBK2NUAZV7QasZTPHVo5J2uJoRgjj3TveBC12QEp9oTdnLis0k=@wuille.net>
 <20201206130453.tiu36iigva2jj5qn@ganymede>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions
	(BIP-173)
Precedence: list


=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 <dave@dtrt.org> 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