From: Pieter Wuille <bitcoin-dev@wuille•net>
To: "David A. Harding" <dave@dtrt•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)
Date: Sun, 06 Dec 2020 20:43:49 +0000 [thread overview]
Message-ID: <vLjiyu9VKGMXcCP2wNvFG1OuYl0IBHm5DQd1WncpKgaxJFZrwdD5JKvRfT5m9Cyrf4YPvmTPbHdREZmS-msdTBlf2RMwlr2mEgZ9TFYaVRg=@wuille.net> (raw)
In-Reply-To: <20201206130453.tiu36iigva2jj5qn@ganymede>
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
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 wrote:
>
> > 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 exist 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 weighs up against protecting both (a) from the insertion issue, and (c) from lost funds. I do think (c) matters in this equation - people may choose to avoid adopting v1+ witnesses if it were to be known that some senders out there 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+ compatible 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 that.
> Given that, I also now agree with changing the checksum for v1+.
Great.
Cheers,
--
Pieter
next prev parent reply other threads:[~2020-12-06 20:44 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-08 0:21 Rusty Russell
2020-10-08 14:59 ` David A. Harding
2020-10-08 15:21 ` Russell O'Connor
2020-10-15 1:40 ` Rusty Russell
2020-10-16 21:09 ` Pieter Wuille
2020-10-19 0:49 ` Rusty Russell
2020-10-19 22:55 ` Pieter Wuille
2020-10-20 0:42 ` Rusty Russell
2020-10-20 3:31 ` Rusty Russell
2020-10-20 9:21 ` Riccardo Casatta
2020-10-20 10:29 ` David A. Harding
2020-10-20 20:12 ` Pieter Wuille
2020-10-20 23:52 ` Mike Schmidt
2020-10-21 4:51 ` Rusty Russell
2020-11-06 19:49 ` Mike Schmidt
2020-12-05 23:10 ` Pieter Wuille
2020-12-06 13:04 ` David A. Harding
2020-12-06 20:43 ` Pieter Wuille [this message]
2020-12-08 17:39 ` Ryan Grant
2020-12-18 2:02 ` Pieter Wuille
2020-10-21 3:05 ` ZmnSCPxj
2020-10-21 4:39 ` Rusty Russell
2020-10-28 0:20 ` Pieter Wuille
2020-12-05 22:59 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='vLjiyu9VKGMXcCP2wNvFG1OuYl0IBHm5DQd1WncpKgaxJFZrwdD5JKvRfT5m9Cyrf4YPvmTPbHdREZmS-msdTBlf2RMwlr2mEgZ9TFYaVRg=@wuille.net' \
--to=bitcoin-dev@wuille$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dave@dtrt$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox