David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2020-12-06 📝 Original message:On Sat, Dec 05, 2020 at ...
📅 Original date posted:2020-12-06
📝 Original message: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).
Given that, I also now agree with changing the checksum for v1+.
Thanks,
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201206/415223da/attachment.sig>;
📝 Original message: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).
Given that, I also now agree with changing the checksum for v1+.
Thanks,
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201206/415223da/attachment.sig>;