Date: Sun, 6 Dec 2020 08:04:53 -0500
From: "David A. Harding" <dave@dtrt.org>
To: Pieter Wuille <bitcoin-dev@wuille.net>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20201206130453.tiu36iigva2jj5qn@ganymede>
References: <87imblmutl.fsf@rustcorp.com.au>
 <sYf9B0e3UaSdMfdBfChon1Vr7BRFdH_6mgzuXIt_xbtlKtdqns9JJp90dRlNfvwBoRq57YEVrKbKX-dHDWz7TE0gobU4u8dGGJTcFFz2n60=@wuille.net>
 <877drn2g6q.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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="it34k6sdqawybbt7"
Content-Disposition: inline
In-Reply-To: <5Zb8Vf0nq7_rg04OTJwVIY565lDZowEfBXX9IBVLIuG7lTa_sIe4BL3YbpBK2NUAZV7QasZTPHVo5J2uJoRgjj3TveBC12QEp9oTdnLis0k=@wuille.net>
User-Agent: NeoMutt/20180716
Subject: Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions
 (BIP-173)
Precedence: list


--it34k6sdqawybbt7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 05, 2020 at 11:10:51PM +0000, Pieter Wuille via bitcoin-dev wro=
te:
> 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.=20

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).

Given that, I also now agree with changing the checksum for v1+.

Thanks,

-Dave


--it34k6sdqawybbt7
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl/M1vUACgkQ2dtBqWwi
adPY4RAAl7YxwzEIc7RnXR0p0CSuQjbUT95FsD1M02Qpq6k7hfjts1dCRCPsx63C
VMHgYHAsKhylJPzHTRNITNAOLxyjwUVZ/WMdTAyeOfGerrx1YGyLEBjVFPpzW+Wa
O70aoYtPCJwkGHRVudON/rbDiQGuSa9x7LZ0hBYvt/cXhJC3V15lky7DC0CyKlS8
KOCmWvvskCQ4CpUsgjkIWrEchtAbjXL3winw0FwQy9deRSzd4akE0bLtR5aYMrdh
08tjcFeQZM707GFRwkzG4xRaGEBY9hqHg/IeCUlTTuap3RLZaY9elzPbAfFu3qja
aY+2v7bVc2lbFvP5regPLV24JOv7K708+EihUwrpOfBcLkT/8SivJCFtnW9wOY/J
3jLcqW+aW3Z1cHCSmKzKokMNb+Ew6Lxo+MIQ+cPnyFq9zADN5eCuxs0cY0dnGg+V
MaSi14T0JNkWZU2Hms4vXVVooH0WCvKKo65Er1PuG/q5s3drgZszxbsc6FnpoWsI
etZ3RXNaUfAqeLODm+7cYxecVXRCf7ujNoZz08X+GKpy/HYcTfcc6PGWg/3IMUe/
Z9DM3HxbUngSEKKVNGVTGhVyyfmXCDNXuEKPrl9eK4KrvqFLsphy+AwFl9m0vYAu
b77N7DCC4kusOP9FXYm0EgaXZbnYALJDfnnEbJkVXS6Nj2xFfr4=
=8ZHo
-----END PGP SIGNATURE-----

--it34k6sdqawybbt7--