As suggested in #24106#issue-1108820339, this PR changes DecodeDestination to consider bech32m (segwit v1) addresses as invalid if the encoded x-only pubkey is not on the curve.
This prevents users from inadvertently burning funds.
This PR must not change policy or consensus rules and keep the current approach, where the user cannot send funds to invalid addresses.
NACK. While this doesn't change policy, practically this is no different than #24106 for batch withdrawals. With #24106 the batch withdrawal will be rejected by the network, or by the local mempool (if it is running #24106). With this pull the batch withdrawal will be rejected by the wallet.
This is a problem that needs to be solved when creating the address (or at least before handing it out).
With this pull the batch withdrawal will be rejected by the wallet.
This already happens for invalid addresses. DecodeDestination() returns CNoDestination for any invalid addresses.
This PR just adds one more validation.
@w0xlt Which addresses are valid should be well-specified and consistent across the network. Yes, some addresses are invalid - obviously - and those are well-specified I think in BIP173 and BIP350. That set can certainly change, and may need to be changed from time to time, but it's not something we can unilaterally change in the Bitcoin Core software without discussions across the ecosystem. Doing so will cause stuck payments (less so than if it's done as a relay policy, but still any infrastructure depending on Bitcoin Core will see things change from under them).
Concept NACK on doing anything more than a warning, unless first preceded by a wide discussion about this.
Treat bech32m (segwit v1) addresses as invalid if the encoded x-only
pubkey is not on the curve.
This prevents users from inadvertently burning funds.
This commit must not change policy or consensus rules.
(It might make sense to treat these as OP_RETURNs and not store the UTXOs? But not sure it's worth the additional code/complexity...)
Can this be closed?