David,

I'm merely speaking in a descriptive sense. I predict that most custodians
are reluctant to whitelist
a witness version they know is insecure.

I'm not sure what's best for not colliding with future versions, I'll let
other wiser folks weigh in.

Cheers,
Greg

On Tue, Jan 31, 2023 at 6:33 PM David A. Harding <dave@dtrt.org> wrote:

> On 2023-01-31 04:30, Greg Sanders wrote:
> > Hi David,
> >
> > From practical experience, I think you'll find that most exchanges
> > will not enable sends to future segwit versions,
> > as from a risk perspective it's likely a mistake to send funds there.
>
> Hi Greg!,
>
> I thought the best practice[1] was that wallets would spend to the
> output indicated by any valid bech32m address.  You seem to implying
> that the best practice is the opposite: that wallets should only send to
> outputs they know can be secured (i.e., which are not currently
> anyone-can-spend).  The more restrictive approach seems kind of sad to
> me since any problem which can result in a user accidentally withdrawing
> to a future segwit version could even more easily result in them
> withdrawing to a witness program for which there is no solution (i.e.,
> no key or script is known to spend).
>
> If it is a best practice, then I think there's a benefit to being able
> to test it even when other people's proprietary software is involved.  A
> wallet or service likely to follow that best practice may be more likely
> to follow other best practices which cannot be as easily tested for.
> But, if it's going to be tested, I want the testing to use the address
> least likely to cause problems for protocol developers in the future.
> Do you (and others on this list) have any reason to believe OP_16
> OP_PUSH2 0000 would be a problematic script, or can you think of a
> better script?
>
> Thanks!,
>
> -Dave
>
> [1] BIP350, emphasis in original: "[...] we emphatically recommend [...]
> ensuring that your implementation supports sending to v1 **and higher
> versions.**"
>