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.


On Tue, Jan 31, 2023 at 6:33 PM David A. Harding <d...@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.**"
bitcoin-dev mailing list

Reply via email to